SV: Consensus Call Tranche 4/5 (Settled Textual Issues and IANAConsiderations

[Anne-Marie Eklund-Löwinder]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

YES.

Anne-Marie Eklund Löwinder
Quality & Security Manager
.SE (The Internet Infrastructure Foundation)

PO Box 7399, SE-103 91 Stockholm, Sweden
Visits: Ringvägen 100 A
Switchboard: +46(0)8-452 35 00
Direct: +46(0)8-452 35 17
Mobile: +46(0)734-31 53 10
E-mail: anne-marie.eklund-lowinder at iis.se
Website: http://www.iis.se
 

> -----Ursprungligt meddelande-----
> Från: idna-update-bounces at alvestrand.no 
> [mailto:idna-update-bounces at alvestrand.no] För Vint Cerf
> Skickat: den 6 oktober 2008 23:00
> Till: idna-update at alvestrand.no
> Ämne: Consensus Call Tranche 4/5 (Settled Textual Issues and 
> IANAConsiderations
> 
> 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/00
> 2537.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
> 
> 
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wj8DBQFI7KwCpdzwAUKxz5QRApVYAJ9MA9C/U98/2PDPw5XEShmeH9tssACfSr4q
wx56mpLSFMODH2YJiQ/9FaM=
=4+1Y
-----END PGP SIGNATURE-----