Consensus Call Tranche 3 (Permanence)

[Mark Davis]

Consensus Call Tranche 3 (Permanence)


> Place your reply here:
>

NO

>
> COMMENTS:
>

The proposal makes promises it cannot guarantee. After all, many people
expected that once a URL was valid according to IDNA2003, it would be valid
forever, but we are with IDNA2008 breaking that for not one or two
characters, but many thousands of characters. And for reasons that are not
just "serious and unanticipated circumstances". So the wording needs to be
fixed.

3a. The permanence of Valid URLs is exceedingly important. The major
breakage between 2003 and 2008 is containable, but we don't want to have
this every 5 years. So we do need to have a strong a language as we can
regarding this. So I would say, that the intent of this should be not to
change PVALID even in serious and unanticipated consequences. But we must
also point out that even this could be overridden in the future by an
obsoleting RFC (as above). So I can see wording somethat like the following.

Once a character is classified as PROTOCOL-VALID, it
will remain in that category for all future versions of the
protocol and tables unless this RFC is obsoleted. It is anticipated that
such reclassification will never occur, given the backwards compatibility
problems that would result.  (R.10)


3b. The permanence of Invalid URLs is a very different case. It means that
we can't fix problems that arise, where for example, minority languages do
need to use a character that ended up in the DISALLOWED bucket, because
people didn't realize the need at the time the character was encoded.

Implementations MUST be set up to deal with formerly invalid URLs becoming
valid all the time -- when the URL contains a code point that was unassigned
in one version, and becomes assigned in the next. Making DISALLOWED be
permanent does not really help implementations (even if people think it
might), and is too strong to allow necessary changes. So in this case, the
language needs to be clearer,

Once a character is classified as DISALLOWED, it will normally
remain in that category for all future versions of the protocol
and tables. However, if further evidence of the necessity of this character
in some language is discovered, it may be moved to PVALID in Tables. Note
that UNASSIGNED characters are not, for this
purpose, DISALLOWED.  (R.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 of a 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.
>
>
>
> (3) Permanence of DISALLOWED and PROTOCOL-VALID
>
> (3.a) Once a character is classified as PROTOCOL-VALID, it
> will remain in that category for all future versions of the
> protocol and tables unless serious and unanticipated
> circumstances occur.  (R.10)
>
> (3.b) Once a character is classified as DISALLOWED, it will
> remain in that category for all future versions of the protocol
> and tables unless serious and unanticipated circumstances
> occur.  Note that UNASSIGNED characters are not, for this
> purpose, DISALLOWED.  (R.5)
> ------------
>
>
> NOTE NEW BUSINESS ADDRESS AND PHONE
> Vint Cerf
> Google
> 1818 Library Street, Suite 400
> Reston, VA 20190
> 202-370-5637
> vint at google.com
>
>
>
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081014/21e1c28b/attachment-0001.htm