Subject: FYI: Link -04

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Feb 2009 17:16:36 +1100

See:
   http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-04.txt

Diffs at:
   http://tinyurl.com/clewkp

Changelog:
    o  Defined context as a resource, rather than a representation.
    o  Removed concept of link directionality; relegated to a deprecated
       Link header extension.
    o  Relation types split into registered (non-URI) and extension
       (URI).
    o  Changed wording around finding URIs for registered relation  
types.
    o  Changed target and context URIs to IRIs (but not extension
       relation types).
    o  Add RFC2231 encoding for title parameter, explicit BNF for  
title*.
    o  Add i18n considerations.
    o  Specify how to compare relation types.
    o  Changed registration procedure to Designated Expert.
    o  Softened language around presence of relations in the registry.
    o  Added describedby relation.
    o  Re-added 'anchor' parameter, along with security consideration  
for
       third-party anchors.
    o  Softened language around HTML4 attributes that aren't directly
       accommodated.
    o  Various tweaks to abstract, introduction and examples.

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Feb 2009 15:45:15 +0100

Mark Nottingham wrote:
> ...

Thanks, Mark. We're almost there, it seems.

A few comments:

Section 4.2:

"An extension relation type is a URI [RFC3986] that, when dereferenced, 
SHOULD yield a document describing that relation type."

It seems to me that "SHOULD" is way too strong here:

1) As that document is not required in any way to process the link 
relation, not providing it won't affect interoperability at all.

2) It also seems to invite dereferencing, which I expect many will oppose.

Proposal: rephrase this in a way similar to RFC 3648, Section 5.1:

"For collections that are ordered, the client SHOULD identify the 
semantics of the ordering with a URI in the Ordering-Type header, ... 
Setting the value to a URI that identifies the ordering semantics 
provides the information a human user or software package needs to 
insert new collection members into the ordering intelligently. Although 
the URI in the Ordering-Type header MAY point to a resource that 
contains a definition of the semantics of the ordering, clients SHOULD 
NOT access that resource to avoid overburdening its server. ..." -- 
<http://greenbytes.de/tech/webdav/rfc3648.html#rfc.section.5.1>

Section 5:

   link-value        = "<" URI-Reference ">" *( ";" link-param ) )

Syntax error (duplicate ")"), replace with:

   link-value        = "<" URI-Reference ">" *( ";" link-param )

Also:

   enc2231-string    = <extended-value, see <xref target="RFC2231"/>,
                       Section 7>

Syntax error (you have an escaped xref element in the artwork), replace 
with:

   enc2231-string    = <extended-value, see [RFC2231], Section 7>

(note prose values can't extend over multiple lines, btw)

Section 5:

"indicates that chapter2 is previous to this resource in a logical 
navigation path."

For readability, I'd put chapter2 into quotes here.

Section 5 -- Examples:

I think the example in Section 5 should be moved into a subsection, and 
we also should have an additional example showing the use of (1) 
multiple link values in one header, and (2) use of title*.

6.2 -- Nits:

"...[RFC2026], section 7)"

s/section/Section/

Best regards, Julian

---

From: "Robert Brewer" <[email-masked]>
Date: Thu, 26 Feb 2009 09:13:15 -0800

> <http://greenbytes.de/tech/webdav/rfc3648.html#rfc.section.5.1>

Might be nice to have a common, compact syntax someday to set apart such
links.

"Thou shalt not dereference the Link thy Constant in vain; for the Link
will not hold him guiltless that dereferenceth him in vain."

Robert Brewer
[email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Feb 2009 09:17:38 +1100

Ah, you've rumbled my secret plan for a link relation caching startup;  
ah well, there's still DTDs, XML Namespaces and the like out there.

I'll have a think about this; I agree that SHOULD is too strong, but  
it would be nice to allow the semweb people to do what they need to if  
they really want to. At the moment, I'm thinking about making the  
entire thing non-normative; i.e., shoulds instead of SHOULD. I'll try  
to float some proposed text in a little while.s

On 27/02/2009, at 1:45 AM, Julian Reschke wrote:
>
> Section 4.2:
>
> "An extension relation type is a URI [RFC3986] that, when  
> dereferenced, SHOULD yield a document describing that relation type."
>
> semantics of the ordering with a URI in the Ordering-Type  
> header, ... Setting the value to a URI that identifies the ordering  
> semantics provides the information a human user or software package  
> needs to insert new collection members into the ordering  
> intelligently. Although the URI in the Ordering-Type header MAY  
> point to a resource that contains a definition of the semantics of  
> the ordering, clients SHOULD NOT access that resource to avoid  
> overburdening its server. ..." -- <http://greenbytes.de/tech/webdav/rfc3648.html#rfc.section.5.1 
> >

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Feb 2009 10:55:31 +0100

Mark Nottingham wrote:
> I'll have a think about this; I agree that SHOULD is too strong, but it 
> would be nice to allow the semweb people to do what they need to if they 
> really want to. At the moment, I'm thinking about making the entire 
> thing non-normative; i.e., shoulds instead of SHOULD. I'll try to float 
> some proposed text in a little while.s

...but my understanding was that at least *some* of the semweb community 
want link relations NOT to be "information" resources, thus expect a 
303, not 200 (*). I think avoiding this discussion would be good.

BR, Julian

PS: I wouldn't worry about that until the W3C manages to respond with 
303 for XML namespace URIs... :-)

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Feb 2009 18:08:27 +0100

Hi,

I just noticed that 
<http://tools.ietf.org/html/draft-nottingham-http-link-header-04#section-6.2> 
registers a few values where the reference points to IANA registry 
itself, such as for "payment".

That would be circular, wouldn't it?

BR, Julian