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

RE: comments on draft-nottingham-http-link-header-04

From: Robert Brewer <fumanchu@aminus.org>
Date: Thu, 26 Feb 2009 09:13:15 -0800
Message-ID: <F1962646D3B64642B7C9A06068EE1E640750D654@ex10.hostedexchange.local>
To: "Julian Reschke" <julian.reschke@gmx.de>, "Mark Nottingham" <mnot@mnot.net>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Julian Reschke wrote:
> Mark Nottingham wrote:
> > See:
> >
> > http://www.ietf.org/internet-drafts/draft-nottingham-http-link-
> header-04.txt
> > ...
> 
> 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>

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
fumanchu@aminus.org
Received on Thursday, 26 February 2009 17:13:53 GMT

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