From jefsey@jefsey.com Sun Aug 2 15:13:04 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3D13A6C68 for ; Sun, 2 Aug 2009 15:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NN9V9xmsvDAq for ; Sun, 2 Aug 2009 15:13:03 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 783013A6C61 for ; Sun, 2 Aug 2009 15:13:03 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:2309 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MXjIc-0002oB-FS for iucg@ietf.org; Sun, 02 Aug 2009 15:13:04 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Aug 2009 00:12:54 +0200 To: iucg@ietf.org From: jefsey 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: Message-Id: <20090802221303.783013A6C61@core3.amsl.com> Subject: [iucg] Countdown to WG Last Call - IDNABIS X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 22:13:04 -0000 FYI ----- The editors of all documents are working on final revisions. These are to be released to the WG for WG last call on August 10. If you have substantive issues or editorial recommendations, please get the to the WG mailing list as soon as possible. vint From eblanconil@gmail.com Sat Aug 8 02:58:23 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4F5928C14C for ; Sat, 8 Aug 2009 02:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SejkjV2+uFGg for ; Sat, 8 Aug 2009 02:58:22 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 2B06D3A6A0D for ; Sat, 8 Aug 2009 02:58:22 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so468230fgg.18 for ; Sat, 08 Aug 2009 02:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=C39CTY0h14cZTcIhRDOp+iPGOgrkF0JAVT9kNFCHKto=; b=WAwpUsrr4gQiF2LIq9KNndpniqjwqoT6dEuKwhXjE9I4p74Zik4uWeJyx3NY2QcHWj hESch7bpDLwxAbQ7kbc9Dl8N0+tWAwTteDUxX1t9VkZ4FeiP+u/67zxCSAj/lvgp1aVn joxFJqoGW5OKMZXBIX/AolZAcwdxP3X38p2hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qjBPmUB8bfM7kAfmrlmKALIPPWAThucEhT8xQeNAb3fE5dOYfU1+c+hGOW1A2ZvVB2 xFKBctaeNPeW8ITIUEU9rgRXnPD0iRJfRFvn7a5AoCOKlVJ/MVZWZ5bheZ85AiMxInAC 8Qq/KuyN+okqX5QSrvPYD1ko+/59PQULNWp9M= MIME-Version: 1.0 Received: by 10.86.87.1 with SMTP id k1mr1684944fgb.74.1249725503058; Sat, 08 Aug 2009 02:58:23 -0700 (PDT) In-Reply-To: <855C6732-5A8A-4926-8BB1-57C5D9E2CF73@shinkuro.com> References: <200908071935.n77JZ7Y12332@birdie.sybase.com> <6589127a0908071313nc8ad6b2r32467dc24cb727b7@mail.gmail.com> <4BA18D8A23980CC54AD56C1D@PST.JCK.COM> <6589127a0908071438l18bb66b4h94d1aebe575c1122@mail.gmail.com> <855C6732-5A8A-4926-8BB1-57C5D9E2CF73@shinkuro.com> Date: Sat, 8 Aug 2009 11:58:22 +0200 Message-ID: <6589127a0908080258m767de91cme5470174c47050ba@mail.gmail.com> From: Elisabeth Blanconil To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "idna-update@alvestrand.no" , John C Klensin , internet users contributing group Subject: Re: [iucg] Katakana Middle Dot again (Was: tables-06b.txt: A.5, A.6, A.9) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 08 Aug 2009 09:58:23 -0000 Dear Andrew, I was refering to John's Draft I quoted further on. The difficulty with the DNS terminology is that "DNS" is taken for many different things: namespace, system, protocol, nameservers, business, etc. in which IDNA does not initially belong. IDNA does not know dnames and cnames, it only knows IDNs. This lack of a properly termed architectural model is most probably the main difficulty we meet. This is something Jefsey's Interplus Draft partly addresses. Only partly, however, and we currently discuss how to clarify it. This is because we did not realise that in the geek's mind the Internet was so much network centric, while it is not, and the use we consider is people centric. IDNA is a _client_ of the DNS which in turn depends on the decisions of zone managers. We only are interested in IDNA, not in DNS. Now, I am not sure - but I am not a logician - that dname/cname properties cannot be transitive; and what would be the UTF-8/punycode implications (let assume that a TLD accepts UTF-8) and the corresponding DNAME does not (I am not sure this case was discussed yet?). Elisabeth Blanconil 2009/8/8 Andrew Sullivan : > I don't have time to reply properly right now, let alone from a decent MU= A, > so apologies in advance. John is quite right: there is _in principle_ no = way > to know what "domain" a given label is "in", because at least of cname an= d > dname. Sorry, but the DNS just does not work as you seem to assume. > > Andrew Sullivan > ajs@shinkuro.com > > On 2009-08-07, at 17:38, Elisabeth Blanconil wrote= : > >> Dear John, >> I do not understand some of your remarks. >> >> 2009/8/7 John C Klensin : >>> >>> >>> --On Friday, August 07, 2009 22:13 +0200 Elisabeth Blanconil >>> Except that a "TLD table inheritance system" is impossible in a >>> DNS in which it is not, in the general case, possible to tell >>> which TLD a label is actually part of and in which a given node >>> can be effectively a subtree of multiple trees. >> >> I am afraid "impossible" only means that some R&D is to be carried. >> Hence my allusion to RFC 3869. >> >>>> Was it not at a time a proposition by John Klensin? >>> >>> Nope. >> >> I refered to >> http://ietfreport.isoc.org/all-ids/draft-klensin-idn-tld-00.txt >> >> Sorry, if I did not understand the underlying idea. If there are >> tables to translate TLDs, it means that TLDs are identified. >> >>>> Ooops! This would have been a problem for "internationalized" >>>> money making gTLDs ICANN wants to sell. >>> >>> No, actually, some of the "Rich people" who want those domains >>> would undoubtedly like the freedom to do whatever they like >>> even to use character coding systems other than Unicode. =A0So you >>> need a different conspiracy theory and/or source of innuendo. >> >> I am afraid you misuderstand the commercial point here. Coca-Cola does >> not want to fool around with ".coke". They want something stable and >> unique. TM protection is not in freedom, but in enforced rules. The >> same for .com. >> >> Freedom is great for IDN TLDs, not for global TLDs. >> >>> 3869 doesn't discuss "development priority". =A0It discusses >>> relatively long-term research priorities. >> >> It intends to suggest that a broad range =A0of ongoing research is >> needed, and to propose some candidate topics. IDNA is not one however >> new namespaces are considered. >> >>> =A0If you would like to >>> put IDNs into that category and accept the five or ten year wait >>> it would imply, I'm sure I can find people who would be >>> sympathetic to that idea. =A0But I'm not one of them and I suspect >>> that few participants in the WG are either. >> >> IDNs were introduced on the Internet in 1998. >> >>>> IMHO the >>>> real issue is to make sure in the final wording that Class, >>>> TLD, presentation, or Zone related character restrictions or >>>> exceptions can be documented without contradicting the >>>> proposed text - in order to avoid unnecessary conflicts. >>> >>> I wish I had a better idea what you are talking about and >>> whether it was relevant to the WG. >> >> I only mean that zone managers will have to deal with the final texts. >> And that we have to make sure no one can use these texts to insert >> hidden MUSTs, for example in the way to implement them or to contract >> their use. >> >> Best. >> >> Elisabeth Blanconil >> _______________________________________________ >> Idna-update mailing list >> Idna-update@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/idna-update > From jefsey@jefsey.com Sat Aug 8 11:40:40 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661BF3A67F6 for ; Sat, 8 Aug 2009 11:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtJBExSg3xOT for ; Sat, 8 Aug 2009 11:40:38 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 48B263A67E6 for ; Sat, 8 Aug 2009 11:40:38 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:3066 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MZqqC-0005d7-ET; Sat, 08 Aug 2009 11:40:29 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 08 Aug 2009 20:40:24 +0200 To: John C Klensin , Elisabeth Blanconil , Lisa Dusseault , Andrew Sullivan ,"Vint Cerf" From: jefsey In-Reply-To: <239062B2AC066BAFDA7F68A2@PST.JCK.COM> References: <200908071935.n77JZ7Y12332@birdie.sybase.com> <6589127a0908071313nc8ad6b2r32467dc24cb727b7@mail.gmail.com> <4BA18D8A23980CC54AD56C1D@PST.JCK.COM> <6589127a0908071438l18bb66b4h94d1aebe575c1122@mail.gmail.com> <239062B2AC066BAFDA7F68A2@PST.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit 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: Message-Id: <20090808184038.48B263A67E6@core3.amsl.com> Cc: iucg@ietf.org Subject: [iucg] Elisabeth's remarks X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 08 Aug 2009 18:40:40 -0000 John, Elisabeth is probably influenced by my often repeated regret that the WG-OPES wasted its time with SMTP instead of working on DNS as I proposed, after HTTP. SMTP was a far too complex a model, while DNS was a real need. Many of the problems we meet result from a misunderstanding of the nature of (the network) "time". Time can be a date or a succession indicator. Date is transitive. Succession is not. We consider the resolution time as a date, instead of considering it as a succession process, so we get our own Heisinberg limitations. Such as not being able to identify the TLD. Now, let consider runing a nameserver with an OPES acting as a ONES shim (open networked extended service/overlay network executive system). If that shim had not been implemented the TLD received by the nameserver is the one the user has entered or the one the nameserver has DNAMEd. If it has been implemented the TLD received by the nameserver is the "DNAMEd" TLD, with possible meta-data that the ONES may deliver (the first of them is the TLD actually requested by the user). That ONES can cover the entire network and act as a pre-DNS unique front-end converting HANS ".com" in ASCII ".com", i.e. supporting your proposition. BTW this is orthogonal to IDNA. This means that IDNA users may or may not use it. IMHO this is a possible answer to the mess the Interplus is going to permit and the lack of possiblility to enforce IDNA. It means that nameservers operators may subscribe to such a ONES as part of their Interplus MDRS (Multilingual Distributed Reference System/Meta-Data Registry Structure) choice, and filter/pre-process/security-check the requests. There will be no change in their installation but they will be able to resolve Class x ibm.com requests as Class IN class-x.ibm.com. A way to protect famous TMs even in alt-roots. What I regret is that we will have to consider this quickly as a patch while it is a long standing unused Internet technology feature. Just remember that the basic difference between the Internet and the Interplus amphitem (encapsulating system) is that the Internet supports passive content, and the Interplus adds "post-wire" support of the active content. The Interplus is a client network and the internet is a server network. So the (meta)data received by the Internet from the Interplus are not necessarily those of the "off-wire" User Client or Interface. JFC At 14:07 08/08/2009, John C Klensin wrote: >Content-Transfer-Encoding: base64Content-Disposition: inline > >--On Friday, August 07, 2009 23:38 +0200 Elisabeth Blanconil > wrote: > > > Dear John, >Hnot understand some of your remarks. > > > > 2009/8/7 John C Klensin : > >g&F'VwW0t 07, 2009 22:13 +0200 Elisabeth Blanconil > >^\] a "TLD table inheritance system" is impossible in > >> a DNS in which it is not, in the general case, possible to > > tell which TLD a label is actually part of and in which a > >> given node can be effectively a subtree of multiple trees. >'g&B&76&"'V2FB6e R&D is to be > > carried. Hence my allusion to RFC 3869. > >No. "Impossible" in this case means that, especially with >DNAMEs, doing resolution or matching with different rules based >on location in the tree is not possible without _very_ >significant changes to the DNS, changes so significant that the >result would essentially be a new, replacement, DNS. It is not >about minor tuning to IDNs or the equivalent. > > >\]]H[YHH][ۈHhn Klensin? > >> Nope. > > > > I refered to > > http://ietfreport.isoc.org/all-ids/draft-klensin-idn-tld-00.txt > >Ah. That proposal. That proposal has nothing to do with this >discussion and is related to TLDs only. It would not work lower >in the tree, even at the second level, and works for TLDs only >if IDN TLDs for countries (or country-like economics or other >entities) are prohibited entirely and, probably, that the number >of new TLDs of any type is significantly limited. ICANN has >decided to go in the opposite direction. I don't consider that >set of ICANN decisions wise, but, to paraphrase and update an >old American saying, my opinion and a few dollars will buy a cup >of coffee-flavored milk. > >The summary of that proposal would be: > > (i) No IDN ccTLDs at all and probably no IDN TLDs. > > (ii) Each localized application (browser or otherwise) > has its own table of TLDs of interest and local names, > in the local language, and performs translations as > needed. Those translations are a function of the > localized software and do not occur in (or anywhere > near) the DNS. > > The net effect of the above is that, as far as the > localized user is concerned, all relevant TLDs exist in > the local language. That user doesn't really care what > some other country is called in that country's language, > only about what it is called locally. For example, for > one of your users, it would be much more useful to be > able to refer to the TLD for the country to your east as > "Allemagne" than to be concerned about what either its > residents call it or about what I (or someone else) > might call it. > > (iii) People traveling outside their preferred localized > environment either need to know and use the global form > or to have a way to carry their localizations with them. > >The third comment above of course has very general >applicability. As soon as we start to do _any_ localizations, >those localizations have to be portable or users who move >outside the locality (geographically or from a >software-selection standpoint) are going to also need to know >the global forms (inconvenient and unnatural as they may be). >Much of the argument about mapping has been this issue in >disguise: if one forces everyone into a single global format and >terminology, one gets better global interoperability; if one >permits (or encourages) localization to make things easier for >casual users, then one has to be careful --and tolerate extra >measures-- in order to avoid losing global interoperability. > >This model has no consequences at all for domains below the top >level. At that level, if the domain administrator wants to make >things easier for a speaker of a given language, she can create >alternate entries, aliases, etc., for those speakers without >either having to make the root huge or engaging in international >politics. > >ܜKYHY[\tand the underlying idea. If there >\HX\Ș[ate TLDs, it means that TLDs are > > identified. > >That model requires a list of TLDs of interest (possibly a >different list for each localized application-instance). That >list is not part of IDNA or the DNS. And, in particular, it >doesn't have anything to do with how names further down in the >tree are interpreted. > > >H\[ave been a problem for "internationalized" > >[ۙ^HXZ@ng gTLDs ICANN wants to sell. > >> > >XX[KYHf the "Rich people" who want those domains > >[[@btedly like the freedom to do whatever they like > >][to use character coding systems other than Unicode. So > >> you need a different conspiracy theory and/or source of >[Y[H[HYZY[HZ\Y\[H[@ercial point here. > > Coca-Cola does not want to fool around with ".coke". They want > > something stable and unique. TM protection is not in freedom, > > but in enforced rules. The same for .com. > >We may need to agree to disagree but, while I believe that what >you are saying is quite sensible and that stability, uniqueness, >and decent rules are the key to predictable and usable behavior >(and, incidentally, the ability to localize), that is _not_ the >direction in which the marketplace is headed. > >And the peculiarity of the "should control pass from ICANN >and/or the US Govt to someone else" debate, whether carried out >in the US Congress, in IGF, or elsewhere, is that it isn't about >stability and uniqueness versus a domain names market that >concentrates on a rather different set of issues, but about who >should control, manage, and maybe profit from that market. > > > Freedom is great for IDN TLDs, not for global TLDs. > >The nature of the DNS is that any TLD is inherently global. The >focus of their registrations may differ as a matter of policy, >but accessibility --and consistency of the rules with which they >are accessed and names are interpreted-- are very much global >whether we like it or not. If we don't like it, the only >options are to layer localizations on top of the DNS (and now on >top of IDNA) without changing the DNS or IDNA --and that is >exactly what the proposal to which you refer was about-- or to >junk the DNS and start over. > > >... >0Y[H[Ze to >]Q[]]YܞH[X\H]Hr ten year >Z]][[\KIH\HH[[@ople who would be > >> sympathetic to that idea. But I'm not one of them and I > >\X]]\X\[[ the WG are either. >"D2vW&RG&GV6VBFRFPrnet in 1998. > >Sigh. Even earlier than that, actually. But, if you think >that is relevant, it is yet another reason why they are not a >research topic. > > >... >H\I had a better idea what you are talking about and > >> whether it was relevant to the WG. >''VFBe managers will have to deal with the >[[^ˈ[that we have to make sure no one can use >\H^ insert hidden MUSTs, for example in the way to > > implement them or to contract their use. > >And so[H[@nge what about what we are doingIB[ۘ\YXut >"make sure" because, ultimately, we have no >enforcement mechanism other than the consequences of misbehavior >causing loss of interoperability. > >regards, > john > >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update From ajs@shinkuro.com Sat Aug 8 19:11:11 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080163A6A98 for ; Sat, 8 Aug 2009 19:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Fh7SgG4oT4Z for ; Sat, 8 Aug 2009 19:11:09 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 1667C3A6A41 for ; Sat, 8 Aug 2009 19:11:08 -0700 (PDT) Received: from [192.168.1.3] (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 34C842FE9634; Sun, 9 Aug 2009 02:11:11 +0000 (UTC) From: Andrew Sullivan To: jefsey In-Reply-To: X-Mailer: iPhone Mail (7A341) References: <200908071935.n77JZ7Y12332@birdie.sybase.com> <6589127a0908071313nc8ad6b2r32467dc24cb727b7@mail.gmail.com> <4BA18D8A23980CC54AD56C1D@PST.JCK.COM> <6589127a0908071438l18bb66b4h94d1aebe575c1122@mail.gmail.com> <239062B2AC066BAFDA7F68A2@PST.JCK.COM> Message-Id: <55518499-F861-4F7A-8D64-4A95FEF1A315@shinkuro.com> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPhone Mail 7A341) Date: Sat, 8 Aug 2009 22:11:00 -0400 Cc: Vint Cerf , John C Klensin , Lisa Dusseault , "iucg@ietf.org" Subject: Re: [iucg] Elisabeth's remarks X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 02:11:11 -0000 Yet again we are in deep confusion caused by sloppy terminology. The =20 problem is not just a TLD that resolves to a dname. AIUI, the idea here is that policies in the TLD recurse down the tree =20= to subordinate zones. But this is what A cname or dname foils. For it =20= is easy to make a cname from www.example.org to = interstupendousplus.exemple.fr=20 . Now whose policies apply? Org's or fr's? I can make a strong =20 argument for either one, depending on which you pick. And none of this =20= even begins to scratch the surface of what "applying" means here. The DNS just isn't subject to central planning the way you seem to =20 think it is. Once the namespace is delegated, the delegator loses =20 control, period. Andrew Sullivan ajs@shinkuro.com On 2009-08-08, at 14:40, jefsey wrote: > John, > Elisabeth is probably influenced by my often repeated regret that =20 > the WG-OPES wasted its time with SMTP instead of working on DNS as I =20= > proposed, after HTTP. SMTP was a far too complex a model, while DNS =20= > was a real need. Many of the problems we meet result from a =20 > misunderstanding of the nature of (the network) "time". Time can be =20= > a date or a succession indicator. Date is transitive. Succession is =20= > not. We consider the resolution time as a date, instead of =20 > considering it as a succession process, so we get our own Heisinberg =20= > limitations. Such as not being able to identify the TLD. > > Now, let consider runing a nameserver with an OPES acting as a ONES =20= > shim (open networked extended service/overlay network executive =20 > system). If that shim had not been implemented the TLD received by =20 > the nameserver is the one the user has entered or the one the =20 > nameserver has DNAMEd. If it has been implemented the TLD received =20 > by the nameserver is the "DNAMEd" TLD, with possible meta-data that =20= > the ONES may deliver (the first of them is the TLD actually =20 > requested by the user). That ONES can cover the entire network and =20 > act as a pre-DNS unique front-end converting HANS ".com" in ASCII =20 > ".com", i.e. supporting your proposition. BTW this is orthogonal to =20= > IDNA. This means that IDNA users may or may not use it. > > IMHO this is a possible answer to the mess the Interplus is going to =20= > permit and the lack of possiblility to enforce IDNA. It means that =20 > nameservers operators may subscribe to such a ONES as part of their =20= > Interplus MDRS (Multilingual Distributed Reference System/Meta-Data =20= > Registry Structure) choice, and filter/pre-process/security-check =20 > the requests. There will be no change in their installation but they =20= > will be able to resolve Class x ibm.com requests as Class IN = class-x.ibm.com=20 > . A way to protect famous TMs even in alt-roots. > > What I regret is that we will have to consider this quickly as a =20 > patch while it is a long standing unused Internet technology =20 > feature. Just remember that the basic difference between the =20 > Internet and the Interplus amphitem (encapsulating system) is that =20 > the Internet supports passive content, and the Interplus adds "post-=20= > wire" support of the active content. The Interplus is a client =20 > network and the internet is a server network. So the (meta)data =20 > received by the Internet from the Interplus are not necessarily =20 > those of the "off-wire" User Client or Interface. > > JFC > > > At 14:07 08/08/2009, John C Klensin wrote: >> Content-Transfer-Encoding: base64Content-Disposition: inline >> >> --On Friday, August 07, 2009 23:38 +0200 Elisabeth Blanconil >> wrote: >> >> > Dear John, >> H=C2=BBnot understand some of your remarks. >> > >> > 2009/8/7 John C Klensin : >> >=C3=89=E2=80=9A=C2=A3=E2=80=9E=E2=80=9A=E2=80=9C=E2=80=98=CB=86=E2=80=9A= g&=E2=89=A0F'=C2=ACVwW0t 07, 2009 22:13 +0200 =20 >> Elisabeth Blanconil >> >^=C5=B8\] a "TLD table inheritance system" is impossible in >> >> a DNS in which it is not, in the general case, possible to >> > tell which TLD a label is actually part of and in which a >> >> given node can be effectively a subtree of multiple trees. >> =C3=87'=E2=80=9Cg&=E2=89=A0B&=E2=89=A0=E2=97=8A=CB=9C76=E2=89=A0&=C3=89= "=CB=86=C3=8A=C2=AB'=C3=B7V=C3=812F=C3=9CB6=CB=86=E2=80=93e R&D is to be >> > carried. Hence my allusion to RFC 3869. >> >> No. "Impossible" in this case means that, especially with >> DNAMEs, doing resolution or matching with different rules based >> on location in the tree is not possible without _very_ >> significant changes to the DNS, changes so significant that the >> result would essentially be a new, replacement, DNS. It is not >> about minor tuning to IDNs or the equivalent. >> >> >=C3=A0=C3=BF\=C2=BB]=C3=B5=E2=80=BA]H[YHH=C3=B5=E2=80=B9=E2=80=B9=E2=81= =84][=E2=82=AC=C3=A0=C3=BBH=C3=B5=C2=BFhn Klensin? >> >> Nope. >> > >> > I refered to >> > http://ietfreport.isoc.org/all-ids/draft-klensin-idn-tld-00.txt >> >> Ah. That proposal. That proposal has nothing to do with this >> discussion and is related to TLDs only. It would not work lower >> in the tree, even at the second level, and works for TLDs only >> if IDN TLDs for countries (or country-like economics or other >> entities) are prohibited entirely and, probably, that the number >> of new TLDs of any type is significantly limited. ICANN has >> decided to go in the opposite direction. I don't consider that >> set of ICANN decisions wise, but, to paraphrase and update an >> old American saying, my opinion and a few dollars will buy a cup >> of coffee-flavored milk. >> >> The summary of that proposal would be: >> >> (i) No IDN ccTLDs at all and probably no IDN TLDs. >> >> (ii) Each localized application (browser or otherwise) >> has its own table of TLDs of interest and local names, >> in the local language, and performs translations as >> needed. Those translations are a function of the >> localized software and do not occur in (or anywhere >> near) the DNS. >> >> The net effect of the above is that, as far as the >> localized user is concerned, all relevant TLDs exist in >> the local language. That user doesn't really care what >> some other country is called in that country's language, >> only about what it is called locally. For example, for >> one of your users, it would be much more useful to be >> able to refer to the TLD for the country to your east as >> "Allemagne" than to be concerned about what either its >> residents call it or about what I (or someone else) >> might call it. >> >> (iii) People traveling outside their preferred localized >> environment either need to know and use the global form >> or to have a way to carry their localizations with them. >> >> The third comment above of course has very general >> applicability. As soon as we start to do _any_ localizations, >> those localizations have to be portable or users who move >> outside the locality (geographically or from a >> software-selection standpoint) are going to also need to know >> the global forms (inconvenient and unnatural as they may be). >> Much of the argument about mapping has been this issue in >> disguise: if one forces everyone into a single global format and >> terminology, one gets better global interoperability; if one >> permits (or encourages) localization to make things easier for >> casual users, then one has to be careful --and tolerate extra >> measures-- in order to avoid losing global interoperability. >> >> This model has no consequences at all for domains below the top >> level. At that level, if the domain administrator wants to make >> things easier for a speaker of a given language, she can create >> alternate entries, aliases, etc., for those speakers without >> either having to make the root huge or engaging in international >> politics. >> >> =E2=82=AC=E2=80=B9=C3=BA=C3=BBKY=C3=A0HY=C3=B5=E2=80=BA[=C3=B4\=C3=BA=C2= =BFtand the underlying idea. If there >> \=C3=B4HX=C3=B5\=C2=BB=C2=BB=C3=B2[=C3=BA=E2=82=ACate TLDs, it means = that TLDs are >> > identified. >> >> That model requires a list of TLDs of interest (possibly a >> different list for each localized application-instance). That >> list is not part of IDNA or the DNS. And, in particular, it >> doesn't have anything to do with how names further down in the >> tree are interpreted. >> >> >=C3=A0=E2=82=AC=E2=82=AC=E2=80=B9=C2=BBH\=C2=BB=E2=82=AC=E2=80=BA[ave = been a problem for "internationalized" >> >=C3=A0[=E2=82=AC=C3=B4^HXZ=E2=81=84@ng gTLDs ICANN wants to sell. >> >> >> >=C3=B5=C3=80X=E2=80=BAX[K=E2=82=AC=E2=82=ACYH=C2=BFf the "Rich = people" who want those domains >> >=E2=82=AC=E2=80=BA[[=C3=B4=E2=80=BA@btedly like the freedom to do = whatever they like >> >]=C3=B4[=C3=A0to use character coding systems other than Unicode. = So >> >> you need a different conspiracy theory and/or source of >> =C3=A0[=C3=B5=C3=B9Y[=C3=B4=C3=A3=C3=A8=C3=A0=C3=A8=C3=A0H[HY=C3=BA=C3=B2= ZY[=E2=80=BAHZ\=E2=80=BAY\=C3=BA=E2=80=BA[=C3=B4H=E2=82=AC=E2=82=AC[@ercia= l =20 >> point here. >> > Coca-Cola does not want to fool around with ".coke". They want >> > something stable and unique. TM protection is not in freedom, >> > but in enforced rules. The same for .com. >> >> We may need to agree to disagree but, while I believe that what >> you are saying is quite sensible and that stability, uniqueness, >> and decent rules are the key to predictable and usable behavior >> (and, incidentally, the ability to localize), that is _not_ the >> direction in which the marketplace is headed. >> >> And the peculiarity of the "should control pass from ICANN >> and/or the US Govt to someone else" debate, whether carried out >> in the US Congress, in IGF, or elsewhere, is that it isn't about >> stability and uniqueness versus a domain names market that >> concentrates on a rather different set of issues, but about who >> should control, manage, and maybe profit from that market. >> >> > Freedom is great for IDN TLDs, not for global TLDs. >> >> The nature of the DNS is that any TLD is inherently global. The >> focus of their registrations may differ as a matter of policy, >> but accessibility --and consistency of the rules with which they >> are accessed and names are interpreted-- are very much global >> whether we like it or not. If we don't like it, the only >> options are to layer localizations on top of the DNS (and now on >> top of IDNA) without changing the DNS or IDNA --and that is >> exactly what the proposal to which you refer was about-- or to >> junk the DNS and start over. >> >> >... >> =C3=A00=C2=AEY=C3=A0[=E2=80=BAH=E2=82=AC=E2=80=BA[Z=C2=BFe to >> =C3=A0]Q=C3=BA=C2=BB[=C3=B9=C2=BB]=C3=BF]Y=E2=82=AC=E2=80=B9=C3=BBH[=C3= =B4X=C3=BF=C5=B8\H=C3=B6]=C3=B4H=C2=BFr ten year >> =C3=A0=C3=BFZ]]=E2=82=AC=E2=80=BA[[\KI=E2=82=ACH=E2=80=BA\=C3=B4HH=C3=BF= [=C3=A0=C3=B6[=C3=B4@ople who would be >> >> sympathetic to that idea. But I'm not one of them and I >> >=E2=80=BA\=E2=80=B9X=E2=80=BA]=C3=B4]=C2=BB\=C3=B9X=E2=81=84\[=C3=B9=C2= =BB[=C3=84 the WG are either. >> =C3=87"D=C3=812vW&R=E2=89=A0=C3=81G&=CB=86GV6VB=CB=86=E2=80=9AF=C3=9CR=E2= =89=A0=C3=81FPrnet in 1998. >> >> Sigh. Even earlier than that, actually. But, if you think >> that is relevant, it is yet another reason why they are not a >> research topic. >> >> >... >> =C3=A0H=E2=81=84\=E2=81=84I had a better idea what you are talking = about and >> >> whether it was relevant to the WG. >> =C3=87'=CB=86=C3=8A=C2=AB'=C3=B7V=E2=80=9AF=C3=9CB=C2=B6=CB=86=E2=80=A1= e managers will have to deal with the >> =C3=B6[=C3=B2[^=C3=80=C3=A0[=C3=B4that we have to make sure no one = can use >> \=C5=B8H^=C2=BB=C2=BF insert hidden MUSTs, for example in the way to >> > implement them or to contract their use. >> >> And so[=E2=80=BAH=E2=82=AC=E2=80=BA[=E2=81=84@nge what about what we = are doingI=E2=82=ACB=C3=B2=20 >> [=E2=82=AC=C2=BB=E2=82=AC=E2=82=AC=C3=B2=C5=B8\=C3=B5=C3=B4YX=C3=B5=C2=BF= ut "make sure" because, ultimately, we =20 >> have no >> enforcement mechanism other than the consequences of misbehavior >> causing loss of interoperability. >> >> regards, >> john >> >> _______________________________________________ >> Idna-update mailing list >> Idna-update@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/idna-update > From jefsey@jefsey.com Sun Aug 9 11:56:11 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5486F3A6B6C for ; Sun, 9 Aug 2009 11:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlWlu6Pv2pI6 for ; Sun, 9 Aug 2009 11:56:10 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 6AA233A6B70 for ; Sun, 9 Aug 2009 11:56:10 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:2537 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MaDYm-0004jw-Vz; Sun, 09 Aug 2009 11:56:01 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 09 Aug 2009 20:33:44 +0200 To: Andrew Sullivan From: JFC Morfin In-Reply-To: <55518499-F861-4F7A-8D64-4A95FEF1A315@shinkuro.com> References: <200908071935.n77JZ7Y12332@birdie.sybase.com> <6589127a0908071313nc8ad6b2r32467dc24cb727b7@mail.gmail.com> <4BA18D8A23980CC54AD56C1D@PST.JCK.COM> <6589127a0908071438l18bb66b4h94d1aebe575c1122@mail.gmail.com> <239062B2AC066BAFDA7F68A2@PST.JCK.COM> <55518499-F861-4F7A-8D64-4A95FEF1A315@shinkuro.com> 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: Message-Id: <20090809185610.6AA233A6B70@core3.amsl.com> Cc: Vint Cerf , John C Klensin , Lisa Dusseault , "iucg@ietf.org" Subject: Re: [iucg] Elisabeth's remarks X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 18:56:11 -0000 At 04:11 09/08/2009, Andrew Sullivan wrote: >Yet again we are in deep confusion caused by sloppy terminology. The >problem is not just a TLD that resolves to a dname. > >AIUI, the idea here is that policies in the TLD recurse down the tree >to subordinate zones. But this is what A cname or dname foils. For it >is easy to make a cname from www.example.org to >interstupendousplus.exemple.fr . Now whose policies apply? Org's or >fr's? I can make a strong argument for either one, depending on >which you pick. And none of this even begins to scratch the surface >of what "applying" means here. > >The DNS just isn't subject to central planning the way you seem to >think it is. Once the namespace is delegated, the delegator loses >control, period. Correct for the "DNS" taken as the currently implemented software system. And we do not want to change that software system. Correct for the "DNS" taken as the currently understood naming system. The resulting distributed responsibility is the key point in favor of DDDS in distributed technologies/environments. However in the "DNS.1" process that you describe there is an entropy loss that network services can overcome (they can even become a feature of the DNS.2 ?) In the case you quote: - either the DNS is used without any additional edge service and at each change the then current rules should transitively apply as it seems to result from general DDDS architecture? - or the DNS is used with edge services that may deny, correct, document, or/and propagate the change and act upon that information. In either cases, there is only a problem if the user is not informed of the functional rules being in use; if the naming topology cannot be properly configurated; or if that configuration is not analyzed enough. This certainly is an area to investigate. The urgent problems we really face, as I see them, are: 1) that the architecture was initially a decentralized master/slave architecture, then a decentralized client/server, and now has to be a "people in multilingual distributed society driven server network/client network/user client" architecture. I do not think we can make it if we do not uncouple the issues and keep each element at the single task it does well. This is why there should be no change (what permits easier replacement, enhancements and transitions) in the existing building blocks, but implement additional building blocks that will organize new synergies and not to expect that miraculously or through IETF due disputation process more will "emerge" from the Internet system than there is in the sum of each of its parts. 2) the content that the Internet propagate is passive. There is now a need to support active content. This is the Interplus area. Active content, that integrate "post-wire" services, is a necessity for the Intersem strata "off-wire" intelligent relation facilitation mind to mind services (what is related to interintelligibility on top of interoperability). The practical difficulty is to introduce the Interplus in trying to protect usage from confusion. This confusion comes from the fact that the Interplus is only an open minded reading of the existing internet technology that everyone can make, and that the same technology has not built yet enough protection against its oneself. It is a bis of the security issues. It must therefore be introduced in a way which is both attractive (so people do not try something different) and which includes the protections the Internet misses, in addition to its own protections. jfc From eblanconil@gmail.com Mon Aug 10 11:20:53 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0083A6E87 for ; Mon, 10 Aug 2009 11:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAfG-OPmMLrN for ; Mon, 10 Aug 2009 11:20:52 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 2E4453A6E61 for ; Mon, 10 Aug 2009 11:20:51 -0700 (PDT) Received: by fxm26 with SMTP id 26so1185547fxm.42 for ; Mon, 10 Aug 2009 11:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ytBFzkct74rwZTrAsO8woBdeorM0pEgdy6QBn3kkKs0=; b=vgWpa14xq+/OXKrKG+dBBJ71hf7Grr5t0YVJeeKJbxXySOk/D+eHtVKL/IIjaeCNfE Xpug1QHodF7wUAtps1ED1eeZ+ATvaodaxmqV4UMynejUsppYYn69+A8nfX2QAgJE7Mco G2kB7ntfAdw+9TagU0bXqtycxflAUDX5D02B8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=W/4q4/Sm2W/tuKxFlVM/Z9Wd11sYPRvWCTH0bwNKZ9KsSTXd5edq02Tzy0X4yEdu49 vSwI4GtYovrnYp3Os5pnB6L5eXFBlBHjeMTLVPLJdTkEREFaYot5dPu01ei8aHOjnRkS tKwB6Fu8UdTCl3xoQHMZN24MzJQA5j9YxmtLA= MIME-Version: 1.0 Received: by 10.86.1.1 with SMTP id 1mr3382133fga.42.1249928453063; Mon, 10 Aug 2009 11:20:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Aug 2009 20:20:53 +0200 Message-ID: <6589127a0908101120gdef3cban456cde42c74fca28@mail.gmail.com> From: Elisabeth Blanconil To: internet users contributing group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Vint Cerf , idna-update@alvestrand.no, lisa Dusseault Subject: Re: [iucg] WG Last Call for Four Primary IDNABIS I-Ds X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 10 Aug 2009 18:20:53 -0000 2009/8/10 Vint Cerf : > Folks, > the following documents are now officially on last call ending August 24, > 2009. Editorial comments and new issues (only) will be considered: These documents are now on http://wikidna.org with the exception of the full tables document. I have two question IRT Patrik's Draft: 1. is it on purpose that section 8 and author come before the Appendixes? I restored them in the wiki page. 2. the port of the appendix B.1. table did not work with our tool. I am therefore going to work on the list under excel first. I understand that IDNA uses the NFC table. I am not sure if the listed codepoints are only NFC or if not if NFC codepoints should not noted? I am sure our multilinguists, some ccTLDs and many users will like to access the excel version of the table. Best Elisabeth Blanconil > Definitions and Document Framework: draft-ietf-idnabis-defs-10.txt > Protocol: draft-ietf-idnabis-protocol-14.txt > The Unicode code points and IDNA: draft-ietf-idnabis-tables-06.txt > > An updated IDNA criterion for right-to-left scripts: > draft-ietf-idnabis-bidi-04 > > The other two IDNABIS documents, Rationale and Mapping, will be submitted as > soon as possible (this week I hope) for final WG call. > > vint From eblanconil@gmail.com Mon Aug 10 11:59:32 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6C2028C1D6 for ; Mon, 10 Aug 2009 11:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VAiEWh3FOGA for ; Mon, 10 Aug 2009 11:59:32 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 7468A28C1DA for ; Mon, 10 Aug 2009 11:58:58 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so473201fga.18 for ; Mon, 10 Aug 2009 11:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=B25cWLr3M3tHrAj75hij8N2ZDWdH5+v1i3u4LBtRkNE=; b=DU5GB+6KNyICI2ogQBeuHtpV5AWcij1SpYiS/6RDfNH5FaBhplxAh0obSVI4Iv7rHz 5Iz6QtjdlC7NBPVQNTltrZVvO3Im26FMC964jd2oYHWcuap+tYt30Cc/OJU7Y7l/PxaP nwv0WKqPAc3B77K7jB/MeitFPMSUm8FYV27Vg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oJUwg5zDe71cSbhafmp197cw9qk4CcTeVM0SGbNrZK+vQ1v3LzLffjgAZFOSCemW3+ XR7O8pdmz7NM1nDysMkDP/9LPzjN4YdtmtBaHxyv1w4XrXYCISv5d7cM/qBXcOBcLf+J sWJaocrxWrbQ+TC3J3+/nh349YGyKGJo5Pt3c= MIME-Version: 1.0 Received: by 10.86.31.14 with SMTP id e14mr3436083fge.79.1249930739125; Mon, 10 Aug 2009 11:58:59 -0700 (PDT) In-Reply-To: <6589127a0908101120gdef3cban456cde42c74fca28@mail.gmail.com> References: <6589127a0908101120gdef3cban456cde42c74fca28@mail.gmail.com> Date: Mon, 10 Aug 2009 20:58:59 +0200 Message-ID: <6589127a0908101158j6f4740bcrfc6351625adc8245@mail.gmail.com> From: Elisabeth Blanconil To: internet users contributing group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Vint Cerf , idna-update@alvestrand.no, lisa Dusseault Subject: Re: [iucg] WG Last Call for Four Primary IDNABIS I-Ds X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 10 Aug 2009 18:59:33 -0000 Sorry, I meant that section 8 and author came _after_ the appendixes. Elisabeth Blanconil 2009/8/10 Elisabeth Blanconil : > 1. is it on purpose that section 8 and author come before the > Appendixes? I restored them in the wiki page. From eblanconil@gmail.com Tue Aug 11 04:55:55 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1995A3A70BB for ; Tue, 11 Aug 2009 04:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSMsxoK2uZ4Q for ; Tue, 11 Aug 2009 04:55:54 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id F366F3A70C1 for ; Tue, 11 Aug 2009 04:55:53 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so584150fga.18 for ; Tue, 11 Aug 2009 04:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ot3KtiPyLMgsRXFaiG7Crk+NWj5HeYIoN96vNHB09Sk=; b=DdiI8V5BdSKk594KkwXhYSHv0iVmMxfnS4Eo0Ol4z80AbP/wv8O7jT60nvwDMe83LF MnQmX9Y1Un5/e0cz2ee5ODMhnRGNxgD940MANgpYO0iv0+m0O69GlhT6IHtFkKS4U1qO PoG7hyMWg2EJOdh5U7VY5u97iaLtDGXAsHkWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=My3wvj00Uev4DaJOkEgMkNFAzBSuz6zP59qjLMLXkj2dlhh75RmHkCggx9Ye1lIEBm gxRFpK18O2YYSZJX3eYIyucH4LI7dx/BNxFBYttBlw4JIrszf7VWyFoyJYB7m6R7N8E/ 3Cg3F0nZXZDs3FcLXltYkkuWLuDAAsop/mDUM= MIME-Version: 1.0 Received: by 10.86.66.20 with SMTP id o20mr4012862fga.15.1249990186781; Tue, 11 Aug 2009 04:29:46 -0700 (PDT) In-Reply-To: References: <30b660a20908101509j75774f59rfd3f62448a8906aa@mail.gmail.com> <30b660a20908101624u52f6a9dbv54ba1f85a2b05044@mail.gmail.com> Date: Tue, 11 Aug 2009 13:29:46 +0200 Message-ID: <6589127a0908110429y342bb4cew57b8c2de2bfbf0db@mail.gmail.com> From: Elisabeth Blanconil To: internet users contributing group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idna-update@alvestrand.no Subject: Re: [iucg] WG Last Call for Four Primary IDNABIS I-Ds X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 11:55:55 -0000 Updated I_D on mapping now in WG/LC has been added to http://wikidna.org. WG/LC ends August 24, 2009. Editorial comments and new issues (only) will be considered. As soon as the Rational I_D is published I will build a single document (with reduced tables) for printing/working convenience. Elisabeth 2009/8/11 Vint Cerf : >WG should consider these five documents to be in WG final call. > vint > > On Aug 10, 2009, at 7:45 PM, Erik van der Poel wrote: >> http://www.ietf.org/id/draft-ietf-idnabis-defs-10.txt >> http://www.ietf.org/id/draft-ietf-idnabis-protocol-14.txt >> http://www.ietf.org/id/draft-ietf-idnabis-tables-06.txt >> http://www.ietf.org/id/draft-ietf-idnabis-bidi-04.txt >> http://www.ietf.org/id/draft-ietf-idnabis-mappings-02.txt From patrik@frobbit.se Tue Aug 11 05:06:38 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2146E3A6EF3 for ; Tue, 11 Aug 2009 05:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YaCdTmrOQEG for ; Tue, 11 Aug 2009 05:06:37 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id EA0B03A68E0 for ; Tue, 11 Aug 2009 05:06:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 0657A6815F75; Tue, 11 Aug 2009 14:05:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nggTH-DLLQRr; Tue, 11 Aug 2009 14:05:38 +0200 (CEST) Received: from junior.frobbit.se (unknown [192.165.72.12]) by srv01.frobbit.se (Postfix) with ESMTP id 1F8836815F6E; Tue, 11 Aug 2009 14:05:38 +0200 (CEST) Message-Id: <4D783AB0-1C07-4744-94B5-C502BCEC6256@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Elisabeth Blanconil In-Reply-To: <6589127a0908101158j6f4740bcrfc6351625adc8245@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 Aug 2009 14:05:37 +0200 References: <6589127a0908101120gdef3cban456cde42c74fca28@mail.gmail.com> <6589127a0908101158j6f4740bcrfc6351625adc8245@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Tue, 11 Aug 2009 06:32:42 -0700 Cc: idna-update@alvestrand.no, Vint Cerf , internet users contributing group , lisa Dusseault Subject: Re: [iucg] WG Last Call for Four Primary IDNABIS I-Ds X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 12:06:38 -0000 Elisabeth, Thanks for noticing this difference in how the documents are generated from the XML that is in use in the IETF. The exact order of the sections will be decided upon (and sections will potentially be moved around) at the time of publication by the RFC Editor while doing other formatting changes. I have been in contact with the other document editors, and our suggestion to our wg chair is to *NOT* risk destroying the actual content of the messages by moving things around at the time of last call (both wg and IETF). Regards, Patrik On 10 aug 2009, at 20.58, Elisabeth Blanconil wrote: > Sorry, I meant that section 8 and author came _after_ the appendixes. > > Elisabeth Blanconil > > 2009/8/10 Elisabeth Blanconil : >> 1. is it on purpose that section 8 and author come before the >> Appendixes? I restored them in the wiki page. > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > From ebw@abenaki.wabanaki.net Tue Aug 11 05:24:39 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F4D3A6A43 for ; Tue, 11 Aug 2009 05:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi5NNyCKwSHt for ; Tue, 11 Aug 2009 05:24:38 -0700 (PDT) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by core3.amsl.com (Postfix) with ESMTP id EF4553A6FD5 for ; Tue, 11 Aug 2009 05:23:38 -0700 (PDT) Received: from limpet.local (cpe-67-241-43-7.twcny.res.rr.com [67.241.43.7]) by abenaki.wabanaki.net (8.14.3/8.14.3) with ESMTP id n7BCLaXJ063825; Tue, 11 Aug 2009 08:21:37 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4A816289.6010903@abenaki.wabanaki.net> Date: Tue, 11 Aug 2009 08:22:33 -0400 From: Eric Brunner-Williams User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= References: <6589127a0908101120gdef3cban456cde42c74fca28@mail.gmail.com> <6589127a0908101158j6f4740bcrfc6351625adc8245@mail.gmail.com> <4D783AB0-1C07-4744-94B5-C502BCEC6256@frobbit.se> In-Reply-To: <4D783AB0-1C07-4744-94B5-C502BCEC6256@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 11 Aug 2009 06:32:42 -0700 Cc: lisa Dusseault , Vint Cerf , idna-update@alvestrand.no, internet users contributing group Subject: Re: [iucg] WG Last Call for Four Primary IDNABIS I-Ds X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 12:24:39 -0000 anything that generates diff noise is strongly depricated. the editor=20 can sort out template induced artifacts. Patrik F=E4ltstr=F6m wrote: > Elisabeth, > > Thanks for noticing this difference in how the documents are generated = =20 > from the XML that is in use in the IETF. > > The exact order of the sections will be decided upon (and sections =20 > will potentially be moved around) at the time of publication by the =20 > RFC Editor while doing other formatting changes. > > I have been in contact with the other document editors, and our =20 > suggestion to our wg chair is to *NOT* risk destroying the actual =20 > content of the messages by moving things around at the time of last =20 > call (both wg and IETF). > > Regards, Patrik > > On 10 aug 2009, at 20.58, Elisabeth Blanconil wrote: > > =20 >> Sorry, I meant that section 8 and author came _after_ the appendixes. >> >> Elisabeth Blanconil >> >> 2009/8/10 Elisabeth Blanconil : >> =20 >>> 1. is it on purpose that section 8 and author come before the >>> Appendixes? I restored them in the wiki page. >>> =20 >> _______________________________________________ >> Idna-update mailing list >> Idna-update@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/idna-update >> >> =20 > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > > > =20 From eblanconil@gmail.com Fri Aug 14 19:37:31 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A813A6922 for ; Fri, 14 Aug 2009 19:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRHrnCuXH7Hi for ; Fri, 14 Aug 2009 19:37:30 -0700 (PDT) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by core3.amsl.com (Postfix) with ESMTP id 548F43A69A5 for ; Fri, 14 Aug 2009 19:37:30 -0700 (PDT) Received: by fxm22 with SMTP id 22so1636738fxm.9 for ; Fri, 14 Aug 2009 19:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zjX35ONhotfjLwER2CjZURasBSdfwgBQCpEAZOTlYiA=; b=qajvH5YglyNv9k/NISV1exsUCus2zbRb5D/tgb6EvC33ruOpI+t4vEHf/5hzmjQlpV Pxpi5KJWEMHB8izI67e84rQfc6YcE+AQDJpJYbBhIxwV99NsrE749cmBzl2JNaxLWdOG HLJ3b4zYS/0NlYTlNXBoKSQAvaWVDdQEcW30Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uKuZU9jmzVTjxkSV8BX+iu5//x6sw8iZj91sWTeKPuiLrxSZZo3gPO1TjjJ01vmvfR yRGtICtIQrFgpWjEYhRVBB902R4lUzi2ohhXe7B6YFQyXJIEHi7Z2t7ckB9gjoPful6m qJUnHh/HtXDJR4utUGIBB405i/J6IPWEYmZTM= MIME-Version: 1.0 Received: by 10.239.184.150 with SMTP id y22mr207062hbg.21.1250303848097; Fri, 14 Aug 2009 19:37:28 -0700 (PDT) In-Reply-To: References: Date: Sat, 15 Aug 2009 04:37:28 +0200 Message-ID: <6589127a0908141937i72f6803hb61a00e91f444d7c@mail.gmail.com> From: Elisabeth Blanconil To: internet users contributing group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: John C Klensin , idna-update@alvestrand.no Subject: Re: [iucg] Rationale-11 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 15 Aug 2009 02:37:31 -0000 I have ported this text on the http://wikidna.org and built a general working abstract of all the IDNA documents. Enjoy the 8/15 WE printing and reviewing the 46 pages of it! Elisabeth Blanconil 2009/8/15 John C Klensin : > Hi. > > Rationale-11 has been posted. =A0This version integrates the > former explanatory text from Mappings-01, contains a number of > rearrangements and changes in the hope of making the mapping > presentation consistent and coherent, has more description of > the registry/registrar/registrant relations per on-list > discussion with Shawn and others, and fixes a lot of glitches > that apparently crept in to recent versions. > > A more complete description appears in the Change Log but I > strongly recommend carefully reading and checking of the > document (i.e., I'm not sure that all of the changes I made are > correct). > > =A0 =A0john From jefsey@jefsey.com Sun Aug 16 14:07:01 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBE523A6933 for ; Sun, 16 Aug 2009 14:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.271 X-Spam-Level: *** X-Spam-Status: No, score=3.271 tagged_above=-999 required=5 tests=[AWL=-4.445, BAYES_80=2, FRT_EXPERIENCE=2.333, MANGLED_MEN=2.3, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ykke1He6E8qR for ; Sun, 16 Aug 2009 14:07:01 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id F0BF53A67AA for ; Sun, 16 Aug 2009 14:07:00 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:2031 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1McmwK-00061i-VQ; Sun, 16 Aug 2009 14:07:01 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 16 Aug 2009 23:06:48 +0200 To: comptoir@cafedu.com From: jefsey Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit 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: Message-Id: <20090816210700.F0BF53A67AA@core3.amsl.com> Cc: iucg@ietf.org Subject: [iucg] Mac Jefsey X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 16 Aug 2009 21:07:02 -0000 Chers CafeduCompres et chres CafeduCommres, je cherchais comment la fois expliquer et faire participer chacun au challenge qui est le notre d'un monde o tout nous converge dessus. Morin l'explique par la complexit, je prfrerais m'en tenir au principe de simplicit naturelle (de moindre action) de Maupertuis. Pour cela il faut s'expliquer beaucoup, beaucoup de choses. Il faut ensuite les mettre en ordre, les crire et les dcrire pour que les lecteurs comprennent, ce qui empche d'avoir le temps de pousser plus loin et de tenir tte la concurrence. Mais le moyen de faire autrement si l'on veut aussi et en plus se faire critiquer pour s'assurer de la cohrence de ce que l'on prtend ? La solution que je tente en ce temps de vacances se veut lgre. Elle consiste en une exprience de pense dont je vous propose de vous amuser. Ce sont les msaventures de "Mac Jefsey", ma MAC (Machine Comprendre). L'ide est d'exprimenter par la pense, mais en mettant progressivement en place le plus de contexte concret l'exprience, nec plus ultra de ce que je vise, le systme qui va se charge de me faire comprendre ma faon mon environnement Intersem (c'est dire l'Internet smiotique et des penses). L'intrt est que c'est l o nous allons que nous le voulions ou non : aprs nous tre facilit le vivre et le calculer nous avons besoin de nous faciliter le penser. Mais un facilitateur notique n'est pas une mince affaire spcifier, imaginer, tudier, comprendre, raliser et surtout protger des dsinformations et influences extrieures. Il y faut sans doute un solide djantement (brainstorming) qui mle le pertinent l'impudent et donc une approche impertinente et bien encadre techniquement dans une discipline technique inconnue. Il y faut aussi un solide environnement architectural qui sera port par les travaux de l'IUCG que je suis en train de consolider, alors que les documents IETF IDNA sont maintenant en dernier appel (Last Call) du groupe de travail (pour ceux qui voudraient revoir tout cela : Elisabeth Blanconil a tout regroup sur wikIDNA http://wikidna.org/index.php?title=IDNA_working_abstract). Vous en trouverez l'bauche sous http://macjefsey.com. Ceux que cela intresse peuvent en parler ici, ou l. L tant la liste de travail propose sur le site. Et me copier - pour amliorer l'ide et la mener selon une autre approche, une autre philosophie. Il est ncessaire qu'au final il y ait autant de machines d'aide la comprhension que d'avatars humains (c'est ainsi que l'on protgera la Libert). Il FAUT donc que les maitres mots dans l'affaire soient la diversit et l'interintelligibilit. Le cadre de ce travail de recherche est sous : http://macjfc.com/wiki/Cadre_de_la_recherche. jfc NB. Pour l'instant la recherche n'est faite qu'en franais. Il serait intressant que d'autres l'engage dans d'autres langues. Ne serait-ce que pour vrifier que la langue franaise entraine plus naturellement une forme de pense plus adapte au traitement diversifi requis. From jefsey@jefsey.com Mon Aug 17 11:42:30 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14EB33A6BA0 for ; Mon, 17 Aug 2009 11:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.066 X-Spam-Level: * X-Spam-Status: No, score=1.066 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_50=0.001, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENI-GSzguL34 for ; Mon, 17 Aug 2009 11:42:29 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 45ADF3A6AC4 for ; Mon, 17 Aug 2009 11:42:29 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:1499 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Md7A8-0006RE-M6; Mon, 17 Aug 2009 11:42:33 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Aug 2009 20:41:16 +0200 To: comptoir@cafedu.com From: JFC Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit 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: Message-Id: <20090817184229.45ADF3A6AC4@core3.amsl.com> Cc: iucg@ietf.org Subject: [iucg] Internet PLUS/Intersem X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 17 Aug 2009 18:42:30 -0000 Chers CafeduCompres et chres CafeduCommres, En prparation de la runion de concertation sur ce sujet dbut octobre prochain, un brouillon du plan de charge vers l'Internet PLUS et l'Intersem dans le cadre de l'IUCG est document sous http://macjfc.com/wiki/Plan_de_documentation_et_validation_Internet_PLUS/Intersem. Du travail de sortie de crises pour quelques annes. Pour ceux que cela intressent, les critiques sont les biens-venues. jfc From eblanconil@gmail.com Thu Aug 20 14:55:31 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B9D3A6BE9 for ; Thu, 20 Aug 2009 14:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn68WVAouMJy for ; Thu, 20 Aug 2009 14:55:31 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 9BEF93A6B74 for ; Thu, 20 Aug 2009 14:55:30 -0700 (PDT) Received: by bwz19 with SMTP id 19so174858bwz.37 for ; Thu, 20 Aug 2009 14:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=d2HNIdUGGFczBVr2WNPu6LW/CGa2eaPa/ReJxHVuTuE=; b=t37jo0TTOxiPz8mk6CgCZo+BytGVKtCw8zax+bmUaPyzi+kcDtNIzkZQOSgP6uBdWr sF/8uKSuPIJhTiSEvIVLL06rOm1XM8JpVv6JS2p2kPM4AR3Rvppa0zlLr2168P8QCX+y z7FO8cVHxW/b+mdzDegrop0P0tKaBElFX9SA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NgdqPlNR2iMSqAbe4jdXIATaIHyLp2nBZcOLQ3kjeeWFqmeSh1Wd8XJRZ2RV64UTOt nFAZaBjNQkpwMKOuOw8uqgCCAR3We+IKqqxC/D3jkMl7WAccrjSCfJez70zVV5kFPArP K/7dPLj11g2OdEQX2i+Jy1zpzintUiDwpZm1U= MIME-Version: 1.0 Received: by 10.239.179.81 with SMTP id c17mr31511hbg.158.1250805332172; Thu, 20 Aug 2009 14:55:32 -0700 (PDT) In-Reply-To: <20090820183001.7AB1E3A691D@core3.amsl.com> References: <20090820183001.7AB1E3A691D@core3.amsl.com> Date: Thu, 20 Aug 2009 23:55:32 +0200 Message-ID: <6589127a0908201455n16048af0m1b44f06e1c96f2d@mail.gmail.com> From: Elisabeth Blanconil To: internet users contributing group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idna-update@alvestrand.no Subject: Re: [iucg] I-D Action:draft-ietf-idnabis-mappings-03.txt X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 20 Aug 2009 21:55:32 -0000 the http://wikidna.org/index.php?title=3DIDNA_Mapping page has been updated. I do not now if this new version is under WG/LC or not. It adds the following section 4: 4. [I-D.ietf-idnabis-protocol] is specified such that the protocol + acts on the indvidual labels of the domain name. If an + implementation of this mapping is also performing the step of + separation of the parts of a domain name into labels by using the + FULL STOP character (U+002E), the following character can be + mapped to the FULL STOP before label separation occurs: +=09 + * IDEOGRAPHIC FULL STOP (U+3002) + There are other characters that are used as "full stops" that one + could consider mapping as label separators, but their use as such + has not been investigated thoroughly. Elisabeth Blanconil 2009/8/20 : > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Internationalized Domain Names in Applic= ations, Revised Working Group of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Mapping Characters in IDNA > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : P. Resnick, P. Hoffman > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-idnabis-mappings-03.t= xt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 5 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-08-20 > > In the original version of the Internationalized Domain Names in > Applications (IDNA) protocol, any Unicode code points taken from user > input were mapped into a set of Unicode code points that "make > sense", which were then encoded and passed to the domain name system > (DNS). =A0The current version of IDNA presumes that the input to the > protocol comes from a set of "permitted" code points, which it then > encodes and passes to the DNS, but does not specify what to do with > the result of user input. =A0This document describes the actions taken > by an implementation between user input and passing permitted code > points to the new IDNA protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idnabis-mappings-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From eblanconil@gmail.com Fri Aug 21 04:38:18 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190EE3A6DD9 for ; Fri, 21 Aug 2009 04:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLot8c4xYlAP for ; Fri, 21 Aug 2009 04:38:16 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 4E4523A6DB4 for ; Fri, 21 Aug 2009 04:38:16 -0700 (PDT) Received: by bwz19 with SMTP id 19so408387bwz.37 for ; Fri, 21 Aug 2009 04:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=42fqMmBIzztGo3WvjYKcXgzYXlFBki48ox/bI52obXU=; b=mqE2SEeIji0It+WagvNG84IU6/hXoOKi+m6v6+it1xC36ybzst+jiGs1GweNvOLIzw Rv5cL+I34wmfZWHx7pYVcRSoSazjDw/awkar1Fy5a4xtRdv+7Ec5qhWk+K0nUFpU8JLA DxVfZ5Pr33IZ/J4C0DIJEijrJ3NtqqhShv/ME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=p5ZhuUnI6T/3TuXdbMe2+hQ6EDuUuX3Ol0A1R1VgnxK39jfx7niYQSM2IQ6Ikm4oKI sdAEODEqEH0Z7btaWzofgDwAZWd79/suhxEE5ESCWC27MqLnDlVyZS4VCZF4WXyupS0G 2SZg3PdLV6iQSBcHKfvlvrlaxORHL6qh3Gqh8= MIME-Version: 1.0 Received: by 10.239.139.156 with SMTP id t28mr99164hbt.33.1250854694055; Fri, 21 Aug 2009 04:38:14 -0700 (PDT) In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB3DED788CCE@off-win2003-01.ausregistrygroup.local> References: <4A8DF6B9.6020306@cse.mrt.ac.lk> <52FBBE9C-E214-4EAD-9AFE-B3AE0156CF02@google.com> <8CEF048B9EC83748B1517DC64EA130FB3DED788CA6@off-win2003-01.ausregistrygroup.local> <8CEF048B9EC83748B1517DC64EA130FB3DED788CCE@off-win2003-01.ausregistrygroup.local> Date: Fri, 21 Aug 2009 13:38:14 +0200 Message-ID: <6589127a0908210438g61b52f9l9ea621c8768b121a@mail.gmail.com> From: Elisabeth Blanconil To: idna-update@alvestrand.no, internet users contributing group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idns , listegenerale@franceatlarge.org, Vint Cerf , lisa Dusseault Subject: Re: [iucg] Tamil Numerals in IDNA - Re: WG Last Call for Four Primary IDNABIS I-Ds X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 11:38:18 -0000 Dear colleagues, This is a collective mail which discusses a strategic non-disclosed IUCG proposition in the multilinguistics area. It has been reveiwed by the IUCG Chair and will be published on the IUCG site. This is a new case of orthotypography based difficulty. The WG is in theory only interested by characters, translated in unicode points. However, in many cases natural languages are interfering or quoted in its Rationale. The WG must officially say how this is to be consistently addressed. For exemple, in the WG definitly not considered French case, upper-cases that support majuscules are DISALLOWED. This is absurd. They should be CONTEXTO. This seems to be equivalent here. Otherwise, different French or Tamil registries may adopt different mapping practices, confuse users, and introduce semantic addressing related problems. This means that there must be a single "IDN table" (see below the considered scope) by linguistic entity - that cross natural language gTLDs may also refer to in their registration policy. JFC has engaged in a solution which is a mecalanguage layer that must be specified (hence grammatically documented) for every empowered linguistic entity (this would be their default "presentation" [IRT presentation layer] on the network). However, this calls for much research and multiple agreements (MLTF, france@large and now IUCG started investigating them several years ago, within the MAAYA network, in relation with UNESCO, ITU, SIL, Linguasphere, Intlnet, Linguamon, etc. and in relation with ISO TC39 and 46). The target is that mecalects support, not regulate, human natural languages, down to idiolects and avalects (avatars). IMHO this is beyond the scope of this WG. I would therefore suggest that these issues are : (1) addressed through a short sub-section in Rationale and left to CONTEXTO, so registries have an IETF position as a basis for their policy, (2) managed by encouraging mapping conventions to be established on a language basis, most probably in continuation with the effort engaged by ISO TC46/SG2 introducing administrative languages in ISO 3166-1. We are touching here national sovereignties when the considered languages are official languages (let remember there is no official language in the USA and in many countries - what may delay mecalanguage issues there. This has WTO related consequence when considering TBT [technical barriers to trade]). The IUCG plans to introduce the concept of an NWIP (New Work Item Proposal) on mecalanguages related tables as an ISO 3166-4 standard. We have been delayed by late ISO 639-6 publishing. This standard is now in FDIS. This will permit us to proceed. It is planned to be introduced in Barcelona at the MAAYA meeting, end of september. May be the IETF and Unicode could associate themselves to this effort. The target are normative "mecalocale" files documenting the globally accepted mecalanguage corresponding to a set of given locale files. In most of the cases we expect this file to become a national laws as they will impact legal texts, official databases, passports, automatic reading, knowledge management, etc. They will actually define national legal "network presentations" (as in network presentation layer). This proposition is based upon the achievement of this WG which shown that one can start from the DNS and Unicode to obtain a stable multilinguistic basis (in the sense of mult-language interoperation) and a good presentation layer support (interplus - that we will publish once the documents of this WG are accepted). This is why we support this effort, and accept the Charter change if the WG is to disband; but would also support the current charter, would the WG continue working towards a full and well documented separation between the technical (network and unicode), use (interplus and mecalocales), and UI (user applications) planes. Elisabeth Blanconil. 2009/8/21 James Mitchell : > Are we wanting to set the expectation that specific IDN groups can make > characters DISALLOWED? =A0What should happen once this WG concludes and > another IDN group decides some of their characters should be DISALLOWED; = do > we reopen this WG and publish updated documents? =A0Note that the origina= l > email said that it was believed that a similar situation exists for other > South Indian scripts as well as Thai. > > I appreciate the work done by the Sri Lanka IDN Task Force, however belie= ve > this information should be made available to those registries wishing to > support Tamil and not made an exception in the protocol. =A0How this > information is made available is another question, but putting it into th= ese > documents does not seem the right place. > > James > >> -----Original Message----- >> From: John C Klensin [mailto:klensin@jck.com] >> Sent: Friday, 21 August 2009 12:19 PM >> To: James Mitchell; Vint Cerf; Gihan Dias >> Cc: idns; Patrik F=E4ltstr=F6m; idna-update@alvestrand.no; lisa Dusseaul= t >> Subject: RE: Tamil Numerals in IDNA - Re: WG Last Call for Four Primary >> IDNABIS I-Ds >> >> >> >> --On Friday, August 21, 2009 12:02 +1000 James Mitchell >> wrote: >> >> > I disagree. >> > >> > This is a result of case-by-case analysis of individual >> > characters. =A0If one does not want the characters in a label >> > then do not allow them during registration. >> >> James, without taking a position on this, it is not >> "case-by-case analysis of individual characters". =A0It is >> exclusion of a block, albeit a small one. >> >> =A0 =A0 john >> >> >> > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > From eblanconil@gmail.com Fri Aug 21 10:04:42 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F75C28C126 for ; Fri, 21 Aug 2009 10:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J65dMyGhFQGq for ; Fri, 21 Aug 2009 10:04:41 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id EA5B43A6974 for ; Fri, 21 Aug 2009 10:04:40 -0700 (PDT) Received: by bwz19 with SMTP id 19so564017bwz.37 for ; Fri, 21 Aug 2009 10:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aQEsYM0U3So7yIJ4PcxCzUwxeuj49GR640D+n1N0S0Q=; b=spzzxZ3cWoepBMRRySsBm8XL4UjfH2pj3i4GPkdxniMJYoHcHF2FFbBhwqDyEkX5B9 datacoYv6eYmnpiyowNC2j+TqvbjWUndu8fZDut7X9E9hmhJnjXdk1GE2urOAPLXWgr6 /SaSAazY0NKJzYQrH/5Sy17qUeWSx3Z5T5sdY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZxL59f8s5uPbKv2CKU/JYErurB1qSh52BBYk7gDsduPnqFEl87GIpSCNxjL6lQk6vk hu7SoFS2Q/zX2o2VxqPEuCbnBWqVg/rl5XfA9ZLozsVKGVdca5xHnWg2fv4FUIW7rMiV LmW6kBQb0haCNlU4Wry57RmgBzIqupYvwHTic= MIME-Version: 1.0 Received: by 10.239.168.157 with SMTP id k29mr120442hbe.67.1250874279478; Fri, 21 Aug 2009 10:04:39 -0700 (PDT) In-Reply-To: <54A0D8617213E816377F58EA@PST.JCK.COM> References: <4A8DF6B9.6020306@cse.mrt.ac.lk> <52FBBE9C-E214-4EAD-9AFE-B3AE0156CF02@google.com> <8CEF048B9EC83748B1517DC64EA130FB3DED788CA6@off-win2003-01.ausregistrygroup.local> <8CEF048B9EC83748B1517DC64EA130FB3DED788CCE@off-win2003-01.ausregistrygroup.local> <6589127a0908210438g61b52f9l9ea621c8768b121a@mail.gmail.com> <54A0D8617213E816377F58EA@PST.JCK.COM> Date: Fri, 21 Aug 2009 19:04:39 +0200 Message-ID: <6589127a0908211004w7740fc8n4bfe869250294d69@mail.gmail.com> From: Elisabeth Blanconil To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: listegenerale@franceatlarge.org, idns , idna-update@alvestrand.no, internet users contributing group , lisa Dusseault , Vint Cerf Subject: Re: [iucg] Tamil Numerals in IDNA - Re: WG Last Call for Four Primary IDNABIS I-Ds X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 17:04:42 -0000 Dear John, we definitly have two different perspective. You as a designer from inside the network and me as a use from outside of the network. What is important is that we can match our position as on an interface no one is to win. 2009/8/21 John C Klensin : > Elizabeth, > > It appears that you are viewing all requests or suggestions from > language communities as equivalent to each other and, Absolutely. This is the very basis of multilingualism. > more > important, as a situation in which "...different French or Tamil > registries may adopt different mapping practices...". =A0In case > there is still confusion, let me stress two things: > > (1) The specifications _forbid_ a registry doing _any_ mapping > (converting one character or code sequence into another) other > than > > =A0 =A0 =A0 =A0(i) testing for and, if necessary, applying Unicode > =A0 =A0 =A0 =A0Normalization Form C (NFC) > > =A0 =A0 =A0 =A0(ii) Converting one Unicode encoding form (e.g., UTF-8) > =A0 =A0 =A0 =A0into another (e.g., UTF-32) for consistency with > =A0 =A0 =A0 =A0internal character storage. you forget one which is : (iii) to correct a misuse of Unicode. Unicode is Unicode. It is not responsible of the way it is being used. > Registrations occur in terms of final characters only. I do not know what "final characters" is. U-labels are expressed in Unicode-points and A-label in ASCII. Registrations may occur in either or both forms. > Of > course, the IETF, as a voluntary standards body, cannot enforce > that rule. =A0But it cannot enforce any other rule either. =A0Those > who do not follow the standards may encounter interoperability > problems and may be subject to other authorities. Correct. The first authority is the user. Our job is to try to prevent his/her interoperability problems. > (2) The request from the Sri Lankan Tamil community asks for > exclusion of a range of characters, i.e., classifying them as > DISALLOWED. =A0If they are DISALLOWED, then no registry is > permitted to register strings that contain them and no lookup > application should look up any string that contains them either. > That case produces absolutely predictable behavior. =A0It also > does not violate any fundamental rules of Unicode or of the > IDNA2008 protocol design -- an exception would just be made to > treat some collection of characters as DISALLOWED that would > otherwise be PVALID. > > What you are asking for where French is involved is a very > different situation. The discussion is over the IETF disallowing desire: refusing/forcing. > First, you want certain characters treated > differently for some languages that use a given script than for > others that use the same script. =A0That is nearly impossible to > think about, just because there is, in general, no way to know > what language a particular label is supposed to be associated > with, nor is there a way to know what top-level domain has the > label in one of its subtrees (even if one could reliably > associate top-level domains with languages). French does not use Unicode. Unicode supports French. > =A0Second, if I > understand your latest note correctly, you would like to have > those characters treated via some contextual rule ("CONTEXTO"). > But the contextual rules yield either "valid" or "invalid" based > on adjacent or nearby characters -- they do not provide > different mappings, nor different rules for different languages > (the latter at least partially for the reasons above). We just speak of scripts and their correct semantic usage (orthotypography). When other characters are Tamil don't we know we are in a Tamil context? >=A0And, > finally, your suggestion requires treating capital letters (or > at least some capital letters) as distinct from their lower-case > forms, which would create massive inconsistencies with IDNA2003 > (not just the two characters of inconsistency with which we have > have had such extensive debates) as well as inconsistencies with > DNS and host table practices that go back to the 1970s. =A0No > matter how strong your justification, and even if it were not > also tied to differential treatment for a particular language, I > cannot imagine the WG (or the IETF more broadly) agreeing to > that change. > > Another part of the difference is that the Tamil script is used > to write only one language or, depending on how one counts, a > small collection of very closely related languages. Our point is simple. Future is to idolects (support, authentication, etc.) and personalized presentations. We do not want anything that might prevent or delay innovations in that area. > That makes > thinking about an exception request much easier than it is with > the Latin script, which is used to write a very large number of > languages, some of them with no recent (e.g., conservatively in > the last 3000 years or so) linguistic relationship to each other > and that use the script in different ways. =A0That is a > long-standing historical problem; there is nothing that the WG > can do about it today other than to recognize it and move on. You will note that this is roughly what we advise. Best. Elisabeth Blanconil. From jefsey@jefsey.com Fri Aug 21 15:19:24 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C2173A6977 for ; Fri, 21 Aug 2009 15:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.076 X-Spam-Level: X-Spam-Status: No, score=-1.076 tagged_above=-999 required=5 tests=[AWL=1.523, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkeF4SVbaijQ for ; Fri, 21 Aug 2009 15:19:23 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id DFC963A69ED for ; Fri, 21 Aug 2009 15:19:12 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:3260 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MecS3-0006m1-SH; Fri, 21 Aug 2009 15:19:16 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 22 Aug 2009 00:11:35 +0200 To: Andrew Sullivan , Elisabeth Blanconil From: jefsey In-Reply-To: <20090821173908.GC382@shinkuro.com> References: <4A8DF6B9.6020306@cse.mrt.ac.lk> <52FBBE9C-E214-4EAD-9AFE-B3AE0156CF02@google.com> <8CEF048B9EC83748B1517DC64EA130FB3DED788CA6@off-win2003-01.ausregistrygroup.local> <8CEF048B9EC83748B1517DC64EA130FB3DED788CCE@off-win2003-01.ausregistrygroup.local> <6589127a0908210438g61b52f9l9ea621c8768b121a@mail.gmail.com> <54A0D8617213E816377F58EA@PST.JCK.COM> <6589127a0908211004w7740fc8n4bfe869250294d69@mail.gmail.com> <20090821173908.GC382@shinkuro.com> 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: Message-Id: <20090821221912.DFC963A69ED@core3.amsl.com> Cc: iucg@ietf.org Subject: Re: [iucg] Tamil Numerals in IDNA - Re: WG Last Call for Four Primary IDNABIS I-Ds X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 22:19:24 -0000 Dear Andrew and Elisabeth, I suggest you drop this because you definitly do not speak of the same thing. >Tough. The world provides a context which limits our ability to do >certain things, and part of that world is the technology within it, >including all its limitations. Just because we made a technology does >not mean that we control it completely. It shapes us just as we have >shaped it. Andrew, this is precisely what we (users) consider as untechnical and want to and will address. We are the bosses, not the machines. This is the difference between a network centric (IETF) and a people centric (WSIS) vision. IETF wants the Internet to work better (but does not document what it does mean), we want our network system to work just as we need it. >In the present case, there is a limitation the technology >provides, and if you want around that limitation you need to replace >the technology. Elisabeth thinks the limitation is in the text. I think it is in the authors' opposing minds, not in the text. This is why I say you do not speak of the same thing. And that the text is technically acceptable. >I think the chances of DNSng being developed and >deployed within my remaining lifetime are very small, and surely its >non-deployment would also prevent or delay the innovations you want. Not really. This is because we are not actually interested in the DNS as a tool. We only are interested in the naming plan it supports. The same we are not interested in IPvX, but in the numbering plans they may serve. One thing at a time. Let first complete the IDNA document set. Best jfc From klensin@jck.com Fri Aug 21 08:55:44 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A520828C13B for ; Fri, 21 Aug 2009 08:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dzm8n-3SD6dq for ; Fri, 21 Aug 2009 08:55:43 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 307C23A6E87 for ; Fri, 21 Aug 2009 08:55:43 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MeWSv-000EJA-19; Fri, 21 Aug 2009 11:55:45 -0400 Date: Fri, 21 Aug 2009 11:55:43 -0400 From: John C Klensin To: Elisabeth Blanconil Message-ID: <54A0D8617213E816377F58EA@PST.JCK.COM> In-Reply-To: <6589127a0908210438g61b52f9l9ea621c8768b121a@mail.gmail.com> References: <4A8DF6B9.6020306@cse.mrt.ac.lk> <52FBBE9C-E214-4EAD-9AFE-B3AE0156CF02@google.com> <8CEF048B9EC83748B1517DC64EA130FB3DED788CA6@off-win2003-01.ausregistrygroup.local> <8CEF048B9EC83748B1517DC64EA130FB3DED788CCE@off-win2003-01.ausregistrygroup.local> <6589127a0908210438g61b52f9l9ea621c8768b121a@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Fri, 21 Aug 2009 15:46:48 -0700 Cc: listegenerale@franceatlarge.org, idns , idna-update@alvestrand.no, internet users contributing group , lisa Dusseault , Vint Cerf Subject: Re: [iucg] Tamil Numerals in IDNA - Re: WG Last Call for Four Primary IDNABIS I-Ds X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 15:55:44 -0000 Elizabeth, It appears that you are viewing all requests or suggestions from language communities as equivalent to each other and, more important, as a situation in which "...different French or Tamil registries may adopt different mapping practices...". In case there is still confusion, let me stress two things: (1) The specifications _forbid_ a registry doing _any_ mapping (converting one character or code sequence into another) other than (i) testing for and, if necessary, applying Unicode Normalization Form C (NFC) (ii) Converting one Unicode encoding form (e.g., UTF-8) into another (e.g., UTF-32) for consistency with internal character storage. Registrations occur in terms of final characters only. Of course, the IETF, as a voluntary standards body, cannot enforce that rule. But it cannot enforce any other rule either. Those who do not follow the standards may encounter interoperability problems and may be subject to other authorities. (2) The request from the Sri Lankan Tamil community asks for exclusion of a range of characters, i.e., classifying them as DISALLOWED. If they are DISALLOWED, then no registry is permitted to register strings that contain them and no lookup application should look up any string that contains them either. That case produces absolutely predictable behavior. It also does not violate any fundamental rules of Unicode or of the IDNA2008 protocol design -- an exception would just be made to treat some collection of characters as DISALLOWED that would otherwise be PVALID. What you are asking for where French is involved is a very different situation. First, you want certain characters treated differently for some languages that use a given script than for others that use the same script. That is nearly impossible to think about, just because there is, in general, no way to know what language a particular label is supposed to be associated with, nor is there a way to know what top-level domain has the label in one of its subtrees (even if one could reliably associate top-level domains with languages). Second, if I understand your latest note correctly, you would like to have those characters treated via some contextual rule ("CONTEXTO"). But the contextual rules yield either "valid" or "invalid" based on adjacent or nearby characters -- they do not provide different mappings, nor different rules for different languages (the latter at least partially for the reasons above). And, finally, your suggestion requires treating capital letters (or at least some capital letters) as distinct from their lower-case forms, which would create massive inconsistencies with IDNA2003 (not just the two characters of inconsistency with which we have have had such extensive debates) as well as inconsistencies with DNS and host table practices that go back to the 1970s. No matter how strong your justification, and even if it were not also tied to differential treatment for a particular language, I cannot imagine the WG (or the IETF more broadly) agreeing to that change. Another part of the difference is that the Tamil script is used to write only one language or, depending on how one counts, a small collection of very closely related languages. That makes thinking about an exception request much easier than it is with the Latin script, which is used to write a very large number of languages, some of them with no recent (e.g., conservatively in the last 3000 years or so) linguistic relationship to each other and that use the script in different ways. That is a long-standing historical problem; there is nothing that the WG can do about it today other than to recognize it and move on. So I don't see the analogy you are drawing as being at all accurate, nor does it appear to me to be helpful to dealing with either the perceived Tamil numeral problem or the French majuscule one. I believe that your inferences about single "IDN tables", etc., are regards, john p.s. My impression is that the WG is not going to accept this change unless it can be demonstrated that these characters pose serious risks (beyond confusability, even within the script) and that the problems cannot be addressed by registry restrictions. That would be consistent with other decisions in the past. However, that is a personal impression as of right now. It is not a statement about the WG opinion, nor is it a prediction. And it is certainly not a statement about my personal preferences (in part because I don't have one yet). Things could change as discussion continues. --On Friday, August 21, 2009 13:38 +0200 Elisabeth Blanconil wrote: > Dear colleagues, > > This is a collective mail which discusses a strategic > non-disclosed IUCG proposition in the multilinguistics area. > It has been reveiwed by the IUCG Chair and will be published > on the IUCG site. > > This is a new case of orthotypography based difficulty. The WG > is in theory only interested by characters, translated in > unicode points. However, in many cases natural languages are > interfering or quoted in its Rationale. The WG must officially > say how this is to be consistently addressed. > > For exemple, in the WG definitly not considered French case, > upper-cases that support majuscules are DISALLOWED. This is > absurd. They should be CONTEXTO. This seems to be equivalent > here. Otherwise, different French or Tamil registries may > adopt different mapping practices, confuse users, and > introduce semantic addressing related problems. This means >... From jefsey@jefsey.com Sun Aug 23 12:30:33 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37FA13A672E; Sun, 23 Aug 2009 12:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.378 X-Spam-Level: X-Spam-Status: No, score=0.378 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_HTML_A_BODY=0.742] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGdH39N997ta; Sun, 23 Aug 2009 12:30:32 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id C60533A69E5; Sun, 23 Aug 2009 12:30:31 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:3471 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MfIlw-0006Wf-H6; Sun, 23 Aug 2009 12:30:37 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 23 Aug 2009 21:30:31 +0200 To: iucg@ietf.org From: jefsey Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_23621609==.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: Message-Id: <20090823193031.C60533A69E5@core3.amsl.com> Cc: maaya@funredes.org, iesg@ietf.org Subject: [iucg] Intersem: 470 years of experimentation X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 23 Aug 2009 19:30:33 -0000 --=====================_23621609==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed http://iucg.org/wiki/French:_470_years_of_experience_for_the_Intersem French: 470 years of experience for the Intersem It was 470 years ago today that King Francois the First signed the ordnance of Villers-Cotterets. This ordnance removed the French judiciary system from any Church jurisdiction and ended the use of Latin in legal public decisions. This was the birth of the French modern language, through its assignment as the language of French law in a lingually diversified Kingdom. The difference This is the basic difference between French and every other language. In every language there is a common referent in the background that is never stated, but is constantly present. In French, as a legal language, this referent comes with an impressive "built-in" metalanguage in some kind of intelligent (as in inter-legere, inter-linked) overlay that is shaped by the influence of the Law, methodically structuring the grammar as well as rules, usages, social agreements, common thinking, knowledge, culture and cultural values that every other human community usually builds from a rough consensus. A progressive exploration Various authors (Du Bellay, Descartes, and Pascal actually tested whether it was possible to use the language of the Law for poetry, science, philosophy, etc.). This also clearly explains the raison d'etre of the French Academy, which is not actually to protect the language, but rather to protect the citizens by protecting the clarity of the law as described by a language, which must be kept equal, logical, and reasonably exciting for everyone, from generation to generation. This is the job of academicians who, for that reason, have been dubbed as "Immortals" (719 to this date), because the Law has to be immortal, as the rules of Justice are carved in the stone, and in this way are also carved in the national language. Revolution gave to the Law the care of the language of the Law, but Napoleon returned it to the expertise of the academicians and made them stabilize and document it. This was more efficient, but less democratic: the first SSDO [specialised standard documentation organisation]. Intrinsic equality This protection of the people by the defense of the languages of the Law of the people is the very basis of a "people centric" society, such as the one found in the unanimous declaration at the World Summit on the Information Society, which described the want for the Internet to support such. This is the motivation for the france@large team that is participating in the IETF linguistic WGs; an equal for all linguistic support of equal languages. Technical contribution Technically, the interest in this experiment results from the fact that it worked. This meant that one can introduce an active referent system as a part of the more passive grammatical system. If one considers that the common referent of a relational space makes the semantics of its language, and that its various contexts make its pragmatics diversity, this would mean that Francois the First was able to port a large and key pragmatic referent into the language semantic references (grammar, syntax, and vocabulary). We know his way rather well: the new references were well structured (Legal system). We do not know if other approaches would have worked, since that respective case was unique. However, we also know that this trains French speakers in their "metaductive" form of thinking, by first understanding how the world is and then "boringly" striving to make it "French" i.e. equal, logical, and reasonably exciting for everyone. One could, in some way (which Kant implied), oppose this with the Descartes' Method 4th rule: limited human methodical considerations come second after a global vision (this is precisely what we are trying to address via research [such as "Complex" or "Intelligent" thinking and "epistemology" (in the French school meaning)] towards a networked consideration of reality). An inspiration for innovation This introduction of the legal language in the language itself, with all its logical implications and constraints, is very similar to the problem that we are facing, which is to make natural languages and mecalanguages [natural language support by machines] (the first issue being IDNA) converge. Metaductive thinking is what registries and metadata networks permit (JTC1/WG2/SC32, ISO 11179): it is the most probable support of mecalanguages. However, it took French a few centuries; we do not have that kind of time - but we do have French as an experimental basis for the job at hand: the Intersem, the multilingual and semantic Internet. --=====================_23621609==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit http://iucg.org/wiki/French:_470_years_of_experience_for_the_Intersem


French: 470 years of experience for the Intersem

It was 470 years ago today that King Francois the First signed the ordnance of Villers-Cotterets. This ordnance removed the French judiciary system from any Church jurisdiction and ended the use of Latin in legal public decisions. This was the birth of the French modern language, through its assignment as the language of French law in a lingually diversified Kingdom.


The difference

This is the basic difference between French and every other language. In every language there is a common referent in the background that is never stated, but is constantly present. In French, as a legal language, this referent comes with an impressive "built-in" metalanguage in some kind of intelligent (as in inter-legere, inter-linked) overlay that is shaped by the influence of the Law, methodically structuring the grammar as well as rules, usages, social agreements, common thinking, knowledge, culture and cultural values that every other human community usually builds from a rough consensus.


A progressive exploration

Various authors (Du Bellay, Descartes, and Pascal actually tested whether it was possible to use the language of the Law for poetry, science, philosophy, etc.). This also clearly explains the raison d'etre of the French Academy, which is not actually to protect the language, but rather to protect the citizens by protecting the clarity of the law as described by a language, which must be kept equal, logical, and reasonably exciting for everyone, from generation to generation. This is the job of academicians who, for that reason, have been dubbed as "Immortals" (719 to this date), because the Law has to be immortal, as the rules of Justice are carved in the stone, and in this way are also carved in the national language. Revolution gave to the Law the care of the language of the Law, but Napoleon returned it to the expertise of the academicians and made them stabilize and document it. This was more efficient, but less democratic: the first SSDO [specialised standard documentation organisation].


Intrinsic equality

This protection of the people by the defense of the languages of the Law of the people is the very basis of a "people centric" society, such as the one found in the unanimous declaration at the World Summit on the Information Society, which described the want for the Internet to support such. This is the motivation for the france@large team that is participating in the IETF linguistic WGs; an equal for all linguistic support of equal languages.


Technical contribution

Technically, the interest in this experiment results from the fact that it worked. This meant that one can introduce an active referent system as a part of the more passive grammatical system. If one considers that the common referent of a relational space makes the semantics of its language, and that its various contexts make its pragmatics diversity, this would mean that Francois the First was able to port a large and key pragmatic referent into the language semantic references (grammar, syntax, and vocabulary).

We know his way rather well: the new references were well structured (Legal system). We do not know if other approaches would have worked, since that respective case was unique. However, we also know that this trains French speakers in their "metaductive" form of thinking, by first understanding how the world is and then "boringly" striving to make it "French" i.e. equal, logical, and reasonably exciting for everyone.

One could, in some way (which Kant implied), oppose this with the Descartes' Method 4th rule: limited human methodical considerations come second after a global vision (this is precisely what we are trying to address via research [such as "Complex" or "Intelligent" thinking and "epistemology" (in the French school meaning)] towards a networked consideration of reality).


An inspiration for innovation

This introduction of the legal language in the language itself, with all its logical implications and constraints, is very similar to the problem that we are facing, which is to make natural languages and mecalanguages [natural language support by machines] (the first issue being IDNA) converge. Metaductive thinking is what registries and metadata networks permit (JTC1/WG2/SC32, ISO 11179): it is the most probable support of mecalanguages.

However, it took French a few centuries; we do not have that kind of time - but we do have French as an experimental basis for the job at hand: the Intersem, the multilingual and semantic Internet.
--=====================_23621609==.ALT-- From eblanconil@gmail.com Sun Aug 23 15:53:34 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96753A69DD for ; Sun, 23 Aug 2009 15:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_50=0.001, GB_I_LETTER=-2, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8GbEkOY1-AN for ; Sun, 23 Aug 2009 15:53:32 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 433AC3A6830 for ; Sun, 23 Aug 2009 15:53:32 -0700 (PDT) Received: by bwz19 with SMTP id 19so1209399bwz.37 for ; Sun, 23 Aug 2009 15:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=4helWFd90VxujmqQ/fK34+NsUo+AzD9KSCFRAjyZb/U=; b=DnbXVP/+9L2qcMvIKTcAbrf0cftYME7gEhnYAnxD+xREe1pcEqFbZCbq/fVBEfT2lC /cPE3FR91LeG/OSBFOvHfKQ6k0wa+S3cUB0Pq9RFIVHQbl/PEFAepdH1h858K1gl1GUi n61QN68OErCJWmFjH4J8SuROZpaBHrJGYIfx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tyNy88cXcYkFzCKXOzJDcJA1DB0ufxdLrzCKnvAjqdL4bdcWNWjbmOr4lWs1XjfcND lgjRumEeeFQjxtWPXBmd3Ae6njZ9CVnDKaun6BdcrIWVfHgCJ3YA5qmq4iI7MA9OMRq5 DVEByyG76pTKKySsxXspM7gpACbaVdePZikDY= MIME-Version: 1.0 Received: by 10.239.179.99 with SMTP id c35mr402269hbg.161.1251068011788; Sun, 23 Aug 2009 15:53:31 -0700 (PDT) Date: Mon, 24 Aug 2009 00:53:31 +0200 Message-ID: <6589127a0908231553n72c40464weba56b41853b9c49@mail.gmail.com> From: Elisabeth Blanconil To: idna-update@alvestrand.no Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: listegenerale@franceatlarge.org, internet users contributing group Subject: [iucg] IDNA document set - Last Call review X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 23 Aug 2009 22:53:35 -0000 Dear Colleagues, This memo covers the collective remarks from the IUCG/france@large CX-DNS participants. The participants are of three origins: * Two newcomers who are motivated by the Last Call opportunity to ensure that they understand everything. * Three participants who have been involved, at some stage and form, in the IDNABIS debate, who in turn would like to see the document published finally. * Five participants who are primarily interested in making sure that they can document "IDNAPLUS" as the strictly conformant support of IDNA by the Interplus architecture that the IUCG is working on. These remarks can be found at http://wikidna.org/index.php?title=3DIUCG_rem= arks Best regards Elisabeth Blanconil ---------------------------------------------------------------------- General appreciation * The document repartition seems adequate. However, even if the Mapping memo was not a part of the IDNA (why?) document set, it is more than logical and enlightening to have it read prior to the Protocol parts. * The documents are rather confusing because it is impossible to decide whether: o they consider IDNA as a part or not as a part of the DNS (we may also be influenced by the ML-DNS pile we work on). o they differentiate (which) between characters and codepoints. o they use NFKC or NFC, and what are their differences, intrinsically and from an IDNA point of view o they want to be a complete standards, or a partial suggestions, set. This results from: + the non-normative forms are being used in places that one would deem normative + the constant discussion of Registries' capacities/obligations and the lack of documentation on the tools for executing them and managing the related registration/coding metadata and rules. IDNA Definitions * Information on Unicode is scattered throughout the document. Wouldn=92t it be much better to describe a clear sequence? * what an IDNA is, * what IDNs are, * what IDNA labels are, * what they are made of, * how Unicode supports them, including NFC in the same 2.1. section= , * how a zone manager may impose profiling rules (description, enforcement). * Most of the new terms are discussed before being defined. This starts with the confusing "looking them up" in part 1.1.1. (which means resolving, and not just asking about, validity or existence) as opposed to "registering"). IDNs are introduced 2.3.2.3. etc. This certainly reflects how difficult the work is in defining all these terms, but it is still quite confusing. For example, it is advisable to begin with part 4.4. * The different classes of domain names that are discussed only seem to be related to IDNA without an exhaustive presentation of the DNS domain name context. The names are somewhat confusing. The drafts are certainly clear, but they do not reflect a progressive logic of discovery of the nature of a name/label that could be ported to programming functions. * References to the lower/uppercase image can be understood by DNS old-timers, but is confusing to newcomers, as it does not reflect the same functionality and because U-label/A-label lower/uppercase treatment is not the same. * Different keyboards and encoding are discussed, stressing that a DNS resolution calls for a U-label conversion, but nothing obliges local applications to transcode user entries to Unicode when they interoperate at a layer other than DNS. However, these applications may want to canonize these entries in their proper way. Interplus supports the idea that an application layer may use middle non-Unicode and non-ASCII coding. Among others, this facilitates interoperability with UTF-8 that Microsoft supports within private nets: the user interface may be common and the underlying machinery either IDNA or UTF-8. * 4.1. "Security on the Internet partly relies on the DNS. Thus, any change to the characteristics of the DNS can change the security of much of the Internet." This sentence seems extremely confusing, as IDNA does not affect (change characteristics) the DNS but is rather built on the fact that they will not be changed. * The same : "The security of the Internet is compromised if a user entering a single internationalized name is connected to different servers based on different interpretations of the internationalized domain name." The security of the Internet is not compromised, however, trust in the IDNA proposition might be. * The 4.7. Summary might be considered adventurous? Corporations such as Nominum propose services that are supposed to protect the DNS. One of the purposes of ML-DNS is precisely to permit an architectural protection. IDNA Rationale * 1.3.1. DNS "Name" Terminology. "" would be better read as "orthotypographic" as an orthographic error that can be a way to lose some special semantics differences due to orthotypographic conventions. * 1.3.2. "IDNA-landr" typo? * 1.4. "Reduce the dependency on mapping, in order that the pre-mapped forms (which are not valid IDNA labels) tend to appear less often in various contexts, in favor of valid A-labels." calls for the Charter to be revised. ALternatively, it could say , remove dependence on mapping as per a mapping document, in which this document would include a section on the various ways to ensure DNS security and the barring of some U+codes in some presentations. * 1.5. "This model has served the existing applications well, but it requires, with or without internationalized domain names, that users know the exact spelling of the domain names that are to be typed into applications such as web browsers and mail user agents. The introduction of the larger repertoire of characters potentially makes the set of misspellings larger, especially given that in some cases the same appearance, for example on a business card, might visually match several Unicode code points or several sequences of code points." may be read as if the users of these languages were more prone to errors than ASCII language. * "If an application wants to use non-ASCII characters in public DNS domain names, IDNA is the only currently-defined option." IDNA is not a DNS option. It is an application way to transcode Unicode domain names in LDH domain names for the convenience of ASCII oriented international managers. The idea is to attain the adherence of local users and managers to IDNA and not to impose ASCII on them. DNS is UTF-8 compatible. * "IDNA2008 divides all possible Unicode code-points into four categories: PROTOCOL-VALID, CONTEXTUAL RULE REQUIRED, DISALLOWED and UNASSIGNED. 3.1.1. PROTOCOL-VALID Characters identified as "PROTOCOL-VALID" (often abbreviated "PVALID") are permitted in IDNs." Are we talking of code-points or of characters? * 3.1.2.1 Not in the TOC * 3.1.3 Disallowed "various HEART symbols" - is U+38FA also disallowed? or U+3966? * 3.1.3. This is the first time anyone has spoken of NFKC. In IDNA Defs and other cases, it is NFC. Shouldn=92t t both of them be documented? Shouldn=92t someone explain in which specific case one is used? * "The character is an upper-case form or some other form that is mapped to another character by Unicode casefolding." this seems to create a very large mapping scheme that depends on a non-documented Unicode system needing correction (at least when it does not specifically support majuscules). Moreover, are we dealing with characters (that are orthogonal to Unicode) or with codepoints that represent characters and that are subject to Unicode casefolding. The proposition is to: (1) clarify the character/codepoint issue, (2) explain what Unicode case folding is and its limitations, (3) move them to CONTEXTO when these codepoints are both used as upper-cases and as majuscules, (4) explain that majuscules that are supported by upper-cases will be transcoded by punycode. * 4.4. Case mapping. One may regret that the French majuscules current support of Unicode, which isperfectly adequate in other circumstances yet inadequate in this case, is not discussed. This would explain the upgrade above. * 4.5. "Examples of this are Yiddish, written with an extended Hebrew script, and Dhivehi (the official language of Maldives) which is written in the Thaana script (which is, in turn, derived from the Arabic script)" It seems that some explanation about Yiddish would be welcome so that the language will obtain the same support as Dhivehi and Thaana. * 5. "Conversely, lookup applications are expected to reject labels that clearly violate global (protocol) rules (no one has ever seriously claimed that being liberal in what is accepted requires being stupid)." The remark between the parentheses is confusing: it possibly qualifies as "stupid" a behavior that is not recommended, but that is acceptable by the document set. * "Application implementors should be aware that where DNS wildcards are used, the ability to successfully resolve a name does not guarantee that it was actually registered." In which terms is this specific to IDNA? * 7.6. The Symbol Question. That part actually discusses the Unicode originated difficulties. Yet, the choice of Unicode has not yet been discussed. * 9. "Adding languages (or similar context) to IDNs generally, or to DNS matching in particular, would imply context dependent matching in DNS, which would be a very significant change to the DNS protocol itself". This sentence seems confusing. Natural languages are quoted throughout this IDNs document. IDNA Mapping * Not sure that the terminology of "make sense" is adequate or clear. * 1. Introduction - This document is supposed to be separated from the IDNA document set. It should then document what the IDNA protocol is. It seems that the IDNA2008 protocols boil down to "DNS domain names are to be expressed in LDH form. IDNA is a commonly agreed upon convention wherein if they are entered by the user in another form, applications are advised to convert them to UTF in order to filter and map them, as is discussed in the present document, as well as to transcode them in by using the punycode algorithm. Depending on the Registry policy, their registration can be carried out in the ITF and/or the transcoded ASCII form." * 2.3. NFC is confirmed, NFKC is not discussed. IDNA Protocol * As a general comment: o The SHOULD/MUST chains may be somewhat awkward. MUSTs are used in a protocol procedure and then an alternative to that procedure is pragmatically considered. It could be of interest to draft a MUST tree to consider which cases are, or are not, covered. o there is some confusion as to what the "string" is compared to the label and domain name, in which "Label" may be used instead of "U-Label" or sometimes "A-Label". Wouldn=92t it be better to review the text in qualifying the "labels" in order to be certain that all the cases are clearly covered? * 3.2. "It does not apply to domain name slots which do not use the Letter/Digit/Hyphen (LDH) syntax rules." Confusing. Would some of the DN slots not accept both? * 3.2.1. The word CLASS only appears in the whole document set in two sentences: "DNA applies only to domain names in the NAME and RDATA fields of DNS resource records whose CLASS is IN. See RFC 1034 [RFC1034] for precise definitions of these terms. The application of IDNA to DNS resource records depends entirely on the CLASS of the record, and not on the TYPE except as noted below." What about internationalized domain name in a non IN CLASS? * 4. "This section defines the procedure for registering an IDN. The procedure is implementation independent; any sequence of steps that produces exactly the same result for all labels is considered a valid implementation." A procedure does provide but does not define a result? * 4.1. The obligation chain reads: "By the time a string enters the IDNA registration process [], it is expected to be in Unicode []", yet "registries [] SHOULD avoid any possible ambiguity by accepting registrations only for A-labels []." * 4.3. Registry restriction inheritance is not alluded to. * 5. Does this repetition (already in INDA Rationale) "the presence of wild cards in the DNS might cause a string that is not actually registered in the DNS to be successfully looked up." reflect what the BIDI documents slightly differently: "Wildcards create the odd situation where a label is "valid" (can be looked up successfully) without the zone owner knowing that this label exists. So an owner of a zone whose name starts with a digit and contains a wildcard has no way of controlling whether or not names with RTL labels in them are looked up in his zone." * 5.2. The case of a character that is not supported by Unicode is not discussed. * 5.4. The use of "U-Labels" in this part instead of "Labels" would probably clarify it. * "applying the test is likely to give much better information about the reason for a lookup failure -- information that may be usefully passed to the user when that is feasible -- than DNS resolution failure information alone" might this lead to the idea that they could also be carried in case of the failure to better document it? * "For all other strings, the lookup application MUST rely on the presence or absence of labels in the DNS to determine the validity of those labels and the validity of the characters they contain". Is it correct to assume that the first labels stand for "A-Label" and the second one stands for "their corresponding U-Labels"? * 7. IANA Considerations - There is no commitment from UNICODE to not update those Unicode documents that are accepted as normative in the IDNA documentation set. Should their copy at the time of the publication of this set not be stored by the IANA? IDNA BIDI * 1.1. Advisable or not to specify "when U-labels" instead of "labels" = ? * 1.4. BIDI properties come from Unicode. They might not be complete or could be completed in the future. What then? * 2. A replacement for the RFC 3454 BIDI rule: it would probably be good to indicate the applying order. * 7. Does that restriction mean that telephone numbers cannot be registered in BIDI zones? * 8. IANA considerations. Same remark as in the Protocol case. Moreover, the section above then states: "the determination of validity for any string depends on the Unicode BIDI property values, which are not declared immutable by the Unicode Consortium." IDNA Tables * 1. Introduction. "In particular, some combinations of allowed code points are not advisable for use in IDNs due to rules specific to a script or class of characters" introduces the concept of a "class of characters", but does not document it. IDNA Rationale 7.1.3 states "Maintain IDNA and Unicode tables that are consistent with regard to versions, i.e., unless the application actually executes the classification rules in [IDNA2008-Tables]" yet the only time "classifications (rules) appears" in IDNA Tables is in "4. Code points" as "The Categories and Rules defined in Section 2 and Section 3 apply to all Unicode code points. The table in Appendix B shows, for illustrative purposes, the consequences of the categories and classification rules, and the resulting property values." What is a "class of characters"? * 1. Introduction ends with " This document is part of a series that, together, constitute a proposal for updating the IDNA standards to resolve issues uncovered in recent years, cover a broader range of scripts, and provide for migration to newer versions of Unicode. See [IDNA2008-rationale] for a broader discussion. " Should this not be removed or edited? * 2.1. "For more information, see section 4.5 of The Unicode Standard [Unicode5]." Is it also the case in Unicode 5.1? Shouldn=92t this document be stored by the IANA? * 2.2. NFKC or NFC? * 2.10. "It should be noted that Unicode distinguishes between 'unassigned code points' and 'unassigned characters'". Can the differences (nature and in relation to IDNA) between the characters and codepoints be explained here? * 5. IANA consideration. It is suggested that IANA should retain online copies of the version of external documents that are normatively referenced in the IETF documents. * "A table from which that registry can be initialized, and some further discussion, appears in Appendix A. " - Who is to decide and maintain the table and according to which rules/procedures? * Appendix A. as a comment, we do not understand, from the presented kind of logic, as to why: o Tamil digits cannot be made subject to a rule and added to CONT= EXTO? o The same for French majuscules? o The same for any zone specific restriction? It seems implied that the logic should be the same on the sending and receiving end. The receiving end is only for decoding what the sending end chose to encode in its own context. That context needs to be considered and supported. If my application is in Tamil or French, it knows it and can be demanded to proceed accordingly. From eblanconil@gmail.com Mon Aug 24 14:19:53 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 903D93A6A08 for ; Mon, 24 Aug 2009 14:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1bKrE4mMPuP for ; Mon, 24 Aug 2009 14:19:52 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 70E373A6E42 for ; Mon, 24 Aug 2009 14:19:12 -0700 (PDT) Received: by bwz19 with SMTP id 19so1699751bwz.37 for ; Mon, 24 Aug 2009 14:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ZwcK0gz2IXUDr7J7RMCpLxkj5hWbqi/7XtwaVZJERHU=; b=sWAj6RqE06Hszlqd6nWyyF25L2OlOQVHzufbuI5/HAWeodRNUYetRu7y70NA5CoJ+2 3lftsRbwEzJoyARzkrdeYOXMBXqyYq1+Bp0fownRZCM7xynBF5wO+g7oldag0PCV4g7a Ffyp13ByQu6uRy+wuIGAcgIlOzvuB052+DOrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=HFFYxuWhoGhZXqU1rFXhEz/S8EP1kNtM55NZHFDvIUOrU7jV1WGXWA+D3KHyKUT5aU PpntScSgDtAqRef2huZfhS9SosJOORFxr4NHyxRzMT5F4WNfdmOLFl77XplCu3056KtB /qCIhh/4jByCGGxf7NO++3aBI9CZ6VrrnD6XU= MIME-Version: 1.0 Received: by 10.239.168.157 with SMTP id k29mr494353hbe.67.1251148755007; Mon, 24 Aug 2009 14:19:15 -0700 (PDT) Date: Mon, 24 Aug 2009 23:19:14 +0200 Message-ID: <6589127a0908241419x2ddc23a1y82fce88c8921f1b3@mail.gmail.com> From: Elisabeth Blanconil To: internet users contributing group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idna-update@alvestrand.no, listegenerale@franceatlarge.org Subject: [iucg] WG-IDNABIS LC situation X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 24 Aug 2009 21:19:53 -0000 Dear Colleagues, we have tried to compile all the LC remarks and the responses given so far. http://wikidna.org/index.php?title=WG-IDNA_LC The name of the author is indicated when it is not an IUCG point. Please let me know if I forgot something (editorial changes are not listed). Best Elisabeth Blanconil From eblanconil@gmail.com Tue Aug 25 02:18:42 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F33028C461 for ; Tue, 25 Aug 2009 02:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LX-0054a-4Gi for ; Tue, 25 Aug 2009 02:18:41 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 4B1E83A6AC2 for ; Tue, 25 Aug 2009 02:18:41 -0700 (PDT) Received: by bwz19 with SMTP id 19so1931313bwz.37 for ; Tue, 25 Aug 2009 02:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=GpNdgjIM+PblNAYqD9SBoLD6awZosF4cm5Mi8cWIW1o=; b=WljikcwfmkFjC+U75+oDBoL9IEyf+k/aUQzaR9DY5KWbVycz3KLJrQN/8xkdgmASoo 1WIo4mCB2wkBMQY1Ur/50VXjk2tJkTNPtwPPKMRXM92VurcYRCSZj6aHiJgosLReOlTE KwLh7O07hGjkgZhbM2sWiJBDbNJ/GfEi5j9d0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=qEI8IV/ECh5ZcJfjVf2k3sivyF4ES7LabkPxiwLAhVVGh/DBxX5UUSa+EdNUZUYmfC JWlZ4XICgt1NNHvHLYLb/b4KxMo0a2nLWrbWwpxnoTDOyqTAnlB6ApvT7QAGLAjPsJ2W xdPU1k0RhgVRU4I3hjg01Wz6pDsmP/wxLj1NM= MIME-Version: 1.0 Received: by 10.239.139.143 with SMTP id t15mr633560hbt.92.1251191923925; Tue, 25 Aug 2009 02:18:43 -0700 (PDT) Date: Tue, 25 Aug 2009 11:18:43 +0200 Message-ID: <6589127a0908250218j19e46bbfr885eca51e95beab3@mail.gmail.com> From: Elisabeth Blanconil To: internet users contributing group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [iucg] LC Status report update X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 09:18:42 -0000 http://wikidna.org/index.php?title=WG-IDNA_LC has been updated up to today last Andrew Sullivan's mail. Best Elisabeth Blanconil From eblanconil@gmail.com Wed Aug 26 00:16:07 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7823A69FE for ; Wed, 26 Aug 2009 00:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9+voV6EbmPr for ; Wed, 26 Aug 2009 00:16:06 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 2DF813A6EDA for ; Wed, 26 Aug 2009 00:16:02 -0700 (PDT) Received: by bwz19 with SMTP id 19so2362174bwz.37 for ; Wed, 26 Aug 2009 00:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UUsI6KCwzMR0ZxsIlEkS3rNHEZnfHUtnm20UkVQKVaY=; b=fAAmOgJWoviNnl7qkbyT+FUVfdS9D6CvPzSny0BTNgsudE/7ErYS0+zhFMhZXIC/7n lZFPNKN1eBTrBVkNk5zXmm3xV4hkTruy1rngmIAXCqdElTR6TLn5fGNZGJhm9kPVGfEM or2Qa8aXIfNLsyuY05y+pqvYQB5XERtLzEGeo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NVnNvQISr6Lz9UXKxgNVjVKBB4yOsIwlO1aFwO9lARfwgi+eARrD+87JclW4KR4sBJ 3I42R31mE+bLJinKRwGnhaqUSdZJZ/ziUFoRxnlXR1JdoBjT0nfzUVlhWzYM4OJ88C0S qqFpr+JMpy8v5jB1Wl7r8a6GwqIgwkkrRA50s= MIME-Version: 1.0 Received: by 10.239.170.35 with SMTP id q35mr740959hbe.150.1251270965452; Wed, 26 Aug 2009 00:16:05 -0700 (PDT) In-Reply-To: <20090826041104.GE5405@shinkuro.com> References: <20090826041104.GE5405@shinkuro.com> Date: Wed, 26 Aug 2009 09:16:05 +0200 Message-ID: <6589127a0908260016m58789e1by39a6e96f6284e22c@mail.gmail.com> From: Elisabeth Blanconil To: internet users contributing group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idna-update@alvestrand.no Subject: Re: [iucg] Comments on draft-ietf-idnabis-protocol-14 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 26 Aug 2009 07:16:07 -0000 http://wikidna.org/index.php?title=3DWG-IDNA_LC has been updated. Best Hebe 2009/8/26 Andrew Sullivan : > Dear colleagues, > I have read draft-ietf-idnabis-protocol-14. =A0Here are my comments. From jmabdp@gmail.com Thu Aug 27 01:02:16 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55DB73A6841 for ; Thu, 27 Aug 2009 01:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6jMbJ2EqL-o for ; Thu, 27 Aug 2009 01:02:15 -0700 (PDT) Received: from mail-px0-f202.google.com (mail-px0-f202.google.com [209.85.216.202]) by core3.amsl.com (Postfix) with ESMTP id 4A0F93A68B9 for ; Thu, 27 Aug 2009 01:02:15 -0700 (PDT) Received: by pxi40 with SMTP id 40so875595pxi.5 for ; Thu, 27 Aug 2009 01:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=nMxnUjI6289ZpSIb/VyNveNFV5WsIthE3LXk6y/w8Zg=; b=YEEas+A4I+rd3Y4C3jEFMSy97KWSKi8ZpijhHMgb94hI+/NZv5Q4Fmk34/m/aQaxNt pg9jT4yF7Yp+6tF7S9EHhje8hwhSv7tkFVCNlV8eNoXD3js2nMGFBcgav2o7WB2Kr5Ia quw661FwtMtuUe4Mg3HwNEE3b1CSPTfBc9GQE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=ET0TThzWwu09vERATiPHdwGy0Q4yHeJc4AYBmuahn9KeJoyEVeI9wYbhyFveEW9g1s dg/ReJJYCbwKbmTHnNqHJn0Kef6BoidkJxk3IqweaI11IXELYZARcXd03gKkvObqSp14 jhjHo7t6mLQa4EIgkCMiYNmcTP3nwHa1OHp80= MIME-Version: 1.0 Received: by 10.143.24.42 with SMTP id b42mr658850wfj.41.1251360136866; Thu, 27 Aug 2009 01:02:16 -0700 (PDT) Date: Thu, 27 Aug 2009 10:02:16 +0200 Message-ID: <6aad7a210908270102n2bcd9d72r54d53b1a32303133@mail.gmail.com> From: jean-michel bernier de portzamparc To: IDNA update work , internet users contributing group Content-Type: multipart/alternative; boundary=001636e1f7ab71abe704721afcfe Subject: [iucg] Updates : Unicode and LC-summary X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 27 Aug 2009 08:02:16 -0000 --001636e1f7ab71abe704721afcfe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear colleagues, 1. Does this announcement of Unicode 5.2. permit to document an example on how IDNA is independent from Unicode version changes? Or should IDNA2008 to be published as conformant to UNICODE2009? 2. for common information http://wikidna.org/index.php?title=3DWG-IDNA_LC h= as been updated with Andrew Sullivan's last comments and Martin D=FCst comment= s on the IAB IDN draft. We will some of ours this morning. Portzambarc ------ From: announcements@unicode.org To: announcements@unicode.org Subject: [Unicode Announcement] Last Call for Unicode 5.2 Data The data files in the Unicode Character Database for Unicode 5.2 have been revised to include all of the authorized changes from the last UTC meeting. If you use any of the Unicode data in your implementations, please update a test version of your implementation to use those files and run your tests. If there are any showstopper bugs, please report them (using http://www.unicode.org/reporting.html)as soon as possible. From this point, the only adjustments that will be made to the data will be on the basis of showstopper bugs, including bugs uncovered in the process of updating the Unicode Collation data files for UCA 5.2. --001636e1f7ab71abe704721afcfe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear colleagues,

1. Does this announcement of Unicode 5.2. permit to= document an example on how IDNA is independent from Unicode version change= s? Or should IDNA2008 to be published as conformant to UNICODE2009?

2. for common information http://wikidna.org/index.php?title=3DWG-IDNA_LC has been= updated with Andrew Sullivan's last comments and Martin D=FCst comment= s on the IAB IDN draft. We will some of ours this morning.

Portzambarc

------

From: announcements@unicode.org
To: announcements@unicode.org<= /a>
Subject: [Unicode Announcement] Last Call for Unicode 5.2 Data

The data files in the Unicode Character Database for Unicode 5.2 have
been revised to include all of the authorized changes from the last UTC meeting. If you use any of the Unicode data in your implementations,
please update a test version of your implementation to use those files
and run your tests. If there are any showstopper bugs, please report
them (using http://www= .unicode.org/reporting.html) as soon as possible.

=A0From this point, the only adjustments that will be made to the data
will be on the basis of showstopper bugs, including bugs uncovered in
the process of updating the Unicode Collation data files for UCA 5.2.
--001636e1f7ab71abe704721afcfe-- From jefsey@jefsey.com Thu Aug 27 17:21:18 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724083A6DE3; Thu, 27 Aug 2009 17:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XikX0U1-QTre; Thu, 27 Aug 2009 17:21:17 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 76FED3A6D3A; Thu, 27 Aug 2009 17:21:17 -0700 (PDT) Received: from [79.94.130.168] (port=4160 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MgpDU-0006Dn-Iq; Thu, 27 Aug 2009 17:21:21 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 28 Aug 2009 02:21:15 +0200 To: dthaler@microsoft.com From: JFC Morfin 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: Message-Id: <20090828002117.76FED3A6D3A@core3.amsl.com> Cc: Vint Cerf , IAB , iucg@ietf.org, Lisa Dusseault , idna-arabicscript@lists.irnic.ir Subject: [iucg] Comments on draft-iab-idn-encoding-00.txt X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 00:21:18 -0000 Dear The IUCG participating users think that your draft-iab-idn-encoding-00.txt is to be considered in a WG-IDNABIS perspective with its set of documents presently under WG/LC. Here are the comments we made. 1. "An Internationalized Domain Name (IDN) is a name that contains one or more non-ASCII characters.". What is a "name" vs. a domain name? 1. "When an IDN is encoded with Punycode, it is prefixed with "xn--",". Is an IDN a label? 1. "it is prefixed with "xn--", which assumes that ASCII names do not start with this prefix." Isn't the whole thing supposed to use "xn--" ASCII labels instead of non-ASCII entries? 1. "reversible Unicode-to-Punycode conversion .... reversible Punycode-to-Unicode conversion". Unicode is a table, Punycode is an algorithm. Punycode is not reversible, but its use can be restricted to codepoints in turn permitting it to perform reversibly. 1. "UTF-8 [RFC3629] is a mechanism for encoding a Unicode character in a variable number of 8-bit octets, where an ASCII character is preserved as-is." Characters belong to scripts that may or may not be supported by ASCII and Unicode encoding tables. 1.1. "When used with a DNS resolver library, IDNA is inserted as a "shim" between the application and the resolver library": that shim should be located in Figure 2. 1.1. "Again this assumes that ASCII names never start with "xn--", and also that UTF-8 strings never contain an ESC character". It may be worth documenting whether "IDN", "names", "labels", and "strings" are or are not the same thing. 2. "Applications that convert an IDN to Punycode before calling getaddrinfo() will result in name resolution failures if the Punycode name is directly used in such protocols. " Why? Is that not actually due to the reason that was given in 3? "Applications that convert an IDN to Punycode before calling getaddrinfo() will result in name resolution failures if the name is actually registered in a private name space in some other encoding (e.g., UTF-8)." 3. "While implementations of the DNS protocol must not place any restrictons on the labels that can be used, applications that use the DNS are free to impose whatever restrictions they like, and many have." Wouldn't these two rules contradict the proposed WG-IDNABIS charter change? Wouldn't they permit the support of cases such as Tatweel, Tamil figures, and French majuscules? 3.4. "The DNS resolver will append suffixes in the suffix search list". Where is the "suffix search list" documented? 4. "even when DNS is used, the conversion to Punycode should be done only by an entity that knows which name space will be used." Fundamental. Yet, this is not considered by IDNA rationale or protocol. 4.1. "Indeed the choice of conversion within the resolver libraries is consistent with the quote from [RFC3490] section 6.2 stating that Punycode conversion "might be performed inside these new versions of the resolver libraries". - "the recommendation is that a resolver library be more liberal in what it would accept from an application would mean that such a name would be accepted and re-encoded as needed". These recommended architectures (such as ML-DNS) are not considered in the IDNA rationale. Will IDNA be interoperable with these recommended architectures? 4. "encoding conversion between Punycode and UTF-8 is unambiguous". (?). This could lead to stabilization through punycode and A-labels, in turn making A-labels the DNS referent entry for UTF support? 5. Security considerations. This kind of consideration is already posing a problem for TM protection. This is the "Babel Names" case. This occurs when someone trademarks the U-label corresponding to a protected Roman script TM. When that U-label displays under its ASCII label form, it infringes on the Roman script TM rights. Ex.: "xn--coca-cola" or "xn--vint-cerf". jfc morfin From eblanconil@gmail.com Sat Aug 29 16:49:21 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3D03A659B for ; Sat, 29 Aug 2009 16:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[AWL=-1.783, BAYES_05=-1.11, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ncjhwnDCBta for ; Sat, 29 Aug 2009 16:49:21 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id A607A3A67EC for ; Sat, 29 Aug 2009 16:49:17 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e21so227228fga.13 for ; Sat, 29 Aug 2009 16:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=y6t0uzqnFMJ+Y5kWxZTlgKe/3wponkwJ9x9ZmdJfr9k=; b=fwPELReBACqSE3iOWEQA3NOIEXzdaCAbyvJ3VB3Lc2Luw04cXN/gfx//oT44kjqqO1 /LFkGhabTxxuSzd5198XZpCrukyJXudRZWBXc57vuAMd80WtU5+b2vS3xtByMi98pm7N hqQGPzhMzeZnrR76ZEhei5wHu0DVymQ56UDo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Z+oOBMKyYgK5OUX71pZmodVr21VHfLkpqILYBR8jEE0R8dXbb0Sh+Qn3TELYlez7rj VgunfBszOszOZBWW0Y5TaBlj8++lCA9B9HzLh3vA9c0WboWLLIuRALFn9/LIa/fxs3wr vOpujTnk4jvcphlllQiTTHGaGahzCHp2bx8Uo= MIME-Version: 1.0 Received: by 10.239.139.134 with SMTP id t6mr286202hbt.12.1251589760284; Sat, 29 Aug 2009 16:49:20 -0700 (PDT) Date: Sun, 30 Aug 2009 01:49:20 +0200 Message-ID: <6589127a0908291649s6e2b0d61o3c599784dfa113bd@mail.gmail.com> From: Elisabeth Blanconil To: Vint Cerf Content-Type: text/plain; charset=ISO-8859-1 Cc: idna-update@alvestrand.no, internet users contributing group Subject: [iucg] WG/IDNABIS LC X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 29 Aug 2009 23:49:21 -0000 Dear Vint, The IDNA is a key issue for the IUCG as a paradigm for the future of the Internet. This is why we invested much in it. There is therefore a need to make sure its description document set reflects a complete IETF and users consensus. To help this, we keep track of the WG-IDNABIS/LC requested and received answers. The IAB Draft on IDN has been added because some of some aspects which are important to the background and to the future of the Multilingual Internet. As you know we collectively carry this work in maintening an updated wiki page at http://wikidna.org/index.php?title=WG-IDNA_LC. We plan to publish it as an Internet Draft at the end of the Last Call, to (1) help the final smithing of its document set and (2) show the consensus (it will be introduced by JFC) over the achieved texts before the IETF/LC. Would it be better introduced as an independent submission or as a WG document? Best regards. Elisabeth Blanconil From vint@google.com Sat Aug 29 19:06:41 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492DF3A68A7 for ; Sat, 29 Aug 2009 19:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO8fGhNkAQFg for ; Sat, 29 Aug 2009 19:06:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id F10CD3A67A6 for ; Sat, 29 Aug 2009 19:06:39 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id n7U26jxh022196 for ; Sun, 30 Aug 2009 03:06:45 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1251598005; bh=YaMHlHG7D8d1y8+Ncdgkcje/Sgk=; h=DomainKey-Signature:Cc:Message-Id:From:To:In-Reply-To: Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date: References:X-Mailer:X-System-Of-Record; b=L8P2S5Vu66NNX33nWMF1Y3h3 k/WX61qncMt0V7OIufL6GrzgzXtH1ia3aPYcfxq+i1SikBO1tq0etmsRRaR1Uw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=cc:message-id:from:to:in-reply-to:content-type: content-transfer-encoding:mime-version:subject:date:references:x-mailer:x-system-of-record; b=nvoQiQuqgKMy2Ao7zvwGBYIn4znE4oUDeI/NcmXGkvOG4BkPruZSjfhte3ecP/eeJ gDWqxDmz7dDUk8p5WEHbQ== Received: from qw-out-2122.google.com (qwi5.prod.google.com [10.241.195.5]) by wpaz13.hot.corp.google.com with ESMTP id n7U26fbo023417 for ; Sat, 29 Aug 2009 19:06:42 -0700 Received: by qw-out-2122.google.com with SMTP id 5so765127qwi.39 for ; Sat, 29 Aug 2009 19:06:41 -0700 (PDT) Received: by 10.224.91.131 with SMTP id n3mr2271008qam.369.1251598001570; Sat, 29 Aug 2009 19:06:41 -0700 (PDT) Received: from ?10.0.1.3? (static-72-66-6-47.washdc.fios.verizon.net [72.66.6.47]) by mx.google.com with ESMTPS id 22sm1249558qyk.2.2009.08.29.19.06.31 (version=SSLv3 cipher=RC4-MD5); Sat, 29 Aug 2009 19:06:38 -0700 (PDT) Message-Id: <012DF8CE-CB29-4803-B65A-06AC570D0E2B@google.com> From: Vint Cerf To: Elisabeth Blanconil In-Reply-To: <6589127a0908291649s6e2b0d61o3c599784dfa113bd@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 29 Aug 2009 22:06:27 -0400 References: <6589127a0908291649s6e2b0d61o3c599784dfa113bd@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-System-Of-Record: true Cc: idna-update@alvestrand.no, internet users contributing group Subject: Re: [iucg] WG/IDNABIS LC X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 30 Aug 2009 02:06:41 -0000 Elisabeth, you are free to publish as an independent Internet Draft but not as a working group document. The working group is near finalization of all documents currently produced under the current charter. As Paul points out, we are about to forward the final documents to the Area Director with the request to carry them forward as a set of RFCs. During the IETF last call, assuming the IESG approves our final documents, you are free to make reference to your I-D vint On Aug 29, 2009, at 7:49 PM, Elisabeth Blanconil wrote: > Dear Vint, > > The IDNA is a key issue for the IUCG as a paradigm for the future of > the Internet. This is why we invested much in it. There is therefore a > need to make sure its description document set reflects a complete > IETF and users consensus. To help this, we keep track of the > WG-IDNABIS/LC requested and received answers. The IAB Draft on IDN has > been added because some of some aspects which are important to the > background and to the future of the Multilingual Internet. > > As you know we collectively carry this work in maintening an updated > wiki page at http://wikidna.org/index.php?title=WG-IDNA_LC. We plan to > publish it as an Internet Draft at the end of the Last Call, to (1) > help the final smithing of its document set and (2) show the consensus > (it will be introduced by JFC) over the achieved texts before the > IETF/LC. Would it be better introduced as an independent submission or > as a WG document? > > Best regards. > Elisabeth Blanconil From eblanconil@gmail.com Sun Aug 30 15:35:07 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84AD3A6CD2 for ; Sun, 30 Aug 2009 15:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_20=-0.74, GB_I_LETTER=-2, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqHFzgDNR6qi for ; Sun, 30 Aug 2009 15:35:06 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 5B7393A6835 for ; Sun, 30 Aug 2009 15:35:06 -0700 (PDT) Received: by fxm17 with SMTP id 17so2468013fxm.37 for ; Sun, 30 Aug 2009 15:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QvSIgFx6xl72vrkCwbYapKlufr04D3KcUvX4ycJfHcY=; b=Q3Cj1T+0OO4As98CvZFKhqKSk8Ia/aKjdxNYVnHiARHMbmrlySDy1tCFnmWI3eZCzZ VIDo2RbUvxxgl7uavIq/8CFiZoBKFy0F2okFbt8LZajN2Ao83mIbX8Taw75787cfv3iC mo8LrkC4w+LcBJ+AaTJOJ4MyZWUU9f0oDlOwo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Did5Xku32wfkdiZRRiVFcKTtohfmngNfKIaR333dvwwulfxLM81/lVif9uGPWypBmx IkGFDdrG8/w5oIozrpj0HNbFL06bNIhzKAWIrJ+cnNtPXHjyPTWQCUAIhHp6I5tdwpxe gu5iDp//ELsjRMhjCsjRQJtEwjyVJIeeKTi+Q= MIME-Version: 1.0 Received: by 10.239.138.34 with SMTP id n34mr294419hbn.64.1251671709259; Sun, 30 Aug 2009 15:35:09 -0700 (PDT) In-Reply-To: <2c74643b0908301122l4574d4acoc68f36a8576adf04@mail.gmail.com> References: <20090825032439.GF3180@shinkuro.com> <2c74643b0908301122l4574d4acoc68f36a8576adf04@mail.gmail.com> Date: Mon, 31 Aug 2009 00:35:09 +0200 Message-ID: <6589127a0908301535pd47fdb2y4bafc36d163716ef@mail.gmail.com> From: Elisabeth Blanconil To: Wil Tan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Andrew Sullivan , idna-update@alvestrand.no, John C Klensin , internet users contributing group , lisa Dusseault Subject: Re: [iucg] Comments on draft-ietf-idnabis-defs-10 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 30 Aug 2009 22:35:07 -0000 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. "(ii) A change to the ACE prefix from "xn--" -> you now propose a change from "xn--" to "$$--" "(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. 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. 2. either the Charter (modified or not?) is respected and we make (i), (ii) and (iii) an issue for the IETF/LC. 3. or we face an IETF process and architectural conflict that will probably resolve at network clients level. 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 : > > > On Sat, Aug 29, 2009 at 5:17 PM, John C Klensin wrote: >> >> --On Monday, August 24, 2009 23:24 -0400 Andrew Sullivan >> 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 =A72.3.2.1: >> >... >> >> These changes, with Paul's suggested modifications, have been >> tentatively accepted and incorporated in the document. =A0Anyone >> who objects should say so quickly. >> > > I posted a comment related to the definition of A-label some time ago, bu= t > the thread was > digressed:=A0http://www.alvestrand.no/pipermail/idna-update/2009-June/004= 558.html > The issue is with case variants of A-labels. By DNS rules, as mentioned i= n > 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 hav= e > been uppercased, the Punycode decoding algorithm (due to its mixed-case > annotation feature) may produce invalid U-label because the ASCII charact= ers > will be in capital letter form. > =3Dwil > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > > From jmabdp@gmail.com Sun Aug 30 17:15:03 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F06E3A6A8D for ; Sun, 30 Aug 2009 17:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PvSR+daNPH3 for ; Sun, 30 Aug 2009 17:15:02 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by core3.amsl.com (Postfix) with ESMTP id 9DACF3A6AFC for ; Sun, 30 Aug 2009 17:15:02 -0700 (PDT) Received: by ywh4 with SMTP id 4so7149160ywh.17 for ; Sun, 30 Aug 2009 17:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=e+k3iWPAGPyjWkd+pNvHGB3eypYbQSGO5IakjJYSo5Q=; b=FtLDeoUhbEDXoErDGHVGjiyyujBuNkvoaCQIbdHKixBTEbLote1qh3mowKzVCyjx6k UEM36t+BtZicnAbSNa2Yze/JU/lzJ2HXkkyv8/oXf6SfwTP4OpY6J0Z3+Pd30+1xyFed sQ42SljYf11fImHThgRPo4XoIp/QQHp2VVDxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Bk+r39i/Sk3a0diE4VxeaRNBhJoOWAT3Vs+B1u8wOZLbByofxsN6tC4BKihnEYN7HM LCNStkgGm8obj7DFW261T+n+q4Tk8VCLaEw/Um+QGiHMCwg6uKP/YtYzjuqDRXfgawDT 0qLSz4xeEloXyYTZc6TAfqgsBkdX/MFriWMeg= MIME-Version: 1.0 Received: by 10.150.47.12 with SMTP id u12mr6542630ybu.332.1251677707647; Sun, 30 Aug 2009 17:15:07 -0700 (PDT) In-Reply-To: <6589127a0908301535pd47fdb2y4bafc36d163716ef@mail.gmail.com> References: <20090825032439.GF3180@shinkuro.com> <2c74643b0908301122l4574d4acoc68f36a8576adf04@mail.gmail.com> <6589127a0908301535pd47fdb2y4bafc36d163716ef@mail.gmail.com> Date: Mon, 31 Aug 2009 02:15:07 +0200 Message-ID: <6aad7a210908301715w7ab2f0a9q49e3d782a8f94d2d@mail.gmail.com> From: jean-michel bernier de portzamparc To: internet users contributing group Content-Type: multipart/alternative; boundary=000e0cd70e0c233d0d047264ed69 Cc: Wil Tan , Andrew Sullivan , idna-update@alvestrand.no, lisa Dusseault , John C Klensin Subject: Re: [iucg] Comments on draft-ietf-idnabis-defs-10 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 00:15:03 -0000 --000e0cd70e0c233d0d047264ed69 Content-Type: text/plain; charset=ISO-8859-1 Elisabeth, you only consider the formal aspects. Technically, 2009/8/31 Elisabeth Blanconil > "(i) A change to the "punycode" algorithm or to the ACE approach to > encoding names in the DNS." > -> this is now what you propose. > this is something we could support if it helped majuscules support. "(ii) A change to the ACE prefix from "xn--" > -> you now propose a change from "xn--" to "$$--" > this is something wich is not Internet specific and we need to see organised at a multilingual digital ecosystem adminance level (ISO?). > "(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)" > we said we did not object that change. If independence (i.e. net neutrality) remains the ultimate objective. Portzemparc an IETF user --000e0cd70e0c233d0d047264ed69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Elisabeth,
you only consider the formal aspects. Technically,

2009/8/31 Elisabeth Blanconil <= ;eblanconil@gmail.com>
"(i) A change to the "punycode" algorithm or to the ACE appr= oach to
encoding names =A0in the DNS."
-> this is now what you propose.

this is someth= ing we could support if it helped majuscules support.

"(ii) A change to the ACE prefix from "xn--"
-> you now propose a change from "xn--" to "$$--"

this is something wich is not Internet specific and = we need to see organised at a multilingual digital ecosystem adminance leve= l (ISO?).
=A0
"(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)"

we sai= d we did not object that change. If independence (i.e. net neutrality) rema= ins the ultimate objective.

Portzemparc
an IETF user

--000e0cd70e0c233d0d047264ed69-- From jmabdp@gmail.com Sun Aug 30 19:51:10 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE3CB28C138 for ; Sun, 30 Aug 2009 19:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdHowW8lVhTQ for ; Sun, 30 Aug 2009 19:51:09 -0700 (PDT) Received: from mail-yx0-f176.google.com (mail-yx0-f176.google.com [209.85.210.176]) by core3.amsl.com (Postfix) with ESMTP id 8AB933A6B25 for ; Sun, 30 Aug 2009 19:51:09 -0700 (PDT) Received: by yxe6 with SMTP id 6so704563yxe.32 for ; Sun, 30 Aug 2009 19:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Bj9lNxvnFItnAgYKrzoCS5awRU3f3hTqYE1n3+CcyBM=; b=wsqCDp/tkrK331WNszSHkRMDpFMeAuO80NceuAzNPSjRnGHa0lMpBGUaA7z5orFI/g PFjlbzV2nfqv4SJcsE953WxReT1u1ftixo9kiL14ai/4680bRqlun7Ny0G2YY3K2MtS1 xKBgxexHukOp2Fo8OJdsbYHEKFaB6bMPy8mzc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OgyYPkHoycLEZv6ii2O1Oc/pHKCOpveTh33qKBchAeZXQkH4nM3P4icKp/2kgwE+og uiGwnO4EyLhngw88Eg/0032gejsTN4URVra+8E4lpVhysD1TkyYLBISud3g10L28vYLP hmvTqC8eIyp1vfynT1j/UUSvRc+UO3Tdnv60o= MIME-Version: 1.0 Received: by 10.150.45.15 with SMTP id s15mr8131040ybs.107.1251687076899; Sun, 30 Aug 2009 19:51:16 -0700 (PDT) In-Reply-To: References: <20090825032439.GF3180@shinkuro.com> <2c74643b0908301122l4574d4acoc68f36a8576adf04@mail.gmail.com> <6589127a0908301535pd47fdb2y4bafc36d163716ef@mail.gmail.com> <6aad7a210908301908n1f19691dvc1c36843e763a449@mail.gmail.com> Date: Mon, 31 Aug 2009 04:51:16 +0200 Message-ID: <6aad7a210908301951j4e2c9795tce70fc29691da542@mail.gmail.com> From: jean-michel bernier de portzamparc To: Paul Hoffman Content-Type: multipart/alternative; boundary=000e0cd3308e96ac690472671b0c Cc: idna-update@alvestrand.no, internet users contributing group Subject: Re: [iucg] Comments on draft-ietf-idnabis-defs-10 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 02:51:10 -0000 --000e0cd3308e96ac690472671b0c Content-Type: text/plain; charset=ISO-8859-1 2009/8/31 Paul Hoffman > At 4:08 AM +0200 8/31/09, jean-michel bernier de portzamparc wrote: > >I think I would support your proposition, but I am not sure I understand > "A pair of A-labels MUST be compared using a case-preserving comparison.". > > A comparison between xn--Axdf and xn--axdf would yield "not matched". > Here is where I dont understand. This violates the DNS context. DNS comparison rules MUST apply because A-labels are whole ASCII labels. > >Moreover, the way you phrase it seems to integrate the case-preservation > in the protocol, i.e. in the ACE and not to keep it as a part of its use? > > Uppercase characters are not allowed in the U-labels anyway, so there is no > reason to keep them in the A-labels. > Uppercase characters are supported but not used by ASCII Domain Name. Once ASCII I do not see why there would be a difference based upon the origin (how do a non-IDNA aware system would know it?). > >The rule proposed by Andrew Sullivan seems quite systematic and clear? > > > >1. The encoding of A-label1 according to [RFC3492] results in U-label1. > >2. The decoding of U-label2 according to [RFC3492] results in A-label2. > >3. A-label1 is equivalent to A-label2 according to DNS matching rules for > labels. > >4. U-label1 is bistring equivalent to U-label2. > > Well, no one spoke up for it. Personally, I find the introduction of > A-label2 and U-label2 out of thin air to be confusing. > Well, it is the same as the present text, but clearer. It appeals to me by its usual scientific approach. The point is that you seem to disagree with the rule 3. I did not realise that before using that presentation. It shows it well. >We felt it addressed our point "References to the lower/uppercase image > can be understood by DNS old-timers, but is confusing to newcomers, as it > does not reflect the same functionality and because U-label/A-label > lower/uppercase treatment is not the same." since everyone knows that > punycode is case preserving. > > I figure it is easier to remove the comparisons to regular-style DNS > mapping than to try to show the differences. > This is not where we saw the problem. We saw it in an explanation using a non yet fully accepted image by a non-specialist. And a confusion between upper-cases in Ascii and Unicode. We are users, not much interested in the black-magic if we can. We just want: (1) in real life use no more constraint IRT upper-cases than in ASCII English. (2) IDNA2008 is case insenstive, but we need to have it majuscule sensitive. We have no real problem with these needs if the ASCII rule is the same in every case, i.e. XN--ABC-DEF is the same as xn--abc-def. This is what we understand as the protocol (on the wire) part. What the applications can do ("IDNA2008 should prohibit upper-case characters as input even though user interfaces to applications should probably map those characters"), i.e. "post-wire" is another different non-ACE but ACE-use story. Or did I misunderstand the whole thing? Portzamparc an IETF user --000e0cd3308e96ac690472671b0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/8/31 Paul Hoffman <phoffman@imc.org>
At 4:08 AM +0200 8/31/09, jean-michel bernier de portzamp= arc wrote:
>I think I would support your proposition, but I am not sure I understan= d =A0"A pair of A-labels MUST be compared using a case-preserving comp= arison.".

A comparison between xn--Axdf and xn--axdf would yield "not matc= hed".

Here is where I dont understand. This v= iolates the DNS context. DNS comparison rules MUST apply because A-labels a= re whole ASCII labels.
=A0
>Moreover, the way you phrase it seems to integrate the case-preservatio= n in the protocol, i.e. in the ACE and not to keep it as a part of its use?=

Uppercase characters are not allowed in the U-labels anyway, so there= is no reason to keep them in the A-labels.

Upperc= ase characters are supported but not used by ASCII Domain Name. Once ASCII = I do not see why there would be a difference based upon the origin (how do = a non-IDNA aware system would know it?).
=A0
>The rule proposed by Andrew Sullivan seems quite systematic and clear?<= br> >
>1. The encoding of A-label1 according to [RFC3492] results in U-label1.=
>2. The decoding of U-label2 according to [RFC3492] results in A-label2.=
>3. A-label1 is equivalent to A-label2 according to DNS matching rules f= or labels.
>4. U-label1 is bistring equivalent to U-label2.

Well, no one spoke up for it. Personally, I find the introduction of = A-label2 and U-label2 out of thin air to be confusing.

Well, it is the same as the present text, but clearer. It appeals to m= e by its usual scientific approach.=A0 The point is that you seem to disagr= ee with the rule 3. I did not realise that before using that presentation. = It shows it well.

>We felt it addressed our point "References to the lower/uppercase = image can be understood by DNS old-timers, but is confusing to newcomers, a= s it does not reflect the same functionality and because U-label/A-label lo= wer/uppercase treatment is not the same." since everyone knows that pu= nycode is case preserving.

I figure it is easier to remove the comparisons to regular-style DNS = mapping than to try to show the differences.

This = is not where we saw the problem. We saw it in an explanation using a non ye= t fully accepted image by a non-specialist. And a confusion between upper-c= ases in Ascii and Unicode. We are users, not much interested in the black-m= agic if we can. We just want:

(1) in real life use no more constraint IRT upper-cases than in ASCII E= nglish.
(2) IDNA2008 is case insenstive, but we need to have it majusc= ule sensitive.

We have no real problem with these needs if the ASCI= I rule is the same in every case, i.e. XN--ABC-DEF is the same as xn--abc-d= ef. This is what we understand as the protocol (on the wire) part. What the= applications can do ("IDNA2008 should prohibit upper-case characters = as input even though user interfaces to applications should probably map those characters")= , i.e. "post-wire" is another different non-ACE but ACE-use story= .

Or did I misunderstand the whole thing?

Portzamparc
an IETF user


--000e0cd3308e96ac690472671b0c-- From vint@google.com Sun Aug 30 20:37:53 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0899128C156 for ; Sun, 30 Aug 2009 20:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.299 X-Spam-Level: X-Spam-Status: No, score=-107.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDEoTkWt7gGI for ; Sun, 30 Aug 2009 20:37:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 353C128C153 for ; Sun, 30 Aug 2009 20:37:50 -0700 (PDT) Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id n7V3c0ZR010159 for ; Sun, 30 Aug 2009 20:38:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1251689880; bh=OYkO4MInDAtGB3+O4h2jbWCoYyY=; h=DomainKey-Signature:From:MIME-Version:X-Mailer:Thread-Index:Date: Message-ID:Subject:To:Cc:Content-Type:Content-Transfer-Encoding: X-System-Of-Record; b=EZ1T4F33XIF0DkF1RPDke+PbVCUp02ouWy3gMsZUpLqx wERQ4VrIyjejaFfvXbWq8GHL++WZI6DwPMWQFzJwlA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=from:mime-version:x-mailer:thread-index:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=wKZDeKgqlsJonwHxxzlzMMEVDrDB4xhxgyB0CiWp068IqSqUqDNElzQkHtVrgaJWv xVLablglt1LigcgGGJwIA== Received: from gxk7 (gxk7.prod.google.com [10.202.11.7]) by zps18.corp.google.com with ESMTP id n7V3bvqS003810 for ; Sun, 30 Aug 2009 20:37:57 -0700 Received: by gxk7 with SMTP id 7so5228593gxk.8 for ; Sun, 30 Aug 2009 20:37:56 -0700 (PDT) From: Vint Cerf MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acopwix4lmMM8/AfTuCSVQQ6SMYHewAKkEJf Date: Sun, 30 Aug 2009 23:37:55 -0400 Received: by 10.150.76.6 with SMTP id y6mr8168244yba.60.1251689876900; Sun, 30 Aug 2009 20:37:56 -0700 (PDT) Message-ID: <41e4801ca29ec$6d8788a0$489699e0$@com> To: eblanconil@gmail.com, wil@cloudregistry.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: ajs@shinkuro.com, klensin@jck.com, idna-update@alvestrand.no, iucg@ietf.org, lisa.dusseault@gmail.com Subject: Re: [iucg] Comments on draft-ietf-idnabis-defs-10 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 03:37:53 -0000 No I did not propose a change. I used these characters to mean that anythin= g with "--" in the third and fourth character positions on the wire are reserved strings. V ----- Original Message ----- From: idna-update-bounces@alvestrand.no To: Wil Tan Cc: Andrew Sullivan ; idna-update@alvestrand.no ; John C Klensin ; internet users contributing group ; lisa Dusseault Sent: Sun Aug 30 18:35:09 2009 Subject: Re: Comments on draft-ietf-idnabis-defs-10 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. "(ii) A change to the ACE prefix from "xn--" -> you now propose a change from "xn--" to "$$--" "(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. 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. 2. either the Charter (modified or not?) is respected and we make (i), (ii) and (iii) an issue for the IETF/LC. 3. or we face an IETF process and architectural conflict that will probably resolve at network clients level. 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 : > > > On Sat, Aug 29, 2009 at 5:17 PM, John C Klensin wrote: >> >> --On Monday, August 24, 2009 23:24 -0400 Andrew Sullivan >> 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 =A72.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, bu= t > 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 i= n > 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 hav= e > 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. > =3Dwil > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > > _______________________________________________ Idna-update mailing list Idna-update@alvestrand.no http://www.alvestrand.no/mailman/listinfo/idna-update From eblanconil@gmail.com Mon Aug 31 02:54:21 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619D13A6DA7 for ; Mon, 31 Aug 2009 02:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXLlN71lO-aU for ; Mon, 31 Aug 2009 02:54:20 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 14A433A6DC9 for ; Mon, 31 Aug 2009 02:52:10 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e21so406357fga.13 for ; Mon, 31 Aug 2009 02:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MGBggWNB1J4EvNH5D8B11oiZQ25gexF7xLZKYOLtNyc=; b=noLMcWpxU8pznc0rJ5OYp5U7n5Ws+KTElq7O11cy2sBfEQwdtoaRibnqKGpHrY30NE 8LmANIXH0ezT9fYOiSUfRX2GEsW6pD9X4qyE/MOWwDlhGcpdnqPMzsdJM4ent9uSJek4 kQNGpaBzZtiqEDWcyGz/wDU6NAinersM3vTH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=stl12UAenBXOjTMG26FwkcCVXBB6OPp/8N7F8a+Kv9ODki1sJ16GxuwMIu66kqdaPl 41OpQiulB5SlwrtspSmXR5e3FGcEAyBY/H3YDCeu9+zmnucISHLWQa+r5k9cZQ3VKwuR PcyIXZads4uhyFeKkPvjSh3Cpg9P8adxh+0Jw= MIME-Version: 1.0 Received: by 10.239.183.23 with SMTP id s23mr407654hbg.56.1251712340557; Mon, 31 Aug 2009 02:52:20 -0700 (PDT) In-Reply-To: <41e4801ca29ec$6d8788a0$489699e0$@com> References: <41e4801ca29ec$6d8788a0$489699e0$@com> Date: Mon, 31 Aug 2009 11:52:20 +0200 Message-ID: <6589127a0908310252p5ba87aa4nfae56d88679ae29c@mail.gmail.com> From: Elisabeth Blanconil To: Vint Cerf Content-Type: text/plain; charset=ISO-8859-1 Cc: wil@cloudregistry.net, ajs@shinkuro.com, idna-update@alvestrand.no, iucg@ietf.org, lisa.dusseault@gmail.com, klensin@jck.com Subject: Re: [iucg] Comments on draft-ietf-idnabis-defs-10 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 09:54:21 -0000 2009/8/31 Vint Cerf : > No I did not propose a change. I used these characters to mean that anything > with "--" in the third and fourth character positions on the wire are > reserved strings. V Dear Vint, Sorry, but obviously you did. Elliptic or not: - This WG is chartered to deal with "xn--". Dealing with "00--" to "zz--", is a change indeed. - The same as imposing lowercases to punycode is a change in the punycode algorithm and/or ACE (impact on UTF-8 conversion?). - The same as declaring invalid some domain names because of the way they are written is a change in the ACE and DNS - The same as mapping some characters (unicodepoints?) requires the charter change you requested. Wil is right: the whole thing does not stand well. We all know that. We can be incremental, disruptive, messy or smart about it. We should stay on our incremental tack. And be smart further on (interplus). Disruptive changes on this last working minutes is messy. There are plenty of pending issues which have not been addressed yet (except by Harald) at http://wikidna.org/index.php?title=WG-IDNA_LC. I wish we are done with IDNA2008 and get it published in 2010, before I am a grand-mother. Elisabeth Blanconil From klensin@jck.com Mon Aug 31 03:01:50 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B875E3A6A7C for ; Mon, 31 Aug 2009 03:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VF1n2N+1g2+i for ; Mon, 31 Aug 2009 03:01:49 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 8CF553A6DBD for ; Mon, 31 Aug 2009 03:01:49 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Mi3hs-0009vQ-Es; Mon, 31 Aug 2009 06:01:48 -0400 Date: Mon, 31 Aug 2009 06:01:47 -0400 From: John C Klensin To: Elisabeth Blanconil , Vint Cerf Message-ID: In-Reply-To: <6589127a0908310252p5ba87aa4nfae56d88679ae29c@mail.gmail.com> References: <41e4801ca29ec$6d8788a0$489699e0$@com> <6589127a0908310252p5ba87aa4nfae56d88679ae29c@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: wil@cloudregistry.net, ajs@shinkuro.com, idna-update@alvestrand.no, iucg@ietf.org, lisa.dusseault@gmail.com Subject: Re: [iucg] Comments on draft-ietf-idnabis-defs-10 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 10:01:50 -0000 --On Monday, August 31, 2009 11:52 +0200 Elisabeth Blanconil wrote: >... > Elliptic or not: > > - This WG is chartered to deal with "xn--". Dealing with > "00--" to "zz--", is a change indeed. No, the WG is chartered to deal with IDNA. We are not proposing to use those prefixes, only to impose a condition on their use for IDNA-aware applications. That condition (or some very small variation on it) has been in the documents since almost the time the WG started. > - The same as imposing lowercases to punycode is a change in > the punycode algorithm and/or ACE (impact on UTF-8 > conversion?). No one has proposed changing Punycode, although it has been tempting. As I noted, both the ToASCII operation of IDNA2003 and the operations of IDNA2008 produce lower-case from the Punycode algorithm. Under IDNA2003, if someone later mixes the cases, the internal Stringprep processing causes the anomaly now under discussion to be eliminated. The question is how to prevent the anomaly under some edge cases in IDNA2008 and preserve the existing behavior. - The same as declaring invalid some domain > names because of the way they are written is a change in the > ACE and DNS Unless you are referring to a case I can't think of right now, this is not being done. > - The same as mapping some characters (unicodepoints?) > requires the charter change you requested. > Wil is right: the whole thing does not stand well. We all know > that. We can be incremental, disruptive, messy or smart about > it. We should stay on our incremental tack. And be smart > further on (interplus). Disruptive changes on this last > working minutes is messy. There are plenty of pending issues > which have not been addressed yet (except by Harald) at > http://wikidna.org/index.php?title=WG-IDNA_LC. I wish we are > done with IDNA2008 and get it published in 2010, before I am a > grand-mother. Regardless of your intentions, your behavior pattern is not advancing things. john From jefsey@jefsey.com Mon Aug 31 09:02:30 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BA33A69B2 for ; Mon, 31 Aug 2009 09:02:30 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char FC hex): Cc: ...nkuro.com>,\n "Martin J. D\374rst" ; Mon, 31 Aug 2009 09:02:30 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 2E93A3A67C0 for ; Mon, 31 Aug 2009 09:02:30 -0700 (PDT) Received: from 42.78.206-77.rev.gaoland.net ([77.206.78.42]:2647 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Mi9Kz-0007ty-GF; Mon, 31 Aug 2009 09:02:34 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 31 Aug 2009 17:56:55 +0200 To: internet users contributing group From: jefsey In-Reply-To: References: <41e4801ca29ec$6d8788a0$489699e0$@com> <6589127a0908310252p5ba87aa4nfae56d88679ae29c@mail.gmail.com> 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: Message-Id: <20090831160230.2E93A3A67C0@core3.amsl.com> Cc: Andrew Sullivan , Patrik Fltstrm , Pete Resnick , lisa.dusseault@gmail.com, John C Klensin , "Martin J. Drst" , Vint Cerf Subject: [iucg] Repel Boarders Stations :-) ! X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 16:02:31 -0000 Dear all, we are now a few hours before the closing of the WG-IDNABIS/LC. We known that the current confusion attempt would be tried by Wil Tan, and for which reasons. I certainly support what you have said so far on the WG list. However, I urge you not to increase the confusion. This is pure tactics. We all know by who and why (Wikipedia speaks up!), for many years. We have, from the very begining, only one question we first asked Vint: what are the Chair's real targets? He initially sided with the answers prompted by James Seng, what dismayed some people. Today he has to formaly take side in forwarding a document set violating the Charter or not (sorry, John, but it might as we [or big others] may ask the IESG and IAB to confirm). We decided to support the current version of the document set, because of the reasonable technical positions of people in copy. For that reason I asked you to delay the interplus documentation so we could possibly amalgamate/build upon IDNA what is our ultimate target for the Intersem. We will review this next week (I might be back in Versailles only on Tuesday). Decision rests with the Chair. Have a good interesting day. jefsey PS. For information of some people in CC who may ignore it: I think that DNS LDH is a blessing for internationalization/multilingualization robustness. I have no problem at all with Vixie's proposition as I think it would definitly protect us from upper/lowercase/majuscule confusion in making clear they are two different and orthogonal issues (this was not my initial position). From mfberny@gmail.com Mon Aug 31 13:20:58 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1469B28C561 for ; Mon, 31 Aug 2009 13:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrNCsFlu6hNa for ; Mon, 31 Aug 2009 13:20:57 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 187A028C560 for ; Mon, 31 Aug 2009 13:20:56 -0700 (PDT) Received: by ewy3 with SMTP id 3so882048ewy.42 for ; Mon, 31 Aug 2009 13:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cpMXH9PuNE68JY3Oezt4jFs1ym18sKAa6Z7zBdT5zQQ=; b=LZ7a+kXd2aGgozWegvMj/4h7MSx3eZY+NavVTytAjKkg622OUI9CcXTM9n4FUAvz0/ MoZ7hXbpuj5nycCOIUnOFIhJ+AK6/Jgmya9XXG0VqrsmJKR0r+ZGcDPmaQM53gnHInr3 f0BkvVkiEM/K9EsRuYtLfYXB4MB4jz1bG7hGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DKabYV8gz5fbIdZeU/Z35N60EEm53VT4x7fkDbOzbHlJAl3VHCqCDUUDtuqU2VcI3/ 9NUDH9oNZVsrCJslkYGSttDtDsopzzB7gw9nXG7Uab/kjmCSiFhzTTVZqUwWvlX4V/Fq 5CoBnjOljbbyKCSr5mxgdDMofJ9GlDZ5GfleU= MIME-Version: 1.0 Received: by 10.210.133.12 with SMTP id g12mr4937244ebd.56.1251750062986; Mon, 31 Aug 2009 13:21:02 -0700 (PDT) In-Reply-To: <58ee45520906281534m33aa336dg511837997367fc63@mail.gmail.com> References: <58ee45520906281534m33aa336dg511837997367fc63@mail.gmail.com> Date: Mon, 31 Aug 2009 22:21:02 +0200 Message-ID: <58ee45520908311321k32f7754cx71597d98ef25f0ca@mail.gmail.com> From: Marie-France Berny To: Wil Tan Content-Type: multipart/alternative; boundary=0015174bee78da29eb047275c54d Cc: idna-update@alvestrand.no, iucg@ietf.org Subject: Re: [iucg] Punycode Mixed-case annotation X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2009 20:20:58 -0000 --0015174bee78da29eb047275c54d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Wil, May be time for you now to answer my June 26th mail? This might help to better analyse your suggestions and all the comments of the day? Marie-France Berny 2009/6/29 Marie-France Berny > Dear William Tan, > I am afraid I am quite confused by this burst of technical ping pong with > Vint who wants mapping at protocol level. > > I just want to know how: > > - ecole.fra > - =E9cole.fra > - Ecole.fra > > These are three French orthotypographies of three different semantics whi= ch > may relate to three different IP addresses. How do you propose to support > them ? > Thank you. > > Marie-France Berny > --0015174bee78da29eb047275c54d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Wil,
May be time for you now to answer my June 26th mail? This migh= t help to better analyse your suggestions and all the comments of the day? =

Marie-France Berny

2009/6/29 Mari= e-France Berny <m= fberny@gmail.com>
Dear William Tan,=
I am afraid I am quite confused by this burst of technical ping pong wi= th Vint who wants mapping at protocol level.

I just want to know how:

- ecole.fra
- =E9cole.fra
- Ecole= .fra

These are three French orthotypographies of three different semantics w= hich may relate to three different IP addresses. How do you propose to supp= ort them ?
Thank you.

Marie-France Berny


--0015174bee78da29eb047275c54d-- From klensin@jck.com Mon Aug 31 17:12:32 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0693A6BBE for ; Mon, 31 Aug 2009 17:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INu1f8hE+Nt8 for ; Mon, 31 Aug 2009 17:12:31 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 06FD53A6CC2 for ; Mon, 31 Aug 2009 17:12:20 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MiGz7-0001YT-9n; Mon, 31 Aug 2009 20:12:29 -0400 Date: Mon, 31 Aug 2009 20:12:28 -0400 From: John C Klensin To: Marie-France Berny , Wil Tan Message-ID: <37825ECB17614A5FA01AE0AC@PST.JCK.COM> In-Reply-To: <58ee45520908311321k32f7754cx71597d98ef25f0ca@mail.gmail.com> References: <58ee45520906281534m33aa336dg511837997367fc63@mail.gmail.com> <58ee45520908311321k32f7754cx71597d98ef25f0ca@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: idna-update@alvestrand.no, iucg@ietf.org Subject: Re: [iucg] Punycode Mixed-case annotation X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2009 00:12:32 -0000 --On Monday, August 31, 2009 22:21 +0200 Marie-France Berny wrote: > Dear Wil, > May be time for you now to answer my June 26th mail? This > might help to better analyse your suggestions and all the > comments of the day? I cannot speak for Wil, and won't try, but... > 2009/6/29 Marie-France Berny >=20 >... >> I just want to know how: >>=20 >> - ecole.fra >> - =C3=A9cole.fra >> - Ecole.fra >>=20 >> These are three French orthotypographies of three different >> semantics which may relate to three different IP addresses. >> How do you propose to support them ? The answer is "no". The first and third of these are not IDNs but are conventional, all-ASCII, host names. For such names, case-insensitive matching is done on the DNS server as part of the basic domain name specification, which has been unchanged in this area for nearly 26 years (and by the host table specification, which predates it by nearly another decade). They cannot identify different DNS tree nodes and hence cannot identify different sets of IP addresses (or anything else). =20 There is no way to change those fundamental DNS behaviors at this point. Even if there were, it would lie far outside the scope of this WG. As I have suggested several times before, it you need to make those distinctions, you are going to need to use an intermediate layer naming system, either resting on the DNS (which is what I would recommend for several reasons) or operating in its stead). =20 But, for the basic functionality and distinctions, top asking: you are about 35 years too late and are wasting your time and ours. john From jefsey@jefsey.com Mon Aug 31 17:48:54 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1AA3A6DDA for ; Mon, 31 Aug 2009 17:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQlq9nXIsZX1 for ; Mon, 31 Aug 2009 17:48:53 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 6F1463A66B4 for ; Mon, 31 Aug 2009 17:48:53 -0700 (PDT) Received: from 42.78.206-77.rev.gaoland.net ([77.206.78.42]:2732 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MiHYP-0008AP-JT; Mon, 31 Aug 2009 17:48:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 01 Sep 2009 02:48:39 +0200 To: John C Klensin ,Andrew Sullivan , From: jefsey In-Reply-To: <3AE29827920E4BA35E58F35A@PST.JCK.COM> References: <43e7101ca2a60$dec35250$9c49f6f0$@com> <20090831180830.GN13987@shinkuro.com> <3AE29827920E4BA35E58F35A@PST.JCK.COM> 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: Message-Id: <20090901004853.6F1463A66B4@core3.amsl.com> Cc: Vint Cerf , iucg@ietf.org, Lisa Dusseault Subject: Re: [iucg] Comments on draft-ietf-idnabis-defs-10 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2009 00:48:54 -0000 John, I _fully_ support this if: - we agree that this only concerns "invalid A-labels" and not any U-labels. This seems obvious from your text, but better make it sure. - this would be an "illegal" limitation of the namespace if this was extended outside of the xn-- scope (and probably IN class). So I particularly support the phrase "the A-labels that come out will be all lower case and that looking up an A-label that contains upper case characters is non-conforming and may produce surprising results." as it makes clear that it only imposes constraints on IDNA and not on the DNS and its namespace. This not a change, but an extremelly clear and welcome formulation of the existing text and consensus fully within the LC time frame. I understand that it does not prevents Vixie's proposition? We spent the night on skype over Francophonie in preparing a final LC mail. I think that Patrick Suger (we used as a scribe) will be happy to short it a lot. Thank you. jfc At 02:03 01/09/2009, John C Klensin wrote: >--On Monday, August 31, 2009 14:08 -0400 Andrew Sullivan > wrote: > > >... > > In my case, it's actually worse: I waded into the thread Wil > > started months ago precisely because I was worried about what > > he was raising & wanted to avoid having it conflated with > > another, unrelated problem. Alas, I think I contributed to the > > confusion instead of keeping the discussion focussed. But I > > still missed this in my review, much to my embarrassment. > > > > Therefore, I do think we need to make this issue completely > > plain, but I am also still not sure whether there is anything > > to change here. If I understand the situation correctly, > > there is no such thing as an A-label that includes an > > upper-case ASCII character. This is because A-labels are > > defined in terms of being convertible to and from U-labels, > > and there's no such thing as a valid U-label that includes > > those upper case characters. > > > > Now, there's an interesting upshot of all this, and that is > > that every A-label also compares as equivalent to some number > > of R-LDH labels; the resulting set of labels is every > > permutation of the A-label in question with the ASCII-range > > characters uppercased. None of those labels are A-labels, > > because they don't obey the restriction that they can be > > produced by conversion from a U-label (because no U-label may > > contain such characters). So far, however, this sounds to me > > like a note that ought to be highlighted, but not a formal > > part of the definitions or protocol. I'm still open to > > persuasion otherwise. > >Let me make an extremely tentative suggestion ("tentative" in >the sense that I'm not sure it is right and I'm very easily >persuaded to do something else): > >(1) Insert a note into Defs that explicitly points out that no >valid A-label can contain any upper case characters (at least >after the "xn" -- does the WG have a preference about the >prefix?) > >(2) In Protocol, put in reminders in the Punycode invocation >steps that indicate that, since the U-label cannot contain upper >case characters, the A-labels that come out will be all lower >case and that looking up an A-label that contains upper case >characters is non-conforming and may produce surprising results. > >(e) Go through Protocol and Defs, ideally with Paul's help, >identify all of the places where case-insensitive actions are >taken or specified, and make sure that they don't need tuning or >additional notes. > >The terms "note" and "reminder" are explicitly intended to be >flags to help the unwary, i.e., non-normative statements that do >not change the spec. > >If that works for folks, I'll sit down with the documents and >try to craft specific text for WG review. > > john > > >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update From vint@google.com Mon Aug 31 17:59:35 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503883A686B for ; Mon, 31 Aug 2009 17:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.774 X-Spam-Level: X-Spam-Status: No, score=-106.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygyvp0p5jgvd for ; Mon, 31 Aug 2009 17:59:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 64E8F3A66B4 for ; Mon, 31 Aug 2009 17:59:31 -0700 (PDT) Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75]) by smtp-out.google.com with ESMTP id n810xf2I023343 for ; Tue, 1 Sep 2009 01:59:42 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1251766782; bh=PtF+tLiAZGWPxxl+hYip6SylSDE=; h=DomainKey-Signature:Cc:Message-Id:From:To:In-Reply-To: Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date: References:X-Mailer:X-System-Of-Record; b=ZPcHxw3LoPjT/ZWnxdidZVsb wOClAC0qvJRhgIPFBlT3LMXwKaOgxTQ6VAFJIOLNALXS5N11lYEHzw4qfMco+w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=cc:message-id:from:to:in-reply-to:content-type: content-transfer-encoding:mime-version:subject:date:references:x-mailer:x-system-of-record; b=T9ycxhhE8wbD4pMtrWWnIj3XDKhRvmUVOjRclKGQU2GgFlkHD3S6tAuDLm9r4MCs3 pqkM6MhLT7vIsm/NdOcFg== Received: from ewy4 (ewy4.prod.google.com [10.241.103.4]) by zps75.corp.google.com with ESMTP id n810xba5003594 for ; Mon, 31 Aug 2009 17:59:38 -0700 Received: by ewy4 with SMTP id 4so1894784ewy.12 for ; Mon, 31 Aug 2009 17:59:37 -0700 (PDT) Received: by 10.210.3.21 with SMTP id 21mr6161388ebc.40.1251766777035; Mon, 31 Aug 2009 17:59:37 -0700 (PDT) Received: from dhcp-172-19-102-178.mtv.corp.google.com (dhcp-172-19-102-178.mtv.corp.google.com [172.19.102.178]) by mx.google.com with ESMTPS id 23sm291158eya.38.2009.08.31.17.59.33 (version=SSLv3 cipher=RC4-MD5); Mon, 31 Aug 2009 17:59:34 -0700 (PDT) Message-Id: From: Vint Cerf To: jefsey In-Reply-To: <200909010049.n810n2p9006551@smtp.google.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 31 Aug 2009 20:59:32 -0400 References: <43e7101ca2a60$dec35250$9c49f6f0$@com> <20090831180830.GN13987@shinkuro.com> <3AE29827920E4BA35E58F35A@PST.JCK.COM> <200909010049.n810n2p9006551@smtp.google.com> X-Mailer: Apple Mail (2.930.3) X-System-Of-Record: true Cc: Andrew Sullivan , John C Klensin , iucg@ietf.org, Lisa Dusseault Subject: Re: [iucg] Comments on draft-ietf-idnabis-defs-10 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2009 00:59:35 -0000 we have no interest in changing DNS. v On Aug 31, 2009, at 8:48 PM, jefsey wrote: > John, > I _fully_ support this if: > - we agree that this only concerns "invalid A-labels" and not any U- > labels. This seems obvious from your text, but better make it sure. > - this would be an "illegal" limitation of the namespace if this was > extended outside of the xn-- scope (and probably IN class). So I > particularly support the phrase "the A-labels that come out will be > all lower case and that looking up an A-label that contains upper > case characters is non-conforming and may produce surprising > results." as it makes clear that it only imposes constraints on IDNA > and not on the DNS and its namespace. > > This not a change, but an extremelly clear and welcome formulation > of the existing text and consensus fully within the LC time frame. I > understand that it does not prevents Vixie's proposition? > > We spent the night on skype over Francophonie in preparing a final > LC mail. I think that Patrick Suger (we used as a scribe) will be > happy to short it a lot. Thank you. > jfc > > At 02:03 01/09/2009, John C Klensin wrote: >> --On Monday, August 31, 2009 14:08 -0400 Andrew Sullivan >> wrote: >> >> >... >> > In my case, it's actually worse: I waded into the thread Wil >> > started months ago precisely because I was worried about what >> > he was raising & wanted to avoid having it conflated with >> > another, unrelated problem. Alas, I think I contributed to the >> > confusion instead of keeping the discussion focussed. But I >> > still missed this in my review, much to my embarrassment. >> > >> > Therefore, I do think we need to make this issue completely >> > plain, but I am also still not sure whether there is anything >> > to change here. If I understand the situation correctly, >> > there is no such thing as an A-label that includes an >> > upper-case ASCII character. This is because A-labels are >> > defined in terms of being convertible to and from U-labels, >> > and there's no such thing as a valid U-label that includes >> > those upper case characters. >> > >> > Now, there's an interesting upshot of all this, and that is >> > that every A-label also compares as equivalent to some number >> > of R-LDH labels; the resulting set of labels is every >> > permutation of the A-label in question with the ASCII-range >> > characters uppercased. None of those labels are A-labels, >> > because they don't obey the restriction that they can be >> > produced by conversion from a U-label (because no U-label may >> > contain such characters). So far, however, this sounds to me >> > like a note that ought to be highlighted, but not a formal >> > part of the definitions or protocol. I'm still open to >> > persuasion otherwise. >> >> Let me make an extremely tentative suggestion ("tentative" in >> the sense that I'm not sure it is right and I'm very easily >> persuaded to do something else): >> >> (1) Insert a note into Defs that explicitly points out that no >> valid A-label can contain any upper case characters (at least >> after the "xn" -- does the WG have a preference about the >> prefix?) >> >> (2) In Protocol, put in reminders in the Punycode invocation >> steps that indicate that, since the U-label cannot contain upper >> case characters, the A-labels that come out will be all lower >> case and that looking up an A-label that contains upper case >> characters is non-conforming and may produce surprising results. >> >> (e) Go through Protocol and Defs, ideally with Paul's help, >> identify all of the places where case-insensitive actions are >> taken or specified, and make sure that they don't need tuning or >> additional notes. >> >> The terms "note" and "reminder" are explicitly intended to be >> flags to help the unwary, i.e., non-normative statements that do >> not change the spec. >> >> If that works for folks, I'll sit down with the documents and >> try to craft specific text for WG review. >> >> john >> >> >> _______________________________________________ >> Idna-update mailing list >> Idna-update@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/idna-update >