W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

Re: Feedback on draft-nottingham-http-link-header-03, was: Fwd: New Version Notification for draft-nottingham-http-link-header-03

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 10 Dec 2008 18:13:18 +0100
Message-ID: <493FF8AE.7020006@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>

Julian Reschke wrote:
> Mark Nottingham wrote:
>> ...
>>> It's good for telling people where to go when they need it. It may 
>>> not be sufficient for ensuring that recipients actually implement it.
>>
>> Yes, I had that feeling too, but failed to find a good way to express 
>> requirements.
>>
>>> Also note that RFC 2231 encoding affects the grammar.
>>
>> What's standard practice -- to explicitly call out the * form in the 
>> ABNF?
> 
> There is no good standard practice, and this is why interoperability 
> sucks for Content-Disposition.
> 
> The precise way to do it to make it explicit in the ABNF. Such as:
> 
> ( "title" "=" quoted-string ) | ( "title*" "=" enc2231-string )
> 
> where
> 
> enc2231-string = <extended-value, see RFC 2231, Section 7>

Actually, we probably should state that for all extension parameters:

     enc2231-string = <extended-initial-value, see RFC 2231, Section 7>

     link-param     = ( "rel" "=" relation-type )
                    | ( "rev" "=" relation-type )
                    | ( "type" "=" type-name )
                    | ( "title" "=" quoted-string ) |
                      ( "title*" "=" enc2231-string
                    | ( link-extension )

     link-extension = ( token [ "=" ( token | quoted-string ) ]
                    | token "*" [ "=" enc2231-string ]

...and then state in prose what to do when both token= and token*= are 
used (either disallow it, or make "*=" override "=" so that the simple 
notation can be used as a fallback for recipients that do not understand 
RFC 2231).

>>> That being said, I already volunteered to profile and clarify RFC 
>>> 2231 for use in HTTP, but I'm not there yet 
>>> (<http://greenbytes.de/tech/webdav/draft-reschke-rfc2231-in-http-latest.html>). 
>>>
>>>
>>> If we can reach agreement that it's sufficient to support only some 
>>> parts of RFC 2231 (no continuations, no charsets other than ISO8859-1 
>>> and UTF-8), I can try to condense that statement into a very short 
>>> paragraph.
>>
>>
>> Please do.
> 
> Will do.

"When using the enc2231-string syntax, producers MUST NOT use a charset 
value other than 'ISO-8859-1' or 'UTF-8'. Therefore, these two character 
sets are the only values a recipient needs to implement."

We may also want to add an example, such as

   title*=UTF-8''a%20Umlaut%20%c3%a4

for a title of "a umlaut ".

BR, Julian
Received on Wednesday, 10 December 2008 17:14:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:58 GMT