Consensus Call Tranche 1 (Document Organization)

[Eric Brunner-Williams]

I'm implementing an application. Both rational and specification could 
be useful (not to me, not for "in applications" but in theory, you know 
how theory and practice are).
I'm implementing a registry, and I've seen this implemented both in pure 
punycode and in utf8. Both rational and specification could be useful 
... again, in theory.

When I think of ccTLD registries, the CDNC and JET participants of 2002 
and the present, in particular, which isn't the whole universe by any 
means, they have "... the technical savvy to implement (and understand) 
the protocol as such ..."

So Yes, in theory, but for archaic reasons only the mandatory to 
implement statements have my personal interest, and "... is behind its 
original schedule. It should be noted that ..." is noted, but not 
particularly useful, even wearing that neither application nor zonefile 
implementor hat.

Vint Cerf wrote:
> DUE DATE: October 10, 2008 (ET)
>
> Place your reply here: [YES]
>
> COMMENTS:
>
>
> Procedure:
>
>
> There are several decisions that the working group will need to make 
> to confirm consensus.  I will send a series of proposals over the next 
> two weeks requesting YES or NO positions on each within a 4 day 
> window. If NO is the response, a reason for that position needs to be 
> stated. If there is a clear consensus based on responses or in the 
> absence ofa consensus against each proposal, it will be assumed that 
> the proposal is acceptable to the Working Group.
>
>
> Parenthesized symbols (e.g., "(R.1)") after the items are references 
> to the issues lists where additional explanations can be found, as 
> sent by John Klensin as body parts "idnabis-protocol-issues-rev3" and 
> "idnabis-rationale-issues-03" on a message titled 'Issues lists and 
> the "preprocessing" topic'  to the working group on 18 August 
> (http://www.alvestrand.no/pipermail/idna-update/2008-August/002537.html)
>
> This group needs to get its documents out; it is behind its original 
> schedule. It should be noted that the IDN ccTLD and gTLD selection 
> initiatives at ICANN have already begun so that delay may weaken the 
> IETF's ability to assist in a rational deployment of IDNA.
>
>
> (1) Document organization 
>
>
> (1.a) The Rationale document should be retained to support 
> implementors whose work requires that they understand the reasoning 
> behind certain design choices.  The philosophy of IDNA2008 relies 
> strongly on the ability of registries (especially those of top-level 
> domains) to properly constrain the choice of labels even if they are 
> composed of characters that are protocol valid.  (R.1)
>
> (1.b) While there has been debate about whether or not the content of 
> the Rationale document should contain normative material, it seems 
> expedient to agree on the content of Rationale for Proposed Standard 
> without attempting to separate it into multiple parts. Therefore, it 
> appears that the WG consensus is that: The normative material 
> (definitions) should be retained in Rationale.
>
> A YES means you concur with the consensus statements above.
>
> The alternative is:
>
> - The normative material should be removed from Rationale and 
> extracted to a separate document (for example Terms and Concepts) even 
> if this lengthens the WG's target dates for an unknown period of time. 
>  Note that there may be controversy about what material is normative 
> and what is not; that is a separate consensus issue and may also take 
> an unknown period of time to resolve   (R.2)
>
>
> NOTE NEW BUSINESS ADDRESS AND PHONE
> Vint Cerf
> Google
> 1818 Library Street, Suite 400
> Reston, VA 20190
> 202-370-5637
> vint at google.com <mailto:vint at google.com>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>