Hello Robert,
Thanks for your questions, and for studying IRIs so carefully.
At 09:15 05/01/29, Robert Sayre wrote:
>IRIs are a step forward and important to include in the spec, but they also worry me. In RFC3987, I read the following:
>
>"The approach of defining a new protocol element was chosen instead of
> extending or changing the definition of URIs. This was done in order
> to allow a clear distinction and to avoid incompatibilities with
> existing software."
Yes. That was put in to clearly say that you can't just expect IRIs to work wherever URIs work without doing anything. Because Atom is a new protocol, we are in a very good position to do the right thing, which turns out to be very little.
>Do you expect Atom implementors will be using incompatible existing software? I think this question should face roughly the same scrutiny that PUT/DELETE did.
Yes. If you look at the pace (http://www.intertwingly.net/wiki/pie/PaceIRI, just updated to take into account the RFC publications, most of this is described under "Impact". Converting an IRI to UTF-8 and doing %-encoding is a lot easier to program if there is no IRI library available than to program your own PUT or DELETE requests, in particular because the former is a completely internal operation, whereas the later is a network operation. Integrating conversion to punycode in case there is no IDN support available is a bit more work, but if you don't do normalization (stringprep,...), the code footprint should be extremely small. Except for encoding issues (UTF-8 or UTF-16 vs. UTF-32), you can basically just copy the code from http://www.rfc-editor.org/rfc/rfc3492.txt.
>I'm also worried that the term "IRI" will cause confusion. After all, the catch phrase is not "Cool IRIs Don't Change." What can we do minimize confusion?
First, every URI is an IRI, so there is absolutely no need for any existing URI to change. Second, there is the confusion with terms. I agree that the term IRI shouldn't be pushed too much, I expect users e.g. in Japan to just use language like "software x-y-z now accepts URLs/Web addresses with Japanese characters".
But in the spec, we have to make clear that IRIs are allowed, in a way that implementers actually see it. So that's why I propose to replace the term URI with the term IRI throughout the spec, but not to change the attribute names. But I'm open to discussion about this; if you have some other ideas, please send them to the list.
Regards, Martin.
