Subject: Re: [iucg] Stop me if I've misunderstood...

From: Marie-France Berny <[email-masked]>
Date: Thu, 9 Jul 2009 00:16:46 +0200

Gervase,
Mark gives a very fair account of the Unicode sub-problem he faces. The same
as you gave a very fair account of the UI sub-problem you are concerned
about. However, prior to addressing sub-problems we need to address the main
problem. The main problem is that:

- (1) none of the existing tools sets (browsers, protocols, codes,
procedures, applications, IDNA2003, etc. ) is prepared to answer the demands
of the linguistic diversity.
- (2) users (China, Russia, Francophonie, Arabic communities, etc.) have now
the capacity and the will (after 10 years delay) to support their own
aspects of this linguistic diversity by their own. They also distrust/oppose
the ICANN IDNA strategy.

So the issue is simple. We need find the exact level of flexibility in
mapping to avoid the end of the Internet either because it becomes chaos (as
you point it) or because users build their own Internet (like China, etc.).
There is a possible consensus in this WG that this depends on the location
where the _mappings_ apply (plural depending on the 30.000 linguistic
orthotypographies eventually involved). This WG is not chartered to go any
further than _permitting_ this flexibility and seems to have made some good
work with the mapping document. It should be the reasoning basis for further
orthotyporaphy support, language by language. Orthotypography being now
mandatory because of the semantic value given to the DNS, awaiting the
semantic addressing.

The IUCG, under the france@large leadership, motivated by the inability of
the current proposition to correctly support the French orthotypography and
the need to support of the Semantic/Semiotic Internet (Intersem), has
prepared an architectural extension (Interplus) that enacts (not create) the
Internet presentation layer in a possibly reasonable manner (everyone can
use it the way one want). This permits the user, the browser, the
applications to work within a "presentation" without bothering about all the
currently discussed details. The presentation they use is then related to
the rest of the world through a "pseudo-network" layer which make them
believe that they relate with a default Internet using the _whole_ Unicode
set and any additional semiotic coding they may want to use.

Depending on presentation (i.e. character set, language orthotypography,
local environemnt, knowledge metastructure, etc.) there will be application
and parametering at several layers, including protection against phishing,
spamming, etc. However, all this "under the hood" mechanics should be
transparent to the user and certified by an authority (ICANN, IANA, his
Government, ISOC, his user association, you name it) he/she trusts and
others will watch and criticize in order to protect interoperability and
interintelligibility.

The interest of this approach is that it will only require the design and
development of something very comparable to a firewall and absolutely no
change in the existing Internet, that ISP could even deploy on their side of
their Internet connexion. This is something many ISPs round the world, are
already used to - for example to support Chinese names.

I hope this helps.
Marie-France Berny

2009/7/8 Mark Davis ⌛ <[email-masked]>

> That is, in fact, the current outcome, because of two issues:
>
>    1. There are 4 characters that are valid in both IDNA2003 and IDNA2008,
>    but will direct to to different IP addresses. So if you send a friend a URL,
>    he could end up going to a different site, if you have different browsers or
>    different browser versions.
>    2. There is a proposal to add a mapping to IDNAbis that would be "UI
>    only", and optional. This is to handle user-expected variant differences:
>    case, width,... That would also end up with problems with "bus-ability" in
>    that whether a URL gets mapped is left up to the user-agent's choice, and
>    what it thinks qualifies as "UI", and even whether the mapping is changed
>    (the mapping is a SHOULD). And there is no current requirement that the
>    mapping be compatible with IDNA2003, so we get the same problem as #1.
>
> My opinion:
>
> This is a rather bad situation -- for interoperability and security, let
> alone the user experience -- but that people in this group just don't
> realize it yet because they haven't gotten enough feedback from people who
> are concerned with interoperability and security. In particular, I believe
> that:
>
>    1. We should have differences from the current state (IDNA2003) that
>    cause a URL to go to a different site *only* if there is overwhelming
>    justification and little negative impact.
>       1. There is convincing evidence that this divergence is necessary
>       for two characters: ZWJ, and ZWNJ. Fortunately these are extremely low
>       frequency characters in current URLs within web pages, so the negative
>       impact is quite limited.
>       2. There is not overwhelming justification for the two others:
>       es-zett (sharp S) and final sigma. As a matter of fact, the German NIC has
>       come out against the former. We do not have enough involvement from the
>       Greek community to have any real case for the latter. And these are
>       extremely frequent characters in the respective language communities.
>       2. We should have a mandatory mapping applied to all lookup (whether
>    "UI" or not "UI"), whereby for any cases where IDNA2003 also maps, they must
>    have the same result. Failing that, we should not provide any mapping in
>    IDNA.
>
> Mark
>
>
>
> On Wed, Jul 8, 2009 at 13:03, Gervase Markham <[email-masked]> wrote:
>
>> I must confess that I've not had time recently to follow carefully the
>> discussions about mappings. If that means that some people consign this
>> message to the bit bucket, so be it.
>>
>> At the moment, standard domain names have what I'll call "bus-ability" -
>> that is, if you see them in an advert on the side of a bus, you can
>> write them down, type them into any web browser or other domain
>> name-using client later, and you'll end up at the place intended by the
>> creator of the advertisement. IDN domain names under the current version
>> of IDN have, as far as I understand it, pretty much the same
>> "bus-ability" property. In the IDN case, what the user types has to be
>> first normalized, and then converted to punycode. The user in no way
>> needs to know or care about this extra technical complexity. It just
>> works.
>>
>> I would assert that this property is pretty key to keeping the web
>> working in a sane and, importantly, secure manner. People convert domain
>> names from print/voice/memory to computer and back all the time.
>>
>> If the standards were to change in such a way that it becomes quite
>> legal and conforming that typing a set of characters into browser A
>> takes you to website Q, but typing the same set into browser B takes you
>> to website R, I would politely suggest that those who wrote the new
>> standards had taken leave of their senses. This is a recipe for chaos.
>> And phishing.
>>
>> This incredible outcome is not a serious possibility, is it?
>>
>> Gerv
>> _______________________________________________
>> Idna-update mailing list
>> [email-masked]
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>
>
>
> _______________________________________________
> Idna-update mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>

---

From: JFC Morfin <[email-masked]>
Date: Thu, 09 Jul 2009 01:46:34 +0200

Ouahou!  Marie-France what a summary!
Let me add a few comments :

At 00:16 09/07/2009, Marie-France Berny wrote:
>It should be the reasoning basis for further orthotyporaphy support, 
>language by language. Orthotypography being now mandatory because of 
>the semantic value given to the DNS, awaiting the semantic addressing.

You can say that orthotypography is advisable, not mandatory. This is 
not a part of their Charter.

>The IUCG, under the france@large leadership, motivated by the 
>inability of the current proposition to correctly support the French 
>orthotypography and the need to support of the Semantic/Semiotic 
>Internet (Intersem), has prepared an architectural extension 
>(Interplus) that enacts (not create) the Internet presentation layer 
>in a possibly reasonable manner (everyone can use it the way one want).

You mean that everyone else can use the Internet presentation layer 
the way he wants and create havoc if this is not coordinated.

>This permits the user, the browser, the applications to work within 
>a "presentation" without bothering about all the currently discussed 
>details. The presentation they use is then related to the rest of 
>the world through a "pseudo-network" layer which make them believe 
>that they relate with a default Internet using the _whole_ Unicode 

This is a part in Pete's document that seems to create a problem to 
Mark. May be the best way to make this understood is to suggest 
participants to think about the Microsoft Natal product and how it 
will relate with the DNS. In the same way as IDNA, but not through Unicode.

jfc

---

From: Gervase Markham <[email-masked]>
Date: Thu, 09 Jul 2009 11:56:07 +0100

On 08/07/09 23:16, Marie-France Berny wrote:
> Gervase,
> Mark gives a very fair account of the Unicode sub-problem he faces. The
> same as you gave a very fair account of the UI sub-problem you are
> concerned about. However, prior to addressing sub-problems we need to
> address the main problem. The main problem is that:
>
> procedures, applications, IDNA2003, etc. ) is prepared to answer the
> demands of the linguistic diversity.

I know little of ICANN politics or the relationship of your group to 
them, the IETF, or any other organization whose acronym begins with an 
I, but it seems self-evident to me that the above is not "the main 
problem", at least not for this group. We are not here to boil the sea.

Life is imperfect. Unicode is imperfect. The DNS is not capable of 
representing all words in Latin-script languages, let alone words in all 
the other scripts. I can't have www.O'Markham.org. If there is an 
expectation from some language communities that every single word they 
can think of to type in can become a valid and different domain name, 
then they will be disappointed, just as the English and other 
Latin-using language communities have been for the past 30+ years. If 
that makes them go off and form a separate Internet, there's little we 
can do about it apart from tell them they have unrealistic expectations.

Gerv

---

From: Marie-France Berny <[email-masked]>
Date: Thu, 9 Jul 2009 15:09:17 +0200

Gervase,
your questions are a repetition. Your broadside of points is an excellent
way for us to check our positions. Thank you. You definitly are an "IETF
user" like us (IUCG stands for Internet users contributing group). We take
"users" as Internet and RFC lead users.

In initating the IUCG, the initial idea was to limit ourselves to inputs and
comments. The IAB asked us more so they could discuss with us over formated
inputs. This is in line with RFC 3935 which says that "The IETF has
traditionally been a community for experimentation with things that are not
fully understood, standardization of protocols for which some understanding
has been reached, and publication of (and refinement of) protocols
originally specified outside the IETF process." We take that our job also as
to specify protocols in _parallel_ to the IETF process, in the hope it could
speed up the internal as well as the external process.

We do not feel at ease with the "acquisition" of the IETF by ISOC (this is
the way we read some of the ISOC documents to their sponsoring members). We
consider ICANN as an interesting source of (good and bad) experience in the
"IN" class and default ASCII presentation.

2009/7/9 Gervase Markham <[email-masked]>

> I know little of ICANN politics or the relationship of your group to them,
> the IETF, or any other organization whose acronym begins with an I, but it
> seems self-evident to me that the above is not "the main problem", at least
> not for this group.

This is correct as the main problem I explained is not point (1) or (2) but
the conjunction of both.

> We are not here to boil the sea.

Correct but as you may know the global warming takes care of it. And we must
cope with it.

> representing all words in Latin-script languages, let alone words in all the
> other scripts. I can't have www.O'Markham.org.

Dear, why would you not ??? This is precisely the purpose of IDNA. Why would
the Scottish language be limited by IDNA?

> If there is an expectation from some language communities that every single
> word they can think of to type in can become a valid and different domain
> name, then they will be disappointed, just as the English and other
> Latin-using language communities have been for the past 30+ years.

I am afraid you confuse disapointment in the Internet and disapointment in
the Internet standards and ICANN commercial management. This kind of
self-imposed technical and R&D limitations on commercial grounds is
chastised in the IAB RFC 3869.

> If that makes them go off and form a separate Internet, there's little we

The problem is not that one. The problem is how realistic is it to behave as
if the rest of the world could not circumvent this IETF imposed
disappointment. While we are documenting it. It will be a Draft as soon as
we understand how to port our bilingual wiki document under an RFC-Editor
acceptable entry in unsing XML2RFC.

Take care.
Marie-France Berny

---

From: jefsey <[email-masked]>
Date: Sat, 11 Jul 2009 22:05:21 +0200

At 19:06 11/07/2009, jean-michel bernier de portzamparc wrote:
>Might we first define what mapping means in order to be sure that when
>we use the word "mapping" we do not initiate unexpected side effects.
>
>I understand mapping as transcoding at the same layer and resolving as
>cross-layer transcoding.
>
>Best
>Portzamparc

Jean-Michel,
thank you for reminding us. I think we need to insert it in the DN part.

- mapping : transcoding at the same layer level - a -> b (name.a -> name.b)
- restoring : back-mapping - b -> a (name.b -> name.a)
- resolving : down-layer transcoding  a -> 12.111.31.22 (name -> address)
- reversing : up-layer transcoding  12.111.31.22 -> a (address -> name)

The habit in the DNS family is to use LDH for "a" or "b" in this 
example (Letter, Digital, Hyphen). The way we clarify the DNS I will 
prefer to speak of "name" and "address", since we consider DNS labels 
and sub-labels made of 0-Z figures and civic and semantic addresses 
are strings.

Best
jfc

---

From: Marie-France Berny <[email-masked]>
Date: Sun, 12 Jul 2009 18:35:08 +0200

Not much my cup of tea, but I feel there is a missing difference depending
on the context. I mean that "converting" could be better than resolving if
the result is not final. For example would not converting better for an UDN
to an ADN or to an IDN, and resolving for an IDN to an IP?

Also, may would we want to introduce "aliasing" by the same tocken.

What is interesting is that this general wording includes string to string
mapping (like ss to eszett) and char to char as the greek final s.

Salut et bonne vacances à tous. Vu l'incroyable superbe anglo-saxone qui
traite allégrement des caractères allemands, turcs, grecs, français à tue
mieux mieux, il serait peut-être plus judicieux de continuer le débat en
tagalog (y a même l'antiborg de service qui ramène son klingon !)

Marie-France Berny

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

> The habit in the DNS family is to use LDH for "a" or "b" in this example
> (Letter, Digital, Hyphen). The way we clarify the DNS I will prefer to speak
> of "name" and "address", since we consider DNS labels and sub-labels made of
> 0-Z figures and civic and semantic addresses are strings.
>
> Best
> jfc
>
>
>
>
>
> iucg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iucg
>

---

From: jefsey <[email-masked]>
Date: Sun, 12 Jul 2009 22:39:45 +0200

At 18:35 12/07/2009, Marie-France Berny wrote:
>(y a même l'antiborg de service qui ramène son klingon !)

C'est un espion de ta Reine des Borgs. Il est payé par Unicode comme 
chien de garde. Il en a reçu le prix "Bulldog". Excellent typographe 
au demeurant.
jfc