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 Wednesday, 28 January 2009 18:48:17 UTC