Proposed Charter for the IDNAbis Working Group

[John C Klensin]

--On Thursday, 27 March, 2008 09:51 -0700 Paul Hoffman
<phoffman at imc.org> wrote:

> At 12:04 PM -0400 3/27/08, John C Klensin wrote:
>...

>> I think "same basic design" is correct.  The "look at the
>> whole domain name" requirement is one that I personally hope
>> we can avoid, regardless of whether "making full names
>> display better" is the motivation.
> 
> This is very distressing. Those of us not in the design team
> have been going on the assumption that the design team had a
> unified vision of the design. That idea was heavily embodied
> in the first proposed charter, and is still central to the
> current proposed charter. Now you say it isn't so.

I said no such thing.  We have a unified version of the design.
What you and I --as distinct from the design team-- disagree
about is whether this particular issue is a basic and critical
part of the design or whether it is an issue we hope the WG
would join us in resolving.  I believe the latter.  If every
detail of the proposed specs were locked down, there would be no
point at all in convening a WG and certainly no point in
structuring a charter that extends through the calendar year.

I suppose you could now ask that the charter contain a
comprehensive list of all issues the design team considers open,
but that would presumably set off yet another debate about
whether the list was correct.  The answer is that all of the
details are open for discussion and that all of the principles
are open to challenge and I think that, not only does the draft
charter more or less say that but that it is intrinsic to an
IETF WG.

> draft-alvestrand-idna-bidi-04 is completely clear on this:
>     o  In a display of a string of labels, the characters of
> each label
>        should remain grouped between the characters delimiting
> the
>        labels.
> 
>     o  These properties should hold true both when the string
> is embedded
>        in a paragraph with LTR direction and when it's
> embedded in a
>        paragraph with RTL direction, as long as explicit
> directional
>        controls are not used within the same paragraph.

I think those are goals.  I think those are goals on which most
sensible people would agree.  They are not statements about
looking at more than one label at a time (although some of the
proposed mechanisms effectively are).  While they look at things
from a user/ display perspective, I consider that more a matter
of the form of the statements than a basic property of the
definition. 

To me, the "key part of the bidi spec" is, and always has been,
that we permit the now-obvious sets of identifiers that IDNA2003
excludes (e.g., the cases with the trailing combining marks). I
have also hoped that we could make the use of domain names
containing RtoL labels, and RtoL domain names (not the same
thing, as you know) more predictable and consistent.  But,
personally and with the clear understanding that "more
predicable to users" and "more consistent to systems" may be
partially-conflicting objectives, I can live with any bidi-spec
output that fixes the first problem and makes the second one no
worse.

To me, that is a rational design and engineering approach: we
know  (or think we do) that bidi needs to be upgraded (I'm going
to try to avoid "fix", because the implication that something
was broken seems to upset you) to address those additional
scripts and identifiers.  It is reasonable to see if overall
improvements can be made in the process of making those
upgrades.  If they can, that is great.  If they cannot, the
basic, key, issue is that upgrade, not the display/ consistency/
predictability improvements.
 
Those are all personal opinions that I have not checked with
Harald or Cary to determine whether we are in complete
agreement, nor had it occurred to me prior to your note that I
should need to do that.

>> I certainly hope the WG will discuss the
>> tradeoffs between better display and full-name interactions
>> (if, in fact, that is the best way to state the issue) in
>> depth.
> 
> Do the other design team members agree with this? That is, if
> we get rid of all the parts of the bidi spec that look beyond
> the current label, does the whole design team agree that we do
> *not* need to recharter?

I hope they will respond to this question.

>> However, I don't believe that the basic design is changed by
>> looking at adjacent labels, any more than I believe that a few
>> provisions of RFC 3490 make it fundamentally about full domain
>> names rather than labels.
> 
> Please be specific where in RFC 3490 you think those
> provisions are. If they exist, they are errors in the protocol
> that no one has noticed before now.

The important one is embedded in the conformance statement of
3.1(1), which has been extensively discussed on this list.
Putting that condition in a conformance statement permits one to
claim that the algorithm doesn't look at full domain names, but,
as soon as one talks about label separators, one is not looking
purely at individual labels.

>> But I wish that we could confine charter discussions to
>> showstoppers and/or issues that would have a significant
>> effect on what the WG does and how it does it, rather than
>> trying to achieve perfection in every sentence.
> 
> I consider it a show-stopper that those of us not on the
> design team cannot figure out where those on the design team
> do not agree.

I do not believe that it is either necessary or appropriate that
the WG base its evaluations on the working methods of the design
team.  The documents either correctly express a basis for
community consensus --and are good enough that it is possible,
with reasonable effort, to align them to community consensus--
or they do not.  If they do not correctly express community
consensus, or express it poorly or inadequately, they need to
fixed and, with the efforts of the WG, will be fixed whether all
design team members agree with the community conclusions or not.
To take one example that has been mentioned on the list, neither
Patrik nor I are completely convinced that removing "MAYBE" was
the right decision (I make no claims about how the other design
team members feel about it).    But it is a decision we are able
to support and work with, so it is reflected in the documents
being used to initialize the WG.

      john