From jefsey@jefsey.com Sat Oct 1 19:58:42 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F6C21F8DC1 for ; Sat, 1 Oct 2011 19:58:42 -0700 (PDT) X-Quarantine-ID: <9jlBVGXxK74f> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): To: Mark Davis \342\230\225 ; Sat, 1 Oct 2011 19:58:42 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 281B021F8DBE for ; Sat, 1 Oct 2011 19:58:42 -0700 (PDT) Received: from 191.39-227-89.dsl.completel.net ([89.227.39.191]:53765 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RACIz-0002bF-26; Sat, 01 Oct 2011 20:01:30 -0700 Message-Id: <7.0.1.0.2.20111002030029.06bbe790@morfin.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 02 Oct 2011 05:06:28 +0200 To: Mark Davis ☕ ,John C Klensin From: JFC Morfin In-Reply-To: References: <4E861F84.6000605@KingsMountain.com> <14729D7066436A2D3B5A3BDC@192.168.1.128> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_95845532==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: IETF IDNA Update WG , iucg@ietf.org, =JeffH Subject: Re: [iucg] wrt IDNA2008 migration (was: IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 02:58:42 -0000 --=====================_95845532==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit At 02:27 02/10/2011, Mark Davis ☕ wrote: >The third choice, of course, was to maintain backwards compatibility >with 2003 for all characters in Unicode 3.2, and just extend the >same principles to new characters. That is a much easier migration path... > >We've seen this before. XML 1.1 only had a small >breaking-compatibility changes, but those changes were enough to >completely doom it. Mark, Your "backwards" compatibility word is correct in terms of usage (your part as Unicode), but is architecurally incorrect because what you actually want is "forwards" IDNA2003 compatibility, with extensions to Unicode 6.1, etc. And this is exactly what IDNA2008 permits but has not documented yet. IDNA2003 actually tested a bundle of different concepts. This test shown that most of these concepts were OK but that the bundling introduced layer violations. The operational IDNA2003 (your need) works.The architectural IDNA2003 (the IETF and users' need) does not scale. >But as you say, that was not the rough consensus of the WG. To the countrary. And this is why I pushed for a quick consensus and for working on IDNA2010 (as the technical use of IDNA2008) and then on IDNA2012 (as the general usage of IDNA2008). Why? you may recall that after the LCs the AD started to raise good architectural questions leading the IESG to not accept RFC 5895 as a WG deliverable. These questions and their solutions were of the essence but ... outside the WG charter. It was then an absolute necessity that we establish IDNA2008, so we might work on the following steps, rather than keeping discussing along our limited charter. As a result, RFC 5895 was not discussed by the WG as it should have had. Therefore, an IDNA2003 section was not included which should have documented how developpers could develop a scalable "IDNA2003 interface" (i.e. a "forewards" adaptibillity at [or with] the user application and an IDNA2008 interface with the Internet DNS). Such an "IDNA2003 layer" is one of the multiple layers (ML) the IDNA2008 conformant ML-DNS should support. Best. jfc --=====================_95845532==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit At 02:27 02/10/2011, Mark Davis ☕ wrote:
The third choice, of course, was to maintain backwards compatibility with 2003 for all characters in Unicode 3.2, and just extend the same principles to new characters. That is a much easier migration path...

We've seen this before. XML 1.1 only had a small breaking-compatibility changes, but those changes were enough to completely doom it.

Mark,

Your "backwards" compatibility word is correct in terms of usage (your part as Unicode), but is architecurally incorrect because what you actually want is "forwards" IDNA2003 compatibility, with extensions to Unicode 6.1, etc. And this is exactly what IDNA2008 permits but has not documented yet.

IDNA2003 actually tested a bundle of different concepts. This test shown that most of these concepts were OK but that the bundling introduced layer violations. The operational IDNA2003 (your need) works.The architectural IDNA2003 (the IETF and users' need) does not scale.

But as you say, that was not the rough consensus of the WG.

To the countrary. And this is why I pushed for  a quick consensus and  for working on IDNA2010 (as the technical use of  IDNA2008) and then on  IDNA2012 (as the general usage of IDNA2008).

Why? you may recall that after the LCs the AD started to raise good architectural questions leading the IESG to not accept RFC 5895 as a WG deliverable. These questions and their solutions were of the essence but ... outside the WG charter.

It was then an absolute necessity that we establish IDNA2008, so we might work on the following steps, rather than keeping discussing along our limited charter.

As a result, RFC 5895 was not discussed by the WG as it should have had. Therefore, an IDNA2003 section was not included which should have documented how developpers could develop a scalable "IDNA2003 interface" (i.e. a "forewards" adaptibillity at [or with] the user application and an IDNA2008 interface with the Internet DNS). Such an "IDNA2003 layer" is one of the multiple layers (ML) the IDNA2008 conformant ML-DNS should support.

Best.
jfc


--=====================_95845532==.ALT-- From jmabdp@gmail.com Sun Oct 2 15:38:29 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AD221F8515 for ; Sun, 2 Oct 2011 15:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6n9UDL-LgLt for ; Sun, 2 Oct 2011 15:38:28 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C77521F8514 for ; Sun, 2 Oct 2011 15:38:27 -0700 (PDT) Received: by wyh21 with SMTP id 21so2969880wyh.31 for ; Sun, 02 Oct 2011 15:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4W+RpnHbgRJ30axI/Phu5pA0EF8SflArX9nUNTNUsnE=; b=QL7pymFHkApc9ZhGJMWYMVYJzyqJ1ksH/hTxRUJ86S73kTk2m63LpWubl7rlKCv+mg dUYzH0gu2Hh4kPNj0e4Lml/gKg+FjB8Kg9uAe4d/7h9mHKYhluZgtYrm4LXaFnIYl8J4 698m2BDSMb7BLYD68PVPEKJRn6oCuJYR3gWZI= MIME-Version: 1.0 Received: by 10.227.195.13 with SMTP id ea13mr203907wbb.36.1317595287530; Sun, 02 Oct 2011 15:41:27 -0700 (PDT) Received: by 10.227.143.12 with HTTP; Sun, 2 Oct 2011 15:41:27 -0700 (PDT) In-Reply-To: <14F34D013E231FEA14AB5C27@192.168.1.128> References: <4E861F84.6000605@KingsMountain.com> <14729D7066436A2D3B5A3BDC@192.168.1.128> <14F34D013E231FEA14AB5C27@192.168.1.128> Date: Mon, 3 Oct 2011 00:41:27 +0200 Message-ID: From: jean-michel bernier de portzamparc To: JFC Morfin , internet users contributing group Content-Type: multipart/alternative; boundary=20cf30025a58122c5904ae588f29 Cc: John C Klensin , =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= , IETF IDNA Update WG , =JeffH Subject: Re: [iucg] wrt IDNA2008 migration (was: IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 22:38:29 -0000 --20cf30025a58122c5904ae588f29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jefsey and dear colleagues, I frankly think we share the same sun but are planets apart with John (hi! = , so far away John - thanks for what you did!). I therefore do not see the need for us to try to spend our weak resources t= o make these people understand what we achieved together, what we are doing, and more than anything else what we need. They are just not interested for most, and the friendly ones just do not understand how they could "rock the mammoth". "Perhaps that would have been the right answer but, again, it wasn't what the WG decided on" (John!) The WG decided nothing! The charter decided it (irt. Unicode and mapping) and the Internet had already decided the rest ("too much calls for subsidiarity"). Our IUusersdebated question is "do we keep pretending we are dismayed yet cooperating Internet lead users, and trying to help ? or do we consider tha= t our interest lies in the Intersem, that we are mainly interested in it, and that however keep being concerned by Telecoms and Internet issues for being part of the data and content oriented communications strata below?". Frankly, John Klensin is by far the most advanced and open minded one in terms of our architectural requirements. Are we happy with RFC 6055? What does IAB provides us with? Vint Cerf did move with Google+, IAB not. Unicod= e not. IETF not. ICANN not. It clearly shows that it is Google and us, and probably - further - on Google vs. us. This is why I vote for clarification and efficiency and I claim being an "Intersem user", relating with the IETF rather than contributing to it. Eve= n if the Intersem is still at exploration, prespecification, prototype development stage, I do agree that this will clarify the issues and most probably permit us to better help IETF-men through occasional summaries and reports published as informational RFCs. Mark and John are right. Now we have: XML 1.1 for five years, IPv6 for 15 years, IDNA2008 for two years, and still a 1983 Internet (28 years). And nothing moves. This is because the politically correct use is still the decentralized master/slave dumb end to end use of the RFC 3935 architecture= , and it is still accepted by users. They achieved the maximum Unicode and IETF could do. Either we are happy at their Internet level or we move to th= e next net stratum. Best and thanks to all for the Internet and your netkeeping. But I need to move up! Portzamparc. 2011/10/2 John C Klensin > > > --On Saturday, October 01, 2011 17:27 -0700 Mark Davis =E2=98=95 > wrote: > > > The third choice, of course, was to maintain backwards > > compatibility with 2003 for all characters in Unicode 3.2, and > > just extend the same principles to new characters. That is a > > much easier migration path... > > Unfortunately, that level of compatibility would have > permanently doomed those who believe that ZWJ and ZWNJ (and some > other "map to nothing" cases) to permanently living with > distinctions that they consider very important. Perhaps that > would have been the right answer but, again, it wasn't what the > WG decided on. > > > We've seen this before. XML 1.1 only had a small > > breaking-compatibility changes, but those changes were enough > > to completely doom it. > > Although the jury is still out, the same could be said for IPv6. > To the extent that analogy is relevant, one might suggest that > there weren't enough perceived benefits in XML 1.1 and IPv6 to > justify dealing with the incompatibilities... or the conversion > and deployment costs whether or not the incompatibilities > existed. It is harder to prove that the incompatibilities alone > are to blame. > > On the other hand, if strict backward-compatibility with > deployed technologies were always the right answer, we wouldn't > need to be having discussions about conversions of > tungsten-filament incandescent lighting to CFLs and LEDs because > we would still be using candles and gas or, to use an older > analogy, we would be worried about a rather different sort of > pollution and waste problem in our cities than emissions from > automobiles. > > john > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > --20cf30025a58122c5904ae588f29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jefsey and dear colleagues,
I frankly think we share the same sun but ar= e planets apart with John (hi! , so far away John - thanks for what you did= !).

I therefore do not see the need for us to try to spend our weak = resources to make these people understand what we achieved together, what w= e are doing, and more than anything else what we need. They are just not in= terested for most, and the friendly ones just do not understand how they co= uld "rock the mammoth".

"Perhaps that would have been the right answer but, again, it wasn= 't what the WG decided on" (John!)

The WG decided nothing!= The charter decided it (irt. Unicode and mapping) and the Internet had alr= eady decided the rest ("too much calls for subsidiarity").

Our IUusersdebated question is "do we keep pretending we are disma= yed yet cooperating Internet lead users, and trying to help ? or do we cons= ider that our interest lies in the Intersem, that we are mainly interested = in it, and that however keep being concerned by Telecoms and Internet issue= s for being part of the data and content oriented communications strata bel= ow?".

Frankly, John Klensin is by far the most advanced and open minded one i= n terms of our architectural requirements. Are we happy with RFC 6055? What= does IAB provides us with? Vint Cerf did move with Google+, IAB not. Unico= de not. IETF not. ICANN not. It clearly shows that it is Google and us, and= probably - further - on Google vs. us.

This is why I vote for clarification and efficiency and I claim being a= n "Intersem user", relating with the IETF rather than contributin= g to it. Even if the Intersem is still at exploration, prespecification, pr= ototype development stage, I do agree that this will clarify the issues and= most probably permit us to better help IETF-men through occasional summari= es and reports published as informational RFCs.

Mark and John are right. Now we have: XML 1.1 for five years, IPv6 for = 15 years, IDNA2008 for two years, and still a 1983 Internet (28 years). And= nothing moves. This is because the politically correct use is still the de= centralized master/slave dumb end to end use of the RFC 3935 architecture, = and it is still accepted by users. They achieved the maximum=C2=A0 Unicode = and IETF could do. Either we are happy at their Internet level or we move t= o the next net stratum.

Best and thanks to all for the Internet and your netkeeping.
But I = need to move up!
Portzamparc.




2011/10/2 John C Klensin <klensin@jck.com>


--On Saturday, October 01, 2011 17:27 -0700 Mark Davis =E2=98=95
<mark@macchiato.= com> wrote:

> The third choice, of course, was to maintain backwards
> compatibility with 2003 for all characters in Unicode 3.2, and
> just extend the same principles to new characters. That is a
> much easier migration path...

Unfortunately, that level of compatibility would have
permanently doomed those who believe that ZWJ and ZWNJ (and some
other "map to nothing" cases) to permanently living with
distinctions that they consider very important. =C2=A0Perhaps that
would have been the right answer but, again, it wasn't what the
WG decided on.

> We've seen this before. XML 1.1 only had a small
> breaking-compatibility changes, but those changes were enough
> to completely doom it.

Although the jury is still out, the same could be said for IPv6.
To the extent that analogy is relevant, one might suggest that
there weren't enough perceived benefits in XML 1.1 and IPv6 to
justify dealing with the incompatibilities... or the conversion
and deployment costs whether or not the incompatibilities
existed. =C2=A0It is harder to prove that the incompatibilities alone
are to blame.

On the other hand, if strict backward-compatibility with
deployed technologies were always the right answer, we wouldn't
need to be having discussions about conversions of
tungsten-filament incandescent lighting to CFLs and LEDs because
we would still be using candles and gas or, to use an older
analogy, we would be worried about a rather different sort of
pollution and waste problem in our cities than emissions from
automobiles.

=C2=A0 =C2=A0john

_______________________________________________
Idna-update mailing list
Idna-update@alvestrand.no<= br> http://www.alvestrand.no/mailman/listinfo/idna-update

--20cf30025a58122c5904ae588f29-- From jfc@morfin.org Mon Oct 3 16:49:55 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9419421F8E63 for ; Mon, 3 Oct 2011 16:49:55 -0700 (PDT) X-Quarantine-ID: <8hwLGEUWeLgB> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): Cc: ...nsin@jck.com>,Mark Davis \342\230\225 ; Mon, 3 Oct 2011 16:49:54 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id DF68E21F8E62 for ; Mon, 3 Oct 2011 16:49:54 -0700 (PDT) Received: from 191.39-227-89.dsl.completel.net ([89.227.39.191]:52507 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RAsJc-00037J-CO; Mon, 03 Oct 2011 16:52:56 -0700 Message-Id: <7.0.1.0.2.20111003193655.06a6c6f0@morfin.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 04 Oct 2011 01:58:06 +0200 To: jean-michel bernier de portzamparc , internet users contributing group From: "J-F C. Morfin" In-Reply-To: References: <4E861F84.6000605@KingsMountain.com> <14729D7066436A2D3B5A3BDC@192.168.1.128> <14F34D013E231FEA14AB5C27@192.168.1.128> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - morfin.org X-Source: X-Source-Args: X-Source-Dir: Cc: Mark Davis ☕ , John C Klensin , =JeffH , IETF IDNA Update WG Subject: Re: [iucg] wrt IDNA2008 migration (was: IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 23:49:55 -0000 At 00:41 03/10/2011, jean-michel bernier de portzamparc wrote: >Jefsey and dear colleagues, >I frankly think we share the same sun but are planets apart I apologize for this partly off-topic mail. Jean-Michel, I do not think your mail was appropriate. One does not get the support of people in hurting them with ad hominems and ad personams. IETF is in charge of the Internet. ITU is in charge of Telecoms. This makes different SDOs and different areas, but the same level of dedication. The Intersem is something more different from the Internet than the Internet is from Telecoms because there is a layer gap (active/local content extended services) between Datacoms and what we call Metacoms. This raised the question of the progression: the WG/IDNABis work is precisely what shown how to fill this gap and permit our further progression, i.e.: - architecturally: by external subsidiarity in full respect of the internal Internet and of the external user applications. - documentation wise: through the IUCG, i.e. the cooperation of those who strive to explore the Intersem area with those who strive to make its Internet basis work better. We certainly still have to make it happen, and I understand your impatience, but at least we know how now: the IUI. And this was a good surprise we also still have to digest. In the past I had to oppose Unicode as a consortium, and more recently I had to oppose some propositions within this WG. This was because I considered them commercially biased, as per the IAB RFC 3869 very honest standards, and therefore detrimental to everyone (Telecoms, Common and Extended Datacoms, and Metacoms [that we are not alone to explore]). The work carried by the IETF and Unicode people is brilliant and we need them for the Internet to exist, and further on the Intersem to emerge. There are no bias. There is respectable specialization. We are not on planets apart: we are at different layers of the same communication system. And our layer(s) are not well defined yet. Give me a final definition and a working proto of the Intersem. RFC 1958 explains that to be stamped as "Internet", propositions must be scalable. IDNA2003 was not architecturally scalable, but was operationally scalable as Mark hinted it. IDNA2008 turns out not only to be scalable in terms of linguistic diversity but to exemplify how the whole Internet is by nature more architecturally scalable than expected. This is what delays me: I am only interested in the "Internet Plus" solution to experiment and validate the IUI concepts and power. But that power is much broader than I foresaw and it takes time to understand it within the Internet architecture and then to experiment it in order to learn its pitfalls. I started with the simple idea for the ML-DNS of building a DNS technology fork, adding linguistic and format IDNA2008 conferment and extended converters, in order to handle domain names as a multilayer pile structure. The IDNA2008 "unusual" (RFC 5895) case and IUI have open an architecturally consistent possibility to support fringe to fringe active/local content without change to the Internet legacy achitecture, which only is oriented towards end to end passive content transport. First, classes, netix interapplications, etc. seemed enough to additionally focus on. Now we consider a full Intersem network operating system, plus true multilingualization and semiotics, graphcodes and orthotypography (variants), plus the emergence of diktyology as a major new discipline, plus semantic processing and the need of the direct involvement of syllodata and of a noetic architectony: these things big issues and they have nothing to do with the IETF. The same as W3C and semantic Web has nothing to do with ITU. Except practical discussions like the IANA and ISO 11179 on the happiana list. So, please: WG/IDNAbis and IUCG are IETF. So let us talk of IETF issues, in the IETF way and netiquette. IDNA2003 was architecturally incomplete. IAB evaluated the consequences. This is why they called for IDNA2008 and he IESG approved the WG/IDNAbis charter. ML-DNS would permit to provide IDNA2003 full compatibility (including fringe to fringe French majuscules). What I tried to explain Mark is that if he wishes to keep an IDNA2003 environment and to enhance it, he can discuss it under IDNA2008 ML-DNS. I am late because I laked time and resources and as I just said the matter became very large, this is true, but my propositions are public and everyone can use them and pass me. jfc From jmabdp@gmail.com Mon Oct 3 17:41:39 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692A521F8D6F for ; Mon, 3 Oct 2011 17:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ER8wdrr4e02 for ; Mon, 3 Oct 2011 17:41:38 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A068021F8D6E for ; Mon, 3 Oct 2011 17:41:38 -0700 (PDT) Received: by wyh21 with SMTP id 21so4323036wyh.31 for ; Mon, 03 Oct 2011 17:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o53movBEY7Uj9olaVLxNRrrZXtN2rZbImm3f6oF4K0w=; b=f7q2gF/zIg7iWfoKhknwtT2ftttPsQhwE8tENAT5yZu9SLGKJ1qtPHTAkUcYiXsF+J 5Z+WoHHBnZ7kRiSlgd9qhxmfidJcOOsh6ziSfRpZslQR6cqnFT09tqZiVCcPKG/CIQKn sxnaIWW+aXakDy/N2V8tmY/4UFYcmSKDu0zX0= MIME-Version: 1.0 Received: by 10.227.28.4 with SMTP id k4mr672131wbc.21.1317689081608; Mon, 03 Oct 2011 17:44:41 -0700 (PDT) Received: by 10.227.143.12 with HTTP; Mon, 3 Oct 2011 17:44:41 -0700 (PDT) In-Reply-To: <7.0.1.0.2.20111003193655.06a6c6f0@morfin.org> References: <4E861F84.6000605@KingsMountain.com> <14729D7066436A2D3B5A3BDC@192.168.1.128> <14F34D013E231FEA14AB5C27@192.168.1.128> <7.0.1.0.2.20111003193655.06a6c6f0@morfin.org> Date: Tue, 4 Oct 2011 02:44:41 +0200 Message-ID: From: jean-michel bernier de portzamparc To: "J-F C. Morfin" Content-Type: multipart/alternative; boundary=002215b03162a23b8704ae6e6561 Cc: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= , John C Klensin , internet users contributing group , =JeffH , IETF IDNA Update WG Subject: Re: [iucg] wrt IDNA2008 migration (was: IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 00:41:39 -0000 --002215b03162a23b8704ae6e6561 Content-Type: text/plain; charset=ISO-8859-1 Jefsey and all, I apologize to everyone if my mail was off topic and hrting. This was not intended. Please understand that one may get frustrated with IDNA2008 being two years old, the same for the IUI, the same for the ML-DNS. And nothing running yet! I understand the huge complexity of the Intersem project and your personal load during these two years. I just considered that starting top odwn from the Intersem topic (starting from mind2mind intercomprehension) might be more motivating than proceeding bottom-up from plug2plug, end2end, fringe2fringe, brain2brain, noos2noos ... Portzamparc 2011/10/4 J-F C. Morfin > At 00:41 03/10/2011, jean-michel bernier de portzamparc wrote: > >> Jefsey and dear colleagues, >> I frankly think we share the same sun but are planets apart >> > > I apologize for this partly off-topic mail. > Jean-Michel, > I do not think your mail was appropriate. > --002215b03162a23b8704ae6e6561 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jefsey and all,
I apologize to everyone if my mail was off topic and hrt= ing. This was not intended.
Please understand that one may get frustrate= d with IDNA2008 being two years old, the same for the IUI, the same for the= ML-DNS. And nothing running yet!
I understand the huge complexity of the Intersem project and your personal = load during these two years.
I just considered that starting top odwn fr= om the Intersem topic (starting from mind2mind intercomprehension) might be= more motivating than proceeding bottom-up from plug2plug, end2end, fringe2= fringe, brain2brain, noos2noos ...
Portzamparc

2011/10/4 J-F C. Morfin <jfc@morfin.org>
At 00:41 03/10/2011, jean-michel bernier de portzamparc w= rote:
Jefsey and dear colleagues,
I frankly think we share the same sun but are planets apart

I apologize for this partly off-topic mail.
Jean-Michel,
I do not think your mail was appropriate.

--002215b03162a23b8704ae6e6561-- From mfberny@gmail.com Mon Oct 3 18:49:32 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C715D21F8E35 for ; Mon, 3 Oct 2011 18:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFrFK4B4XQem for ; Mon, 3 Oct 2011 18:49:32 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E09A721F8DC8 for ; Mon, 3 Oct 2011 18:49:31 -0700 (PDT) Received: by gyd12 with SMTP id 12so850gyd.31 for ; Mon, 03 Oct 2011 18:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=UuKmh6kg4l9lFRfdhEEK4qqLzvuGH8n7g0NV/KHuGes=; b=aVEGEy7HshfJ0uNdBTXBGadznlLjRG86KywBsDxTVx0kVctZdnxbbGPj506nyBv5Bv mwCWWV1AO8JuefMz+YzXQjXOXGfgtXVoOWK5E28X+lsasbB5XLXGbad0irS9UjksXFc4 FVU7CXjgy6hQXzro96XZNJHam/kKQ/Ibe8LoY= MIME-Version: 1.0 Received: by 10.236.147.114 with SMTP id s78mr3463255yhj.45.1317693155563; Mon, 03 Oct 2011 18:52:35 -0700 (PDT) Received: by 10.236.61.35 with HTTP; Mon, 3 Oct 2011 18:52:35 -0700 (PDT) Date: Tue, 4 Oct 2011 03:52:35 +0200 Message-ID: From: Marie-France Berny To: internet users contributing group Content-Type: multipart/alternative; boundary=20cf303dd2d875d77b04ae6f58b9 Subject: [iucg] mind2mind X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 01:49:32 -0000 --20cf303dd2d875d77b04ae6f58b9 Content-Type: text/plain; charset=ISO-8859-1 Jefsey I must say that I share jean-michel's frustration. I fully understand we miss the developpers capacities we need, but we might try to think and work together on the box2box level, supposing that everything below works. I had a look at your entries in http://ecomoneco.com on the Intersem. What we should try to do is to start from there, build a working boiler-plate, so we have the same presentation everywhere, in bi-lingual format. You said you would have some more time from end of october. Is this still true? Marie-France 2011/10/4 jean-michel bernier de portzamparc > Jefsey and all, > I apologize to everyone if my mail was off topic and hrting. This was not > intended. > Please understand that one may get frustrated with IDNA2008 being two years > old, the same for the IUI, the same for the ML-DNS. And nothing running yet! > I understand the huge complexity of the Intersem project and your personal > load during these two years. > I just considered that starting top odwn from the Intersem topic (starting > from mind2mind intercomprehension) might be more motivating than proceeding > bottom-up from plug2plug, end2end, fringe2fringe, brain2brain, noos2noos ... > Portzamparc > > 2011/10/4 J-F C. Morfin > > At 00:41 03/10/2011, jean-michel bernier de portzamparc wrote: >> >>> Jefsey and dear colleagues, >>> I frankly think we share the same sun but are planets apart >>> >> >> I apologize for this partly off-topic mail. >> Jean-Michel, >> I do not think your mail was appropriate. >> > > > _______________________________________________ > iucg mailing list > iucg@ietf.org > https://www.ietf.org/mailman/listinfo/iucg > > --20cf303dd2d875d77b04ae6f58b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jefsey
I must say that I share jean-michel's frustration. I fully un= derstand we miss the developpers capacities we need, but we might try to th= ink and work together on the box2box level, supposing that everything below= works. I had a look at your entries in ht= tp://ecomoneco.com on the Intersem. What we should try to do is to star= t from there, build a working boiler-plate, so we have the same presentatio= n everywhere, in bi-lingual format.
You said you would have some more time from end of october. Is this still t= rue?
Marie-France


2011/10/4 jean-m= ichel bernier de portzamparc <jmabdp@gmail.com>
Jefsey and all,
I apologize to everyone = if my mail was off topic and hrting. This was not intended.
Please under= stand that one may get frustrated with IDNA2008 being two years old, the sa= me for the IUI, the same for the ML-DNS. And nothing running yet!
I understand the huge complexity of the Intersem project and your personal = load during these two years.
I just considered that starting top odwn fr= om the Intersem topic (starting from mind2mind intercomprehension) might be= more motivating than proceeding bottom-up from plug2plug, end2end, fringe2= fringe, brain2brain, noos2noos ...
Portzamparc

2011/10/4 J-F C. Morfin <jfc@mo= rfin.org>

At 00:41 03/10/2011, jean-michel bernier de portzamparc wrote:
Jefsey and dear colleagues,
I frankly think we share the same sun but are planets apart

I apologize for this partly off-topic mail.
Jean-Michel,
I do not think your mail was appropriate.

<= div style=3D"padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;wor= d-wrap:break-word;color:black;font-size:10px;text-align:left;line-height:13= 0%">

_______________________________________________
iucg mailing list
iucg@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/iucg


--20cf303dd2d875d77b04ae6f58b9-- From jfc@morfin.org Tue Oct 4 01:21:59 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766DC21F8997 for ; Tue, 4 Oct 2011 01:21:59 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): To: Mark Davis \342\230\225 ; Tue, 4 Oct 2011 01:21:58 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id D93B121F889A for ; Tue, 4 Oct 2011 01:21:56 -0700 (PDT) Received: from 191.39-227-89.dsl.completel.net ([89.227.39.191]:53623 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RB0J1-0002Vi-MD; Tue, 04 Oct 2011 01:24:52 -0700 Message-Id: <7.0.1.0.2.20111004091057.06a6cd58@morfin.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 04 Oct 2011 10:30:02 +0200 To: Mark Davis ☕ ,John C Klensin From: "J-F C. Morfin" In-Reply-To: References: <4E861F84.6000605@KingsMountain.com> <14729D7066436A2D3B5A3BDC@192.168.1.128> <14F34D013E231FEA14AB5C27@192.168.1.128> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_117498205==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - morfin.org X-Source: X-Source-Args: X-Source-Dir: Cc: IETF IDNA Update WG , iucg@ietf.org, =JeffH Subject: Re: [iucg] wrt IDNA2008 migration (was: IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 08:21:59 -0000 --=====================_117498205==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit At 05:59 04/10/2011, Mark Davis ☕ wrote: >There are other alternatives. The obvious one is, well, maintaining >backwards compatibility. In this case, it would provide that: > * Every valid 2003 IDN remains valid under 2008 > * Additional valid IDNs are allowed under 2008: with either post > Unicode 3.2 characters or those unmapped by 2003. This is exactly what IDNA2003 did not permit and IDNA2003 does permit. However: - this demand belong to the user side. Therefore, someone must develop it on the user side, as RFC 3958 exemplifies it. I am not alone and buzy: Unicode could do it. - there may be other demands that a strict statu quo: this is why adequate developments on the user side must support multiple solutions. And why, to answer the questions of Lisa Dussault, the IDNinA is to be replaced first by an IDNApplication. IDNA2003 did not architecturally scale, but IDNinA also does not scale. Now, you and I can keep ourself repeating this non-exchange for years, until users have defacto changed from the Internet2003 to their Internet20XX. It is true that IDNA2008 has changed the status of the Unicode consortium contribution to the Internet architecture. Why is Unicode not taking advantage from it to bring other contribution. For example, why is Unicode not participating to the ICANN/VIP work? "IDNA201XX" will have to support variants and, more generaly, orthotypography. This going to call for the support of "netlocale" new kind of files. Will this be through a grassroots, an ICANN, an IETF, an Unicode or a joint effort? To permit is the "IDNA2010" basic concepts of the IUI "plugged layers on the user side" (Internet PLUS) are to be identified, tested, validated (ML-DNS), within the IDNA architectural framework. Or just delayed in implementing some on the Host side, like with the "Google+". Or in joing efforts. Best jfc --=====================_117498205==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit At 05:59 04/10/2011, Mark Davis ☕ wrote:
There are other alternatives. The obvious one is, well, maintaining backwards compatibility. In this case, it would provide that:
  • Every valid 2003 IDN remains valid under 2008
  • Additional valid IDNs are allowed under 2008: with either post Unicode 3.2 characters or those unmapped by 2003.
This is exactly what IDNA2003 did not permit and IDNA2003 does permit. However:

- this demand belong to the user side. Therefore, someone must develop it on the user side, as RFC 3958 exemplifies it. I am not alone and buzy: Unicode could do it.
- there may be other demands that a strict statu quo: this is why adequate developments on the user side must support multiple solutions. And why, to answer the questions of Lisa Dussault, the IDNinA is to be replaced  first by an IDNApplication. IDNA2003 did not architecturally scale, but IDNinA also does not scale.

Now, you and I can keep ourself repeating this non-exchange for years, until users have defacto changed from the Internet2003 to their Internet20XX. It is true that IDNA2008 has changed the status of the Unicode consortium contribution to the Internet architecture. Why is Unicode not taking advantage from it to bring other contribution. For example, why is Unicode not participating to the ICANN/VIP work?

"IDNA201XX" will have to support variants and, more generaly, orthotypography. This going to call for the support of "netlocale" new kind of files. Will this be through a grassroots, an ICANN, an IETF, an Unicode or a joint effort? To permit is the "IDNA2010" basic concepts of the IUI "plugged layers on the user side" (Internet PLUS) are to be identified, tested, validated (ML-DNS), within the IDNA architectural framework. Or just delayed in implementing some on the Host side, like with the "Google+". Or in joing efforts.

Best
jfc
--=====================_117498205==.ALT-- From psuger@gmail.com Tue Oct 4 10:50:56 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A452221F8CC0 for ; Tue, 4 Oct 2011 10:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tjAcP7W8wL0 for ; Tue, 4 Oct 2011 10:50:56 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5C91921F8D6F for ; Tue, 4 Oct 2011 10:50:55 -0700 (PDT) Received: by qyk33 with SMTP id 33so661221qyk.10 for ; Tue, 04 Oct 2011 10:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ePBZ9rJIwh3pqkyY6j9dg15twANaY39EDHH/NXlCyOc=; b=WbUuGKZYgjSfnDsz3b8ccJqQMiKPWLcvP1+1BFfCbTqIfG0mcVuSNdTX7KMf2cnVP5 ojTDurHr/3g2+g1Noq46kAwDO4Jko9J10WMdDUp29r7y/GaI31qoJeKrUBvU1We79eEZ 08tAcsLCXCktjdBO8l6YZTWnTO4HyWwf1o5Iw= MIME-Version: 1.0 Received: by 10.68.55.100 with SMTP id r4mr11273226pbp.69.1317750840272; Tue, 04 Oct 2011 10:54:00 -0700 (PDT) Received: by 10.68.46.39 with HTTP; Tue, 4 Oct 2011 10:54:00 -0700 (PDT) In-Reply-To: <7.0.1.0.2.20111004091057.06a6cd58@morfin.org> References: <4E861F84.6000605@KingsMountain.com> <14729D7066436A2D3B5A3BDC@192.168.1.128> <14F34D013E231FEA14AB5C27@192.168.1.128> <7.0.1.0.2.20111004091057.06a6cd58@morfin.org> Date: Tue, 4 Oct 2011 19:54:00 +0200 Message-ID: From: Patrick Suger To: internet users contributing group Content-Type: multipart/alternative; boundary=bcaec53af0bebca69404ae7cc6b3 Cc: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= , John C Klensin , =JeffH , IETF IDNA Update WG Subject: Re: [iucg] wrt IDNA2008 migration (was: IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 17:50:56 -0000 --bcaec53af0bebca69404ae7cc6b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable as a group we do not understand because we did not understand what the problem was and what we really agreed upon. No surprise, this is typically = a "third window" problem. This also is true for Jean-Michel and most of the "JEDIs" I am afraid. There is no bottom-up, nor top-down correct approach: this was the actual IDNA2008 consensus. This is complexity. There is an iterative synergy approach. The work carried by ICANN WG/VIP might be impressive: yet how could the IETF methodology address it and make a better internet out of their variants? I agree with you guys that the Intersem could be the correct approach but through internal self-catalysis. However, who is ready to think that way? PS 2011/10/4 J-F C. Morfin > At 05:59 04/10/2011, Mark Davis =E2=98=95 wrote: > > There are other alternatives. The obvious one is, well, maintaining > backwards compatibility. In this case, it would provide that: > > - Every valid 2003 IDN remains valid under 2008 > - Additional valid IDNs are allowed under 2008: with either post > Unicode 3.2 characters or those unmapped by 2003. > > This is exactly what IDNA2003 did not permit and IDNA2003 does permit. > --bcaec53af0bebca69404ae7cc6b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable as a group we do not understand because we did not understand what the prob= lem was and what we really agreed upon. No surprise, this is typically a &q= uot;third window" problem. This also is true for Jean-Michel and most = of the "JEDIs" I am afraid.
There is no bottom-up, nor top-down correct approach: this was the actual I= DNA2008 consensus. This is complexity. There is an iterative synergy approa= ch. The work carried by ICANN WG/VIP might be impressive: yet how could the= IETF methodology address it and make a better internet out of their varian= ts?
I agree with you guys that the Intersem could be the correct approach but t= hrough internal self-catalysis. However, who is ready to think that way?PS

2011/10/4 J-F C. Morfin <jfc@morfin.org>
At 05:59 04/10/2011, Mark Davis =E2=98=95 wrote:
There are other alternatives. The obvious one is, well, maintaining backwards compatibility. In this case, it would provide that:=20
  • Every valid 2003 IDN remains valid under 2008=20
  • Additional valid IDNs are allowed under 2008: with either post Unicode 3.2 characters or those unmapped by 2003.
This is exactly what IDNA2003 did not permit and IDNA2003 does permit.

--bcaec53af0bebca69404ae7cc6b3-- From jefsey@jefsey.com Sat Oct 8 18:58:53 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2BC21F8B7F for ; Sat, 8 Oct 2011 18:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRJkDTWsZCNv for ; Sat, 8 Oct 2011 18:58:52 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 93CD721F8B7D for ; Sat, 8 Oct 2011 18:58:52 -0700 (PDT) Received: from 196.237-227-89.dsl.completel.net ([89.227.237.196]:63854 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RCif8-0004B1-C0; Sat, 08 Oct 2011 18:58:47 -0700 Message-Id: <7.0.1.0.2.20111008191649.06ceaa08@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 09 Oct 2011 03:18:56 +0200 To: Gervase Markham From: JFC Morfin In-Reply-To: <4E907083.5010509@mozilla.org> References: <4E853263.1040508@KingsMountain.com> <4E861170.8090201@stpeter.im> <4E907083.5010509@mozilla.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: iucg@ietf.org, =JeffH Subject: Re: [iucg] IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 01:58:53 -0000 At 17:47 08/10/2011, Gervase Markham wrote: >On 30/09/11 19:58, Peter Saint-Andre wrote: > > Because it seems that most or all of the browsers implement IDNA2003 but > > have no plans to migrate to IDNA2008. > >Mozilla wishes, as far as I know, to migrate to IDNA2008, but we are >blocked by two problems: > >- a licensing issue with the library we want to use >- manpower Gervase, there are two complementary types of support IDNA2008 which only specifies the network side behavior: - through the IDNA current architectural framework: in this case you have to use a library and implement it. - through the IUI (Intelligent Use Interface) supporting a unified IDNA service: in that case one only have to make sure that what is typed in by the user is what is passed to the IUI ML-DNS resolver. IDNA2008 compliance and punycode conversion is one of its tasks. At this stage, the IUI architecture well understood and partly disclosed at the IUCG site. The delay we meet with the ML-DNS testing are also due to man power, but most of all to the evaluation, test and choice of the components of an IUI quasi universal prototype middleware. Until now, I did bet on an IETF efficiency and waited for the IAB to acknowledge the architectural implications of IDNA2008. Jeff Hodges's questions shown I was wrong. So, I am going to work more seriously these coming mounths on an IUI prototype and on an organization to document its standards. The only thing I would need from Firefox would be an easy options menu choice : - enable stringprep+punycode - enable punycode after IDNA2008 filtering. - filter non-ASCII entries - disable any modification of the user entry. Best jfc From jefsey@jefsey.com Tue Oct 11 02:40:26 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0309621F86C1 for ; Tue, 11 Oct 2011 02:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.7 X-Spam-Level: X-Spam-Status: No, score=-99.7 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, J_CHICKENPOX_55=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EODwHl01Iyme for ; Tue, 11 Oct 2011 02:40:25 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 99F1621F86AA for ; Tue, 11 Oct 2011 02:40:25 -0700 (PDT) Received: from 196.237-227-89.dsl.completel.net ([89.227.237.196]:57814 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RDYon-0007Cl-3b; Tue, 11 Oct 2011 02:40:14 -0700 Message-Id: <7.0.1.0.2.20111011112411.06a6d798@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 11 Oct 2011 11:45:45 +0200 To: Frank Ellermann , John C Klensin From: JFC Morfin In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: IETF IDNA Update WG , iucg@ietf.org Subject: Re: [iucg] UTS 46 (was: IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 09:40:26 -0000 At 07:17 11/10/2011, Frank Ellermann wrote: >they would be also able to flag say Latin + Cyril mixtures, Agreed. However nothing forbids Latin+Cyril trade-marked mixtures, moreover at globalization time. WIPO realized and accepted the problem when we discussed it in Geneva some years ago. A sollution could have been to use x--n as a header, x--ncocacola.com being less confusing. The only solution which resisted technical and max legal (not all) objections was a CLASS 0 referent layer in the multi-layer domain name pile that would be based on sign binary graphs (unigraph) permitting an unisign algorithm. Such an algorithm would embedd a "punyplus" punycode extension to support metadata (e.g. French majuscules, which can optionally expressed as accentuated or not upper-cases or lower cases, with a direct consequence on the readibility of the word meaning). jfc From jefsey@jefsey.com Thu Oct 27 23:54:11 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7770921F8797; Thu, 27 Oct 2011 23:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n96CquuMP-ob; Thu, 27 Oct 2011 23:54:10 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 26C6D21F8770; Thu, 27 Oct 2011 23:54:03 -0700 (PDT) Received: from 243.96-227-89.dsl.completel.net ([89.227.96.243]:54615 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RJgKH-0004cG-B1; Thu, 27 Oct 2011 23:54:02 -0700 Message-Id: <7.0.1.0.2.20111027114817.06d3d9e0@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 28 Oct 2011 09:00:48 +0200 To: Yoshiro YONEYA ,precis@ietf.org From: JFC Morfin In-Reply-To: <20111026145017.35f865e5.yoshiro.yoneya@jprs.co.jp> References: <20111026145017.35f865e5.yoshiro.yoneya@jprs.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: iab@ietf.org, iucg@ietf.org Subject: Re: [iucg] [precis] Fw: I-D Action: draft-yoneya-precis-mappings-00.txt X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 06:54:11 -0000 At 07:50 26/10/2011, Yoshiro YONEYA wrote: >Dear all, >I submitted a preliminary mapping document as an individual (no hat). >I'd like to discuss this topic at Taipei. Dear Yoshiro, Being only an IETF user I cannot afford attending its meetings. Here are some IDNA2008 remarks on the concerned topic. 1. Lack of a presentation layer The reason as to why IDNs and Internationalized strings support takes so long is that it is supposed to be the job of an OSI presentation layer, which is absent from the Internet. 1) The IDNA concept and IDNA2003 were based upon a presentation layer patch that did not scale the number of scripts, language specifics, and time (Unicode new versions) very well. 2) IDNA2008 has only partly uncovered, introduced, and implemented the very rich non-OSI way that the Internet supports presentation services. 2. The solution is to be RFC 1958 conformant. As a result, there are three, RFC 1958, well defined issues: 2.1. Single network encoding RFC 1958:3.2: "If there are several ways of doing the same thing, choose one. [...] Duplication of the same protocol functionality should be avoided as far as possible". This means how to make the IDNA2003 and IDNA2008 transition and coexist within end to end Internet protocols. The response is RFC 1958:3.5 "Keep it simple. When in doubt during design, choose the simplest solution." This is why IAB's RFC 6055 "explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today." 2.2. Orthotypography RFC 1958:5.4: "Designs should be fully international, with support for localization (adaptation to local character sets). In particular, there should be a uniform approach to character set tagging for information content." This means that the support of linguistic orthotypography, i.e. scripting syntax, is mandatory (French, Latin language, PRECIS mapping, etc.). However, IDNA2008 could not support it on an end to end basis - RFC 1958:4.3: "Public (i.e. widely visible) names should be in case-independent ASCII. Specifically, this refers to DNS names, and to protocol elements that are transmitted in text format." Therefore, it must be addressed differently - RFC 1958:3.6 "Modularity is good. If you can keep things separate, do so." and RFC 1958:2.3: "Everything else should be done at the fringes.": the response is carried out by fringe to fringe modules. This is the enormous power of IDNA2008: to address (linguistic, application, etc.) diversity by (local, contextual) subsidiarity. 2.3. Scalability RFC 1958:3.1: "Heterogeneity is inevitable and must be supported by design"; RFC 1958:2:1: "The community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network."; RFC 1958:3.3: "All designs must scale readily to very many nodes per site and to many millions of sites". This means that the whole "IDNA" architectural concept is to be reviewed in order for it to be simple, orthotypographic, and scalable fully using IDNA2008 to address the heterogeneity of the linguistic diversity. 3. Consequent need Without considering any other context and technical opportunity, this means that the IDNA2008 should modularly support orthotypography on a fringe to fringe basis so as to readily scale to very many nodes, many millions of sites, and many billions of kinds of (orthotypographic) use. The IDNA2003 fringe is stringprep, which did not scale. IDNA2008 puts punycode at the fringe: therefore, punycode has to transparently scale, and punycode can transparently scale. 3.1. Algorithmic solution How to make punycode scale? RFC 1958 says nearly everything: RFC 1958:6.1 "All designs must fit into the IP security architecture". RFC 1958.6.2: "the primary responsibility of the end users to protect themselves." - RFC 1958:6.5. "To ensure interoperation between endpoints [] one algorithm (or suite of algorithms) should be mandated to ensure the ability to negotiate a [] context between implementations. Without this, implementations might otherwise not have an algorithm in common and not be able to communicate []." RFC 1958:3.8: "Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually" - punycode is to be enhanced into a "punyplus" strictly punycode conformant algorithm, with (an) extension(s) to be defined. - so it may optionally support applications' orthotypographic needs (upper-cases, variants, etc.) in a simple, dynamic manner. - this must be kept transparent to IDNA2003 and non-enhanced punycode versions. 3.2. Architecturally stable framework solution. The rest is to be deduced from the above requirements: the simplest manner to obtain this and to answer the pertinent questions raised by the Applications AD (Lisa Dussault) after the WG and ITEF/LC is to embed that "simple dynamic manner" in order to serve multi-level applications into an IDNA2008 multi-level service. RFC 5895 exemplifies one of them. The term "ML-DNS", standing for multilayer DNS front-end service, generalizes the concept. Once you have accepted this, you see that there still is a lot of architectural work, but that this architectural work: 1. is orthogonal to the "punyplus" design. 2. will only better house and protect the punycode/punyplus function. 4. Implementation 4.1. Conceptual clarification RFC 1958:4.2 "A single naming structure should be used." RFC 1958:3.12: "All specifications should use the same terminology and notation, and the same bit- and byte-order convention". This means that the priority should be to unify DNs and IDNs into a single Internet Domain Name System (IDNS) that could interoperate with other technologies' DNS and be documented simply and by using the same terms and models. 4.2. Intertesting RFC 1958:3.14 "And perhaps most important: Nothing gets standardised until there are multiple instances of running code." The whole issue should be tested. This means that once the current WG/PRECIS, happianna, ICANN variants, IAB and IUCG inputs are gathered (RFC 1958:3.7 "In many cases it is better to adopt an almost complete solution now, rather than to wait until a perfect solution can be found"), it should be the right time to document an experiment on an architectural framework at a fringe IDNs use Interface (IUI) that is able to support the multiple IDN layers (ASCII, UTF-8, with/without uppercase, etc.) that are actually being discussed. However, an "intertest" charter, i.e. the terms and conditions for the community to use the Internet as the test-bed of its own evolution, should be crafted first based on RFCs and ICANN/ICP-3 various lists of constraints. jfc >-- >Yoshiro YONEYA > >Begin forwarded message: > >Date: Mon, 24 Oct 2011 03:09:24 -0700 >From: internet-drafts@ietf.org >To: i-d-announce@ietf.org >Subject: I-D Action: draft-yoneya-precis-mappings-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Mapping characters for PRECIS classes > Author(s) : Yoshiro YONEYA > Filename : draft-yoneya-precis-mappings-00.txt > Pages : 9 > Date : 2011-10-24 > > Preparation and comparison of internationalized strings > ("PRECIS") > Framework [I-D.ietf-precis-framework] is defining several classes of > strings for preparation and comparison. In the document, case > mapping is defined because many of protocols handle case sensitive or > case insensitive string comparison and therefore preparation of > string is mandatory. As described in IDNA mapping [RFC5895] and > PRECIS problem statement [I-D.ietf-precis-problem-statement], > mappings in internationalized strings are not limited to case, but > also width and/or delimiters are taken into consideration. This > document considers mappings other than case mapping in PRECIS > context. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-yoneya-precis-mappings-00.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-yoneya-precis-mappings-00.txt >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >_______________________________________________ >precis mailing list >precis@ietf.org >https://www.ietf.org/mailman/listinfo/precis From jefsey@gmail.com Mon Oct 31 03:48:21 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183AF21F8D02; Mon, 31 Oct 2011 03:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9zRCRyFjjkb; Mon, 31 Oct 2011 03:48:20 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCA921F8D00; Mon, 31 Oct 2011 03:48:19 -0700 (PDT) Received: by qyk34 with SMTP id 34so3473473qyk.10 for ; Mon, 31 Oct 2011 03:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IonBYjc8ifVIlSvgzZQsRCQAPew5Jqoak/xWsXari2Y=; b=U2tW8LfTQeKP0NLxGy7uWlL3YEAQ3aHTB+iwZqQ4E1BPbywdPbZ4zv63FBPuT9H/+s UFChrloY03aoxS7YGI0LzIKw25O8hEniSoaKT3vrl+kCfH4dIdpIDKY3nyBclyNQBZYO jK2OcgtR9JbNhWIb3+VpyRgOAJNB8hwirDn80= MIME-Version: 1.0 Received: by 10.182.227.7 with SMTP id rw7mr2728938obc.70.1320058099447; Mon, 31 Oct 2011 03:48:19 -0700 (PDT) Sender: jefsey@gmail.com Received: by 10.182.116.9 with HTTP; Mon, 31 Oct 2011 03:48:19 -0700 (PDT) In-Reply-To: <4EAE4B27.80902@it.aoyama.ac.jp> References: <4E9DBD27.8050600@stpeter.im> <20111018181159.GG13166@shinkuro.com> <4E9DC243.4040803@stpeter.im> <11733D0D-0C58-4415-BE7B-40EC025E0B49@frobbit.se> <4EAB13D5.7070705@stpeter.im> <4EAE4B27.80902@it.aoyama.ac.jp> Date: Mon, 31 Oct 2011 11:48:19 +0100 X-Google-Sender-Auth: 2xKgmrr3iiBNA8iadQ8sCmU6geg Message-ID: From: JFC Morfin To: =?ISO-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: precis@ietf.org, Peter Saint-Andre , iucg@ietf.org Subject: Re: [iucg] [precis] passwords as octet strings X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 10:48:21 -0000 This is why I would prefer an open list of criteria rather than a few classes gathering rigidly a few of them. Special needs would be more easily addressed. jfc 2011/10/31, "Martin J. D=FCrst" : > On 2011/10/29 5:43, Peter Saint-Andre wrote: >> On 10/18/11 1:20 PM, Patrik F=E4ltstr=F6m wrote: >>> >>> On 18 okt 2011, at 20:15, Peter Saint-Andre wrote: >>> >>>>>> However, we might want to provide some text in the security >>>>>> considerations about the desirability (or not) of full-Unicode >>>>>> passwords. > > For the record, there are other issues which make using full Unicode > passwords a problem. They mainly stem from the fact that you can't see a > password when you type it. This for example makes it very difficult to > e.g. use passwords with Han characters, because they are usually input > by using a phonetic method and then verifying/tweaking the converted resu= lt. > > [I don't think there's a need for this fact to go into the document.] > > Regards, Martin. > > >>>>> I'm slow, but what's the security consideration? There are >>>>> interoperability considerations: if two applications want to >>>>> co-operate in authentication, then they're going to need to use >>>>> Unicode or make up their own protocol. >>>> >>>> Right, it's text about interoperability. Where exactly that belongs is >>>> another matter. I'm happy to add a section about interoperability. >>> >>> Please separate the question on what charset (including encoding) is us= ed >>> in the protocol with how comparisons (etc) is done. What is the >>> responsibility on the "client" and "server", etc. >> >> Here is proposed text. >> >> ### >> >> Although strings that are consumed in PRECIS-based application >> protocols are often encoded using UTF-8 [RFC3629], the exact encodin= g >> is a matter for the using protocol, not the PRECIS framework. >> >> It is known that some existing systems are unable to support the ful= l >> Unicode character set, or even any characters outside the US-ASCII >> range. If two (or more) applications need to interoperate when >> exchanging data (e.g., for the purpose of authenticating a username >> or password), they will naturally need have in common at least one >> coded character set (as defined by [RFC6365]). Establishing such a >> baseline is a matter for the using protocol, not the PRECIS >> framework. >> >> ### >> >> _______________________________________________ >> precis mailing list >> precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis >