support of metadata

Elisabeth Blanconil eblanconil at gmail.com
Mon Sep 21 18:04:54 CEST 2009


François,

the issue is as usual a common tussle (cf. Dave Clark,  John
Wroclawski, Karen R. Sollins, Bob Braden :  Tussle in Cyberspace:
Defining Tomorrow's Internet:
http://conferences.sigcomm.org/sigcomm/2002/papers/tussle.pdf). What
Jefsey, in a recent mail, called the "hand to hand" new internet
architectural fundamental principle.

Here, the tussle is about the linguistic diversity scripting
bandwidth: what commercial sponsors (RFC 3869) allow engineers to work
out vs. what the internet users demand (and will implement anyway).
The working example is the French language (not the language of
France) because we know it, it is a good example of diversity
(francophonie) and all of us are not French. To explain Jean-Michel
mail, rules about accents and small capital for postal addresses are
not the same in France and in Swiss. This means that if we relate a
domain name to a civic or postal address (RFC 4776) what is not only
advisable but necessary when TMs are involved, we have a conflict.

So our position is simple "qui peut le plus peut le moins". We want to
make sure IDNA, or at least IDNABIS with a possible 100% IDNA
compatible dowgrading, does support the "worst" legal and use cases.
Martin Dürst told us there were similar problems in other European
languages, but the issue is technical not linguistic.

Now, neither engineers nor lead users have the monopoly for finding
solutions. This is why an iterative dialog is necessary. Also, there
are in life two kinds of technologies - the one for the machine side
(engineering and manufacturing) and the one for the people side
(interface and know how). Some tasks are better located on one side or
the other. This is why we have started completing the Engineering's
effort to "influence those who design, use, and manage the Internet
for it to work better" by the lead users contributions in order to
help those who design, use, and manage the internet for them to use it
better.

For example, what Gervase says is wikipedia knowledge. Wikipedia
forgets the diversity of laws, orthotypography of more than 50
countries and national French based cultures. Wikipedia does not know
either about the innovative capacity of IETF participants. We all know
that the issue is not that simple - otherwise ICANN could have solved
it without calling on the IETF. This is why we are here: to make a
complex technical challenge simple to the users, not to make it simple
to us in constraining it within the limits of our existing
architectural inabilities. If our target is to match the past I am
afraid Ping-Pong (my horse) will not be able to deliver much of this
single mail.

Best.
Elisabeth Blanconil

Le 21 septembre 2009 03:16, François Jacquemin
<francois.jacquemin at free.fr> a écrit :
>
> Le 18 sept. 09 à 00:02, Nicolas Krebs a écrit :
>
>> jean-michel bernier de portzamparc wrote
>>
>>> accentuated majuscules should be
>>> rendered in best mechanical printing as accentuated upper cases,
>>> but should
>>> be rendered as non- accentuated uppercases in manual scripting.
>>
>> Not in French language ( http://www.academie-francaise.fr/langue/questions.html#accentuation
>> etcetera).
>
> You are absolutely right. I strongly agree.
>>
>>
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
> --
> François Jacquemin
> fjacquemin at francois-jacquemin.net
>
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>


More information about the Idna-update mailing list