RE: I-D ACTION:draft-nottingham-http-link-header-01.txt

[Removed Atom-Syntax] 

Phil Archer wrote:
> I am sympathetic to your proposal for foo-Links - it seems clear and 
> your experiments add weight to it. However, it seems to lose out on 
> flexibility. With Link, anyone can create a new relationship type by 
> providing an absolute URI, it's only relative ones that are 
> tied to the IANA namespace.
> 
> Putting people in a tight corner will lead them to ignore some of the 
> rules and I fear you'll soon see 'links' of the type
> 
> dunno_about_registration-Links:
> 
> so that clashes become rather more likely.

The example in the Link header proposal was: 

    Link: </foo>; rel="http://example.com/profile1/foo"

How would we convert this to a "foo-Link"? How about just dropping the
"http://" as noise, and then replacing all the characters that are illegal
in HTTP header field names with "-"?:

example.com-profile-foo: /foo

I think that this is a nice compromise between the ease of processing,
readability, while making collisions extremely unlikely. The worldwide Java
programming community has used a very similar naming convention and it has
worked out very well over the last ten years.

Regards,
Brian



> 
> -- 
> Phil Archer
> POWDER WG
> 
> 
> Brian Smith wrote:
> > [CC'd to ietf-http-wg. I think it is better to continue the 
> conversation
> > over there as most of my comments are not specific to Atom.]
> > 
> > Mark Nottingham wrote:
> >> The draft does not advocate removing links from Atom 
> >> documents to put them in headers; rather, the common
> >> use case is repeating them in headers, so that they
> >> can be easily discovered and processed.
> > 
> > With HTML, I've never seen the Link header used that way; 
> it has always been
> > used to add new links to the document (usually style sheets 
> that vary
> > depending on the UA).
> > 
> > When processing Atom documents, we are usually more interested in
> > atom:title, atom:content/@src (if any), and 
> atom:content/@type. In AtomPub
> > we also often want atom:link/@rel='edit' and 
> atom:link/@rel='edit-media'.
> > Since the Link header can only store the atom:link 
> elements, we are almost
> > always going to have to parse the document anyway. If 
> parsing Atom (or HTML)
> > is problematic for the software application then the 
> application shouldn't
> > have chosen to store everything in Atom (or HTML) documents. :)
> > 
> >>> For all those reasons, I actually think it makes a lot more 
> >>> sense for the Link header registry to be mutually exclusive
> >>> with the HTML and Atom registry, instead of attempting to
> >>> merge them all together.
> >> You're the first person to suggest that. I think we can get 
> >> to a place where there's alignment between the specs without
> >> abusing the semantics of existing relations. It's certainly
> >> worth trying...
> > 
> > It seems like a lot of effort just to (re-)define all the 
> link relations in
> > a format-agnostic way without being overly vague. It is 
> probably even more
> > work to convince everybody (especially the HTML WG) to 
> agree to the result.
> > I think it would be nice if the same link relation 
> identifiers meant the
> > same thing in Atom as they do in HTML. However, for most of 
> the existing
> > registrations, I don't see the advantage to also making 
> them available in
> > the HTTP message header. 
> > 
> > Last Friday I implemented support for the Link header in a 
> simple AtomPub
> > application. Now I will take an even stronger stance: its 
> use should not be
> > encouraged at all. It is much simpler to process hyperlinks 
> that use the
> > "Relation: URI" syntax like Location and Content-Location 
> than it is to
> > process hyperlinks that use the Link header. For example, 
> writing Python
> > middleware or Apache mod_rewrite/mod_headers rules to 
> filter/add/remove
> > links is much harder using the Link header than when using the
> > Location-header approach:
> > 
> > 1. There is too much flexibility in the syntax of the "rel" 
> parameter. For
> > example, the following all mean the same thing:
> >       rel=edit
> >       rel="edit"
> >       rel="\e\d\i\t"
> >       rel="http://www.iana.org/assignments/link-relations.html#edit"
> >       ....
> > If you want to be able to catch all variations, then you 
> have to write a
> > pretty nasty regular expression.
> > 
> > 2. The Link header mixes unrelated information into the 
> same header field.
> > Consequently, in order to process specific types of links, 
> you have to parse
> > the Link header field into parts, process the parts that 
> you are interested
> > in, and put it all back together.
> > 
> > 3. The "rev" mechanism makes processing unnecessarily 
> difficult. You have to
> > be careful to note whenever rev=A means the same thing of 
> rel=B when you are
> > attempting to process the header.
> > 
> > I think a better alternative to a single "Link" header is 
> to define a
> > standard for multiple Link-like headers:
> > 
> > [Relation]-Links: #(URI-Reference LWS *(; param=value LWS))
> > 
> > For example, an "edit" link would be:
> > 
> > Edit-Links: http://foo.org
> > 
> > This could be done by changing the registration rules for 
> HTTP headers so
> > that header fields with a "-Links" suffix must have the 
> above syntax, with
> > the definitions of the "media", "type", and "title" 
> parameters to be the
> > fixed to be the same as in HTML 4 (or 5) and Atom 1.0. Each 
> link header
> > would have to define the processing rules for when multiple 
> links are
> > provided, and applications must be prepared to handle 
> multiple links of the
> > same type, even when they are not expected (that is why I 
> chose "-Links"
> > instead of "-Link").
> > 
> > Try to write a mod_headers rule or Python WSGI middleware 
> that filters out
> > all the links with a particular type. Using the "-Links" 
> header syntax, it
> > is just "del environ[HTTP_RELATION_NAME_LINKS]" in Python and "unset
> > RELATION-NAME-LINKS" in mod_headers. The Link header 
> version requires a some
> > tricky parsing in Python. I think it is actually impossible 
> to process the
> > Link header correctly using Apache's mod_headers.
> > 
> > I think the "-Links" header idea allows for uniform syntax 
> (like the Link
> > header) while still being extremely easy to process.
> > 
> > Thoughts?
> > 
> > - Brian
> > 
> > 
> > 
> > 
> 
> 
>

Received on Tuesday, 29 April 2008 14:44:54 UTC