Mapping (was: Issues lists and the "preprocessing" topic)

John C Klensin klensin at jck.com
Sat Aug 23 01:45:50 CEST 2008



--On Friday, 22 August, 2008 15:44 -0700 Mark Davis
<mark.davis at icu-project.org> wrote:

> In Dublin, we unfortunately never got to a main issue, which
> was the document structure. What I think we need to do is move
> all normative material from rationale to protocol, and then:
> 
>    1. In the protocol document in an appendix have a listing
> of the    differences with IDNA2003, with examples of each
> kind of difference for    clarity.
>    2. In the rationale document have some explanation of why
> the differences    exist.

Mark,

Let me first stress that I don't object to trying to go down
this path if it is what the WG wants to do.   More on that at
the end.  But...

I've tried marking up copies of Rationale and Protocol to
identify the material that would need to be moved (and, in most
cases, rewritten... it is not a simple move) from one to the
other to eliminate all normative material from Rationale.    The
very sensitive U-label/ A-label/
whatever-we-call-the-other-things definitions are examples of
the problem of normative material that is needed to understand
important non-normative parts of Rationale.  There are some
subjective judgment calls and a good deal of text that would
have to either be duplicated to permit Rationale to continue to
make sense or we would have to require that readers of Rationale
read and understand major sections of Protocol first. 

The latter is not, IMO, desirable for two reasons.  First,
Rationale is now partially an introduction to how to read and
understand Protocol, Tables, and how things hang together
generally (I'm trying to remove material from Rationale that
might lead people to believe that it contains enough information
to be an implementation specification, but that is [mostly] a
separate issue).  With IDNA2003, some of the equivalent material
was in RFC 3490 (while the rest of 3490 corresponds to material
that is in Protocol in IDNA2008) and the rest of it was just
omitted, leading to one of the sources of confusion about what
IDNs are all about.  If we require reading normative
definitional material in Protocol in order to understand the
overview/ introductory material in Rationale, we drive the
reader in a circle.     Second, as has been discussed
extensively on the list, Rationale has an audience among those
who manage names or design applications and applications
contexts for IDNs, including but not limited to those who try to
set IDN policies.  However we might wish otherwise, those groups
of people will not read a protocol specification and will be
more deterred the more rigorous we make the spec; many of them
cannot do so.

The net result is that I don't believe that we can accomplish
what I would consider to be the real goal, which is to have
Protocol, Tables, and (if we keep it separate) Bidi documents
that do not depend on Rationale for understanding or definitions
and a Rationale document that does not depend on them. At this
stage, I also believe we should strive for no duplicate text
because having duplicate text, especially at a time when we are
still considering and changing the documents in basic ways, is
an invitation to trouble (again, the controversies about
"LDH-label" are an obvious example here, but not the only one).

The quick summary is that it is easy to say "move the material"
and much harder to actually do it.  If we try, I would hope that
the WG would get firm commitments for review of the revised
documents that would be much broader and more intense than most
of what we've seen in the last several months.   Put more
bluntly, I'm scared about making changes that are not
technically necessary and substantive when the level and speed
of review of new documents is the "slow and only by a very few
people" pattern that what we've seen in the last several months.
A decision to start moving material around in significant ways
would, IMO, cost us at least two and probably three rounds of
draft that we would not otherwise need.  Unless we can
significantly speed up review cycles and input, that could drag
the WG out for many extra months.  I think that is a poor
tradeoff.  YMMD and, as I said at the beginning, I'm willing to
try to do it if that is what the WG really wants.

For the record, an intermediate strategy of leaving the
normative definitions and closely-related material in Rationale
but moving all other normative or protocol-specific material is
a lot more feasible than what I believe you are proposing.  That
activity is already in progress, with the pre-IETF drafts better
sorted in that regard than the earlier ones and the ones I'm
working on now being better sorted than those of a month ago.

I do have an alternate suggestion, which is that we get these
drafts through to Proposed Standard with more or less the
current document organization (I'm still agnostic about whether
we should do an eleventh-hour collapse of Bidi into Protocol).
Getting the documents approved at Proposed Standard and
implementations and deployment started would give us some
assurance that the definitions and other details are correct and
clear.  Then we come back and generate Draft Standard versions
against a stable underlying specification.  Those versions would
move the text around, duplicating or summarizing the (then
fairly firm) definitions and other material as needed.

But this is the point at which I need instructions from Vint and
the WG.  As with the "what to say about relationships to
IDNA2003" question, I cannot go down two paths at once.

    john



More information about the Idna-update mailing list