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

From: Vint Cerf <[email-masked]>
Date: Tue, 1 Sep 2009 21:41:05 -0400

this need not be a change to punycode - it is a change to the input to  
punycode.

v

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

---

From: JFC Morfin <[email-masked]>
Date: Wed, 02 Sep 2009 04:31:26 +0200

>this need not be a change to punycode - it is a change to the input to

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

>>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

---

From: jefsey <[email-masked]>
Date: Wed, 02 Sep 2009 03:39:29 +0200

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.

- 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

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Sep 2009 04:00:00 -0400

--On Wednesday, September 02, 2009 04:31 +0200 JFC Morfin
<[email-masked]> 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.

This is just personal opinion, but, although I see the issue and
its resolution differently, you are probably correct for the
long term.  As Paul Hoffman noted, the whole issue about being
able to use Punycode in a case-sensitive way was something that
only Adam wanted to do (and comment on) but the nature of the
IDNA2003 process is that no one had the energy to push back on
that point.  If, as I have suggested to Martin in another
context, we can get this round of documents finished and start
working on a rewritten (but technically equivalent) set for
Draft Standard, that will be the time to fix Punycode, not
exactly by changing it, but by noting that the particular
case-sensitive feature and the supporting appendix have not been
significantly used and, when they have been used, that they have
mostly caused trouble... and then tearing them out on that basis.

That doesn't change the input-control issue or solution,
however: it is, IMO, the right answer for IDNA2008 just as it
was the right answer for IDNA2003 (although the mandatory
mappings there smoothed over the edge cases).

> I
> just wander what is the difference with Nameprep. 

Nameprep is not used at all in IDNA2008, but is a
now-essentially-obsolete component of the IDNA2003 mapping
model.  If IDNs were its only use (and they might be), then we
are essentially abandoning it.

>...

best,
   john

---

From: JFC Morfin <[email-masked]>
Date: Wed, 02 Sep 2009 15:09:39 +0200

Quickly about "nameprep", I just meant that all the constraints many 
will not observe actually builds a virtual canonalization filter that 
has to be implemented somewhere.

Nobody implements something without an incentive. The IDNAPLUS 
concept (same reasoning as Internet Plus) is to say IDNAPLUS = IDNA + 
IDNAPLUG, and IDNAPLUG means additional client side services that - 
if we are cute enough in proposing a client architecture with 
services people want or get used to - may lead to a bundled use.

This is the network of usages (brainware - metacoms - meanings) of 
the common network (software - datacoms - passive and active content) 
of local networks (hardware - telecoms - signal). This is how we 
built the international network at the beginning, not with OSI or 
X.25, but by standardisation by usage. The Tymnet International 
bundled diversity of personalized and multilingual naming, credit 
card validation, no-spam emails, airline reservations, bank 
transaction support, multi-vendors protocol support, externets etc. 
_services_ Thses services were de facto bundled by the monopolies 
locally and between themselves. The monopoly today is the digital 
ecosystem necessary ICTS intergovernance/interadminance. The key 
letter is S for services. This is this de facto common monopoly 
stability that the presentation layer and the IDNAPLUG permit to 
serve and consolidate. Also to turn into havoc if it does not come 
with its mechanic enforcement. This the common protection we need to 
build. This can be worse than altroots, spam, viruses. This can only 
be through adequate brainware (not only hardware [middleboxes] and 
software [protocols]) oriented thinking. This calls for the 
adhesion/critics of brainware co-experts: users, sociologists, 
semioticians, multilinguists, brain scientists, PR and marketing 
people, philosophers, cosmologists, press, etc. etc. and politics.

When people start using a package, they use the whole package (this 
is Chrome's idea - but I disagree with Google's centralization 
culture). We here are on the service plane (people have needs, they 
do not want solutions, they want services - something Google is the 
only one to have really understood, hence the response, and Microsoft 
move). To stabilize and open all this in a more or less concerted and 
competitive way (coopetition) we need to acknowlddge, develop and 
deploy a brainware (people use) strata. Interplus is a generic 
concept of open network client architecture. It needs a common vision 
(IDNA shows that the Internet supports it at datacoms level) 
supported by a common interoperating system. This is what I name 
"netix" and which has to be explored (John Day has probably some 
ideas but I have not the time to read his book). The interest of 
Interplus is that it is a delivery system, not a transportation 
system. This way it only enhances, automates, facilitates the use of 
the passive content transportation systems (Internet, regular mail, 
video, etc. ) and houses the user client networked applications that 
will build what some wants to call an NGN, which are optional 
pseudo-network services delivering active content. This is where we 
can take over the exploration of the intercomprehension facilitation 
strata to support people relational spaces.

All this must encapsulate (certainly not affect - millions of 
nameservers to be strictly preserved) the Internet strata. So, your 
resolution are, IMHO, fully compatible as being "on the wire". As the 
whole internet value added they benefit form the telecoms "through 
the wire" signaling basic services. Mine are "post-wire" extended 
services (my department in 1985). All this is physically, logically 
tied together. However, past the prototyping test/evaluation and 
distributed intertest validation period, pious wishes do not work 
well to secure/ensure the whole thing in a distributed human/crook 
environment. They are "off-wire" wishes. All this is brainware (the 
way people decide to use IDNA for example). For brainware to work 
nicely it must be rooted in software by usage. Usage is simple: 
whatever is fun, useful, harming or making money will be used. It is 
"easy" to enforce: make it much easier than misusage.

jfc