Subject: [iucg] consensus over PVALIDs

From: jefsey <[email-masked]>
Date: Mon, 30 Nov 2009 17:16:01 +0100

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

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Tue, 1 Dec 2009 02:54:01 +0100

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?

Portzamparc

2009/11/30 jefsey <[email-masked]>

>  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:
>
> 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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iucg
>
>