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

[Vint Cerf]

Perhaps an alternative tactic is possible. If there is normative  
information in rationale, let's put it into the appropriate other  
document (protocol, bidi, tables) and KEEP it in the rationale  
document. Let's say up front that rationale is NOT normative but  
intended to help understanding of the normative documents.

vint


On Aug 22, 2008, at 7:45 PM, John C Klensin wrote:

>
>
> --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
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update