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.orgReceived on Thursday, 26 February 2009 17:13:53 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:35 GMT