RE: Reviving HTTP Header Linking: Some code and use-cases

Julian Reschke wrote:
> Brian Smith wrote:
> > Julian Reschke wrote:
> >>> HTTP cannot share the same link registry as Atom unless the Atom 
> >>> link registry is completely redone. The whole registry is 
> specific 
> >>> to Atom or feed processing.
> >> How so?
> > 
> > Just as an example, look at "edit". It is defined to always 
> link to an 
> > Atom entry. All the link currently-defined relations are defined by 
> > Atom RFCs.
> 
> OK, thanks for clarifying.
> 
> So making this a non-specific Atom registry probably requires 
> making these relations have generic semantics.

Some (most?) of them already have pretty generic semantics. But, others
don't, and if you try to make them generic, then they will stop working
for AtomPub. AtomPub requires "edit" to link to an Atom Entry, for
example.

> RFC 4287 says that relative references
> (<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.7.2>)
> must be simple names:
> 
> "Note that use of a relative reference other than a simple 
> name is not allowed."

<snip>

> So it seems to me that this *is* URI resolution.

Right, but only after you've verified that the document is conformant to
RFC 4287. If you aren't sure that the link relation is conformant, then
you can't use IRI resolution to verify it. Also, you have to make sure
that whatever library you are using to do the IRI resolution actually
supports IRIs, and not just URIs.

> >>> The Atom mechanism does comparisons 
> >>> character-for-character. An IRI 
> >>> and its URI equivalent do not match. That means that RFC
> >>> 3987 IRI-URI conversion cannot be used for the Link 
> >>> header

> >> Sounds like a good reason for not allowing link relations 
> >> that aren't URIs (or URI references).

I think it would be better to only allow link relations where URI -> IRI
conversion is a no-op, and then specify that URI -> IRI conversion is
done when serializing the header, and URI -> IRI conversion must be done
to compare link relations.

> > That is against IETF policy. New standards have to allow the use of 
> > IRIs wherever URIs are allowed. At least, that is what I 
> > was told on the Atom mailing list. While I have read RFC 2277,
> > I'm not an expert on IETF's
> 
> I don't think this is true.
> 
> Also, we're not really talking about something new here; 
> what's being discussed is restoring what RFC 2068 already 
> said about "Link:".
> 
> > internationalization policy. However, I personally believe 
> it is wrong 
> > to create new standards where things may be named in European 
> > languages but not in non-European languages.
> 
> If this would be a new standard, I would agree.

If the link header is going to be (re-)standardized, it has to be
specified in a new standard. It is out of scope for HTTPbis. And, RFC
2277 says all new IETF standards must support UTF-8, which implies that
all new IETF standards for URI processing must support IRIs.

- Brian

Received on Wednesday, 12 March 2008 22:33:07 UTC