Re: [iucg] Comments on draft-ietf-idnabis-defs-10

[JFC Morfin <[e-mail]>]

At 03:41 02/09/2009, Vint Cerf wrote:
>this need not be a change to punycode - it is a change to the input to
>punycode.
>v

You decide what you send to IESG for it to be accepted. However, IMHO 
a change to punycode is the only way to enforce, protect, and deploy 
a mandatory change to punycode inputs. I just wander what is the 
difference with Nameprep. Anyway, IDNAPLUS will be IDNA conformant 
and support lowercasing among other things. This should address most 
of the problems we faced so far and permit to remotely upgrade and 
protect non-IDNA name servers. I understand this is in phase with IAB-IDN.
Well done.
jfc


>On Sep 1, 2009, at 9:39 PM, jefsey wrote:
>
>>At 22:01 01/09/2009, Vint Cerf wrote:
>>>let's go with the "make sure the XN-label string is in lowercase
>>>before converting to U-label"
>>
>>There is only one way to make this sure, it is in amalgamating it as
>>a canonalization within the algorithm (so there is no confusing
>>constraint on A-labels, and IDNA behaves in tune with the DNS - U- 
>>label equivalence being through identity of the canonalized A- 
>>label). This is no problem with me, as I think it is the only way to
>>get a foolproof solution. I agree, as Wil pointed it, this change
>>should not contradict existing IDNA2003 implementation. The same for
>>other Charter requirements. However, it _is_ a change in the
>>punycode algorithm (as reported, at IUCG we call it, for clarity
>>purpose, the "punyless" algorithm). So, this is another disrespect
>>of the Charter.
>>
>>I therefore raise the question of:
>>
>>- a second tuning of the Charter to prevent IETF/LC objections.
>>- the other generic amalgamation we plan (considering how to best
>>specify once IDNA2008 has stabilized) in order to offer a support to
>>orthotypographic semantic constraints such as French majuscules,
>>protocol mappings, security features, UTF-8/ACE conversion, dynamic
>>name services, etc. For clarity purposes we call it "punyplus" 
>>(http://punyplus.org ). It could be supported by an OPES as a 
>>two-stage algorithm
>>(punycode + punyplug) which could use ISO 10646 dedicated extensions.
>>
>>jfc