Re: governance vs intergovernance

Dear John,
I understand where you come from with this point. But the point here is 
quite the opposite. It is to say that I am entitled to see my culture 
respected and that culture to self determine the way it wants to express 
itself on the internet.

For example, a question debated in here in many accoasion is ; to be case 
sensitive or not? This is not a question for the IETF. This is not a 
question for the Mail service provider, this is a question for the user to 
decide what he wants.

But non only the IETF specification must permit it, but it must deliver a 
tool which will permit the user to decide a parameter set according to the 
Academic, Politic, Family, whatever Lingual Authority he wants to chose.

This may have a lot of implication. MINC rises the point of ".xxx" being or 
not translated by ICANN decision. They say it is to be by lingual 
organization decision. Why? Because most of the Arabic countries are 
Moslems, and they oppose pornography in their constitution. Not translating 
it permits to address the demand of the users to protect them against this 
risk - because "xxx" cannot not be typed easily on an Arabic keyword.

You will say that they could bar it.
- one: this is not to others to decide for their law. Would you accept 
easily if the US car driving had to adapt to the French standard because 
internationalized (you must come back on the right lane on an highway) ?
- two: there is a big difference between censoring and not helping.
- etc.


On 02:56 08/06/04, John Cowan said:
>J-F C. (Jefsey)  Morfin scripsit:
>
> > The question is: can the above strategy, together with the
> > IETF disclaimer below, be copied for LHS for average registrants,
> > when RHS (ie. ccTLD) leads to situation inflaming international
> > highly representative organizations?
>
>Yes.  Indeed, it will work better for email providers, because there are 
>many of them in most environments.  Each can set a private policy
>about what characters, or sequences of characters, they will or will not 
>accept in local-parts.

We are not only talking of e-mail providers but of every mail. This is a 
standard. Let say this. You have your email system home. You define a 
configuration and you discover that a new standard has killed your 
configuration because some other people said they known better what was 
good for you. And you discover that the new configuration doe snot conform 
to the law. Then that it violates your beliefs.

What would you say?

>In general, companies are far less malleable under political pressure than 
>government agencies.  The only way to forcibly shift one from its policy 
>will be by private lawsuit, and in a vanishing number of cases will it be 
>worth doing that rather than just switching to another email provider.


hmmm. I hope you do not mean that Govs are malleable under the pressure of 
a foreign Gov? Again we talk of universal standard which are to respect the 
sovereignty, the law, the decision of countries, of states, of people. A 
standard is not here to force because the designer was not able to do 
otherwise, it is to serve the users to dialog together the way they want. 
The first human right on a network is to be able to refuse. To refuse 
hackers, to refuse spam, to refuse adult picture, to refuse cultural 
corruption, to refuse privacy violation (you will note that all these 
points which look quite political, legal or societal are parts of the LHS).


IMHO the LHS (and more generally the whole mail solution) should stay 
untouched. Because it is here. No one can object to all what it may provide 
today. This permits the current minimum to stay. Then this should be 
considered as the low level structure of the new system encapsulating it. 
The propositions today should therefore be user layer oriented. Then the 
technical underlaying structure will be able to adapt, and probably 
simplify in the future. The "mail layer" is too complex. Let split it in 
adding a new layer, an interface and leaving part of the current system 
obsoleting. Leave users organizations specify the user layer or debate it 
with manufacturers. Let just help them simplifying the current solution 
when possible.

Otherwise, how do you want to provide what people most need today : address 
menus? target groups? originating classes? issue related addresses, 
multilingal relations (I send in one language, I receive in another one, or 
several ones depending on copies), etc.
jfc