Re: Link: relation registry and 303

Jonathan Rees wrote:
> (This message reports on TAG ACTION-184: contact Lisa D of IESG, cc
> www-tag, to explain about 303, with cool URIs and webarch as
> references, due 2009-01-29.)
>
> Mark Nottingham has prepared a draft [1] on the HTTP Link: header, an
> HTTP 1.1 extension for communicating links between resources.  One
> application, among others, is 'resource descriptor discovery', the
> subject of my recent memo [2] and Eran Hammer-Lahav's draft [3].
> Link: and RDD are different and shouldn't be confused. My particular
> interest is in RDD, which as proposed relies on Link:, so that makes
> Link: interesting.
>
> Link: headers refer to relations using URI-references.  Because
> relations (we presume) are not "information resources", the
> httpRange-14 rule says servers shouldn't respond with a 200 when the
> URI denotes a relation.  In particular, if the URI-reference is
> relative (e.g. 'describedby'), the relation URI, in this case
> http://www.iana.org/assignments/relation/describedby, should not yield
> a 200.
>
> The question is how to bring about such 200-eschewing (or
> 303-embracing) at www.iana.org - who should contact IANA about
> 303, and how the request should
> be posed.  IANA has a relationship with IETF, but not with the TAG.  I
> contacted Lisa Dusseault, Applications Area Director for the IETF, and
> Mark Nottingham, Link: RFC editor and HTTPbis chair, for advice.
>
> I did not succeed in persuading Mark or Lisa to take on the cause.
>
> Note: In talking with them, rather than use the term "information
> resource", which is not an IETF kind of term and might have been
> confusing, I used "network data object or service" which here I'll
> abbreviate NDOOS.  NDOOS is the phrase used in RFC 2616 (it's the
> definition of "resource").  NDOOS and IR are different, but not in any
> way that bears on this issue.
>
> One argument I advanced was that used for the httpRange-14 resolution:
> A 2xx response could lead to someone wrongly thinking that the URI
> identified an NDOOS.
>
> Lisa and Mark's responses will all be familiar to anyone who's been
> following this permathread. (There's a FAQ somewhere, isn't there?)
> Paraphrasing:
>
> 1. Anyone doing HTTP GETs is going to have to deal with 2xx for things
> that are not NDOOSes, since this happens in so many cases, e.g. XML
> namespaces.  To attempt to put this kind of semantics into 2xx is a
> lost cause.
>
> 2. Why can't a single string identify a relation for some purposes and
> a document for others?
>
> 3. Who says a relation can't be a NDOOS?  What you get back from the
> 200 is a representation of the relation, right?
>
> 4. What practical effect could this possibly have?  What benefit would
> there be to anybody besides HTTP/URI architects?
>
> 5. It's not the business of HTTP to convey semantics such as
> information about what a URI denotes.  HTTP is only about access.
>
> 6. Isn't 303 used for a lot of things other than avoiding 200s?  How
> does 303 help if it's so unspecific?
>
> 7. Not interested in the debate.
>   
A good summary of the 303-debates.
> all of which I answered as best I could citing RFC 3986 and so on, but
> not well enough to win any converts.
>
> I attempted a second assault using the principle of standards
> conformance.  RFC 2616 section 9.3 can't (in my view) be read as
> permitting information *about* a relation in place of the relation
> itself (which would be nonsense) or data produced by the relation
> (also nonsense).  Thus 2xx for a relation is off-label.  Off-label use
> of a protocol may be overlooked for some random web site, but we're  
> talking
> about the keepers of the standards here, so set a good example and
> don't do it.
>   
Anything, including information resource, is a relation because we know 
things and describe them by how they are related to others but not 
because how "the thing" is "the thing".  This is, in fact, how we do it 
in RDF(or DL) right?  Thus, by extension, if a relation cannot 303, then 
any resource that can return RDF must be 303 unless the RDF says: "X is 
X", which in principle is still a relation.  Then, even if an HTML /XML 
document, since it can be GRDDLed to RDF, it must 303.  Then, what is 
left for 200? Not much, if any.

Xiaoshu
> Response from Mark:
>
> "I think you're reading *way* too much into this text...  2616 is
> flawed, as all documents are, and it should be read in the context of
> how it was produced.  If you're doing networked access of HTTP
> resources, it should be followed carefully... If you're doing other
> things, it has much less relevance."
>
> The obvious next step is to contact IANA saying the request comes from
> the W3C TAG, and see what they say.  (They may just turn around and
> ask Lisa or Mark what this is about, and they will give their
> opinions, as above.)  My assessment is that the chances of getting
> 303s are slim - I hear IANA has not always been very responsive to
> even much more conventional requests from IETF. But at worst they'll
> say no.
>
> An alternative to asking for 303s is to ask for 404s.  As IANA need do
> nothing in order to bring this about, this becomes more a question for
> Mark and the Link: header RFC.  I know 404 isn't ideal but at least it
> is consistent with the httpRange-14 rule.  A parallel set of URIs
> (different base URI, perhaps) could name the descriptions of the
> relations; such URIs would also be needed for 303 redirects.  Make
> these document URIs be well known, perhaps in the Link: RFC, and at
> least part of the problem is solved.
>
> If the request(s) to IANA fails, or even if it succeeds, it might help
> if the httpRange-14 rule got a little more clout by being taken up
> either in a W3C recommendation (webarch volume 2??) or in an RFC.  I
> am considering dipping into the active HTTPbis effort, and can
> think of a couple of different ways to clarify the situation there.
>
> I'm happy to continue to represent the TAG here, even though my own
> approach (not relevant here) might be slightly different and as a  
> result I
> might not be 100% evangelical.  I'll seek direction on a future
> telecon.
>
> -Jonathan
>
> [1] http://tools.ietf.org/html/draft-nottingham-http-link-header-03
> [2] http://www.w3.org/2001/tag/doc/more-uniform-access.html
> [3] http://tools.ietf.org/html/draft-hammer-discovery-00
>
>
>

Received on Wednesday, 28 January 2009 21:52:41 UTC