From jefsey@jefsey.com Thu Apr 21 04:49:23 2011 Return-Path: X-Original-To: iucg@ietfc.amsl.com Delivered-To: iucg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D253EE06CF; Thu, 21 Apr 2011 04:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.834 X-Spam-Level: X-Spam-Status: No, score=-101.834 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkygD8apeAcd; Thu, 21 Apr 2011 04:49:22 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfc.amsl.com (Postfix) with ESMTP id 945B0E0698; Thu, 21 Apr 2011 04:49:22 -0700 (PDT) Received: from 18.109-227-89.dsl.completel.net ([89.227.109.18]:60868 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QCsNr-0004v5-LK; Thu, 21 Apr 2011 04:49:20 -0700 Message-Id: <7.0.1.0.2.20110421111550.059fe118@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 21 Apr 2011 13:49:31 +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: Cc: apps-discuss@ietf.org, precis@ietf.org, public-iri@w3.org, idna-update@alvestrand.no, ima@ietf.org, draft-hoffman-rfc3536bis@tools.ietf.org Subject: [iucg] terminology X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 11:49:24 -0000 Dear IUsers, Barry Leiba, WG/APPSAWG Chair has sent the following most important mail for us: >"Paul Hoffman and John Klensin have undertaken to update RFC 3536, >which specified terminology for use in internationalization-related >documents and discussions. The editors, appsawg chairs, and >Applications Area directors think the document needs broad review, >and propose to make it an appsawg document. >You can find the document here: >http://tools.ietf.org/html/draft-hoffman-rfc3536bis/ >The editors will soon submit an updated version, and await a >decision on accepting the document into appsawg before doing >that. We ask that anyone with a stake in internationalization >review the current version and state any objections to making this >an appsawg document by 29 April. >You may, or course, also send comments on the document at this point >to the editors and/or the apps-discuss list. Remember that there >are changes queued, so you might bring up points that they're >already planning to change/correct. >The reply-to on this message is set to the apps-discuss list >. Please put all responses and discussion there. This terminology is obviously going to be the mutual understanding bridge between the IETF and the IUTF communities. http://iucg.org/wiki/Wiki_RFC_3536bis is the traditional wiki working transcript (unfinished as yet) of the proposed draft. This is in line with my own I_D on orthotypography: http://tools.ietf.org/html/draft-iucg-idna2008-orthotypography-00 I suggest thet our target should be : 1. to make sure RFC 3536bis by APPSAWG is in line with our own understanding of the terms in our own working contexts (IDNA2008, ML-DNS, IUI, EST). 2. to build our own Internet extension section to document in a similar manner the emergent IUse terminology. This section should not document any concept than the way we read and use the existing "Internal Internet" technology (i.e. no bit change). 3. to continue building in contnuity our own dictionnary of the new IUI and Intersem (semiotic/semantic Intercomprehension network) stratum. Best. jfc NB: due to personal constraints that should now progressively reduce I was not able to sustain my post-IDNA2008 endeavour as I planned it. Some terminology used in this mail is not therefore as common and supported by operational prototypes as our little group hoped. Thank you to read the used acronyms/terms as follows: - IDNA2008: as documented by RFC 5890 to 5895 - ML-DNS: multilayer DNS (of which layer 1 is the Internal Internet DNS, layer 2 is IDNA2008). - IUI: Intelligent Use Interface (Internet Use Interface from an Internet perspective). i.e. a generalization of principle introduced by Paul Hoffman and Pete Resnick in RFC 5895 and a stable optional response to problems discussed by the IAB in RFC 6055 - IUse: an emergent community interested in an open general Intelligent Use of the world digital ecosystem (whatever the multitechnological convergence). - EST: Extended System Theory, a glogalization of the General System Theory which includes networking and interfaces and is necessary to better read the IETF RFCs in an IUse perspective. - IUTF: Intelligent Use Task Force, TF under formation further to the responses to the appeals to IESG and IAB following the successfull, but not documented yet as such, introduction of the principle of subsidiarity (IDNA2008) as the third internet architectural principle (RFC 1958: principle of permanent change, RFC 3439: principle of simplicity). I note that subsidiairity should come with suppleance (I did not found so far an English equivalent for the core to support peripheral difficulties) and precaution. - Dictionnary (http://iucg.org/wiki/Dictionnary): this IUCG project to integrate digital ecosystem convergence and ALFA (Free Acrchitecture) words. From klensin@jck.com Thu Apr 21 05:31:40 2011 Return-Path: X-Original-To: iucg@ietfc.amsl.com Delivered-To: iucg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5DBD3E071B; Thu, 21 Apr 2011 05:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NixfpDviCjVU; Thu, 21 Apr 2011 05:31:39 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfc.amsl.com (Postfix) with ESMTP id 2A007E070F; Thu, 21 Apr 2011 05:31:39 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QCt2n-0009Kv-Sm; Thu, 21 Apr 2011 08:31:38 -0400 Date: Thu, 21 Apr 2011 08:31:36 -0400 From: klensin@jck.com, john-ietf@jck.com To: jefsey , iucg@ietf.org Message-ID: In-Reply-To: <7.0.1.0.2.20110421111550.059fe118@jefsey.com> References: <7.0.1.0.2.20110421111550.059fe118@jefsey.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: public-iri@w3.org, draft-hoffman-rfc3536bis@tools.ietf.org, idna-update@alvestrand.no, precis@ietf.org, ima@ietf.org Subject: Re: [iucg] terminology X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: apps-discuss@ietf.org, 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, 21 Apr 2011 12:31:40 -0000 (top post) Jefsey, Thanks. The notice was already forward to a few other lists, which I hope I have trimmed. Any discussion of the appropriateness of doing this should continue on the apps-discuss list, as requested by Barry, and not cross-posted. I would prefer that any substantive comments be deferred until after AppsAWG makes a decision about discussion venue and then sent to their list (if they decide to take the document on). In the interim, substantive or editorial comments may be sent to Paul and myself at draft-hoffman-rfc3536bis@tools.ietf.org if needed. Neither he nor I have time to track multiple lists for comments so comments to random lists, or long distribution lists are likely to get lost -- please, everyone, don't do a multiple posting and then complain that your comments were lost. Substantive comment for planning purposes: Whether it ends up being posted as draft-ietf-appsawg-rfc3536bis-00 or as draft-hoffman-rfc3536bis-02 (with the version after that posted as draft-ietf-appsawg-rfc3536-00), the main substantive change between that version and the current draft-hoffman-rfc3536bis-01 will be the addition of an extended description of the term "variant" (used in domain name contexts). Wisely or not, the use of that term in various context has been expanded significantly beyond the definition in RFC 3743. Those whose work involves that term, or notions of "equivalence" in domain names, will want to look at the description carefully. Each new version of course also includes a selection of editorial improvements and less significant fixes. john p.s. I note that the "the traditional wiki working transcript" referred to in your note contains several significant errors and that we are unlikely to be able to have a useful discussion or incorporate changes based on that version. I strongly suggest that people use http://tools.ietf.org/html/draft-hoffman-rfc3536bis/ as the relevant discussion/ reading version instead. --On Thursday, April 21, 2011 13:49 +0200 jefsey wrote: > Dear IUsers, > Barry Leiba, WG/APPSAWG Chair has sent the following most > important mail for us: > >> "Paul Hoffman and John Klensin have undertaken to update RFC >> 3536, which specified terminology for use in >> internationalization-related documents and discussions. The >> editors, appsawg chairs, and Applications Area directors >> think the document needs broad review, and propose to make >> it an appsawg document. >> You can find the document here: >> http://tools.ietf.org/html/draft-hoffman-rfc3536bis/ >> The editors will soon submit an updated version, and await a >> decision on accepting the document into appsawg before doing >> that. We ask that anyone with a stake in >> internationalization review the current version and state >> any objections to making this an appsawg document by 29 >> April. >> You may, or course, also send comments on the document at >> this point to the editors and/or the apps-discuss list. >> Remember that there are changes queued, so you might bring >> up points that they're already planning to change/correct. >> The reply-to on this message is set to the apps-discuss list >> . Please put all responses and >> discussion there. > > This terminology is obviously going to be the mutual > understanding bridge between the IETF and the IUTF > communities. >... From jefsey@jefsey.com Sun Apr 24 06:54:33 2011 Return-Path: X-Original-To: iucg@ietfc.amsl.com Delivered-To: iucg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 986BCE06A9; Sun, 24 Apr 2011 06:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.882 X-Spam-Level: X-Spam-Status: No, score=-100.882 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9ZYpi0gYtN7; Sun, 24 Apr 2011 06:54:33 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfc.amsl.com (Postfix) with ESMTP id 29E7FE0696; Sun, 24 Apr 2011 06:54:33 -0700 (PDT) Received: from 142.183-227-89.dsl.completel.net ([89.227.183.142]:57501 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QDzlf-0003HG-C1; Sun, 24 Apr 2011 06:54:31 -0700 Message-Id: <7.0.1.0.2.20110424020635.05d8a470@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 24 Apr 2011 15:55:00 +0200 To: From: JFC Morfin In-Reply-To: <503575932.12389@cnnic.cn> References: <503575932.12389@cnnic.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: iucg@ietf.org Subject: Re: [iucg] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 13:54:33 -0000 This draft is worded in a way I, and I suppose other IUCG Members, can accept. However, the need to publish it underlines that Unicode is not the most appropriate Internet oriented solution to support IDNs, the multilingual internet, and further on the Intersem (semiotic/semantic Internet). For example, I underlines once more that IDNA2008 using Unicode does not support the French (and many other languages) orthotypography. jfc morfin IUCG Facilitator From jmabdp@gmail.com Tue Apr 26 17:51:29 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DACE081F; Tue, 26 Apr 2011 17:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZXIpdIwlmne; Tue, 26 Apr 2011 17:51:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC296E0680; Tue, 26 Apr 2011 17:51:28 -0700 (PDT) Received: by vws12 with SMTP id 12so1039315vws.31 for ; Tue, 26 Apr 2011 17:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zDAe3rTIT4WmQn2/riOAicZfzBboAi6kZx3OVbYHwh0=; b=GBRKG6Oy5z9khbnX7TZJc2lrE5Jndask7xDcfiPydkOqa2tbdtWYrdx0IG/NtNiu4D pUOCPV+FHe0eI+PRg/XWso8KwgPpIzTdxt6Ypcv9/A4tqyZ2ehLkot9RtIdhB+PEFi4N ojBMOZnjLlkPq7TTChhN21xImsnsbgVQRNi4A= 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=jUhqCGeou2rQYLH/V2Fc/Gkgkxv6+RWeMCk673Ymx7hvZQtiKmxbSI2FRE6H2iSpqB 3XYOgBjqFsAHXrYoLBNiTDV8jZNO/vW4HKzMnDdkV9vqKvp0AFz9aNhvEtrdRTbE4bo5 yBX3qGrCyLsv8LZwBVpXLYsQsqRj5WDFsVTsE= MIME-Version: 1.0 Received: by 10.52.172.2 with SMTP id ay2mr553328vdc.50.1303865488033; Tue, 26 Apr 2011 17:51:28 -0700 (PDT) Received: by 10.52.111.162 with HTTP; Tue, 26 Apr 2011 17:51:28 -0700 (PDT) In-Reply-To: <87mxjc21vi.fsf@latte.josefsson.org> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> Date: Wed, 27 Apr 2011 02:51:28 +0200 Message-ID: From: jean-michel bernier de portzamparc To: Simon Josefsson , internet users contributing group Content-Type: multipart/alternative; boundary=bcaec53f2ae73fc74b04a1dbd742 Cc: Jiankang Yao , idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [iucg] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 00:51:30 -0000 --bcaec53f2ae73fc74b04a1dbd742 Content-Type: text/plain; charset=ISO-8859-1 However I support JFC's position on the long range, I disagree that IUCG should support the Draft until the points well made by Simon Josefsson are addressed. Even if we can introduce a better network suited approach than Unicode we will still have to interface the Unicode codepoints for a very long time. Portzamparc 2011/4/26 Simon Josefsson > "Jiankang Yao" writes: > > > Dear colleagues, > > > > This message starts a two-week WGLC on the draft > > draft-faltstrom-5892bis-04.txt. > > All, > > I support publication of a document to clarify IDNA2008's relationship > to Unicode 6.0 but I believe the content of the above document causes an > instability for U+19DA which can be avoided. From my implementer's > point of view, it seems better to add U+19DA as PVALID in the > BackwardCompatible (G) category so that we have the property that > IDNA2008-Unicode5.2(X) = IDNA2008-Unicode6.0(X) for all strings X that > were permitted by IDNA2008-Unicode5.2. > > The above document effectively forbids some strings that were permitted > before. I believe this causes a perception of instability in the > algorithm. It seems that permitting strings with this code point would > not cause any problem in practice. To me that is a strong argument that > good algorithmical/implementation properties are more important than any > consideration for this particular code point. If U+19DA would cause > operational difficulties, I would be more inclined towards forbidding > strings that contains it, but I haven't seen those arguments. > > This has been brought up before by others, and I have merely been > convinced by that discussion. I'm not trying to state this point as > anything original. In particular, here are pointers to where Mark Davis > explains the point: > > http://article.gmane.org/gmane.ietf.idnabis/6910 > http://www.alvestrand.no/pipermail/idna-update/2010-October/006742.html > > > Note: This draft is a document that updates an earlier RFC by stating > > nothing is to be updated. > > That seems wrong. Technically the document does not claim to update any > earlier RFC according to the document content (there is no 'Updates:' > header). Could you clarify what you mean here? Is the intention that > the document will be marked as Updating any earlier RFC or not? > > /Simon > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > --bcaec53f2ae73fc74b04a1dbd742 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable However I support JFC's position on the long range, I disagree that IUC= G should support the Draft until the points well made by Simon Josefsson ar= e addressed. Even if we can introduce a better network suited approach than= Unicode we will still have to interface the Unicode codepoints for a very = long time.
Portzamparc


2011/4/26 Simon Josefsson= <simon@josefss= on.org>
"Jiankang Yao" <yaojk@cnnic.cn> writes:

> Dear colleagues,
>
> This message starts a two-week WGLC on the draft
> draft-faltstrom-5892bis-04.txt.

All,

I support publication of a document to clarify IDNA2008's relationship<= br> to Unicode 6.0 but I believe the content of the above document causes an instability for U+19DA which can be avoided. =A0From my implementer's point of view, it seems better to add U+19DA as PVALID in the
BackwardCompatible (G) category so that we have the property that
IDNA2008-Unicode5.2(X) =3D IDNA2008-Unicode6.0(X) for all strings X that were permitted by IDNA2008-Unicode5.2.

The above document effectively forbids some strings that were permitted
before. =A0I believe this causes a perception of instability in the
algorithm. =A0It seems that permitting strings with this code point would not cause any problem in practice. =A0To me that is a strong argument that<= br> good algorithmical/implementation properties are more important than any consideration for this particular code point. =A0If U+19DA would cause
operational difficulties, I would be more inclined towards forbidding
strings that contains it, but I haven't seen those arguments.

This has been brought up before by others, and I have merely been
convinced by that discussion. =A0I'm not trying to state this point as<= br> anything original. =A0In particular, here are pointers to where Mark Davis<= br> explains the point:

http://article.gmane.org/gmane.ietf.idnabis/6910
http://www.alvestrand.no/pipermail/idna-update/2= 010-October/006742.html

> Note: This draft is a document that updates an earlier RFC by stating<= br> > nothing is to be updated.

That seems wrong. =A0Technically the document does not claim to updat= e any
earlier RFC according to the document content (there is no 'Updates:= 9;
header). =A0Could you clarify what you mean here? =A0Is the intention that<= br> the document will be marked as Updating any earlier RFC or not?

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

--bcaec53f2ae73fc74b04a1dbd742-- From stelancel@gmail.com Wed Apr 27 07:49:26 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35816E07BC; Wed, 27 Apr 2011 07:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mI7vO0gKgOW9; Wed, 27 Apr 2011 07:49:21 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8C4E0778; Wed, 27 Apr 2011 07:49:21 -0700 (PDT) Received: by fxm15 with SMTP id 15so1384071fxm.31 for ; Wed, 27 Apr 2011 07:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nxT1O2X27sFrcQU2lpZZ7iQ2CkZK6HHHZUUk1w4XTKo=; b=I8UksyoD0Dju9c3LIgVzE3IAv0c6OEArNWPTCmTmR8uJ5XqZRrYR7REW6mfSDaakYE KT4vi6dol7fWuGYrE7aak8rDCibiK8grOfGWoFbb6FIh7dYb7DNkpom9SCKvm+2YpFmE uzd+I0f+f/EqiFXVKG7Sj3K3keFKmxqjebOoU= 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=lje7A355Mxzp5iJ7ZT1a0ZXLPHaNtw19okjPiLj24mIguNBYXWPUi/DHp/IWrwxbnP AA5HXCgRyc+2Vw48pNHD/aydy3p9cnzC0xWfGpwVSDPASRXl3X1qMrYqWU85vdsuCfzp 7Cllb6YvgOUz6jqNaaQtyHVS59aPtcBeHGPwA= MIME-Version: 1.0 Received: by 10.223.160.8 with SMTP id l8mr2511441fax.114.1303915758592; Wed, 27 Apr 2011 07:49:18 -0700 (PDT) Received: by 10.223.105.145 with HTTP; Wed, 27 Apr 2011 07:49:18 -0700 (PDT) In-Reply-To: <20110427140644.GH7329@crankycanuck.ca> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> <20110427140644.GH7329@crankycanuck.ca> Date: Wed, 27 Apr 2011 16:49:18 +0200 Message-ID: From: =?ISO-8859-1?Q?St=E9phane_Lancel?= To: Andrew Sullivan , Vint Cerf Content-Type: multipart/alternative; boundary=0023542750009d133b04a1e78bf0 Cc: Simon Josefsson , Jiankang Yao , idna-update@alvestrand.no, internet users contributing group , apps-discuss@ietf.org Subject: Re: [iucg] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 14:49:26 -0000 --0023542750009d133b04a1e78bf0 Content-Type: text/plain; charset=ISO-8859-1 This worries me: "implicit in the decision on the past". In RFC everything MUST be explicit. (my interest lies in non registered sub-domain names used to deliver an information to the other end). I am sorry because I am not really expert in PVALID issues (changes, etc.), but I understood that PVALID once, PVALID for ever. I realize with this Draft that this means at character level not at codepoint level. Or am I wrong? What about the applications using hard-coded code points names, or crypted domain names or subnames based upon an algorythm among PVALID code points (I understood that ".su" permitted that).. Another point is that this Draft is precisely to show that IDNA2008 is stable. Simon and Andrew show that this may not be the case, even when IETF says it is? How could the IDNS be stable if it uses a non-stable element (Unicode) ? 2011/4/27 Andrew Sullivan > On Wed, Apr 27, 2011 at 09:28:25AM -0400, Vint Cerf wrote: > > algorithms for PVALID, etc. Does anyone know whether U+19DA has > > actually been used in any domain names? > > Short of scanning the entire DNS of the entire Internet (presumably > including split-brain cases where the name is not visible in the > public tree), non-evidence of use doesn't show very much. But it > seems a very unlikely character. > > Implicit in the decision in the past about these sorts of cases was > that we'd treat them case by case. The reason to do that was that > some (potential) incompatibilities are more serious than others. IF > we were changing the rules around (say) the character "0", I'm quite > sure that the reaction would be different. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > --0023542750009d133b04a1e78bf0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This worries me: "implicit in the decision on the past". In RFC e= verything MUST be explicit. (my interest lies in non registered sub-domain = names used to deliver an information to the other end).

I am sorry b= ecause I am not really expert in PVALID issues (changes, etc.), but I under= stood that PVALID once, PVALID for ever. I realize with this Draft that thi= s means at character level not at codepoint level. Or am I wrong?

What about the applications using hard-coded code points names, or cryp= ted domain names or subnames based upon an algorythm among PVALID=A0 code p= oints (I understood that ".su" permitted that)..

Another p= oint is that this Draft is precisely to show that IDNA2008 is stable. Simon= and Andrew show that this may not be the case, even when IETF says it is? = How could the IDNS be stable if it uses a non-stable element (Unicode) ?
2011/4/27 Andrew Sullivan = <ajs@shinkuro.com>
=
On Wed, Apr 27, 2011 at 09:28:25AM -0400, Vint Cerf wrote= :
> algorithms for PVALID, etc. Does anyone know whether U+19DA has
> actually been used in any domain names?

Short of scanning the entire DNS of the entire Internet (presumably including split-brain cases where the name is not visible in the
public tree), non-evidence of use doesn't show very much. =A0But it
seems a very unlikely character.

Implicit in the decision in the past about these sorts of cases was
that we'd treat them case by case. =A0The reason to do that was that some (potential) incompatibilities are more serious than others. =A0IF
we were changing the rules around (say) the character "0", I'= m quite
sure that the reaction would be different.

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
__________________________________= _____________
Idna-update mailing list
Idna-update@alvestrand.no<= br> http://www.alvestrand.no/mailman/listinfo/idna-update

--0023542750009d133b04a1e78bf0-- From ajs@shinkuro.com Wed Apr 27 07:58:03 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A17E07AD; Wed, 27 Apr 2011 07:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHxRfTe70iNt; Wed, 27 Apr 2011 07:58:03 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 66CE0E0721; Wed, 27 Apr 2011 07:58:03 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6A7A31ECB41D; Wed, 27 Apr 2011 14:58:02 +0000 (UTC) Date: Wed, 27 Apr 2011 10:58:00 -0400 From: Andrew Sullivan To: =?utf-8?B?U3TDqXBoYW5l?= Lancel Message-ID: <20110427145800.GI7329@crankycanuck.ca> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> <20110427140644.GH7329@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idna-update@alvestrand.no, internet users contributing group , apps-discuss@ietf.org Subject: Re: [iucg] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 14:58:04 -0000 [cc:s trimmed] On Wed, Apr 27, 2011 at 04:49:18PM +0200, Stéphane Lancel wrote: > I am sorry because I am not really expert in PVALID issues (changes, etc.), > but I understood that PVALID once, PVALID for ever. I realize with this > Draft that this means at character level not at codepoint level. Or am I > wrong? I think you're wrong in two ways. First, it's true that the idea in IDNA2008 was that once something would be PVALID, it would be PVALID forever. But IDNA2008 depends on Unicode and its properties. If Unicode changes properties such that something moves from PVALID to something else, then the desired state is not achieved. Now, one could just make a rule, "once PVALID then always PVALID." But this is tantamount to sticking IDNA2008 to the Unicode version that was around at the time of IDNA2008 publication. We wanted to be Unicode-version independent, and so that strategy doesn't meet the goal. Second, I don't think "at character level not at codepoint level" is right. We're dealing in code points. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From stelancel@gmail.com Wed Apr 27 08:56:17 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7262E07B0; Wed, 27 Apr 2011 08:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzmDDQWeFucC; Wed, 27 Apr 2011 08:56:17 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFA49E070E; Wed, 27 Apr 2011 08:56:16 -0700 (PDT) Received: by fxm15 with SMTP id 15so1436622fxm.31 for ; Wed, 27 Apr 2011 08:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=V5KTDzf4WCPc/Eq/+Cum1FiWcic8FpgNvyDZwoOCWpc=; b=YTJhvM1AHdoPHbbARO2+meWrVSzqGoBT5bugsrIl5Wa+f4SrcyPm6XX3CH6TFnLZ05 Pa6dsDsjvyTPQUbhYi8OG3oQ5zdw6A3eOvkdwXal1QsdTcy9ZZRRp6+VOWEDFRXRJ3Es k7BCmMR7jwAgdsC15zjoI290E0viDFHNSVEOw= 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=Ln3O6wM6t7KIjIIyj8f0QjvaUA1RLcSKLrX8rOdphchaIAb2vZX2ptOsL4QwCtLxOp jbKi+oLgblyuIM1IzrY+R1JRzLKojT/ZG3x9Dy5wTurkJBD3wlLAFyESlvrnfQRSK6RI Dkh3DzcFokb0LeSwjSZLrVIaFRGhh3VF2qSH4= MIME-Version: 1.0 Received: by 10.223.94.129 with SMTP id z1mr2604741fam.144.1303919775910; Wed, 27 Apr 2011 08:56:15 -0700 (PDT) Received: by 10.223.105.145 with HTTP; Wed, 27 Apr 2011 08:56:15 -0700 (PDT) In-Reply-To: <20110427145800.GI7329@crankycanuck.ca> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> <20110427140644.GH7329@crankycanuck.ca> <20110427145800.GI7329@crankycanuck.ca> Date: Wed, 27 Apr 2011 17:56:15 +0200 Message-ID: From: =?ISO-8859-1?Q?St=E9phane_Lancel?= To: Andrew Sullivan Content-Type: multipart/alternative; boundary=000e0ce0b1160f61e904a1e87b69 Cc: idna-update@alvestrand.no, internet users contributing group , apps-discuss@ietf.org Subject: Re: [iucg] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 15:56:17 -0000 --000e0ce0b1160f61e904a1e87b69 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 27 avril 2011 16:58, Andrew Sullivan a =E9crit : > I think you're wrong in two ways. > No problem. I try to understand. " But IDNA2008 depends on Unicode and its properties. If Unicode change= s properties such that something moves from PVALID to something else", is that not a change in Unicode, i.e. a new version ? > We wanted to be Unicode-version independent, and so that strategy doesn't > meet the goal. > Here I am lost. > Second, I don't think "at character level not at codepoint level" is righ= t. > We're dealing in code points. > Yes, and their properties change for the same character ? Best S. Lancel --000e0ce0b1160f61e904a1e87b69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Le 27 avril 2011 16:58, Andrew Sullivan = <ajs@shinkuro.com<= /a>> a =E9crit :
I think you're wrong in two ways.

No problem. = I try to understand.
=A0
=A0=A0 " But IDNA2008 dep= ends on Unicode and its properties. =A0If Unicode changes properties such t= hat something moves from PVALID to something else",

is that not a change in Unicode, i.e. a new version ?
=A0
=
We wanted to be U= nicode-version independent, and so that strategy doesn't meet the goal.=

Here I am lost.

=A0
Second, I don't think "at character level not at codepoint level&q= uot; is right. =A0We're dealing in code points.
Yes, and their properties change for the same character ?

Best
S. Lancel
=A0

--000e0ce0b1160f61e904a1e87b69-- From ajs@shinkuro.com Wed Apr 27 09:05:51 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73083E082E; Wed, 27 Apr 2011 09:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7twcukHmP5X7; Wed, 27 Apr 2011 09:05:51 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id EB7ECE07F8; Wed, 27 Apr 2011 09:05:50 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2684E1ECB41D; Wed, 27 Apr 2011 16:05:50 +0000 (UTC) Date: Wed, 27 Apr 2011 12:05:48 -0400 From: Andrew Sullivan To: =?utf-8?B?U3TDqXBoYW5l?= Lancel Message-ID: <20110427160548.GJ7329@shinkuro.com> References: <503575932.12389@cnnic.cn> <87mxjc21vi.fsf@latte.josefsson.org> <20110427140644.GH7329@crankycanuck.ca> <20110427145800.GI7329@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idna-update@alvestrand.no, iucg@ietf.org, apps-discuss@ietf.org Subject: Re: [iucg] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 16:05:51 -0000 On Wed, Apr 27, 2011 at 05:56:15PM +0200, Stéphane Lancel wrote: > " But IDNA2008 depends on Unicode and its properties. If Unicode changes > properties such that something moves from PVALID to something else", > > is that not a change in Unicode, i.e. a new version ? It is. That's what the issue is in this case: there's a new Unicode version, and a code point's properties changed from one version to another, such that the derived category in IDNA2008 changes from PVALID to something else. Have you read the draft? This is called out quite explicitly in section 1. > Yes, and their properties change for the same character ? Please don't bring characters into this. We are talking about code points, and we don't need to muddy the waters. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc.