- From: Martin Duerst <duerst@w3.org>
- Date: Wed, 07 Jul 2004 17:12:42 +0900
- To: Ted Hardie <hardie@qualcomm.com>, "Williams, Stuart" <skw@hp.com>
- Cc: public-iri@w3.org
At 08:33 04/06/29 -0700, Ted Hardie wrote: >This way of describing it concerns me, and I believe we >need to be very, very careful about saying "IRI scheme". Sorry to be a bit loose in my answer. If there is any concern with the actual spec, please tell us. >The IRI spec is defined such that any URI should be >representable as an IRI. Did you want to write 'any IRI should be representable as an URI'? The converse is true, too, by the fact that every URI is by definition an IRI, >That does not mean that the >URI schemes themselves are capable of using IRIs, In what sense would an URI scheme be 'capable of' doing something? >nor that any protocol that currently uses URIs will understand >IRIs in those protocol slots. Definitely not. But this is, or should be, completely scheme- independent, not because of IRIs, but because that's a general design principle of URIs. >It simply means that a >common, Internationalized presentation layer can be used >to represent the URIs. Yes. >There are systems out there that may be able to use IRIs >natively as identifiers, but that it is, I understand, in >cases like the XML "AnyURI"(sic) where the actual use >is to provide an identifier for which equality will be >checked character by character. It is true that XML Schema defines its equality operation for anyURI as 'character-by-character equivalent', but this is only for schema-related operations. Applications are free to use other equivalences as needed. Regards, Martin. >But this use >is not the same as the URI protocol processing, >and we should not conflate the two. > > regards, > Ted > > >At 10:31 PM +0900 6/29/04, Martin Duerst wrote: >>Hello Stuart, >> >>Just a quick answer, because I'm traveling. >> >>At 11:56 04/06/29 +0100, Williams, Stuart wrote: >> >>>Martin, >>> >>>I'd like to understand expectations wrt to IANA registered URI schemes >>>following adoption of the IRI spec as an RFC and during deplyment of IRIs. >>> >>>Do they 'instantly' become IRI schemes too? >> >>Yes, all of them in the sense that every URI is an IRI, at least. >>And most of them to the extent that they allow %-encoding and either >>require (e.g. urn, imap,...) or allow (e.g. http) the %-encoding >>to be based on UTF-8. >> >>>Will they require maintenance to allow the use of the expanded character set >>>allowed by the generic IRI syntax? >> >>Some of them will. The most prominent example: mailto:, which is >>very restrictive in where it allows %-encoding, if at all. >> >>>The IRI spec gives a generic syntax that allows a broader range of >>>characters to be used identifiers, but each currently registered scheme is >>>written from a URI perspective with the potential to narrow rather than >>>broaden the range characters used in an identifier from those permissablein >>>the URI spec. >>> >>>The IRI spec. has section on upgrade strategy (7.8) which speaks of >>>upgrading of applications to handle IRI, but it does not appear to say >>>anything about upgrading of URI scheme registrations. >> >>What URI schemes might need upgrade or not can be deduced from >>the exact definition of what's an IRI, which explicitly requires >>that the result of the IRI->URI conversion has to be a legal URI. >> >>>The identifier http://www.w3.org/People/dナ@st >> >>[sorry, my Japanese mailer will have garbled that] >> >>>may be admissable under the >>>generic IRI syntax, but is it a valid HTTP scheme IRI? And if so... what >>>specification makes it admissable as an HTTP scheme IRI? >> >>The IRI spec. If you take the above, and convert it to an URI, >>you will get http://www.w3.org/People/d%C3%BCrst. The HTTP URI >>spec says that this is a legal URI, so the one above is a legal IRI. >>In this case, it's not only legal, it's actually dereferencable, >>although the content at that location isn't terribly up to date, >>and the exact URI would be http://www.w3.org/People/D%C3%BCrst, >>but the server takes care of the casing issue. >> >>You will also observe that if you put the URI in the address bar >>in Opera, you'll get back the IRI. Other browsers may do something >>similar, or may at least allow you to put in the IRI and get >>to the actual page. (you have to be careful in the above example >>because I also put in some redirects, e.g. for >>http://www.w3.org/People/d%FCrst, the Latin-1-encoded version, >>but you'll see when that happens because the redirects are >>explicitly taking time. >> >>>Simply, my question is... what is the transition plan for scheme >>>registrations wrt to IRI deployment? >> >>For many if not most, there is no need for a plan. For some, >>such as http, it's mostly an issue of how people set up their >>servers. For some, such as mailto:, some work may be appropriate, >>but in that specific case, there have been quite a few discussions >>about weather and how to internationalize the left hand side of an >>email address, and that discussion hasn't yet been conclusive. >>It seemed better to wait to see where that would lead before >>upgrading mailto:. >>For newly created URIs, if they follow the guidelines for new >>URI schemes, they'll work with IRIs automatically. >> >>>Apologies if you have answered this before... I have looked, but did not >>>find anything relevant. >> >>In the IRI spec, please look at 'applicability' very early on, >>and then at the prose in the sections on syntax and on IRI->URI >>mapping. There is no such thing as e.g. a 'catalog of schemes >>that need upgrading', because after all, the IRI draft is a >>generic document. >> >> >>Regards, Martin.
Received on Wednesday, 7 July 2004 04:13:33 UTC