Subject: Re: link relationship registration

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 02 Jan 2009 07:50:47 +0100

On Wed, 10 Dec 2008 12:50:09 +0100, Phil Archer <[email-masked]> wrote:

> Case sensitivity is an issue. Hmmm... can 04 say that tokens given as  
> rel types SHOULD be lower case and that UAs SHOULD treat such tokens as  
> case insensitive? Would that put too much of a strain on saying that  
> tokens are treated as relative URIs? (I know that paths are case  
> sensitive).

Is perhaps RFC 4287's definition of atom:id a good starting place for defining how this token should be created, matched, etc.?

  <http://www.atompub.org/rfc4287.html#element.id>

> There shouldn't be any need for UAs to resolve tokens given as values  
> for @rel as absolute URIs and no one's suggesting that UAs should  
> actually make an HTTP request of any kind to iana.org every time there's  
> a link to a stylesheet. It's the person minting the new relationship  
> type that needs to check. What it means is that if you create a link  
> (HTML or HTTP) and use a @rel type 'foo' that gives a 404 from  
> http://www.iana.org/assignments/relation/foo then you really shouldn't  
> expect UAs to do anything sensible with it.

I think this is basically the same old "should a URI be resolvable" discussion we've been having for years, especially wrt XML namespaces and as mentioned; the atom:id element.

> Whether a UA chooses to actually implement support for a registered @rel  
> type remains very much up to the UA developer of course.

Entirely up to, imho.

-- 
Asbjørn Ulsberg         -=|=-          [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 30 Jan 2009 20:06:14 +1100

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/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Jan 2009 10:20:40 +0100

> explicitly, rather than blanket applying it to all extensions.

Agreed.

BR, Julian