AW: Sharp-S and Final Sigma Consensus Call Results

[Vint Cerf]

Mark, et al,

I believe that the documents as they now stand are reasonable to  
forward to the IESG.
The way in which these documents are applied (including any transition  
plan(s)) need not
affect the documents, I believe. It is my guess that transition will  
occur registry by registry
and application by application (not only browsers) over a potentially  
extended period of time.

Because transition implementation is not likely to be something that  
IETF can either dictate
or enforce, we are going to have to offer non-mandatory advice. Some  
of the ideas that
have been expressed on the list appear to me to fall into that category.

As I mentioned in my brief note responding to Gervase, I am going to  
try to offer a synthesis
of transition tactics tomorrow if possible.

v

On Dec 10, 2009, at 12:16 PM, Mark Davis ☕ wrote:

> While we could all declare Mission Accomplished, and push this out  
> the door as is, if there is no viable transition strategy and the  
> best implementers can do to support their customers in avoiding  
> compatibility and security problems is to map, then they will map-- 
> no matter what the consensus among the thirty-odd individuals in  
> this WG is.
>
> If a viable transition strategy can be formulated for avoiding  
> problems during the transition, I don't think there is any problem  
> with having these 4 characters be PVALID. That strategy needs to be  
> part of the IDNA specification, so that we don't get dozens of  
> different transition strategies. It appears to me that we are still  
> in the midst of that discussion, because it never got serious  
> attention beforehand. So closing off such a discussion would be  
> premature, no matter how sick and tired we are of the IDNA issues.
>
> Mark
>
>
> On Wed, Dec 9, 2009 at 22:37, "Martin J. Dürst" <duerst at it.aoyama.ac.j 
> p> wrote:
> Hello John, others,
>
> I agree with half of Shawn, namely that this should be a MUST NOT.
>
> The reason is that there have been many people on this list that say
> that this is a really bad idea, but on the other hand, there have been
> serious proposals (read TRs) to just do that.
>
> Regards,    Martin.
>
> On 2009/12/10 6:18, John C Klensin wrote:
> >
> >
> > --On Wednesday, December 09, 2009 21:40 +0100 Alexander
> > Mayrhofer<alexander.mayrhofer at nic.at>  wrote:
> >
> >>>> I am supporting PVALID for both Sharp-S and Final Sigma,
> >>>> given that mapping of PVALID characters is disallowed.
> >>>
> >>> Mapping of PVALID characters is *not* disallowed in
> >>> draft-ietf-idnabis-mappings-05.
> >>
> >> I understand. An i don't think draft-ietf-idnabis-mappings
> >> should be the place where mapping of PVALID characters should
> >> be disallowed - it's an Informational document.
> >>
> >> The rule would need to be in one of the Standards Track
> >> documents.
> >
> > Since I'm trying to look at text this afternoon and evening, is
> > there agreement that it would be wise to add a "SHOULD NOT
> > change the interpretation of valid strings by mapping PVALID
> > characters to anything else" to the portion of Protocol where
> > mapping is mentioned, or should (sic) I leave well enough alone?
> > If the former, is that a correct statement of the proposition?
> >
> > Note that such a statement would make Sharp-S to "ss" mapping
> > not-fully-conformant to IDNA2008, even though "SHOULD" does
> > leave an opening...
> >
> > Vint?
> >
> >      john
> >
> > _______________________________________________
> > Idna-update mailing list
> > Idna-update at alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/idna-update
> >
>
> --
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp   mailto:duerst at it.aoyama.ac.jp
> _______________________________________________
> 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/20091210/c6b80bcd/attachment.htm