RE: Link: relation registry and 303

Jonathan,

Very nice summary of the usual objections!

I do *not* think 404s would be preferable to 200s.  At least with a 200 you get *something* useful back, even if it causes the URI to be ambiguous.  Ambiguous information is better than no information at all, and the ambiguity may not matter to many applications.

The *reason* for the httpRange-14 rule of reserving 200 responses for "information resources"
http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039
is to prevent URI *collision*, as defined in the AWWW:
http://www.w3.org/TR/webarch/#URI-collision
In this case, serving a 200 response would cause that URI to identify *both* the relation *and* a web page (a/k/a "information resource").  The harm imposed by URI collision is: "a cost in communication due to the effort required to resolve ambiguities".

While this particular ambiguity happens to be between a Link relation and an "information resource"
it is not fundamentally different from other kinds of ambiguity of reference that will occur.  Ambiguity of reference is inescapable, and it is *not* merely because people fail to follow good practice.  It is because different applications have different needs: a URI that is unambiguous for one application may be ambiguous for another, but that does not make it wrong.

Semantic web practitioners must learn to deal with this kind of ambiguity without being judgemental.

I hope you are successful in convincing the IETF to serve 303s, as I think it is helpful.  But if you fail and they serve 200s there is no need to view it as a violation of web architecture, as I have explained in
http://dbooth.org/2007/splitting/ 

 

David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.
 

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Jonathan Rees
> Sent: Wednesday, January 28, 2009 1:48 PM
> To: www-tag@w3.org WG
> Subject: Link: relation registry and 303
> 
> 
> (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.
> 
> 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.
> 
> 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 Thursday, 29 January 2009 04:38:29 UTC