- From: Larry Masinter <LMM@acm.org>
- Date: Sat, 04 Sep 2004 10:52:47 -0700
- To: "'Tim Kindberg (by way of Martin Duerst <duerst@w3.org>)'" <timothy@hplb.hpl.hp.com>, uri@w3.org
> What is it I'm missing in thinking that (URI) tags containing > pct-encoded characters are: > (a) self-defeating -- tags are supposed to be tractable for humans > (b) redundant -- it's never necessary to turn a tag containing, say, > Chinese characters into URI form; we need be sure only that it's in > canonical form and thus comparable with other tags. This makes it look like 'tag' doesn't have general applicability as a URI, as it can not generally be used in contexts that accept URIs but do not accept IRIs. Perhaps, in the transition from URIs to IRIs, it would make sense to allow new URI schemes to be registered that have this property, but it seems unnecessarily limiting. It might be useful, as an informational adjunct to the IRI draft, to do a survey of URI contexts and the state of application for use of IRIs in those contexts, e.g., within HTML, inside email headers, in SIP, etc. For example, RFC 3106, ECML, has a "URI indicating version of this set of fields." Can this actually be an IRI? I don't think RFC 3106 allows that. Can you use a Chinese 'tag' here? Not unless you allow pct-encoded characters. I just picked ECML at random; I think there are lots of other protocols that use 'URI' and would need their definition to be upgraded to allow 'IRI'. Larry -- http://larry.masinter.net
Received on Saturday, 4 September 2004 17:53:41 UTC