Re: I-D Action: draft-ietf-iri-bidi-guidelines-02.txt

--On Thursday, April 12, 2012 00:27 -0700 Larry Masinter
<masinter@adobe.com> wrote:

>...
> That said, I think it would help a lot to identify the roles
> for which conformance behavior is being standardized. I
> suspected that sometimes we were talking about IRI selection,
> sometimes about IRI processing, sometimes about  Iri display,
> and rarely about restrictions on IRI syntax.

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

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

The question then is whether I layer my presentation format on
top (and translate to) IRIs or layer it directly on top of URIs.
If the answer is the second, then we better not do anything with
IRIs (or with HTML, XML, HTTP, etc.) that requires the first.
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.

    john

Received on Thursday, 12 April 2012 13:47:17 UTC