I am afraid we also have traveling linguists to consider.<br>I am quite unatease with specfic cases.<br>I would prefer to discuss PVALIDIty criteria.<br>What is we miss equivalent issues in less familiar languages?<br>Why would the .gr Manager or the youth of Martin be of a particular impact on a global Internet protocol?<br>
<br>Portzamparc<br><br><br><div class="gmail_quote">2009/11/30 jefsey <span dir="ltr"><<a href="mailto:jefsey@jefsey.com">jefsey@jefsey.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
Dear all,<br><br>
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:<br><br>
1. each group should define its own consensus<br>
2. document the way each group's solution can interoperate with the two
other groups.<br>
3. document their consensus over that interoperation being possible or
not possible.<br><br>
I read at least three different trade visions which are:<br><br>
1.<b> the internet designers</b> : 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.<br><br>
2.<b> the manufacturers</b> : 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.<br><br>
3. <b>the internet users </b>: 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
_<b>supported</b>_<b>when</b>_ we need it, not _<b>enforced</b>_.
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). <br><br>
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. <br><br>
jfc </div>
<br>_______________________________________________<br>
iucg mailing list<br>
<a href="mailto:iucg@ietf.org">iucg@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/iucg" target="_blank">https://www.ietf.org/mailman/listinfo/iucg</a><br>
<br></blockquote></div><br>