Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation

From: JFC Morfin <[email-masked]>
Date: Wed, 01 Jul 2009 14:19:06 +0200

At 04:18 01/07/2009, Vint Cerf wrote:
>jefsey, it cannot be an A-label since that is defined to include
>"xn--" as a prefix.

Dear Vint,
This is the conflict we have and the resulting confusion.

- usage considers what is enter in usage applications (from the 
entire Unicode set [actually it needs much more (ex.Natal from M$] 
_including_ ASCII)
- I consider what the DNS is asked to resolve after an algorithm 
(including null and punycode ones) has been applied.
- you consider complex U-/A-... labels which do not overlap. 
"Ecole.fra" is not supported by this label list.

"Ecole.fra",
1) it is a U-label
2) but you do not want to support it as xn--cole-abc.fra. You keep it 
as an non punycoded yet A-label without "xn--" prefix.
3) this confuses Andrew and John (who should not be concerned) 
because they try to understand how the DNS and Unicode casefolding 
could support the orthogonal User's casefolding (i.e. orthotypography).

I see no other solution that to carry the mapping:
- at the user application layer (outside of the Internet pile) and 
the Internet should remain transparent to "xn--" labels.
- through a different presentation, and casefolding mapping etc. 
using "xs--" labels.

Neither DNS nor Unicode casefolding are concerned. Only usage's side 
application (this is why the architecture is named IDNA): usage 
casefolding is to be decided and managed by the user through his 
application (if he wants to have it), depending on his own context, 
language, culture, job, kind of application, etc. and if the other 
end supports additional usage side features. This permits an 
application to application relation, where entropic actions (as 
required by the DNS resolution) can be restored through a negantropic 
process supported by metadata exchanges. As Elisabeth explained it.

This being said, if you find a case (so far there is none) where a 
entropic mapping (casefolding or other) is universally accepted by 
users - or restored through a negentropic process such as what we 
call "duplex entities" -, supported by exvery encryption system, 
transparent to other technologies as well (netneutrality), etc. it 
could very well be investigated at protocol level (i.e within the 
Internet pile). Otherwise mapping can only be processed outside of 
the Internet pile. This is exactly the target and Charter of IDNA as 
I read and respect it.

jfc

>On Jun 30, 2009, at 8:42 PM, JFC Morfin wrote:
>
>>At 17:12 30/06/2009, Andrew Sullivan wrote:
>>>and, in particular, if we want to be sensitive to such upper and
>>>lower case when the data comes back to us from the DNS resolver
>>>level.
>>
>>Please, let not confuse :
>>
>>1) the DNS layer, where you run the game the way you want according
>>to your published rules, and the Application Domain Names.
>>2) French majuscules and upper cases.
>>
>>The U-label, A-label, etc. wording IMHO helps that confusion. Is
>>Ecole.fra an U-label or an A-label? All I know is that it is an
>>application domain name (like in "IDNA"). Also, that if the proposed
>>text does not actually document the "ecole.fra, école.fra,
>>Ecole.fra" case, this case will have to be documented during the
>>IETF/LC.
>>
>>May be it is the best thing to do? so the whole IETF community may
>>decide what does concern the whole community?
>>jfc
>>
>>_______________________________________________
>>Idna-arabicscript mailing list
>>Arabic Script IDN Working Group (ASIWG)
>>[email-masked]
>>http://lists.irnic.ir/mailman/listinfo/idna-arabicscript

---

From: Vint Cerf <[email-masked]>
Date: Wed, 1 Jul 2009 08:38:16 -0400

Jefsey, maybe my email rendering code is broken but the string I am  
seeing in your message looks like a purely ascii string making it a  
conventional ascii domain name not requiring any special treatment.

vint

On Jul 1, 2009, at 8:19 AM, JFC Morfin wrote:

> 2) but you do not want to support it as xn--cole-abc.fra. You keep  
> it as an non punycoded yet A-label without "xn--" prefix.
> required by the DNS resolution) can be restored through a  
> negantropic process supported by metadata exchanges. As Elisabeth  
> explained it.
>

---

From: jefsey <[email-masked]>
Date: Wed, 01 Jul 2009 15:13:07 +0200

>conventional ascii domain name not requiring any special treatment.

Vint,
The string you see on your screen is ASCII - the string I enter is 
not. This is because Unicode is being used and Unicode does not 
properly supports the French language orthotypography.

In "Ecole.fra" the semantics demands that "E" is not an "E" ASCII but 
a French "E" majuscule. I am sure Unicode has no problem in 
supporting them, or TLD Tables can be used. "Ecole.fra" is a user 
domain name which may have nothing to do (except phishing) with 
"école.fra", "ecole.fra" and "École.fra".

This means there are wo problems:

- they are to be able to resolve different IP addresses.
- they also are to be able to resolve the same IP address.

However, the decision is only with the registrant. So, the simplest 
is to consider each usage domain name separately. If some are to 
resolve the same IP, the registrant will only register several domain names.

jfc

---

From: JFC Morfin <[email-masked]>
Date: Wed, 01 Jul 2009 16:39:48 +0200

At 15:15 01/07/2009, Vint Cerf wrote:
>jefsey, then your issue is UNICODE and not IDNABIS. Work with them!
>vint

Vint,
Why would I work with Unicode, about what ?? What is true about 
French is probably true about hundreds of other languages?? They are 
grown respected experts. They do for the best - up to them to tell 
what they do. If we wanted them to behave differently, we had to let 
them know before.

Unicode is like the DNS, IDNA and the Internet. They are existing, 
deployed, stable solutions. Our opposition is to time wasting ill 
identified, slow to change, conflicting propositions. All what I need 
is that IDNABIS is published as it is today and that its texts are 
polished by the IETF/LC to make sure they respect the charter, the 
DNS, the IDNA principles and the Internet end to end process. Without 
any technological barrier to open trade.

-----

Now, I suggest that IUCG and france@large members stop participating 
for at least a couple of hours. The target is not to fight other's 
positions, but to find the best way to facilitate the user's life.

Again, we have a three step process which will take some time:

1) let me finish the IUCG Draft(s) I should have completed a mont ago.
2) let us structure the project.fra process
3) let get developped/integrated and tested a few working tools so 
everyone may better understand that we talk about nothing which is 
not here for years.

Thanks to everyone.
Non-IUCG/france@large comments welcome.
jfc

>On Jul 1, 2009, at 9:13 AM, jefsey wrote:
>
>>In "Ecole.fra" the semantics demands that "E" is not an "E" ASCII
>>but a French "E" majuscule. I am sure Unicode has no problem in

---

From: Vint Cerf <[email-masked]>
Date: Wed, 1 Jul 2009 09:15:37 -0400

vint

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Jul 2009 10:54:52 -0400

I don't think I'm a member of the lists you cc:d, so I expect this
will get moderated.  But. . .

On Wed, Jul 01, 2009 at 02:42:01AM +0200, JFC Morfin wrote:
>> and, in particular, if we want to be sensitive to such upper and lower 
>> case when the data comes back to us from the DNS resolver level.
>
> 1) the DNS layer, where you run the game the way you want according to 
> your published rules, and the Application Domain Names.

I am not confusing them.  The fact is that they _are confused_ --
there's no way to distinguish "Ecole.fra" the (all ASCII) LDH labels
and "Ecole.fra" the pair of putative labels that includes an
(unaccented) upper-case "é".  There simply _is not_ a way,
technically, to disambiguate this even if we would like to do so: both
are (in Unicode) LATIN CAPITAL LETTER E.  If you want that fixed, go
talk to the Unicode consortium and get them to change it.  It would
plainly reqire that two glyphs, which both look like "E", get
different code points so that LATIN CAPITAL LETTER E would be
different from UPPER-CASE LETTER E WITH INVISIBLE ACUTE (or whatever
it got named) would actually be different characters.

Whether such an addition to the Unicode code-space would be a good
idea from the point of view of actual users is something entirely
beyond my professional competence.  I will say that I would be
personally surprised to have two characters that always appear to be
identical, but that do not match one another.

Until there are different characters for upper-case e and upper-case é
without the accent, there is no way to get école.fra and Ecole.fra to
match one another, because Ecole.fra already matches ecole.fra.
That's an old, long-standing limitation of the DNS, and since no IDNA
proposal plans to interfere in the resolution path for plain ASCII
characters (which Ecole.fra is, whether you like it or not), it's a
limitation we're stuck with.  

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: JFC Morfin <[email-masked]>
Date: Thu, 02 Jul 2009 00:42:42 +0200

> > 2) French majuscules and upper cases.

Dear Andrew,
I suggest you give me a few days to finish my Interplus Draft which 
is delayed by my family obligations.

>At 16:54 01/07/2009, Andrew Sullivan wrote:

We know and want the DNS does not confuse them: it takes them as identical.

It MUST stay that way. This means that mapping at DNS (protocol) 
service layer MUST not be permitted. Mapping charfacters at the same 
service layer as the DNS is to build a new DNS. This is not permitted 
by the Charter (the IESG and IAB must be involved). Whatever the motivations.

The DNS MUST _entirely_ stay outside of IDNA.

>technically,

Perefectly true. This is why I 100% supports the Chartef which says 
that disambiguation does _not_ belong to the network area. Mapping 
MUST be outside of the protocol.

>to disambiguate this even if we would like to do so: both

This would be pragmatically foolish (irt. pragmatics as a 
discipline), orthotypographycally uncorrect, and semantically confusing.

>identical, but that do not match one another.

This is exactly what the current character mapping debate would lead 
to (interfering with "E", "e", "é", "è", "ë", "ê", Unicode, 
semantics, pragmatics, DNS, IDNA, etc.). IETF is only to document 
where mapping may occur, under which conditions, with which 
consequences. Or it may better not speak about it.

Please also remember that my French example are only an easy exemple 
to type in ASCII of the consequence of the considered Internet / 
Usage strata violations.

>Until there are different characters for upper-case e and upper-case ýA9
>match one another,

Who is asking for that?

>because Ecole.fra already matches ecole.fra.

Who says that? Please do not confuse user domain names and DNS domain 
names. It take one minute to contradict you in using Host.txt.

>That's an old, long-standing limitation of the DNS,

Who is here talking of DNS? Only mapping at protocol layer supporters 
are. And mapping at protocol layer is forbiden by the charter.

Mapping at protocol layer propagates the DNS "e to E to e" DNS 
_feature_ as an IDNA _rigidity_ (at user level).

>and since no IDNA

"IDNA" is a BCP suggesting a proven forrmalization of the way one can 
use the Internet presentation layer. Because the IETF is to " 
influence the way people design, use, and manage the Internet in such 
a way as to make the Internet work better" (RFC 3935). However, it 
should "embrace technical concepts such as decentralized control, 
edge-user empowerment and sharing of resources, because those 
concepts resonate with the core values of the IETF community."

Mapping at protocol level is network centric IETF centralised 
control, mapping at user application is "edge-user empowerment". 
"These concepts have little to do with the technology that's 
possible, and much to do with the technology that we choose to 
create". (Same RFC) Some may push towards different concepts. I 
disagree. Moreover than:
- it is a major strata violation (network vs. user)
- the Internet alternative is in operation for decades (in various 
embryonic manners - I accept this - but very deep in the Internet 
architecture and culture) and nothing can prevent it to be applied. 
However, the risk is that it may scale in a non coordinated ways 
(example: the indecision of ICANN about IDNcc/gTLD policy in the IN class).

jfc

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Jul 2009 18:47:47 -0400

> We know and want the DNS does not confuse them: it takes them as identical.

They are in fact identical code points.  User intention, which is
inscrutable, is not relevant here.

> It MUST stay that way. This means that mapping at DNS (protocol) service 
> layer MUST not be permitted. Mapping charfacters at the same service 
> layer as the DNS is to build a new DNS. This is not permitted by the 
> Charter (the IESG and IAB must be involved). Whatever the motivations.

Nobody was suggesting they get mapped in the DNS.  The question is
whether they get mapped before the DNS, which is IDNA, and I am merely
pointing out that you can't do that because one of the rules was "no
change to DNS".  Since the plan is to put IDNA in between an
application and the DNS, you can't have behaviour in IDNA that is
contrary to the traditional rules of DNS; one of those rules is that E
and e match, and that neither of them matches anything else.

> names. It take one minute to contradict you in using Host.txt.

Clearly, if you enter stray data into the system, you can get a
different result.  That's nowise a premise in favour of your view.

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: JFC Morfin <[email-masked]>
Date: Thu, 02 Jul 2009 12:00:46 +0200

>different result.  That's nowise a premise in favour of your view.

The point is what what do you mean by "stray" and by "system".

I feel you do not make a difference between what the user enter in 
the application and what the DNS receives as a querry. Pete has very 
well documented this point in his Draft. We are considering two systems.
- one is the Internet and its ASCII DNS. The charter says they should 
stay unchanged. IMHO this is an architectural MUST.
- the other is the Internationalized Internet which is made of the 
Internet plus IDNA. The purpose is to permit to use Chinese, French, 
Arabic, English domain names (IDNs) in the Internationalized 
Internet, however they are stray data in the DNS.

To map anything at:
- protocol level, i.e. at the same layer as the DNS, is to build a new DNS.
- IDNA level, i.e. above the DNS Internet application layer, is 
transparent to the DNS and does not build a new DNS. This is the 
whole IDNA idea.

There are therefore two layer violations under discussion:
1. to map at protocol layer. We roughly agree, however my 
architectural motives seem to be stricter than your DNS requirements.
2. to only consider the ASCII Unicode sub-part as a special part: 
this is the linguistic English "bias" of English 
internationalization. We consider that _every_ Unicode sub-part (down 
to code point level) is potentially a special part, while Vint only 
want to cristalize a few of them in the technology itself.

This means that our conceptual premises are equivalent, so please let 
drop disputes on that matter. We only differ in terms of mapping 
flexibility (who decides, for how long) and extension (which code 
points and contexts); also we commonly explore mapping location 
(prior, after or within the punycode algorithm) and should consider 
architectural coherence and stability (how to document the whole 
thing in order to influence a better stability).

I understand there are two main positions:

- to protect the internet from linguistic originated technical 
overload through very limited changes, even if this does not fulfill 
the users expectations. The people supporting this position consider 
linguistic and Unicode details. They also want to use constraints as 
protection of technical status quo.

- to protect the internet from any technical change, because users 
expectations are much more extended than linguistic needs and are 
common to every digital technology: they must therefore be treated 
between the user and the Internet - what is named IDNA in here, and 
we more generally name Interplus. The people supporting this position 
are only interested in presentation layer issues, whatever the 
presentation details. They want no constraints on the Internet 
considering that the overload will more likely result from the 
constraint mechanism and and of its impact on the global network equilbrium.

IMHO, whatever the good reasons the first coalition may propose, they 
will most probably be disregarded by users as unnecessary constraints 
happening to support commercial and political status-quo. My concern, 
if there is no general IETF and ICANN consensus, at least for Class 
IN, a wild IDN usage will deploy.

jfc

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 Jul 2009 07:05:23 -0400

> The point is what what do you mean by "stray" and by "system".

Yes.

> I feel you do not make a difference between what the user enter in the 
> application and what the DNS receives as a querry. 

No.  But there's a subtle and important relationship.

IDNA-oblivious applications pass along whatever is typed in to the
DNS.  This means that entries like é fail completely, but both E and e
succeed.

Therefore, a constraint on any IDNA protocol for dealing with
internationalized names MUST deal with the cases that always were
successfully passed along the same way.  The upshot of this is that
the ASCII e and E have to be treated as the same character.
Therefore, until the E that corresponds to e and the E that
corresponds to é are different code points (which might never happen),
there's no way to get Ecole to correspond to école unless école and
ecole correspond to one another.  Which was the original question, you
may recall.

> - protocol level, i.e. at the same layer as the DNS, is to build a new DNS.

Yes.

> transparent to the DNS and does not build a new DNS. This is the whole 
> IDNA idea.

Yes, but see above.

> 2. to only consider the ASCII Unicode sub-part as a special part: this is 
> the linguistic English "bias" of English internationalization. We 
> consider that _every_ Unicode sub-part (down to code point level) is 
> potentially a special part, while Vint only want to cristalize a few of 
> them in the technology itself.

I get the objection, but I don't think we can violate the rule that
how ASCII was ever processed will have to be how it will be processed
in future.  If we truly want to break that, I think it's time to get
to work on DNS2.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Elisabeth Blanconil <[email-masked]>
Date: Thu, 2 Jul 2009 13:16:06 +0200

Jefsey,
je déjeune et je lis ton mail. Quelques petits points. I will comment them
in English for Andrew and the ASIWG.

2009/7/2 JFC Morfin <[email-masked]>

> The point is what do you mean by "stray" and by "system".
>
> I feel you do not make a difference between what the user enters in the
> application and what the DNS receives as a querry. Pete has very well
> documented this point in his Draft. We are considering two systems.
> - one is the Internet and its ASCII DNS. The charter says they should stay
> unchanged. IMHO this is an architectural MUST.
> - the other is the Internationalized Internet which is made of the Internet
> plus IDNA. The purpose is to permit to use Chinese, French, Arabic, English
> domain names (IDNs) in the Internationalized Internet, however they are
> stray data in the DNS.

IMHO if you want IDNA people to understand things clearly, they need to
understand here that we consider four:

Core System = the unchanged Internet four layers pile. With the DNS in the
service layer.
IDNA System = currently still undefined internationalization ability
addition to the core internet system for the user to be able (to some
extent) to enter Chinese, French, Arabic, etc. names.
Interplus System = the coherent extension of the Internet layers pile to
fully support the usage system requirements, including full multilingual and
semiotic names (as documented by Pete).
Usage system = the system being used by the edge-user.

To map anything at:
> - IDNA level, i.e. above the DNS Internet application layer, is transparent
> to the DNS and does not build a new DNS. This is the whole IDNA idea.
>
> 1. to map at protocol layer. We roughly agree, however my architectural
> motives seem to be stricter than your DNS requirements.

You mean you agree together that you disagree about mapping at protocol
layer.

> the linguistic English "bias" of English internationalization. We consider
> that _every_ Unicode sub-part (down to code point level) is potentially a
> special part, while Vint only want to cristalize a few of them in the
> technology itself.

We consider it for two main reasons:
- because idiolect orthotypography has to be semantically consistent with
the other forms of human naming (polynymy)
- because (RFC 1958) similar problems should receive similar solutions and
as I noted it yesterday, multilingual presentation support is just a
paradigm for many other similar needs. The resolution of these needs should
not depend on tricks to accommodate IDNA to Unicode specifics.

> This means that our conceptual premises are equivalent, so please let drop
> disputes on that matter. We only differ in terms of mapping flexibility (who
> decides, for how long) and extension (which code points and contexts); also
> we commonly explore mapping location (prior, after or within the punycode
> algorithm) and should consider architectural coherence and stability (how to
> document the whole thing in order to influence a better stability).

This grid is very important. No mapping discussion can be complete if these
topics are not discussed.

- authority (structural, namespace, host, user)
- duration (permanent, parametrised, option)
- scope (per scripts, language, application, culture, usage, style, etc.)
- contexts (semantic, pragmatic, semiotic, orthotypographies)
- before, within, after punycode
- architectural coherence with other usages of the resources being
documented, neutrality for cross technology support.
- technical, operational, economic, strategic and usage stability.

I understand there are two main positions:
>
> - to protect the internet from linguistic originated technical overload
> through very limited changes, even if this does not fulfill the users
> expectations. The people supporting this position consider linguistic and
> Unicode details. They also want to use constraints

limitations

> as protections of technical status quo.

Mostly they consider the Internet as a single system of which they know the
limitations, while we consider it as a flexible much more resilient
concatenated distributed system. They focus on traffic and transport. We
focus on semantic and facilitation.

We need to keep that in mind. On both sides.

Elsiabeth Blanconil

---

From: Elisabeth Blanconil <[email-masked]>
Date: Thu, 2 Jul 2009 13:28:23 +0200

Great !!!
You and Jefsey agree !. I have finished my lunch time and I must go. I will
leave JFC explain the project.fra answer to the very good point you make.

Elisabeth Blanconil.

2009/7/2 Andrew Sullivan <[email-masked]>

---

From: Vint Cerf <[email-masked]>
Date: Thu, 2 Jul 2009 07:32:37 -0400

jefsey,

thanks for taking the trouble to prepare this note. It does lay out  
the issues clearly. I think I can report agreement with you in several  
areas.

First, while the IDNA working group members may not yet have reach  
consensus, there is at least among them, some who would treat the  
mapping on look up as a "should" (for compatibility reasons) but not a  
MUST and distinguish between the basic IDN protocol that preserves the  
A-label/U-label definitions and 1:1 conversion feature as part of  
protocol, and the pre-processing of strings that may be destined for  
lookup in the DNS. Some of the potential preprocessing is not  
specified in any of the documents except to say that by the time a  
look up occurs, it must be in A-label form (including the "xn--") or  
must be a "traditional" ASCII form ("LDH"). One form of preprocessing,  
about which we continue to debate, is to map some of the characters of  
the eventual "lookup" string so as to reduce variance from  
expectations that arise from the IDNA2003 behaviors.

The DNS itself continues to have the purely ASCII behavior it has  
always had to avoid requiring changes on the domain name server side.

Second, I think there is considerable room for innovation and  
standardization at a conceptual "presentation" layer - such a layer  
was not defined in the Internet while some effort to define on was in  
the OSI system. As applications have become increasingly  
internationalized, it is arguable that codifying presentation concepts  
may prove useful. Some might go so far as to suggest re-inventing the  
system of binding strings to internet addresses (what the DNS does).  
While that path was not chosen in the present DNS-IDNA2003-IDNA2008  
sequence, it might be considered in the future and in my opinion, it  
is in these areas (presentation and re-definition) that much of your  
work, jefsey, has relevance.

I am interpreting your message here as arguing not to change the  
existing basic DNS, to confer stability at the server level, and here  
we agree.

vint

On Jul 2, 2009, at 6:00 AM, JFC Morfin wrote:

> - one is the Internet and its ASCII DNS. The charter says they  
> should stay unchanged. IMHO this is an architectural MUST.
> internationalization. We consider that _every_ Unicode sub-part  
> (down to code point level) is potentially a special part, while Vint  
> only want to cristalize a few of them in the technology itself.
>
> This means that our conceptual premises are equivalent, so please  
> let drop disputes on that matter. We only differ in terms of mapping  
> we more generally name Interplus. The people supporting this  
> position are only interested in presentation layer issues, whatever  
> the presentation details. They want no constraints on the Internet  
> IMHO, whatever the good reasons the first coalition may propose,  
> they will most probably be disregarded by users as unnecessary  
> constraints happening to support commercial and political status- 
> quo. My concern, if there is no general IETF and ICANN consensus, at  
> least for Class IN, a wild IDN usage will deploy.
>
> jfc
>
>
>

---

From: jefsey <[email-masked]>
Date: Thu, 02 Jul 2009 18:41:32 +0200

>ecole correspond to one another.  Which was the original question, you

Correct.

However, please remember that we are talking of linguistic TLDs (this 
is why I first initiated Multilinc and want to run the project.fra 
test-bed). This mean that I can manage the TLD registry the way I want.

1. I can put a TTY 0 (which corresponds to Web 2.0 anyway), so the 
ecole/Ecole data are not cached.
2. unless you change the DNS for security reasons (scrambling the 
lower/upper cases) "ecole" and "Ecole" will be passed as such to the 
DNS, even they both are treated as "ecole". So I will filter out 
"Ecole" which is meaningless to me (I need to receive 
xn--cole-abc.fra). I have the right to do that because I do not 
change the DNS at all, only put an OPES on the DNS.

I tried to push the WG/OPES to work on the DNS protocol before SMTP. 
This might have helped.

>how ASCII was ever processed will have to be how it will be 
>processed in future.

I agree with this. And we need it (hence my objection to your 
considered change which breaks that rule with case scrambling - which 
is a good idea in terms of security - but I suggested you an 
alternative which is to use IPv6 requests).

1) an OPES filter is not a DNS change because it is a new TLD.
2) French is not ASCII but FSCII. There is no change in DNS, no 
change in ASCII.

>  If we truly want to break that, I think it's time to get to work on DNS2.

Is it not already here, in the same way as Web 2.0. A generalization 
of existing practices and possibilities.

jfc

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 Jul 2009 13:04:14 -0400

> ecole/Ecole data are not cached.

I guess you mean "TTL".  TTLs of 0 are well-known not to work
everywhere, so this will likely break in at least some cases.  Let's
suppose you want to accept that breakage.  You increase the load on
the Net, too, but let's suppose you're willing to do that.

> DNS, even they both are treated as "ecole". So I will filter out "Ecole" 
> which is meaningless to me (I need to receive xn--cole-abc.fra). I have 
> the right to do that because I do not change the DNS at all, only put an 
> OPES on the DNS.

No.  They _are not_ both treated as "ecole": that's exactly the
problem.  They both _match_ "ecole", but DNS _preserves_ case even as
it is insensitive for matching.  If they were in fact both _treated_
as "ecole", then I agree the entire problem would go away.  By
"filtering out 'Ecole'" you are in fact violating the DNS protocol. 

> I agree with this. And we need it (hence my objection to your considered 
> change which breaks that rule with case scrambling - which is a good idea 
> in terms of security - but I suggested you an alternative which is to use 
> IPv6 requests).

I don't think I understand the proposal for IPv6 requests, but if you
have a comment that is relevant to this it needs to be pursued in the
DNSEXT WG, where we're considering the work.  I encourage you to raise
objections to this "0x20" approach in that forum, because we will be
considering whether to adopt it and objections will form an important
part of the input.

> 1) an OPES filter is not a DNS change because it is a new TLD.

This conflates the protocol, the database, and the data in it.

> 2) French is not ASCII but FSCII. There is no change in DNS, no change in 
> ASCII.

It doesn't matter whether "French" is in ASCII.  The DNS knows nothing
about the language a label is in (whatever it means for a label to be
in a language).

> Is it not already here, in the same way as Web 2.0. A generalization of 
> existing practices and possibilities.

I meant "a different protocol".  The marketing slogan "Web 2.0" is
just a name for a bunch of practices that have made people more or
less wealthy.  The point of a "DNS2" would be to solve the manifold
issues with the existing DNS.  For what it's worth, I imagine such an
effort would take longer than either IPv6 or DNSSEC to get deployed.
Since those two efforts have taken upwards of 15 years (and counting),
I cannot believe that we'd get DNS2 (DNSng?  whatever) deployed in
anything like a timeline acceptable to the current user community.
That's the reason I haven't started working on it: it's so late now
that it will never happen.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: JFC Morfin <[email-masked]>
Date: Fri, 03 Jul 2009 01:42:36 +0200

Dear Vint,

Thank you for this mail. These various exchanges took quite some time 
away from my planned agenda for the Interplus Draft and the 
Project.FRA documents, but they truly help in evaluating how to 
better introduce them.

>expectations that arise from the IDNA2003 behaviors.

This is the actual point John and Pete made very well. SHOULD and 
COULD can be used in clever ways in order to influence network 
design, usage and management in the way most of this WG feels the 
best. MUST should not be used.

>always had to avoid requiring changes on the domain name server side.

Absolutely. This is mandatory. We should not use scrambling for 
security purposes (moreover, IPv6 random IIDs offer a better 
possibility and pushes for IPv6 implementation). However, we must be 
careful to not harm the network in confusing what a function is 
supposed to do and what it can actually do without being changed but 
in being better used through the evolution of its upper layer context 
and possibilities (which usually means innovation and extended 
possibilities). The less we change the lower layers and the best we 
can use them preserve network consistency.

>system of binding strings to internet addresses (what the DNS does).

 From the dot-root community test-bed that I ran a few years ago 
(along the ICANN ICP-3 recommendation), I feel that there is still 
plenty of things to do with the DNS tools in the way that they 
currently are. However, there is also a lot to debate about the best 
way to utilize them.

>work, jefsey, has relevance.

My concern is that this work shows that many things are already here. 
The Internet has really great potential. These things are not used, 
but they are consistently here. However, this also means that anyone 
freely can take advantage from them . Therefore, the real issue is to 
try to influence some concerted usage vision. After the hardware and 
software, we need to influence the brainware - in openly exploring as 
to how some usage architecture may turn out to be more efficient than others.

This is not network technology or topology any longer but rather 
ideology as Rod Beckstrom would say. We face the concerns expressed 
by IAB in RFC 3869 . We need a review of RFC 3935 because the 
criteria for success are no longer only technical, or even financial, 
but are rather more related to a broad diversity of common, private, 
public, cultural, individual, and personal empowerments that we are 
not used to seeing at that level.

>existing basic DNS, to confer stability at the server level, and here

ABSOLUTELY.

Maybe I am wrong (and this is what project.fra should help to check), 
but my four leading concerns are that:

- net neutrality is not engaged by "xn--" mapping at the protocol 
level - or it is labeled as an experiment and an alternative 
experiment is organized.

- DNS behavior is not changed, for example by case scrambling. This 
does not prevent additions outside of the nameservers (through OPES, 
for example) in turn assisting in a smooth evolution towards what I 
call the Multilingual Distributed Referential System (including 
"DNS2", local IANA, etc.).

- the ICANN dreamspace documentation complexity. I have no idea (lack 
of time, poor presentation of changes) as to what ICANN may be 
telling the world over IDNA, Fast Track - except that there seem to 
be conflicts ahead that result from misunderstanding and sovereignty 
trespasses.

- nothing has been prepared in order to migrate from a single root to 
a virtual matrix self-deployment, i.e. billions of individual 
rootnameservers running billions of  class/presentation roots. Its 
architecture and adminance (technical and administrative governance) 
are far less a problem (if the DNS protocols remain unchanged) than 
its governance and economy might be.

I know these are not usual concerns for an IETF WG.

- Yet small decisions by this WG will most probably decide of them 
due to the DNS importance in the world life.
- This is why I first tried to explore the IETF precautionary duty 
(http://tools.ietf.org/html/draft-iucg-precaution-00.html)

jfc

---

From: JFC Morfin <[email-masked]>
Date: Fri, 03 Jul 2009 03:51:35 +0200

Dear all,
Will I answer Mark? No.

My prority is now with the Interplus Draft as a working document. So 
I would lack the time. But mainly this is because I could not.
What Mark talks about is not nonsense.However, (1) everyone knows it 
(2) it is by nature a different topic.
I am a multilinguist (simultaneous technical support of a language 
diversity), not a linguist (discussing individual language cases).

Mark's interest is in globalization, i.e. the system he invented to 
support foreign languages in English technologies. As such it is a 
great success. It has the technical cons and pros of being an English 
language machine-centric system.

My interest is in presentation and extended services network layers. 
This what we need in order to empower:
- without constraints every language (including English, French, 
Arabic, Chinese etc.)
- as part of semiotic (including scripts) mediatic end to end 
functions (access, addressing, delivery, routing, etc.) ,
- in every technology (including the Internet),
- in using every coding (including Unicode),
- for every application (including IDNA),
- in every environment from brain cells to outerspace identified by 
their namespaces.
This is a people centric system, to accomodate the relations of the 
people diversity in what they are and what they do. Is it a reason 
why to disregard Unicode? No!  As fas as the Internet is concerned, 
Unicode is a structured set of code-points. If IDNA users are happy 
with it, the Internet should be happy with it. If they are not, they 
should be not.

Does that mean that Unicode should be disregarded ? No!

The same as Unicode is not a reason for disregarding the DNS (this is 
the justification of IDNA). Each addresses the needs of a different 
layer. Layers need to cooperate. In order for all them to progress in 
symbiosis.

NB. what Marks discusses is not obsolete, it is just (as he documents 
it himself very well) a layer below what I discuss.
Best.
jfc

At 01:47 03/07/2009, Mark Davis wrote:
>What Jefsey suggests is all nonsense.
>
>Here is what is happening. Basically, one can make a distinction 
>between capital letters that are required linguistically (the L at 
>the start of the sentence below and the M at the start of the proper 
>name Marcel in the example below) and those that just happen to have 
>a capital form (because the sentence is set in all caps). The former 
>in French are called majuscules, and the latter capitales. From Wikipedia:
>
>La phraseÂ : Â«Â LONGTEMPS MARCEL Sâ€™EST COUCHÃ‰ DE BONNE HEUREÂ Â» 
>est Ã©crite en capitales, mais seule la premiÃ¨re et la dixiÃ¨me 
>lettres sont majuscules. On sâ€™en rend mieux compte si on Ã©crit 
>cette phrase en petites capitalesÂ : Â«Â Longtemps Marcel sâ€™est 
>couchÃ© de bonne heureÂ Â».
>
>However, that distinction is not captured in Unicode, nor in ASCII, 
>nor in any other character encodings that I know of, nor should it 
>be. There are many distinctions in the usage of characters that are 
>not, and should not be, represented in the encoding. One could just 
>as well argue that the distinction between the pronunciation of "o" 
>in "rove", "move", and "love" needs to be in the encoding, or that 
>the difference between the "." in "1.2", "etc.", or "." at the end 
>of a sentence needs to be in the encoding. That would end up with 
>scads of identical characters that people would not distinguish when 
>keying, could not distinguish in display, are not in any existing 
>data, could not be depended on in processing, but would be just a 
>marvelous opportunity for spoofing!
>Nor, of course, should anyone think of trying to capture this 
>distinction in IDNA.
>
>Mark

---

From: Mark Davis <[email-masked]>
Date: Thu, 2 Jul 2009 16:47:42 -0700

Here is what is happening. Basically, one can make a distinction between
capital letters that are required linguistically (the *L* at the start of
the sentence below and the *M* at the start of the proper name *Marcel* in
the example below) and those that just happen to have a capital form
(because the sentence is set in all caps). The former in French are called *
majuscules*, and the latter *capitales*. From Wikipedia:

La phrase : « LONGTEMPS MARCEL S’EST COUCHÉ DE BONNE HEURE » est écrite en
capitales, mais seule la première et la dixième lettres sont majuscules. On
s’en rend mieux compte si on écrit cette phrase en petites capitales :
« Longtemps
Marcel s’est couché de bonne heure ».

However, that distinction is not captured in Unicode, nor in ASCII, nor in
any other character encodings that I know of, *nor should it be*. There are
many distinctions in the *usage* of characters that are not, and should not
be, represented in the encoding. One could just as well argue that the
distinction between the pronunciation of "o" in "rove", "move", and "love"
needs to be in the encoding, or that the difference between the "." in
"1.2", "etc.", or "." at the end of a sentence needs to be in the encoding.
That would end up with scads of identical characters that people would not
distinguish when keying, could not distinguish in display, are not in any
existing data, could not be depended on in processing, but would be just a
marvelous opportunity for spoofing!
Nor, of course, should anyone think of trying to capture this distinction in
IDNA.

Mark

On Wed, Jul 1, 2009 at 06:13, jefsey <[email-masked]> wrote:

> The string you see on your screen is ASCII - the string I enter is not.
> This is because Unicode is being used and Unicode does not properly supports
> the French language orthotypography.
>
> In "Ecole.fra" the semantics demands that "E" is not an "E" ASCII but a
> French "E" majuscule. I am sure Unicode has no problem in supporting them,
> or TLD Tables can be used. "Ecole.fra" is a user domain name which may have
> nothing to do (except phishing) with "école.fra", "ecole.fra" and
> "École.fra".
>
> However, the decision is only with the registrant. So, the simplest is to
> consider each usage domain name separately. If some are to resolve the same
> IP, the registrant will only register several domain names.
>
> jfc
>
>
>

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Fri, 3 Jul 2009 04:58:17 +0200

Dear Dr. Davis,
Do you mean that the project.fra is a nonsense, that academics participating
to it are ignorant, that politicians supporting it are fooled by Jefsey,
that supporting linguists dont know their mother tongue, and that its future
users' IQ will be too low for them to understand on the internet the words
of their very daily language?

Is that not a little blunt?
Portzamparc

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 3 Jul 2009 07:17:42 -0400

On Fri, Jul 03, 2009 at 01:42:36AM +0200, JFC Morfin wrote:

> - nothing has been prepared in order to migrate from a single root to a 
> virtual matrix self-deployment, i.e. billions of individual  
> rootnameservers running billions of  class/presentation roots. 

Indeed, nothing has been done that way, and that's because it's a
completely incoherent idea.  The DNS namespace is a coherent namespace
with a single root.  If you have "billions of individial
rootnameservers running billions of … roots", you're imagining
something.  The namespace is structured such that you have to start
_somewhere_.  If you have another layer "beyond the root" that tells
you where to look things up, then all you have done is move the root
around.  Having actually billions of entries in the rootserver.hints
file would be, frankly, stupid: not copying around such a list is what
the DNS was invented for.  I think you know that perfectly well.

If you want a distributed hash table, self-publication arrangement, I
encourage you to get to work.  Several such proposals have already
foundered on the serious problem that, in a global context (and I know
that individuals aren't on purpose in a global context, but the
network still provides access to that context anyway) it's very hard
to get unique names without co-ordination.  If you have a magic
solution to that problem, excellent.  But let's not confuse matters by
talking about "billions of roots".  

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: jefsey <[email-masked]>
Date: Fri, 03 Jul 2009 14:06:57 +0200

Jean-Michel,
Please, let keep it cool.

Mark is a linguist using English based/biased (not pejorative) 
digital computers as they are, and feeding them with "pre-data" 
(Unicode, CLDR) in order to permit them to work correctly in an 
English+languages+scripts context. He must be thanked a lot for that.

Now, we are confronting him with a new technical challenge, because 
the "computers" we consider are very different. They are networked, 
virtual (in many ways), with semiotic interface, semantic and 
neuronal, and interactive with distant humans (heterarchic context).

So, he is fully correct in challenging the sense of what we say. This 
is not because I say something that I am right against the entire 
world. He just overdoes it a little in starting with a conclusion 
("this is nonsense") and too quick in his thinking (he associates the 
whole of what we say, only with French language related details).

However,
- challenging what we say on linguistic grounds is not an IETF issue. 
As the IETF we are not here to oppose the specs and direct the users.
- discussing French language will always be opposed, as for the 
Arabic Tatweel: are you sure everyone agrees with you? We do not want 
to go by a single gopel but by the diverse and sometimes opposing people ways.
- we certainly are interested in making sure that the technology we 
want to add will make the best out of his Unicode, and his inputs are 
very welcome. As well as his comments when we want to use Unicode and 
some "meta-data" we have to enrich it.
- we also are very interested in his command of English and French 
and his love of the French language, because he may better perceive 
what is pragmatic (context dependent) and semantic (meaning related) 
in what we consider. Moreover when we consider the French, English, 
Chinese, etc. languages not only as a human languages but as 
particular parts of a semantic multilinguistic metatechnology.

Mark is a long time practitioneer of a part which interests us a lot: 
human usage interface with "mecanologie". How people do react when 
confronted with new  "mechanical" rules (such as Unicode tables, 
locale files, etc.).  We have much to learn from him about 
man/machine relation in a language context

I do hope he accepts to work with us, helping us to correct what we 
might think wrong.
Best
jfc

At 04:58 03/07/2009, jean-michel bernier de portzamparc wrote:
>Dear Dr. Davis,
>Do you mean that the project.fra is a nonsense, that academics 
>participating to it are ignorant, that politicians supporting it are 
>fooled by Jefsey, that supporting linguists dont know their mother 
>tongue, and that its future users' IQ will be too low for them to 
>understand on the internet the words of their very daily language?
>
>iucg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/iucg

---

From: JFC Morfin <[email-masked]>
Date: Fri, 03 Jul 2009 15:25:12 +0200

> > rootnameservers running billions of  class/presentation roots.

Dear Andrew,
I read and understand what you say. The difference between our 
perceptions is simple to understand.

The IETF is to influence those who build, use, and manage the 
Internet so it works better; the Internet (capital "I") is made of 
all the computers that can interoperate throughout the world via (IP) 
packetswitch networks. This is the IETF/USC description of the issue. 
The best one can think in that context is what ISOC calls for : all 
this is to be "[internet] user centric". Then all what you say is 
then coherent: the facilitating technologie decides.

I am not user centric. I am realist.

If Brian Carpenter explained me that the least IETF heard about WSIS 
the best it was, it is because the entire world consensus (IETF not 
being here) disagreed with ISOC (USA included) and said it wanted a 
human society which would be "people centered, à caractère humain, 
centrada en la persona". The person decides and the facilitating 
technology serves.

This is something I identifed in 1976 when starting considering the 
digital facilitation architecture the world needed. So, I am more 
familiar with the implications. This is also something which 
corresponds to the French legal definition of the necessary tools 
(including the internet) of the "on-line public communication and services".

In a DNS user centric world you can centralise it. In a distributed 
people centric world you can only accept that I (and everyone can do 
the same) use the root file and the nameserver I loaded on my 
lap-top. In terms of architecture it only means that the DNS is not a 
replacement for the Host.txt job, but a replacement for its 
maintenance job. The problem we have to solve is that as soon as 
users learn about all the cons and pros of a local rootnameserver and 
then about the cons and pros of presentation and classes 
rootnameservers we will face a borad diversity of usage and a big 
risk of pollution.

Today the namespace consistency is "mechanically" constrained by the 
"root server tale". We urgently need to build, document and make 
appealing a "virtual matrix tale" which sounds and is (people are 
more and more technology aware) technically acceptable and pertinent 
to the next century development. I feel there may be some, but I 
presently see none. This is a reason of project.fra: to discover what 
can keep a virtual terminology (such as the DNS supported semantic 
addressing) stable enough for the world to continue to trust it. 
Human languages do it pretty well for a long time, Trad Marks also. 
These are good omens. But I am afraid the "structured namespace 
starting somewhere" justification will not be of use. Starting 
somewhere is the attribute of an entity, not of billions of human entities.

Now, if you want who is the first to propagate the call about this: 
http://www.icann.org/en/icp/icp-3.htm. "In an ever-evolving Internet, 
ultimately there may be better architectures for getting the job done 
where the need for a single, authoritative root will not be an issue. 
But that is not the case today. And the transition to such an 
architecture, should it emerge, would require community-based 
approaches. In the interim, responsible experimentation should be 
encouraged, but it should not be done in a manner that affects those 
who do not consent after being informed of the character of the 
experiment.". I carried such an experimentation ICANN asked the IETF 
to carry. All I can say, is that time has flown.

Now, if you want to compute some figures. I think it is rather conservative
- to consider one root per idolect/avalect (person, avatar), per 
relational space and per parametrised application (look at yesterday 
mail of Mark Davis. The "nonsense" is simply the support of what I 
perceive as the reality.
- then you will to consider versions of each namespaces (ex. the 
"kid" filtered version of the ".com" namespace - nothing to do with 
"kid.com" or ".kid").
This may make trillions.

To address this we have to think, not of namespace controlled 
delivery, but about open usage, not in terms of maintenance but in 
terms of access.  Just think that "unicode.org" can legally resolve 
into thousands of IP addresses, in thousands of classes.

No, I have no magic solution. But I try to find today working and 
quickly deployable ones, in considering, investigating, testing the 
reality. The only thing I know is that constraining the network (such 
as "mapping at protocol level") only complexify the network (making 
further solutions more complex) and will be immediately circumvented, 
accelerating the problem.

jfc

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 3 Jul 2009 13:16:47 -0400

On Fri, Jul 03, 2009 at 03:25:12PM +0200, JFC Morfin wrote:

> people centric world you can only accept that I (and everyone can do the 
> same) use the root file and the nameserver I loaded on my lap-top. 

You are simply equivocating on the term "root" in that statement,
which is what I was saying in the first place.  "The root" just means
where the namespace starts.  If you happen to have a bunch of root
nameservers that aren't in the IANA root, then you have a different
root.  That's all.
 
> terms of architecture it only means that the DNS is not a replacement for 
> the Host.txt job, but a replacement for its maintenance job. 

I think it more accurate to say that the DNS was intended to supersede
the old mechanism because maintaining the old mechanism was difficult,
error-prone, and cumbersome.  You appear to think that it has some
advantage.  I think I understand what that advantage is, and in my
opinion you're being unrealistic.  The fact is that mostly-closed,
mostly-insular, tightly-knit communities give up some of the
advantages of that cohesiveness in order to interact with people
outside their community.  That's what's happened in the case of the
Internet: to use the technology, everyone has to adjust themselves
some to it even as it has to be adjusted some to everyone.  There is
no such thing as a technology that does not change the users even as
the users change the technology, and dreaming that our technology will
exclusively be bent to our collective will is a way to be disappointed
in future.  (I think this is one of the central points of Latour's
_Nous n'avons jamais été modernes_, among others of that set.  It's
certainly one of the central points Haraway makes, and I've yet to see
a coherent argument against her position.)

Anyway, I think we've strayed very far from the point of this
discussion, so I won't indulge more in it.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Fri, 3 Jul 2009 20:51:28 +0200

Jefsey,
There is still a long way before we all understand each other. But some
points are very positive.

2009/7/3 Andrew Sullivan <[email-masked]>

> If you happen to have a bunch of root

We have a buch of root, the same namespace, the same caches and the same
users.

> That's what's happened in the case of the
> some to it even as it has to be adjusted some to everyone.

We agree :-) but ICANN is not aware of that :-)

>  (I think this is one of the central points of Latour's

I suggest we have a look at these two authors.

> discussion, so I won't indulge more in it.

Too bad, you were nearing the core of the point. Next time ?

Anyway, this was a very interesting exchange. Thank you both.
Portzamparc

---

From: jefsey <[email-masked]>
Date: Sat, 04 Jul 2009 01:08:13 +0200

At 20:51 03/07/2009, jean-michel bernier de portzamparc wrote:
>We have a buch of root, the same namespace, the same caches and the 
>same users.

And the same huge governance problem. Moreover if all of them want to 
sell their TLDs $ 150.000 a piece. Or to ransom others. Unfortunately 
ISOC/ICANN/IETF did not want to listen, for so long. And still do not 
(but at least we talk).

So, I suggest that we focus back to the Interplus document. I am 
going to review it now based upon Margaret's and Michael's 
contributions, inputs on the wiki, etc. and then to consider the 
point raised at the IDNABIS that might be interesting to address in it.

The main points right now is to decide (due to my delay) if :

1) a generalized communication embryonic global framework (I think 
about Andrew's and Mark's Internet/Unicode rooted points of view we 
need to confort and enlarge). It would be introduced in explaining 
that it would be by no means a model, just a temptative working 
framework. We could use the france@large "livre blanc" effort.
2) the glossary should be removed now and form a separate document.
3) I try to install the documents concerning "projet.fra" online from 
the document for the Francophonie before we meet with Marcel this 
week or after.

I copy this mail to the idna-arabicscript mailing list because it 
transitions from the fruitful discussion we had there. I changed the 
thread subject, and as suggested by Vint, I invite those interested 
to continue this on the [email-masked] mailing list - remembering that 
this list is not a dedicated and paid engineers mailing list, but 
only a motivated lead users open minded and free speach one.

To join : https://www.ietf.org/mailman/listinfo/iucg
jfc

---

From: Marie-France Berny <[email-masked]>
Date: Sat, 4 Jul 2009 02:03:33 +0200

Jefsey,
it seems it is the friday night fever and everybody is on the bridge to
night!

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

> 1) a generalized communication embryonic global framework (I think about
> Andrew's and Mark's Internet/Unicode rooted points of view we need to
> confort and enlarge). It would be introduced in explaining that it would be
> by no means a model, just a temptative working framework. We could use the
> france@large "livre blanc" effort.

That could help to present it this way.
- It would make a annoucement of the intended scope (the documents we
published last year for ISO TC46 could be a good starter?)
- the document on the model could be annouced as the last document. To be
based on experience.

> 2) the glossary should be removed now and form a separate document.

In the hypothesis above, it could come as part of Interplus and be moved as
a document by its own right as new Drafts are issued.

>
> 3) I try to install the documents concerning "projet.fra" online from the
> document for the Francophonie before we meet with Marcel this week or after.

Don't rush. Dont get impressed by hurluberlus. Better to get a good job done
first (we do not have to come back on it). Let just nominate Krebs for
Hurl2009.

Marie France Berny

---

From: Xavier Legoff <[email-masked]>
Date: Sat, 4 Jul 2009 02:24:02 +0200

Why not to introduce the framework as introduction to a set of RFC 4846
Independent Submissions. This could be a good experiment to add Independent
Submissions as the highest form of lead user contribution. This would
probably fit well what the IAB said they expected from us.

Kenavo.
------------------
Xavier Legoff

PS. I do no know if my old friend Vint Cerf wants to receive this so I
removed him from the cclist.

2009/7/4 Marie-France Berny <[email-masked]>

> Don't rush. Dont get impressed by hurluberlus. Better to get a good job
> done first (we do not have to come back on it). Let just nominate Krebs for
> Hurl2009.
>
> Marie France Berny
>
>
>