And, fwiw, I think that is another symptom of lack of broad consensus about whether IRIs are part of UI/presentation interfaces or are protocol elements.
I'm certain that the route we've gone down forces IRIs to be protocol elements in some circumstances, if only because IRIs (and not just URIs) appear within languages used in network protocols. I'm not sure I have heard anyone actually advocating for trying to confine IRIs merely to a presentational role, except as wishful thinking. I don't think you (John Klensin) are even advocating that position, are you?
I wish we could, but I don't think we can do so, because it's not how the web works.
Proceeding simultaneously
as if they are both, or whichever is convenient at the moment,
does not make it easy to think clearly about those role, much
less identify them.
Surely with IDNA we have some history of distinguishing between the roles of protocol element vs. presentational interfaces already, which should provide ample groundwork for thinking about them.
In fact, I have tried, in recent edits to the various drafts, to clarify that IRIs are protocol elements, and that there are also presentational forms ("printed on the side of the bus") which are not, themselves, IRIs, but presentations of them. If there is any part of any current document which you think isn't clear on this point, could you let us know so we can open a ticket and fix it?
That is also where the larger issue that I've been asked to defer intrudes. To illustrate briefly, I note that the IETF has never been foolish or arrogant enough to try to tell UI
designers what they can or cannot do.
I think there are numerous cases where IETF documents give advice for "user agents" (especially in "security considerations") as guidance for how a user interface might help avoid user confusion, although such advice is often couched in a "SHOULD". And I think most of the issues we're concerned (and for which we are giving advice) are ones where user confusion and associated security risks are the motivation for going into details in the IRI documents.
Now suppose that I'm a designer of a UI for a language that is very different from Western European ones and that uses a script that is very different from the Greek-Latin-Cyrillic group.
I think our obligations in IRI are quite similar to those in IDNA (and, in fact, some of the concerns expressed about IRIs are more appropriate for IDNA).
I conclude that, for my users, IRIs are a completely unreasonable user-presentation and user-input form, whether because of issues specific to IRIs or because I've concluded that long-tailed, multiple-element URIs are not an acceptable user-presentation and user-input form completely independent of i18n issues.
I think this is quite likely in some cases, and seems to be relevant even for ASCII: people use URL shorteners or expect search engines to provide a better user interface naming and discovery.
It doesn't make much difference to this hypothetical case whether my issues are relatively small (e.g., presentation of method names, order of labels in domain names) or more complex (e.g., moving to a completely standardized and explicit tagged metadata format).
I don't understand why we need to have hypothetical use cases when we have ample real ones.
The question then is whether I layer my presentation format on top (and translate to) IRIs or layer it directly on top of URIs.
It seems clear enough ot me that in many use cases, the protocols traffic in representations that include IRIs as protocol elements (HTML, XML-based languages), but in some use cases, the protocols send URIs, even when the presentation layer displays things that look like IRIs and encourage users to enter things that look like IRIs. An application designer often needs to deal with the URIs and IRIs protocol elements both and also the presentational forms of both, and the translations between those.
If the answer is the second, then we better not do anything with IRIs (or with HTML, XML, HTTP, etc.) that requires the first.
I don't think designing IRIs as a presentational form of URIs is feasible, because the IRI -> URI mapping is information lossy, and there are protocols, formats, languages that treat an IRI and the URI to which it might be converted as distinct. So "the answer" cannot be "layer directly on top of URIs", much as we wish it could.
And, if it is the first, then we need to be really, really, clear about canonical forms as well as about why such an interface should have to go through two translation/mapping
steps at least most of the time.
I'm all in favor of being clear, and would ask again if you could point out places in the documents that are not. I don't think it is feasible to handle our difficulties by being clear about "canonical forms", because different IRI applications have different needs for equivalence relationships, and often in a way that is not easily characterized by defining a canonical form.
As for te fact that interfaces which map between protocol and presentation might have to deal with both URI and IRI protocol elements -- well, they have to do that because the world is complex. I wish it weren't, but that's what we need to do, so let's get on with it.
Regards,
Larry
--
http://larry.masinter.net