[iucg] consensus over PVALIDs

jean-michel bernier de portzamparc jmabdp at gmail.com
Tue Dec 1 02:54:01 CET 2009

I am afraid we also have traveling linguists to consider.
I am quite unatease with specfic cases.
I would prefer to discuss PVALIDIty criteria.
What is we miss equivalent issues in less familiar languages?
Why would the .gr Manager or the youth of Martin be of a particular impact
on a global Internet protocol?


2009/11/30 jefsey <jefsey at jefsey.com>

>  Dear all,
> Vint Cerf has called for a consensus. Actually we are in a multiconsensus
> configuration that the IETF does not support. We have three different trade
> consensuses (see below) which might conflict. In such a situation
> multiconsensus rules say that:
> 1. each group should define its own consensus
> 2. document the way each group's solution can interoperate with the two
> other groups.
> 3. document their consensus over that interoperation being possible or not
> possible.
> I read at least three different trade visions which are:
> 1.* the internet designers* : this is the bulk of the participants since
> we are on an IETF list. They consider the IDNA support of IDNs through LDH
> domain names. They wants a better performing IDNA because making the
> Internet working better is the mission of the IETF, and that is why the
> Internet work. Consensus is for PVALID.
> 2.* the manufacturers* : Unicode people (Mark, Shawn, etc). They know
> that  costs and pains are higher in adaptation than in development. Also
> that small changes at the network level may imply big changes at the
> production and operation level. I note that (1) they worry about one letter
> (having an alternative) in two languages but do not care about Latin
> majuscules which represent 26 (no alternative) semantically damaging letters
> in a dominant set of languages (2) hence a necessary alternative or
> alteration to IDNA; (3) the real cost is in the delays.
> 3. *the internet users *: these are ccTLDs and lead users (@larges). We
> are used to work on a multiconsensus basis by necessity. We consider IETF
> Internet layers as value added dumb bandwidth we can use the way we need. We
> oppose mapping at protocol level as it impacts on the IDNA orthotypographic
> neutrality (and probably on network neutrality due to possible poor
> understandings by some developpers or too good understanding by some
> hackers.). We certainly share the concerns of Mark and Shawn, but we only
> are interested in them being _*supported*_*when*_ we need it, not _*
> enforced*_. Supported means at a layer we control. Enforced means at a
> layer we do not control. This is why we want the network layers to stay as
> dumb as they should be (RFC 1958, this is the whole IDNA2008 purpose as we
> see it); and why we include in our machines two extra layers for a smart
> pseudo-network (Interplus) where we can do everything we want (including
> ML-DNS transcoding and DNS resolution).
> I know the Interplus may represent at protocol and naming layers far worse
> a nightmare than NATs represent at addressing layer. But I did not develop
> it. I do think that it might be worth to address the danger it may represent
> if poorly used/governed rather than to oppose the messenger.
> jfc
> _______________________________________________
> iucg mailing list
> iucg at ietf.org
> https://www.ietf.org/mailman/listinfo/iucg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20091201/0e549bd7/attachment.htm 

More information about the Idna-update mailing list