W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

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

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 30 Jan 2009 20:06:14 +1100
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-Id: <6C5E6CD1-4716-4B4B-8468-77DA9514B314@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

Putting this text in, I'm inclined to omit the enc2231-string from  
link-extension, because I think extensions should call it out  
explicitly, rather than blanket applying it to all extensions.

Cheers and many thanks,


On 11/12/2008, at 4:13 AM, Julian Reschke wrote:

> 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
>


--
Mark Nottingham     http://www.mnot.net/
Received on Friday, 30 January 2009 09:06:55 GMT

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