Subject: Re: [iucg] Comments on draft-ietf-idnabis-defs-10

From: Vint Cerf <[email-masked]>
Date: Thu, 3 Sep 2009 09:10:22 -0400

Elisabeth,

  See comments below.

vint

On Aug 30, 2009, at 6:35 PM, Elisabeth Blanconil wrote:

> Dear Wil,
> thank you for reading the interplus provisional documents and spotting
> how IUCG user members trust the WG Charter when it states :
>
> "The WG will stop work and recommend that a new charter be generated
> if it concludes that any of the following are necessary to meet its
> goals:
>
> "(i) A change to the "punycode" algorithm or to the ACE approach to
> encoding names  in the DNS."
> -> this is now what you propose.
We have made NO change to the punycode algorithm. The lowercasing  
observation is to assure canonical form conversions between punycoded  
forms (A-labels) and Unicode forms (U-labels) but does not change the  
punycode algorhtm itself.
>
>
> "(ii) A change to the ACE prefix from "xn--"
> -> you now propose a change from "xn--" to "$$--"

No that was my way of referring to all strings containing "--" in  
positions 3 and 4 of the on-the-wire form of R-LDH labels. We continue  
to use "xn--" as the A-label prefix but for all IDNA-aware  
applications, reserve the use of the first and second characters in  
case there is ever a need to define a new prefix.
>
>
> "(iii) A change to the basic approach taken in the design team
> documents (Namely: independence from Unicode version and elimination
> of character mapping in the protocol)"
> -> Vint already proposed the change of the last sub-point.Yet the WG
> has not stopped work as the Chair confirmed it when I asked if it was
> necessary for an I_D concerning and quoting the WG to be published as
> a WG Draft or if IUCG could submit it.

A minor change in the charter was made and approved by the AD to allow
for non-normative mapping document.
>
>
> As we expected it, at this stage of the document set production, a few
> hours before the end of the WG/LC, you question the worked out rough
> consensus. Since we obviously expected your requests, we have
> considered at length how they could be best addressed. Our consensus
> is:
>
> 1. either the Chair calls for a stop on the WG work, and a debate on
> Charter changes to be proposed.
There was extensive discussion on the matter of putative A-labels  
containing
upper case ASCII and the matter was resolved in my opinion by assuring
that input to punycode conversion is done using lower-case ASCII only.
>
> 2. either the Charter (modified or not?) is respected and we make (i),
> (ii) and (iii) an issue for the IETF/LC.
You are free to raise any issues you like in IETF/LC but it is my  
sense that
we have complete the WG Last Call and are in final edits leading to
presentation of the IDNABIS/IDNA2008 documents to the AD.
>
> 3. or we face an IETF process and architectural conflict that will
> probably resolve at network clients level.
I have no idea what you mean here but adoption of IDNA2008 is
plainly voluntary.
>
>
> It would be better to avoid (3). (1) and (2) seem technically
> equivalent at this stage. The real issue is the impact of the
> resulting further delays in implementing IDNA2008, on Fast Track and
> IDNccTLDs, etc. and their FLOSS strategic equivalents: Project.FRA,
> Multilinc, etc. FYI, since FLOSS have no financial nor political
> dependency, AFAIK they seem to be on track.
>
> Best regards.
> Elisabeth Blanconil
>
> 2009/8/30 Wil Tan <[email-masked]>:
>>
>>
>> On Sat, Aug 29, 2009 at 5:17 PM, John C Klensin <[email-masked]>  
>> wrote:
>>>
>>> --On Monday, August 24, 2009 23:24 -0400 Andrew Sullivan
>>> <[email-masked]> wrote:
>>>
>>>>
>>>> In a previous comment (see
>>>> http://www.alvestrand.no/pipermail/idna-update/2009-July/00497
>>>> 0.html), I made a vague remark about something I find
>>>> worrisome in this text in §2.3.2.1:
>>>> ...
>>>
>>> These changes, with Paul's suggested modifications, have been
>>> tentatively accepted and incorporated in the document.  Anyone
>>> who objects should say so quickly.
>>>
>>
>> I posted a comment related to the definition of A-label some time  
>> ago, but
>> the thread was
>> digressed: http://www.alvestrand.no/pipermail/idna-update/2009-June/004558.html
>> The issue is with case variants of A-labels. By DNS rules, as  
>> mentioned in
>> several places in the idnabis-defs draft, A-labels are to be  
>> compared in a
>> case independent manner. However, if certain characters in an A- 
>> label have
>> been uppercased, the Punycode decoding algorithm (due to its mixed- 
>> case
>> annotation feature) may produce invalid U-label because the ASCII  
>> characters
>> will be in capital letter form.
>> =wil
>> _______________________________________________
>> 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: Sat, 05 Sep 2009 00:36:38 +0200

At 19:22 04/09/2009, Andrew Sullivan wrote:
>To be perfectly honest, I don't think you're working very hard to 
>make yourself understood.  Either that, or your views are already so 
>confused that they can't be understood.

Dear Andrew,

Frankly I do not think so. To be perfectly honest as you put it, I 
acknowledge that we do not have the same world digital ecosystem 
model in mind. And this is particularly difficult to manage in this 
WG-IDNABIS, because our real difference is on linguistics (as a 
scientific discipline and philosophical base) aspects and therefore 
precisely starts on IDNA. IMHO this is why IDNA takes so long to be 
understood, supported, accepted, deployed.

I accept this is particularly upsetting for you because you are quite 
open minded on the matter, accept linguistic relativity, understand 
conceptual schemes, are well advanced along Wittgenstein thinking 
(somebody I find interesting to discover for a few months because, as 
he says, you must have explored the same ideas by yourself to 
understand him). Actually, I think we differ by our "Khun paradigm". 
We had long debates on the france@large mailing list with a guy named 
Patrick Yeu who would certainly please you (every author you quoted 
was not only familiar to him, but he has a pertinent analysis he made 
by himself). He is French but of Austrian and Chinese (parents) 
origin ... and thinking. I must also accept that the French 
linguistic school is particularly active, and based upon the work of 
Culioli, Poincaré, Thom, Benveniste, David Dalby, Marcel Diki-Kidiri, etc.

I feel that for you, the IETF Internet is (as you could probably 
describe it) the IETF "architectural scheme" (in reference to the 
Davidson "conceptual scheme" you alluded to) of that digital 
ecosystem. For me, this is the IETF "architectural perspective" that 
IETF has to _share_ with other perspectives of the same real system. 
This is where I certainly differ from Wittgeinstein, since we 
discussed his ideas: I know that the limits of my world are not the 
limits of my language. So, the difference is not within different 
perceptions of "linguistic relativity", but in a reality made of 
"multilinguistic diversity". This is why communications evolve:

- from "information transfer" within conceptual scheme (and I accept 
that Davidson's line may help simplify things if it is understood in 
its practical consequences),

- to "meaning transfer" across relational frameworks, where each 
allocutor _and_ internal dialog and soliloquy has his/her/its own 
conceptual scheme (and language(s)) within the common polylogue and 
doxa, with the addition of one or several mecalanguage(s) used by 
intercomprehensions facilitators (on wire, post wire, off wire). This 
has most probably very deep consequences and explains the apparent 
complexity we observe and that (cf. Wittgeinstein) should not be. 
This is why I feel that Khun's paradigmatic change is from mathematic 
equivalence based logic (Russell, Frege, Wittgenstein mental 
construct) to semantic coherence based technologic (I mean, a logic 
that tekchne _permits_).

This means that I _technically_ pay attention to points you do not 
consider because you think that in your "linguistic" world 
(Wittgenstein, John Day) you can decide about them. I pay attention 
to them because I know that in my _shared_ multilinguistic world, 
hence"metalinguistic" reality, I must respect what others may 
do/think. They may do thing I may ignore, and I do not necessarily 
understand. This is why I am more at ease to understand your 
conceptual scheme, than you are ready to enter my metaconceptual 
framework. So, I accept that the burden is on my side: this is why I 
committed not to interfere with IDNA. Unless it inadvertently 
compromises ML-DNS: something the respected of the WG-IDNABIS Charter 
should have permitted. I will certainly try to keep ML-DNS totally 
IDNA compliant since what I perceive as Charter changes should permit it if:
- I understand what will replace the Appendix A features to carry 
uppercase metainformation.
- prefix stays "xn--" and do not limit other prefixing.
- class stays "IN".
- the U-labels no-uppercase restriction is removed.

Please understand that in my shared world there may be a normative 
diversity of the use of the same digital ecosystem. This means that 
IDNA has no architectural right to consume/spoil what does not belong 
to it. This is why I need the charter I carefully accepted for that 
reason is respected. This is why the initial RFC 4646 confusing text 
was absolutely to consensually clarified. Normative pollution creates 
complexity, and leads to standard more and more opposed 
internationalization (dominance of one standardization scheme). If we 
fully want to take advantage from the Internet we must clean the RFC 
system from normative pollution. We have good principles for that, 
listed as RFC 3935 duties (I add the precautionary duty in a draft I 
am to publish when I have finished my Wiki/RFC conversion program - 
the I_D text is on-line: http://iucg.org/drafts/draft-jfcm-precaution-00.htm ).

I therefore only ask two things from you:

- (1) not to protest that you do not know ML-DNS, since ML-DNS will 
only be finalized ... after _you_ accept that IDNA is stabilized (on 
the DNS side at least). We are allies: we need what you want: DNS 
respect and stability.

- (2) not to go beyond what is the IDNA area and not to hamper 
ML-DNS. For that, you can either trust me when I say there is a risk, 
or help us explore how the ML-DNS should be designed. This is why the 
IESG Chair created an IETF non-WG mailing list for the contribution 
of the most demanding and involved users (business and civil society) 
and I created a site where we try to maintain things in line within 
the limits of our practical personal possibilities.

The WG Chair initially proposed to host that list, and the AD 
acknowledged that the Intersem as I introduced it fall in her area. 
However, experience of the first drafting effort shown that ML-DNS 
must go with a semantic addressing definition and support, then with 
a presentation layer, then with a distributed referential 
metastructure, hence demanded active content delivery, extended 
network services, etc. etc. This was definitely wider than the WG 
scope and called for a documentation effort voluntary users cannot 
assume alone, moreover in an IETF working context (cf. your 
legitimate expectations they definitely cannot financially and timely 
match, moreover in a foreign language [i.e. a foreign conceptual 
scheme thinking]), while they are more directly confronted to open 
political, multitechnology, market and their own business/cultural 
environment.

> > IMHO unwillingness to try to  understand the IDNA conceptual 
> framework is also a users' priviledge,
>
>Of course it is.  See above re: protocol police.

Yes. This is what makes our multilinguistic evaluation and normative 
cleansing difficult but key tasks. Protocol police, but this is only 
MHO, is based upon a simple principle: that violation be more complex 
and costly than respect of the protocol. Again IMHO, this calls for a 
comprehensive approach of multilaterality, to make sure "crooks" 
cannot evade into a parallel universe where protocol violation is 
less difficult and less costly (ex. NATs, spam, phishing, etc.)

Best
jfc