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

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Apr 2008 18:30:01 -0700

Hello Atom-ers,

I'd like opinions on the draft below; it proposes some changes to  
facilitate alignment of the HTML and Atom link relation values and  
registries, so that we don't have format-specific link relations.

Feedback has been positive so far (mostly on the HTTP list, also in  
W3C circles), but since this changes the registry (and otherwise is so  
directly related to Atom), it's important that there's buy-in here as  
well.

Comments?

Begin forwarded message:
> From: [email-masked]
> Date: 17 March 2008 11:30:01 AM
> To: [email-masked]
> Subject: I-D ACTION:draft-nottingham-http-link-header-01.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: HTTP Header Linking
> 	Author(s)	: M. Nottingham
> 	Filename	: draft-nottingham-http-link-header-01.txt
> 	Pages		: 13
> 	Date		: 2008-3-17
> 	
> This document clarifies the status of the Link HTTP header and
>   attempts to consolidate link relations in a single registry.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--
Mark Nottingham     http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Wed, 23 Apr 2008 08:36:54 -0700

Mark,

overall I think this is a good thing.  However, I am concerned that this 
would allow for a bunch of new link relations to be used in Atom without 
a clear understanding of their meaning in that context.  For instance, 
"index: refers to an index" is not exactly clear and the description in 
HTML 4.01 doesn't help either "Refers to a document providing an index 
for the current document."  It is an index of the Atom entry or of the 
content?  It's not a showstopper, of course, but it is something that 
should be considered.

- James

Mark Nottingham wrote:
> Feedback has been positive so far (mostly on the HTTP list, also in W3C 
> circles), but since this changes the registry (and otherwise is so 
> directly related to Atom), it's important that there's buy-in here as well.
> 
> Comments?
> 
> 
> Begin forwarded message:

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 23 Apr 2008 12:35:01 -0700

> > directly related to Atom), it's important that there's 

The HTML5 draft document says that Link: headers are to be processed
according to the definitions given in HTML 5. I vaguely remember that
the HTML WG (or WHATWG, I forget) wanted to be the authoritative
reference for all link relations in HTML, they wanted to define how
conflict are handled, and they even have their own wiki-based registry:
http://wiki.whatwg.org/wiki/RelExtensions. What did the HTML 5 people
have to say about shifting the maintenance of the registry to the IESG?

Is a Link header is even a good idea for Atom documents? Atom documents
are almost universally machine-generated, and it is easy for a generator
to just add the appropriate <link> element to the document, instead of
adding a Link header. Most Atom clients do not look for Link: headers
anyway, so you have to put them in the document if you want them to be
found. Splitting the information between the headers and the document
just makes processing Atom documents more difficult. 

The precise meaning of each link relation should be defined in a way
that doesn't depend on the content type of the variant being returned.
Some of the definitions in the draft are too vague, and when you follow
the references to the more precise definitions, those definitions are
either Atom-specific or HTML-specific. Vague definitions will lead
different people to use the same link relation for different, but
vaguely-similar purposes.

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.

The current draft says "[A] link relation SHOULD NOT specify what the
context of its use is, although the media type of the dereferenced link
may constrain how it is applied." I don't understand what that means; it
could be read as saying that the precise meaning of the link depends on
the target's media type. Is that what you meant? Could you give an
example?

In the introduction, in explaining the motivation for standardizing the
Link header, the draft says "[T]he status of the Link header is unclear,
leading some to consider minting new application-specific HTTP headers
instead of reusing it." I agree that application-specific HTTP headers
are problematic; however, the Link header only addresses the case where
the application-specific header is a hyperlink; it would be better to
solve the problem more generally.

Also, I think a lot of the discussion about decentralized media types
[1] applies to using URIs for link relations too.

[1]
http://steve.vinoski.net/blog/2008/02/11/more-about-decentralized-media-
types/

Cheers,
Brian

> Sent: Wednesday, April 23, 2008 8:37 AM
> To: Mark Nottingham
> Cc: atom-syntax Syntax
> Subject: Re: Fwd: I-D ACTION:draft-nottingham-http-link-header-01.txt
> 
> 
> Mark,
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Apr 2008 20:13:37 -0700

Brian --

Thanks for the feedback. Replies below...

> have to say about shifting the maintenance of the registry to the  

I haven't engaged them yet; they're next on the list.

> just makes processing Atom documents more difficult.

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.

> that doesn't depend on the content type of the variant being returned.

Yes, that's the point of this approach.

> vaguely-similar purposes.

Yes. I wanted to get feedback on the overall approach; I know they  
need some work, and I'm open to suggestions for text.

> 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...

> the target's media type. Is that what you meant? Could you give an

A link relation shouldn't say that it's to be used in a particular  
part of a format; that's up to a format to specify.

> solve the problem more generally.

Can you expand upon this?

> http://steve.vinoski.net/blog/2008/02/11/more-about-decentralized-media-

It certainly deserves some thought. Some escape hatch is necessary;  
the question is how much its use should be encouraged...

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Apr 2008 20:15:34 -0700

I think this is mostly a consequence of grandfathering in a bunch of  
very old and mostly unused link relations. I'm open to not registering  
those, or registering them as obsolete, specific to HTML, or something  
similar.  Would that do it?

Cheers,

On 23/04/2008, at 8:36 AM, James M Snell wrote:

> Mark,
>
> overall I think this is a good thing.  However, I am concerned that  
> this would allow for a bunch of new link relations to be used in  
> Atom without a clear understanding of their meaning in that  
> context.  For instance, "index: refers to an index" is not exactly  
> clear and the description in HTML 4.01 doesn't help either "Refers  
> to a document providing an index for the current document."  It is  
> an index of the Atom entry or of the content?  It's not a  
> showstopper, of course, but it is something that should be considered.
>
> - James
>
> Mark Nottingham wrote:
>> Hello Atom-ers,
>> W3C circles), but since this changes the registry (and otherwise is  
>> so directly related to Atom), it's important that there's buy-in  
>> here as well.
>> Comments?
>> Begin forwarded message:

---

From: James M Snell <[email-masked]>
Date: Thu, 24 Apr 2008 22:19:04 -0700

I believe having a flag that indicates whether the relation is specific 
to HTML, Atom, HTTP or any combination there of would be the most 
helpful option.

- James

Mark Nottingham wrote:
>> this would allow for a bunch of new link relations to be used in Atom 
>> without a clear understanding of their meaning in that context.  For 
>> instance, "index: refers to an index" is not exactly clear and the 
>> description in HTML 4.01 doesn't help either "Refers to a document 
>> providing an index for the current document."  It is an index of the 
>> Atom entry or of the content?  It's not a showstopper, of course, but 
>> it is something that should be considered.
>>
>> - James
>>
>> Mark Nottingham wrote:
>>> Hello Atom-ers,
>>> so directly related to Atom), it's important that there's buy-in here 
>>> as well.
>>> Comments?
>>> Begin forwarded message:

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 29 Apr 2008 07:49:21 -0700

Jamie Lokier wrote:
> How about:
> 
>     Generic-Link: URL=value
> 
> Which is required to be written in exactly that form, the URN denotes
> the relation type, and the URN is always unquoted, absolute, and in
> a canonical form.
> 
> It seems to satisfy the same easy parsing and substitution
> requirements that motivate foo-Link, while providing the flexibility
> of URNs for unregistered relation types.

I agree it is seems easier to parse at first. But, you have to change it to
at least the following to support multiple "Generic-Link" headers (See [1]):

     Generic-Link: #(URL=value)

And then you have to disambiguate the commas:

     Generic-Link: #(<URL>=value)

And, even then, there is no mechanism for parameters, which I think it
helpful (especially the "type" parameter).

Regards,
Brian

[1] RFC 2616, Section 4.2:

"Multiple message-header fields with the same field-name MAY be
 present in a message if and only if the entire field-value for that
 header field is defined as a comma-separated list [i.e., #(values)].
 It MUST be possible to combine the multiple header fields into one
 "field-name: field-value" pair, without changing the semantics of the
 message, by appending each subsequent field-value to the first, each
 separated by a comma. The order in which header fields with the same
 field-name are received is therefore significant to the
 interpretation of the combined field value, and thus a proxy MUST NOT
 change the order of these field values when a message is forwarded."