Subject: [lemonade] Comments on draft-cridland-urlfetch-binary-01.txt

From: Alexey Melnikov <[email-masked]>
Date: Sat, 09 Feb 2008 18:49:51 +0000

> 4.  Example Exchanges

[...]

>   Note that the data here does not contain a NUL octet, therefore a
>   literla - not literal8 - syntax has been used.

typo: literal

> 5.  Formal Syntax

[...]

> urldata-ext      =  SP url-full [url-metadata] SP (nstring / literal8)
>    ; Note that content is always returned.
>    ; If the content contains a NUL octet, the server MUST use literal8.
>    ; Otherwise, the server SHOULD use nstring syntax.
>
I think the extension need to be changed to allow returning only 
BODYPARTSTRUCTURE without returning the body part itself, as we have no 
idea how URLAUTH URLs might be used in the future.
If a client issuing URLFETCH discovers that it doesn't like 
BODYPARTSTRUCTURE for some reason, it would either have to download and 
ignore the whole body part, or it would have to kill the connection. So 
I think this is a bad design choice.

[...]

> urldata-ext      =  SP url-full [url-metadata] SP (nstring / literal8)
>    ; Note that content is always returned.
>    ; If the content contains a NUL octet, the server MUST use literal8.
>    ; Otherwise, the server SHOULD use nstring syntax.
>
> url-metadata     =  1*(SP "(" url-metadata-el ")")
>
> url-metadata-el  =  "BODYPARTSTRUCTURE" SP body / "BINARY"

None of the examples in section 4 contain "BINARY" marker in extended 
URLFETCH responses.
The marker is needed, as otherwise a client receiving URFETCH response 
can't reliably tell if returned data is binary, but doesn't contain 
NULs, or if it is base64 encoded. So I think examples need to be fixed.

_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade