W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

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

From: Martin Duerst <duerst@it.aoyama.ac.jp>
Date: Fri, 14 Mar 2008 20:33:33 +0900
Message-Id: <>
To: "Brian Smith" <brian@briansmith.org>, <ietf-http-wg@w3.org>

At 07:32 08/03/13, Brian Smith wrote:
>Julian Reschke wrote:

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

I don't understand the three uses of "URI -> IRI conversion". If the
first is a no-op, that essentially means that URI contains no %-escape
sequences that can be interpreted as UTF-8.

And to put an IRI in a header, one would usually use IRI -> URI conversion,
rather than the other way round. But using that conversion would result
in an URI that wouldn't conform to the first condition.

Can you explain?

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

There is no explicit requirement to use IRIs for new IETF protocols.
There are lots of cases where that makes sense, but there may be
others where it doesn't make sense.

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

It's not about European languages. There are some non-European
languages that can be written with ASCII only (Swahili, Hawai'ian,...),
but most European languages require non-ASCII characters to be
written properly.

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

As Paul has explained, the IETF isn't a machine. It may make sense
in some cases to make a last minute fix before something goes to
Standard, but on the other hand, even if we decide to allow resource
identifiers for link relationships, the need for internationalized
ones is probably pretty low indeed. After all, these link relationships
are intended to be shared across languages and writing conventions,
I assume.

Regards,   Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     
Received on Friday, 14 March 2008 13:17:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC