Consensus Call Tranche 4/5 (Settled Textual Issues and IANA Considerations

[Yoshiro YONEYA]

> Place your reply here: [YES or NO]

NO

> COMMENTS:

> (4.a) The explanation of mappings in Rationale-02 and later is
> satisfactory.   (R.24)

Explanation in Rationale-03 is better, but I think this part should be 
written an another document describing application implementation guidelines.

> (4.c) The explanation of requirements on registries, the role
> of registration policy, and their scope in Rationale-02 and
> Protocol-05 is satisfactory (R.9, R.27, P.6).

This part also should be an another document.

> (4.e) The description of detecting domain names in text and how
> it interacts with the idea of alternate label separator
> ("dotoid") characters is adequate in Rationale-02  (R.23)

This part should be marged with application implementation guidelines.

> (4.f) The description of the implications of mapping changes
> between IDNA2003 and IDNA2008 is satisfactory in Rationale-02
> (R.28)

This part should be marged with application implementation guidelines.

> (5.a) The IANA considerations section setting up the Contextual
> Rule registry (in Tables, taken from Protocol at -03) is
> satisfactory.   (R.8)

Contextual rules in Protocol-03 was too restrictive.  Contextual rules 
should be much simpler.  Properties of exception characters should be 
defined in registries' policy.

-- 
Yoshiro YONEYA <yone at jprs.co.jp>

On Mon, 6 Oct 2008 17:00:24 -0400 Vint Cerf <vint at google.com> wrote:

> DUE DATE: OCTOBER 10, 2008 (ET)
> 
> Place your reply here: [YES or NO]
> 
> COMMENTS:
> 
> A YES response means that you agree with all of topics 4 and 5.
> 
> 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.
> 
> (4) Textual issues believed settled
> 
> (4.a) The explanation of mappings in Rationale-02 and later is
> satisfactory.   (R.24)
> 
> (4.b) The explanation of the symbol prohibition in Rationale-02
> and later is satisfactory.   (R.25)
> 
> (4.c) The explanation of requirements on registries, the role
> of registration policy, and their scope in Rationale-02 and
> Protocol-05 is satisfactory (R.9, R.27, P.6).
> 
> (4.d) The description of the Bidi changes between IDNA2003 and
> IDNA2008 in Rationale-02 is satisfactory.   (R.15)
> 
> (4.e) The description of detecting domain names in text and how
> it interacts with the idea of alternate label separator
> ("dotoid") characters is adequate in Rationale-02  (R.23)
> 
> (4.f) The description of the implications of mapping changes
> between IDNA2003 and IDNA2008 is satisfactory in Rationale-02
> (R.28)
> 
> (4.g) The discussion of user agent security issues should be
> retained in Section 6.3 of Rationale.  (R.6, R.19)
> 
> (4.h) The description of why we are using Unicode is
> satisfactory in Rationale-02.   (R.13)
> 
> (4.i) With the new note warning that, while the lookup and
> registration steps in Protocol are similar, they are not
> identical, the structure of the description of those steps is
> satisfactory. (P.10, P.15)
> 
> 
> (4.j)  The text about A-label dislay that now appears in Rationale-02
> is satisfactory.  (R.20)
> 
> 
> 
> (5) IANA Considerations and table changes.
> 
> (5.a) The IANA considerations section setting up the Contextual
> Rule registry (in Tables, taken from Protocol at -03) is
> satisfactory.   (R.8)
> 
> (5.b) We are agreed that changes to the table-defining rules,
> and especially to lists of contextual rules and exception
> characters, require IETF consensus and publication of a new
> RFC.   (R.12)
> 
> (5.c) The IANA registry for contextual rules should be
> maintained with a "last updated" date.   (P.16)
> 
> (5.d) The contextual rules themselves should be specified and
> maintained as procedural steps, as discussed in Dublin. (P.2,
> P.3)
> 
> 
> NOTE NEW BUSINESS ADDRESS AND PHONE
> Vint Cerf
> Google
> 1818 Library Street, Suite 400
> Reston, VA 20190
> 202-370-5637
> vint at google.com
> 
> 
> 
> 
>