From jefsey@jefsey.com Tue Jun 2 15:40:06 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 565213A6923 for ; Tue, 2 Jun 2009 15:40:06 -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 iYnFpeVNwQMH for ; Tue, 2 Jun 2009 15:40:05 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 6F76A3A6900 for ; Tue, 2 Jun 2009 15:40:05 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:1854 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MBcdw-00071B-4X; Tue, 02 Jun 2009 15:39:43 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 03 Jun 2009 00:39:26 +0200 To: iucg@ietf.org 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: <20090602224005.6F76A3A6900@core3.amsl.com> Cc: plus-sig@thinkingthe.net Subject: [iucg] The "Internet PLUS" IUCG document is released 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, 02 Jun 2009 22:40:06 -0000 Eventually ... I compeleted it :-) ! For your information the bilingual IUCG Draft on the Internet PLUS is now on http://iucg.org/wiki/Internet_PLUS. It notably extends the possibilities of the Internet usage without touching to the Internet itself. I am interested in comments before also publishing it as an IETF Draft. jfc From vesely@tana.it Thu Jun 4 11:24: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 E510E3A70AC for ; Thu, 4 Jun 2009 11:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 0RUEppBRtKS9 for ; Thu, 4 Jun 2009 11:24:00 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 055373A6A41 for ; Thu, 4 Jun 2009 11:23:59 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 04 Jun 2009 20:23:28 +0200 id 00000000005DC02F.000000004A281120.00002882 Message-ID: <4A28113D.7050304@tana.it> Date: Thu, 04 Jun 2009 20:23:57 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: internet users contributing group References: <20090602224005.6F76A3A6900@core3.amsl.com> In-Reply-To: <20090602224005.6F76A3A6900@core3.amsl.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [iucg] The "Internet PLUS" IUCG document is released 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, 04 Jun 2009 18:24:02 -0000 JFC Morfin wrote: > Eventually ... I compeleted it :-) ! > For your information the bilingual IUCG Draft on the Internet PLUS is > now on http://iucg.org/wiki/Internet_PLUS. (While being bilingual eases reading, it makes changes tougher...) > It notably extends the possibilities of the Internet usage without > touching to the Internet itself. Being a newcomer, I'm not shy to say I have difficulties understanding it. I've taken a few notes while reading it, and I paste them below, as feedback (format: "---" snippet-of-original-text newline comment.) --- The Internet upper layer began with three applications (Telnet, FTP, and RJE). Several applications have been added RJE is Remote Job Entry? I'd drop this, unless many readers know it. --- The proposition of this memo is to consider a response to these needs "these" is slightly ambiguous in such a statement. --- The presentation layer is then understood as proceeding from the concept of the "prestag" of a domain name label. "prestag" hasn't been defined yet. ("xn--" is called the "ACE prefix", where ACE means ASCII Compatible Encoding, in rfc3490. prestag is defined by example as a generalization of that concept.) --- This is why an optional transparent addition to the TCP/IP (v4 and v6) protocol header is probably needed for delivering the naming information when the used protocol does not do it Hm... that would conflict with the requirement that the network architecture must not be affected. It should be possible to add names on a protocol by protocol basis (as in the Server Name Indication of rfc4366). A generic layer to store needed extra parameters could also be envisaged, making that extra data available for protocols built upon such layer, but TCP/IPP is a misnomer if such layer can transparently use, say, SCTP instead of TCP, or IPv6 instead of IPv4. --- RFC 2929 says: "At the present time, there are two categories of label types: data labels and compression labels." s/2929/5395/ --- This MUST respect the DNS rules when the Internet is used as a network. IDNA is an example of such a respect. I'd word the first sentence as "This MUST respect the DNS rules so that the Internet can be used as a network", in order to avoid readers wondering about what cases are allowed to break DNS rules. As for the IDNA example, I'm not sure how generic it is. (Possibly unlike TATWEEL) accents in French are just part of orthography, and cannot be used to _accentuate_ a label, in the sense of tweaking its semantics. A transparent behavior similar to IDNA, where the encoded name is nonsensical and hence never displayed, could be achieved with per-user settings, and that is, IMHO, the limit of the example. BTW, making the only example in Arabic --or Greek, for that matter-- may also limit understanding somewhat ;-) --- Network "Application" layer This chapter gives the impression that we are talking about i18n mangling only. (If that were true, the term "semantic" would be a misnomer.) Conceptually separating "the Internet" from the new framework being described is also going to generate confusion. Even if it is named "Internet PLUS", it doesn't make much sense to distinguish "the Internet" and "the PLUS" as separate parts, because Internet PLUS is meant to eventually be part of the Internet, and hence, at some point, it will be the Internet tout-court. --- Syntax Limiting to "." and "-" provides for a very restrictive syntax. Since we have converters, it would be possible to define type-rendering of UDNs using other ASCII characters that are not allowed in ADNs, e.g. parentheses as in www.example(my-binding).org, or john(tel).example.net --along the line of user#passwd@ftp.example.com. --- This means that nothing, that it permits to dynamically do could, which in turn not be statically obtained by using "Host.txt". That's not strictly true if part of the UDN is going to be stored at an intermediate layer, e.g. the virtual host name (mentioned in a previous comment about TCP/IPP.) From jefsey@jefsey.com Thu Jun 4 11:50:22 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 1417F3A6BEF for ; Thu, 4 Jun 2009 11:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 1iBZW7Jc-9Ik for ; Thu, 4 Jun 2009 11:50:21 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id D4A293A69E4 for ; Thu, 4 Jun 2009 11:50:19 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 8F0FCE080D4 for ; Thu, 4 Jun 2009 20:50:09 +0200 (CEST) Received: from jfcmh.online.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp6-g21.free.fr (Postfix) with ESMTP id 694B6E0815B; Thu, 4 Jun 2009 20:50:05 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 04 Jun 2009 20:49:57 +0200 To: internet users contributing group , internet users contributing group From: JFC Morfin In-Reply-To: <4A28113D.7050304@tana.it> References: <20090602224005.6F76A3A6900@core3.amsl.com> <4A28113D.7050304@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090604185005.694B6E0815B@smtp6-g21.free.fr> Subject: Re: [iucg] The "Internet PLUS" IUCG document is released 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, 04 Jun 2009 18:50:22 -0000 Thank you for these inputs! I am buzzy with a key answer to an RFP until 17:00 tomorrow. I will look into this then Best jfc At 20:23 04/06/2009, Alessandro Vesely wrote: >JFC Morfin wrote: >>Eventually ... I compeleted it :-) ! >>For your information the bilingual IUCG Draft on the Internet PLUS >>is now on http://iucg.org/wiki/Internet_PLUS. > >(While being bilingual eases reading, it makes changes tougher...) > >>It notably extends the possibilities of the Internet usage without >>touching to the Internet itself. > >Being a newcomer, I'm not shy to say I have difficulties >understanding it. I've taken a few notes while reading it, and I >paste them below, as feedback (format: "---" >snippet-of-original-text newline comment.) > >--- >The Internet upper layer began with three applications (Telnet, FTP, >and RJE). Several applications have been added > >RJE is Remote Job Entry? I'd drop this, unless many readers know it. >--- >The proposition of this memo is to consider a response to these needs > >"these" is slightly ambiguous in such a statement. >--- >The presentation layer is then understood as proceeding from the >concept of the "prestag" of a domain name label. > >"prestag" hasn't been defined yet. ("xn--" is called the "ACE >prefix", where ACE means ASCII Compatible Encoding, in rfc3490. >prestag is defined by example as a generalization of that concept.) >--- >This is why an optional transparent addition to the TCP/IP (v4 and >v6) protocol header is probably needed for delivering the naming >information when the used protocol does not do it > >Hm... that would conflict with the requirement that the network >architecture must not be affected. It should be possible to add >names on a protocol by protocol basis (as in the Server Name >Indication of rfc4366). A generic layer to store needed extra >parameters could also be envisaged, making that extra data available >for protocols built upon such layer, but TCP/IPP is a misnomer if >such layer can transparently use, say, SCTP instead of TCP, or IPv6 >instead of IPv4. >--- >RFC 2929 says: "At the present time, there are two categories of >label types: data labels and compression labels." > >s/2929/5395/ >--- >This MUST respect the DNS rules when the Internet is used as a >network. IDNA is an example of such a respect. > >I'd word the first sentence as "This MUST respect the DNS rules so >that the Internet can be used as a network", in order to avoid >readers wondering about what cases are allowed to break DNS rules. > >As for the IDNA example, I'm not sure how generic it is. (Possibly >unlike TATWEEL) accents in French are just part of orthography, and >cannot be used to _accentuate_ a label, in the sense of tweaking its >semantics. A transparent behavior similar to IDNA, where the encoded >name is nonsensical and hence never displayed, could be achieved >with per-user settings, and that is, IMHO, the limit of the example. >BTW, making the only example in Arabic --or Greek, for that matter-- >may also limit understanding somewhat ;-) >--- >Network "Application" layer > >This chapter gives the impression that we are talking about i18n >mangling only. (If that were true, the term "semantic" would be a misnomer.) > >Conceptually separating "the Internet" from the new framework being >described is also going to generate confusion. Even if it is named >"Internet PLUS", it doesn't make much sense to distinguish "the >Internet" and "the PLUS" as separate parts, because Internet PLUS is >meant to eventually be part of the Internet, and hence, at some >point, it will be the Internet tout-court. >--- >Syntax > >Limiting to "." and "-" provides for a very restrictive syntax. >Since we have converters, it would be possible to define >type-rendering of UDNs using other ASCII characters that are not >allowed in ADNs, e.g. parentheses as in www.example(my-binding).org, >or john(tel).example.net --along the line of user#passwd@ftp.example.com. >--- >This means that nothing, that it permits to dynamically do could, >which in turn not be statically obtained by using "Host.txt". > >That's not strictly true if part of the UDN is going to be stored at >an intermediate layer, e.g. the virtual host name (mentioned in a >previous comment about TCP/IPP.) > >_______________________________________________ >iucg mailing list >iucg@ietf.org >https://www.ietf.org/mailman/listinfo/iucg From jefsey@jefsey.com Sat Jun 6 19:59: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 F38E63A6B6B for ; Sat, 6 Jun 2009 19:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 yOpiwJx280pn for ; Sat, 6 Jun 2009 19:59:22 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id 5989D3A689B for ; Sat, 6 Jun 2009 19:59:20 -0700 (PDT) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 08C234C803D for ; Sun, 7 Jun 2009 04:59:21 +0200 (CEST) Received: from jfcmh.online.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp4-g21.free.fr (Postfix) with ESMTP id 6FDD64C802F for ; Sun, 7 Jun 2009 04:59:17 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 07 Jun 2009 04:59:12 +0200 To: internet users contributing group From: JFC Morfin In-Reply-To: <7.1.0.9.2.20090604203304.03e2b250@jefsey.com> References: <20090602224005.6F76A3A6900@core3.amsl.com> <4A28113D.7050304@tana.it> <7.1.0.9.2.20090604203304.03e2b250@jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090607025918.6FDD64C802F@smtp4-g21.free.fr> Subject: Re: [iucg] The "Internet PLUS" IUCG document is released 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, 07 Jun 2009 02:59:24 -0000 At 20:49 04/06/2009, JFC Morfin wrote: >Thank you for these inputs! >I am buzzy with a key answer to an RFP until 17:00 tomorrow. I will >look into this then >Best >jfc > > >At 20:23 04/06/2009, Alessandro Vesely wrote: >>JFC Morfin wrote: >>>Eventually ... I compeleted it :-) ! >>>For your information the bilingual IUCG Draft on the Internet PLUS >>>is now on http://iucg.org/wiki/Internet_PLUS. >> >>(While being bilingual eases reading, it makes changes tougher...) The IUCG is supposed to accept every language (in the hope there is someone to pick the relevant idea and translate). As ISO it should be bilingual. In fact for good writing it should also be dicussed in Chinese to get the three different reasoning systems. >>>It notably extends the possibilities of the Internet usage without >>>touching to the Internet itself. >> >>Being a newcomer, I'm not shy to say I have difficulties understanding it. No need to be a new comer. I am not specially a good writer. And the matter is complex. >> I've taken a few notes while reading it, and I paste them below, >> as feedback (format: "---" snippet-of-original-text newline comment.) >> >>--- >>The Internet upper layer began with three applications (Telnet, >>FTP, and RJE). Several applications have been added >> >>RJE is Remote Job Entry? I'd drop this, unless many readers know it. This is history. >>--- >>The proposition of this memo is to consider a response to these needs >> >>"these" is slightly ambiguous in such a statement. OK. Would "to consider a response to usage oriented needs". The important point is "a" to show that there could be other responses as well or better ones. Because the whole thing is on the usage side, not on the internet side. >>--- >>The presentation layer is then understood as proceeding from the >>concept of the "prestag" of a domain name label. >> >>"prestag" hasn't been defined yet. ("xn--" is called the "ACE >>prefix", where ACE means ASCII Compatible Encoding, in rfc3490. >>prestag is defined by example as a generalization of that concept.) Prestag is quoted as a new term in the introduction. I will expend the paragraph above to indicate that prestage is generalization of the prefix. >>--- >>This is why an optional transparent addition to the TCP/IP (v4 and >>v6) protocol header is probably needed for delivering the naming >>information when the used protocol does not do it >> >>Hm... that would conflict with the requirement that the network >>architecture must not be affected. It should be possible to add >>names on a protocol by protocol basis (as in the Server Name >>Indication of rfc4366). A generic layer to store needed extra >>parameters could also be envisaged, making that extra data >>available for protocols built upon such layer, but TCP/IPP is a >>misnomer if such layer can transparently use, say, SCTP instead of >>TCP, or IPv6 instead of IPv4. TCP/IPP is not defined in this document, only the probable need is alluded to. Changing a protocol is not changing the architecture as long as the change is transparent to those not using it. The most probable solution for TCP/IPP is very simple: to use a one bit in the header to signal the availbility of metadata (what actually means the Internet Plus is activated on the sending end. How to signal this is worth some consideration. You are correct that it should be noted as IPP. >>--- >>RFC 2929 says: "At the present time, there are two categories of >>label types: data labels and compression labels." >> >>s/2929/5395/ Thank you. I did not notice that Interstellar Switches Draft had made it to an RFC yet. Did you notice some contradictions in some other place? I need to reread the text now it is published. >>--- >>This MUST respect the DNS rules when the Internet is used as a >>network. IDNA is an example of such a respect. >> >>I'd word the first sentence as "This MUST respect the DNS rules so >>that the Internet can be used as a network", in order to avoid >>readers wondering about what cases are allowed to break DNS rules. Good. >>As for the IDNA example, I'm not sure how generic it is. (Possibly >>unlike TATWEEL) accents in French are just part of orthography, and >>cannot be used to _accentuate_ a label, in the sense of tweaking >>its semantics. A transparent behavior similar to IDNA, where the >>encoded name is nonsensical and hence never displayed, could be >>achieved with per-user settings, and that is, IMHO, the limit of >>the example. BTW, making the only example in Arabic --or Greek, for >>that matter-- may also limit understanding somewhat ;-) I just wanted to say that architecturally Internet Plus strictly respect the IAB rule set-up for IDNA - not to interfere with DNS. >>--- >>Network "Application" layer >> >>This chapter gives the impression that we are talking about i18n >>mangling only. (If that were true, the term "semantic" would be a misnomer.) IRT what I underestand when you talk of i18n mangling: 1. any constraint on the net byte level neutrality affects the semantic bandwidth, since it may block some strings which carry a meaning? 2. would probably be addressed in saying ? "any constraint related to any byte level limitations (for example: i18n characters mangling or IDNA relate filtering) and, therefore, the semantic bandwidth of the Internet wire". >>Conceptually separating "the Internet" from the new framework being >>described is also going to generate confusion. Even if it is named >>"Internet PLUS", it doesn't make much sense to distinguish "the >>Internet" and "the PLUS" as separate parts, because Internet PLUS >>is meant to eventually be part of the Internet, and hence, at some >>point, it will be the Internet tout-court. There is absolutely no intent to have the plugged layers being integrated into the Internet. What is described here is how they are plugged into the internet. This will be the same for any Internet interoperable technology from the past or in the future. "PLUS" is certainly a good buzword as it corresponds to what the Internet misses to support the Intersem. But it is on the intersem side in Vint's opinion. >>--- >>Syntax >> >>Limiting to "." and "-" provides for a very restrictive syntax. >>Since we have converters, it would be possible to define >>type-rendering of UDNs using other ASCII characters that are not >>allowed in ADNs, e.g. parentheses as in >>www.example(my-binding).org, or john(tel).example.net --along the >>line of user#passwd@ftp.example.com. You are fully correct. This is something I forgot to rephrase. This was meant for a direct DN like use in different languages. Also, because in programing, structures are tld.level1.level2. I also forget to rewrite the example part to show that bcd---efg means a prefix and a suffix and not core domain name; what can be used to talk to a gateway or possibly call the root of a secondary space. I will use your example. >>--- >>This means that nothing, that it permits to dynamically do could, >>which in turn not be statically obtained by using "Host.txt". >> >>That's not strictly true if part of the UDN is going to be stored >>at an intermediate layer, e.g. the virtual host name (mentioned in >>a previous comment about TCP/IPP.) Correct. I meant at the DN/IDN level. Will correct it. I must confess that I focus right now on the semantic addressing related issues because I proposed to use the ".fra" space as a taxonomy for an open interknowledge ontology serving as a a semantic referential system. But obviously UDN can be used in the way people want for whatever applications. Thanks for your inputs/ Actually the first try was to document the semantic addressing system need, as an IETF customer. But it became very complex very soon. So, the best was to define what we need from the Internet and that the IAB can review. And to proceed more slowly on an practical experimentation basis for the Intersem, but there is a need of some development ! Best jfc From mfberny@gmail.com Sun Jun 7 04:48: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 B50B83A6B59 for ; Sun, 7 Jun 2009 04:48:03 -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_63=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 Dm4t2gxCK6gM for ; Sun, 7 Jun 2009 04:48:02 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id DBA363A6A0A for ; Sun, 7 Jun 2009 04:48:01 -0700 (PDT) Received: by ewy6 with SMTP id 6so3405134ewy.37 for ; Sun, 07 Jun 2009 04:48: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:content-type; bh=UntVMUyXfXhi50FC6LflNUoBvrP91H05KieHCPc7jnE=; b=F187dCdLJMbBAZA1oSYLva8BxUqK3O9pa+iKoK224ejamqq1V6xqBI1sofVvjMN0G6 gNPoCL45vqFwzp2cF13ZG6w59P8koneMwcNYqd8HmWqobXZgiR8K7SXBsQTudEoB/WEb j6fdVXnpD2ESpdZu2BwTfdbop82AhniZY4130= 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 :content-type; b=eMY09UrvC4fqW/xs2C/MgbeuTuDyjTDbi081oNNs/WIFiyjmkxGye8scJlp6+Ru4ay 6EJBM9bQ0skqSUPd0eLxSBo8gpV1/QbKMEqvpdh/4JfAtwgb7Es5zzE+6bx9Bg8sxsJF MKVLcgLSCavdX14adSpCMJGJB46QuPLTe9M0Y= MIME-Version: 1.0 Received: by 10.216.10.210 with SMTP id 60mr1920434wev.81.1244375282345; Sun, 07 Jun 2009 04:48:02 -0700 (PDT) In-Reply-To: <20090607025918.6FDD64C802F@smtp4-g21.free.fr> References: <20090602224005.6F76A3A6900@core3.amsl.com> <4A28113D.7050304@tana.it> <7.1.0.9.2.20090604203304.03e2b250@jefsey.com> <20090607025918.6FDD64C802F@smtp4-g21.free.fr> Date: Sun, 7 Jun 2009 13:48:02 +0200 Message-ID: <58ee45520906070448g5874a3b8s164f6d1f46baa84c@mail.gmail.com> From: Marie-France Berny To: internet users contributing group Content-Type: multipart/alternative; boundary=0016364d31f9abe5d1046bc0b207 Subject: Re: [iucg] The "Internet PLUS" IUCG document is released 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, 07 Jun 2009 11:48:03 -0000 --0016364d31f9abe5d1046bc0b207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Jefsey,Let me comment this. 2009/6/7 JFC Morfin > >>> Being a newcomer, I'm not shy to say I have difficulties understanding >>> it. >>> >> > No need to be a new comer. I am not specially a good writer. And the matter > is complex. Everyone is a new comer. We just are users attempting something new ! Welcome among us ! > This is why an optional transparent addition to the TCP/IP (v4 and v6) >>> protocol header is probably needed for delivering the naming information >>> when the used protocol does not do it >>> >>> Hm... that would conflict with the requirement that the network >>> architecture must not be affected. It should be possible to add names on a >>> protocol by protocol basis (as in the Server Name Indication of rfc4366). A >>> generic layer to store needed extra parameters could also be envisaged, >>> making that extra data available for protocols built upon such layer, but >>> TCP/IPP is a misnomer if such layer can transparently use, say, SCTP instead >>> of TCP, or IPv6 instead of IPv4. >>> >> > TCP/IPP is not defined in this document, only the probable need is alluded > to. Changing a protocol is not changing the architecture as long as the > change is transparent to those not using it. The most probable solution for > TCP/IPP is very simple: to use a one bit in the header to signal the > availbility of metadata (what actually means the Internet Plus is activated > on the sending end. How to signal this is worth some consideration. You are > correct that it should be noted as IPP. Question: are we really interested in the Internet? We started from the Intersem, found it was too complex for us to explain to IETF people. Se we went to an Internet Pile and kept the Application layer not to change anything and to have the DNS. As you say ... > > I just wanted to say that architecturally Internet Plus strictly respect > the IAB rule set-up for IDNA - not to interfere with DNS. > > --- >>> Network "Application" layer >>> >>> This chapter gives the impression that we are talking about i18n mangling >>> only. (If that were true, the term "semantic" would be a misnomer.) >>> >> > > IRT what I underestand when you talk of i18n mangling: > 1. any constraint on the net byte level neutrality affects the semantic > bandwidth, since it may block some strings which carry a meaning? > 2. would probably be addressed in saying ? > "any constraint related to any byte level limitations (for example: i18n > characters mangling or IDNA relate filtering) and, therefore, the semantic > bandwidth of the Internet wire". > > Conceptually separating "the Internet" from the new framework being >>> described is also going to generate confusion. Even if it is named "Internet >>> PLUS", it doesn't make much sense to distinguish "the Internet" and "the >>> PLUS" as separate parts, because Internet PLUS is meant to eventually be >>> part of the Internet, and hence, at some point, it will be the Internet >>> tout-court. >>> >> > There is absolutely no intent to have the plugged layers being integrated > into the Internet. What is described here is how they are plugged into the > internet. This will be the same for any Internet interoperable technology > from the past or in the future. "PLUS" is certainly a good buzword as it > corresponds to what the Internet misses to support the Intersem. But it is > on the intersem side in Vint's opinion. I a not sure this would be good English, but we could use "Inter Pluggable Layer User Systemic" or Systematic ? > > --- >>> This means that nothing, that it permits to dynamically do could, which >>> in turn not be statically obtained by using "Host.txt". >>> >>> That's not strictly true if part of the UDN is going to be stored at an >>> intermediate layer, e.g. the virtual host name (mentioned in a previous >>> comment about TCP/IPP.) >>> >> > Correct. I meant at the DN/IDN level. Will correct it. > > I must confess that I focus right now on the semantic addressing related > issues because I proposed to use the ".fra" space as a taxonomy for an open > interknowledge ontology serving as a a semantic referential system. But > obviously UDN can be used in the way people want for whatever applications. We are going to get confusion at generalising too much. We need to respect UIR/IRIs. Thanks for your inputs/ > > Actually the first try was to document the semantic addressing system need, > as an IETF customer. But it became very complex very soon. So, the best was > to define what we need from the Internet and that the IAB can review. And to > proceed more slowly on an practical experimentation basis for the Intersem, > but there is a need of some development ! This is why I suggest we stick to our needs. If some people want more, up to them to document it ! Marie-France --0016364d31f9abe5d1046bc0b207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Jefsey,
Let me comment this.

200= 9/6/7 JFC Morfin <jefsey@jefsey.com>

=A0Being a newcomer, I'm not shy to say I have difficulties understandi= ng it.

No need to be a new comer. I am not specially a good writer. And the matter= is complex.

Everyone is a new comer. We ju= st are users attempting something new !
Welcome among us !
=A0
This is why an optional transparent addition= to the TCP/IP (v4 and v6) protocol header is probably needed for deliverin= g the naming information when the used protocol does not do it

Hm... that would conflict with the requirement that the network architectur= e must not be affected. It should be possible to add names on a protocol by= protocol basis (as in the Server Name Indication of rfc4366). A generic la= yer to store needed extra parameters could also be envisaged, making that e= xtra data available for protocols built upon such layer, but TCP/IPP is a m= isnomer if such layer can transparently use, say, SCTP instead of TCP, or I= Pv6 instead of IPv4.

TCP/IPP is not defined in this document, only the probable need is alluded = to. Changing a protocol is not changing the architecture as long as the cha= nge is transparent to those not using it. The most probable solution for TC= P/IPP is very simple: to use a one bit in the header to signal the availbil= ity of metadata (what actually means the Internet Plus is activated on the = sending end. How to signal this is worth some consideration. You are correc= t that it should be noted as IPP.

Question: are we really interested in the Internet?=A0<= /div>
We started from the Intersem, found it was too complex for us to = explain to IETF people. Se we went to an Internet Pile and kept the Applica= tion layer not to change anything and to have the DNS.

As you say ...

I just wanted to say that architecturally Internet Plus strictly respect th= e IAB rule set-up for IDNA - not to interfere with DNS.

---
Network "Application" layer

This chapter gives the impression that we are talking about i18n mangling o= nly. (If that were true, the term "semantic" would be a misnomer.= )


IRT what I underestand when you talk of i18n mangling:
1. any constraint on the net byte level neutrality affects the semantic ban= dwidth, since it may block some strings which carry a meaning?
2. would probably be addressed in saying ?
"any constraint related to any byte level limitations (for example: i1= 8n characters mangling or IDNA relate filtering) and, therefore, the semant= ic bandwidth of the Internet wire".


Conceptually separating "the Internet" from the new framework bei= ng described is also going to generate confusion. Even if it is named "= ;Internet PLUS", it doesn't make much sense to distinguish "t= he Internet" and "the PLUS" as separate parts, because Inter= net PLUS is meant to eventually be part of the Internet, and hence, at some= point, it will be the Internet tout-court.

There is absolutely no intent to have the plugged layers being integrated i= nto the Internet. What is described here is how they are plugged into the i= nternet. This will be the same for any Internet interoperable technology fr= om the past or in the future. "PLUS" is certainly a good buzword = as it corresponds to what the Internet misses to support the Intersem. But = it is on the intersem side in Vint's opinion.

I a not sure this would be good English, but we could u= se "Inter Pluggable Layer User Systemic" or Systematic ?=A0
=
=A0

---
This means that nothing, that it permits to dynamically do could, which in = turn not be statically obtained by using "Host.txt".

That's not strictly true if part of the UDN is going to be stored at an= intermediate layer, e.g. the virtual host name (mentioned in a previous co= mment about TCP/IPP.)

Correct. I meant at the DN/IDN level. Will correct it.

I must confess that I focus right now on the semantic addressing related is= sues because I proposed to use the ".fra" space as a taxonomy for= an open interknowledge ontology serving as a =A0a semantic referential sys= tem. But obviously UDN can be used in the way people want for whatever appl= ications.

We are going to get confusion at generalising too much.= We need to respect UIR/IRIs.=A0

Thanks for your inputs/

Actually the first try was to document the semantic addressing system need,= as an IETF customer. But it became very complex very soon. So, the best wa= s to define what we need from the Internet and that the IAB can review. And= to proceed more slowly on an practical experimentation basis for the Inter= sem, but there is a need of some development !

This is why I suggest we stick to our needs. If some pe= ople want more, up to them to document it !

Marie-= France

--0016364d31f9abe5d1046bc0b207-- From vesely@tana.it Mon Jun 8 03:19: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 864B33A6AC1 for ; Mon, 8 Jun 2009 03:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 ZIe0hq1REkBZ for ; Mon, 8 Jun 2009 03:19:40 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 749CC3A69B6 for ; Mon, 8 Jun 2009 03:19:40 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 08 Jun 2009 12:19:43 +0200 id 00000000005DC030.000000004A2CE5BF.00006489 Message-ID: <4A2CE5BF.40405@tana.it> Date: Mon, 08 Jun 2009 12:19:43 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: internet users contributing group References: <20090602224005.6F76A3A6900@core3.amsl.com> <4A28113D.7050304@tana.it> <7.1.0.9.2.20090604203304.03e2b250@jefsey.com> <20090607025918.6FDD64C802F@smtp4-g21.free.fr> In-Reply-To: <20090607025918.6FDD64C802F@smtp4-g21.free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [iucg] The "Internet PLUS" IUCG document is released 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, 08 Jun 2009 10:19:41 -0000 JFC Morfin wrote: > Prestag is quoted as a new term in the introduction. I will expend the > paragraph above to indicate that prestage is generalization of the prefix. The prefix or the concept? Obviously xn-- is much shorter than, say, application/octet-stream. However, it is interesting to recall that Iana just selected a random prefix rather than setting up a registry of reserved prefixes (compare http://iana.org/cctld/ietf-announce-30jan03.txt and http://iana.org/assignments/media-types/). Given that the basic problems were similar, conveying binaries through ascii, the difference between the respective approaches is characteristic of one shot hacks versus expandable architectures. Generalizations can also stem from the enclosed space that rfc3490 has added between UDNs and ADNs. Initially filled with punycode processing, that space can be dilated at will. Its result is not necessarily a prefixed label. To the opposite, requiring a reserved prefix has stronger standardization constraints that limit the generality of the concept. I agree with Marie-France that generalizing too much may result in confusion; however, falling too short has even worse implications... From jefsey@jefsey.com Mon Jun 8 09:47:48 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 DD72E28C13E for ; Mon, 8 Jun 2009 09:47:48 -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 wsN0bkylp2ZO for ; Mon, 8 Jun 2009 09:47:47 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id D041628C173 for ; Mon, 8 Jun 2009 09:47:47 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:2622 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MDi0l-0000fO-Jx; Mon, 08 Jun 2009 09:47:52 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Jun 2009 18:47:50 +0200 To: internet users contributing group , internet users contributing group From: JFC Morfin In-Reply-To: <4A2CE5BF.40405@tana.it> References: <20090602224005.6F76A3A6900@core3.amsl.com> <4A28113D.7050304@tana.it> <7.1.0.9.2.20090604203304.03e2b250@jefsey.com> <20090607025918.6FDD64C802F@smtp4-g21.free.fr> <4A2CE5BF.40405@tana.it> 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: <20090608164747.D041628C173@core3.amsl.com> Subject: Re: [iucg] The "Internet PLUS" IUCG document is released 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, 08 Jun 2009 16:47:48 -0000 At 12:19 08/06/2009, Alessandro Vesely wrote: >JFC Morfin wrote: >>Prestag is quoted as a new term in the introduction. I will expend >>the paragraph above to indicate that prestage is generalization of the prefix. > >The prefix or the concept? The prestag concept is a generalisation of the IDNA prefix concept, the way it can be read, i.e. the use of a part of a label to convey an information to a layer, that is accepted by the DNS. >Obviously xn-- is much shorter than, say, application/octet-stream. >However, it is interesting to recall that Iana just selected a random >prefix rather than setting up a registry of reserved prefixes (compare >http://iana.org/cctld/ietf-announce-30jan03.txt and >http://iana.org/assignments/media-types/). Given that the basic >problems were similar, conveying binaries through ascii, the >difference between the respective approaches is characteristic of >one shot hacks versus expandable architectures. Actually, I proposed roughly the InterPlus to the WG-IDNA in 2002, calling the pseudonetwork layer application an "access engine" (from a large application prototype and the dot-root test bed of the DNS governance evolution). I also, underlined that the prefix was creating a left to right ("--" separated) hierachy local to each label, in addition to the right to left "." separated hierarchy. The reason why I am shy in describing is that it seems to be the usual way of IETF documents. Also, because I want to establish that InterPlus brings nothing which as not been tested for a long (the "xn--" format is tested for 8 years as transparent to the DNS). >Generalizations can also stem from the enclosed space that rfc3490 has >added between UDNs and ADNs. Yes. This is why the text takes punycode as an application/algorithm example. So, everyone understands that punycode can be respected. But that familly of application/algorithm can be indefinitly expanded (in addition of piles being concatenated) in dialoging with other appluications through the interapplication layer. Thought, the result must be a registered (I)DN to go through. BTW, I do not want to expand too much in this document, but now it is not negatively commented by some people, I will add in the Network Application description that the DNS application can be local to the user if the network being used has not it. I did not want to do that before Unbound was not released under Windows. This is now the case, however, I have not had the time yet to load and test it. > Initially filled with punycode >processing, that space can be dilated at will. Its result is not >necessarily a prefixed label. To the opposite, requiring a reserved >prefix has stronger standardization constraints that limit the >generality of the concept. If you read it well, the prestag can be a prefix or a suffix. And nothing prevents the core of the label to be empty (ab---cd), nor to read the entire label as a prestag (I think I give the example of the TLDs), nor to consider composed prestags. >I agree with Marie-France that generalizing too much may result in >confusion; however, falling too short has even worse implications... Worse, I do not know. But limiting innovative thinking yes. This is the purpose of discussing the text to also feel how far thing can/should be described in order not to hurt conservative spirits (so the position gets used) and not to block innovative ones (so it gets usefull). I plan to review the text in coming days before sending it to IAB. I will consider all your remarks in so doing. Thanks ! jfc From mfberny@gmail.com Tue Jun 9 01:12: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 1F0FF28C153 for ; Tue, 9 Jun 2009 01:12:01 -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_37=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 AuKv5qmZWy2e for ; Tue, 9 Jun 2009 01:12:00 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 2AFAD3A68EC for ; Tue, 9 Jun 2009 01:11:59 -0700 (PDT) Received: by bwz9 with SMTP id 9so3616141bwz.37 for ; Tue, 09 Jun 2009 01:12:03 -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; bh=N23fYGfyfZOjGnkSMU45smWoFHkIZAIzX03o37pU7KU=; b=tp84AWHt5YIswApl8m5NfuTa8mqz3X8ieBpXNQFElu7xDUvDqzhe7tPUZ+u7XO+6Oi uCtRztUMC3qdRK7vd0oabjzLuRHBiGgiDUqMtTv9slKMKLuo9XF6MZWnSU0H1nPVstjQ tl5i056YqzvzxF+MF7cqt5vLtVmGu2PsS9X18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=OECkCYVO5fS9aogi5rBvGrGlU2zw3+EBBP04jCnerYksJjAWQNC1WM9GV3pcYUGg6F ODZcLn1+UF+7GZAbK7gRPUbcBnWh7YEh044XqYF+nR2M6p5duDWkMBBBInEqvGtx0Osz h70EbHmqVuv8Lf6aMcBfHrnsYPQY7OmliYUUQ= MIME-Version: 1.0 Received: by 10.216.45.207 with SMTP id p57mr2647290web.94.1244535122995; Tue, 09 Jun 2009 01:12:02 -0700 (PDT) Date: Tue, 9 Jun 2009 10:12:02 +0200 Message-ID: <58ee45520906090112g387b6a3dtee2b28fe9d658393@mail.gmail.com> From: Marie-France Berny To: internet users contributing group Content-Type: multipart/alternative; boundary=0016e6db6c09eaaf27046be5e907 Subject: [iucg] IETF main: DNSSEC is NOT secure end to end 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, 09 Jun 2009 08:12:01 -0000 --0016e6db6c09eaaf27046be5e907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The refered thread at the IETF rises the question of the end to end issue when you consider the pseudonetwork layer. Some of the discussions seem appropriate. I would suggest to better phrase the text saying that the end is extended to the top of the pile, and then to talk of "top to top" service, over the network end to end.MFBerny --0016e6db6c09eaaf27046be5e907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The refered thread at the IETF rises the question of the end to end issue w= hen you consider the pseudonetwork layer. =A0Some of the discussions seem a= ppropriate. I would suggest to better phrase the text saying that the end i= s extended to the top of the pile, and then to talk of "top to top&quo= t; service, over the network end to end.
MFBerny
--0016e6db6c09eaaf27046be5e907-- From jefsey@jefsey.com Wed Jun 10 15:10: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 DE58E3A6CA2 for ; Wed, 10 Jun 2009 15:10:33 -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 NkI2dlQvc87c for ; Wed, 10 Jun 2009 15:10:33 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 38A153A6C3C for ; Wed, 10 Jun 2009 15:10:33 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:2295 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MEW0F-0002kx-E4; Wed, 10 Jun 2009 15:10:39 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 11 Jun 2009 00:10:35 +0200 To: internet users contributing group , internet users contributing group From: jefsey In-Reply-To: <58ee45520906090112g387b6a3dtee2b28fe9d658393@mail.gmail.co m> References: <58ee45520906090112g387b6a3dtee2b28fe9d658393@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: <20090610221033.38A153A6C3C@core3.amsl.com> Subject: Re: [iucg] IETF main: DNSSEC is NOT secure end to end 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, 10 Jun 2009 22:10:33 -0000 At 10:12 09/06/2009, Marie-France Berny wrote: >The refered thread at the IETF rises the question of the end to end >issue when you consider the pseudonetwork layer. Some of the >discussions seem appropriate. I would suggest to better phrase the >text saying that the end is extended to the top of the pile, and >then to talk of "top to top" service, over the network end to end. >MFBerny I think you are right. We could then stabilise our wording as : - hop to hop from machine to machine - plug to plug for telecoms - end to end from Internet edge to internet edge - top to top from Interplus' user plug - brain to brain between physical users (knowledge) - mind to mind between intellectual users (noetics, compehension) jfc From jefsey@gmail.com Mon Jun 15 11:34:25 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 46E0C3A67A1 for ; Mon, 15 Jun 2009 11:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 qw3O5AblRsm5 for ; Mon, 15 Jun 2009 11:34:24 -0700 (PDT) Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by core3.amsl.com (Postfix) with ESMTP id 522A03A67E7 for ; Mon, 15 Jun 2009 11:34:23 -0700 (PDT) Received: by fxm7 with SMTP id 7so113633fxm.37 for ; Mon, 15 Jun 2009 11:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=9nFLuibK15tgMDT4bcWMOWNJk/W7Os32amifLrQis2o=; b=h5PpxMMLj6ZS8mA181H10DciVv3EcelCa1WV8k07BT6cFBaYW6hBPAtu+cb44W6b9Z rtpnGmT1aJ52Y0P3i/aUP5DP0LxOdA5bux4yoptDnuFdF9Buzd7Vo9EPv3hZyqoBKrtW +R9L0Va2M17xDqAdG5wxWodAYUPgcDeVZV0Uo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=nWAIxlxRG5E4Im4b8AIC5lCuC5iazUKxs8SKpYzBJltXB87D5BxYkeUwrHYXh9rzk3 Sdl7M6O2ZoNh3hAPJvummAAwJRkfdEBXLcXmQbYE5uiRJpLVvGExJKi/l00EJvXeLHru oSvyJ9dGs7pVzk2Y4SEpz7La5Mfw06LjfgG7I= MIME-Version: 1.0 Sender: jefsey@gmail.com Received: by 10.204.120.16 with SMTP id b16mr7301929bkr.64.1245090845543; Mon, 15 Jun 2009 11:34:05 -0700 (PDT) In-Reply-To: <20090608164747.D041628C173@core3.amsl.com> References: <20090602224005.6F76A3A6900@core3.amsl.com> <4A28113D.7050304@tana.it> <7.1.0.9.2.20090604203304.03e2b250@jefsey.com> <20090607025918.6FDD64C802F@smtp4-g21.free.fr> <4A2CE5BF.40405@tana.it> <20090608164747.D041628C173@core3.amsl.com> Date: Mon, 15 Jun 2009 20:34:05 +0200 X-Google-Sender-Auth: daae105e3bbde853 Message-ID: <1f9674ed0906151134g7f3e309h6774f4dea97caaf9@mail.gmail.com> From: JFC Morfin To: internet users contributing group Content-Type: multipart/alternative; boundary=001636c5ab47901a1a046c674d59 Subject: Re: [iucg] The "Internet PLUS" IUCG document is released 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, 15 Jun 2009 18:34:25 -0000 --001636c5ab47901a1a046c674d59 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am sorry for being late in reviewing the Interplus document. I am overloaded with family, business and political issues. I will try to go ahead in the coming days. jfc 2009/6/8 JFC Morfin > At 12:19 08/06/2009, Alessandro Vesely wrote: > >> JFC Morfin wrote: >> >>> Prestag is quoted as a new term in the introduction. I will expend the >>> paragraph above to indicate that prestage is generalization of the prefix. >>> >> >> The prefix or the concept? >> > > The prestag concept is a generalisation of the IDNA prefix concept, the way > it can be read, i.e. the use of a part of a label to convey an information > to a layer, that is accepted by the DNS. > > Obviously xn-- is much shorter than, say, application/octet-stream. >> However, it is interesting to recall that Iana just selected a random >> prefix rather than setting up a registry of reserved prefixes (compare >> http://iana.org/cctld/ietf-announce-30jan03.txt and >> http://iana.org/assignments/media-types/). Given that the basic problems >> were similar, conveying binaries through ascii, the difference between the >> respective approaches is characteristic of one shot hacks versus expandable >> architectures. >> > > Actually, I proposed roughly the InterPlus to the WG-IDNA in 2002, calling > the pseudonetwork layer application an "access engine" (from a large > application prototype and the dot-root test bed of the DNS governance > evolution). I also, underlined that the prefix was creating a left to right > ("--" separated) hierachy local to each label, in addition to the right to > left "." separated hierarchy. > > The reason why I am shy in describing is that it seems to be the usual way > of IETF documents. Also, because I want to establish that InterPlus brings > nothing which as not been tested for a long (the "xn--" format is tested for > 8 years as transparent to the DNS). > > Generalizations can also stem from the enclosed space that rfc3490 has >> added between UDNs and ADNs. >> > > Yes. This is why the text takes punycode as an application/algorithm > example. So, everyone understands that punycode can be respected. But that > familly of application/algorithm can be indefinitly expanded (in addition of > piles being concatenated) in dialoging with other appluications through the > interapplication layer. Thought, the result must be a registered (I)DN to go > through. > > BTW, I do not want to expand too much in this document, but now it is not > negatively commented by some people, I will add in the Network Application > description that the DNS application can be local to the user if the network > being used has not it. I did not want to do that before Unbound was not > released under Windows. This is now the case, however, I have not had the > time yet to load and test it. > > Initially filled with punycode >> processing, that space can be dilated at will. Its result is not >> necessarily a prefixed label. To the opposite, requiring a reserved >> prefix has stronger standardization constraints that limit the >> generality of the concept. >> > > If you read it well, the prestag can be a prefix or a suffix. And nothing > prevents the core of the label to be empty (ab---cd), nor to read the entire > label as a prestag (I think I give the example of the TLDs), nor to consider > composed prestags. > > I agree with Marie-France that generalizing too much may result in >> confusion; however, falling too short has even worse implications... >> > > Worse, I do not know. But limiting innovative thinking yes. This is the > purpose of discussing the text to also feel how far thing can/should be > described in order not to hurt conservative spirits (so the position gets > used) and not to block innovative ones (so it gets usefull). > > I plan to review the text in coming days before sending it to IAB. I will > consider all your remarks in so doing. > Thanks ! > jfc > > > > _______________________________________________ > iucg mailing list > iucg@ietf.org > https://www.ietf.org/mailman/listinfo/iucg > --001636c5ab47901a1a046c674d59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am sorry for being late in reviewing the Interplus document. I am overloa= ded with family, business and political issues. I will try to go ahead in t= he coming days.
jfc
=A0

2009/6/8 JF= C Morfin <jefsey@= jefsey.com>
At 12:19 08/06/2009, Alessandro Vesely wrote:
JFC Morfin wrote:
Prestag is quoted as a new term in the introduction. I will expend the para= graph above to indicate that prestage is generalization of the prefix.

The prefix or the concept?

The prestag concept is a generalisation of the IDNA prefix concept, the way= it can be read, i.e. the use of a part of a label to convey an information= to a layer, that is accepted by the DNS.


Obviously xn-- is much shorter than, say, application/octet-stream.
However, it is interesting to recall that Iana just selected a random
prefix rather than setting up a registry of reserved prefixes (compare
http://iana.org/cctld/ietf-announce-30jan03.txt and
http= ://iana.org/assignments/media-types/). Given that the basic problems we= re similar, conveying binaries through ascii, the difference between the re= spective approaches is characteristic of one shot hacks versus expandable a= rchitectures.

Actually, I proposed roughly the InterPlus to the WG-IDNA in 2002, calling = the pseudonetwork layer application an "access engine" (from a la= rge application prototype and the dot-root test bed of the DNS governance e= volution). I also, underlined that the prefix was creating a left to right = ("--" separated) hierachy local to each label, in addition to the= right to left "." separated hierarchy.

The reason why I am shy in describing is that it seems to be the usual way = of IETF documents. Also, because I want to establish that InterPlus brings = nothing which as not been tested for a long (the "xn--" format is= tested for 8 years as transparent to the DNS).


Generalizations can also stem from the enclosed space that rfc3490 has
added between UDNs and ADNs.

Yes. This is why the text takes punycode as an application/algorithm exampl= e. So, everyone understands that punycode can be respected. But that famill= y of application/algorithm can be indefinitly expanded (in addition of pile= s being concatenated) in dialoging with other appluications through the int= erapplication layer. Thought, the result must be a registered (I)DN to go t= hrough.

BTW, I do not want to expand too much in this document, but now it is not n= egatively commented by some people, I will add in the Network Application d= escription that the DNS application can be local to the user if the network= being used has not it. I did not want to do that before Unbound was not re= leased under Windows. This is now the case, however, I have not had the tim= e yet to load and test it.


=A0Initially filled with punycode
processing, that space can be dilated at will. Its result is not
necessarily a prefixed label. To the opposite, requiring a reserved
prefix has stronger standardization constraints that limit the
generality of the concept.

If you read it well, the prestag can be a prefix or a suffix. And nothing p= revents the core of the label to be empty (ab---cd), nor to read the entire= label as a prestag (I think I give the example of the TLDs), nor to consid= er composed prestags.


I agree with Marie-France that generalizing too much may result in confusio= n; however, falling too short has even worse implications...

Worse, I do not know. But limiting innovative thinking yes. This is the pur= pose of discussing the text to also feel how far thing can/should be descri= bed in order not to hurt conservative spirits (so the position gets used) a= nd not to block innovative ones (so it gets usefull).

I plan to review the text in coming days before sending it to IAB. I will c= onsider all your remarks in so doing.
Thanks !
jfc



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

--001636c5ab47901a1a046c674d59-- From jefsey@jefsey.com Fri Jun 19 15:17:27 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 2D8E43A6A59 for ; Fri, 19 Jun 2009 15:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.28 X-Spam-Level: * X-Spam-Status: No, score=1.28 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, SARE_CHILDPRN1=1.15, SARE_MILLIONSOF=0.315] 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 rUVtp5D8dEdw for ; Fri, 19 Jun 2009 15:17:26 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 06B893A6A31 for ; Fri, 19 Jun 2009 15:17:25 -0700 (PDT) Received: from 125.143.98-84.rev.gaoland.net ([84.98.143.125]:1482 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MHmOw-0002B4-9y; Fri, 19 Jun 2009 15:17:38 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 19 Jun 2009 23:30:58 +0200 To: governance@lists.cpsr.org, David Goldstein , governance@lists.cpsr.org From: JFC Morfin In-Reply-To: <441605.48126.qm@web58907.mail.re1.yahoo.com> References: <874c02a20906171714t3779606atee614d0829f111e0@mail.gmail.com> <67248.907.qm@web58906.mail.re1.yahoo.com> <4A39A44B.6030902@zedat.fu-berlin.de> <441605.48126.qm@web58907.mail.re1.yahoo.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: <20090619221726.06B893A6A31@core3.amsl.com> Cc: iucg@ietf.org Subject: [iucg] The dawning of Internet censorship in Germany 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, 19 Jun 2009 22:17:27 -0000 David, Joe, Peter and all, technically this debate seems senseless, because the internet being discussed just does not exist. Neither in law, nor in technology. This is the first problem we meet everywhere. Please first legally define what you are talking about. So the debate may stop being emotional, subjective, irreal, etc. On one side we are talking of bits and protocols, on the other side we are talking of human behaviour and laws. Let start from an example David and Joe know well: domain names. The worldwide claimed and acclaimed ICANN success is UDRP. The UDRP document starts with a legal recital, documenting the meaning of theterms being used, ... except what a ... domain name is. The US and new IETF definition of the Internet is every packetswitch network interoperable computer. And both understand it as under their political/technical jurisdiction or influence. The French law, which is an application of the European directives, discusses the "public online communication" that may use the "internet" (small "i") : it does not bother defining (this is no more legal but common terminology). The first question is therefore: what are we talking about. What are discussed here are not laws to punish crime that would actually (100% or not) prevent crimes, but laws that would prevent bows and arrows to be able to kill specific targets [quite hazardeous] while everyone may have access to guns [what makes the debate somewhat outdated]. While also, nobody realizes that the IETF "standards" are just "influences" (the very IETF mission definition by RFC 3935) to make the Internet work in a way the IETF better along its own core values. By no means they are describing any technical obligations or reality. It happens that the Internet we use everyday is by far more powerfull and versatile, and that it is actually more and more used everyday in ways which architecturally are sounder than the way ICANN, ISOC, and Govs believes it. This is no surprise for the IETF (this is plainly explained in the very same RFC 3935: the IETF is here to analyse, document, integrate new developments made outside of it). Today such developments are taking advantage from IDNs and are carried by China and hundred of millions of users. The current technology we use makes intercontinental machine guns free and available everywhere. Summary: what you discuss are the relations between two orthogonal things: technology and law. In addition they have different development cycles, no common basis (as people are not left any control in the way the technology is designed) and different "jurisdictions". Protocols are for machines, laws are for people. The interesting issue in Hadopi and other legislations is that they want to impose laws on machines to force people to respect societal protocols, upto making machines to judge people. jfc At 13:25 18/06/2009, David Goldstein wrote: >Ralf, > >Laws don't ever, or almost never, stop the problem they set out to >do. They merely set out to reduce the problem to a certain extent. >There are laws against murder, yet there is still murder. So you are >wrong - it is analogous to speeding. Expecting any law to stop >something 100% is naive. > >As for Baptista, Dambier and their cast of fools, maybe you should >first understand the difference between child protection, that is >protecting children from unsuitable content online, and child abuse >where children are actually abused. > >And thank you Rui for a thoughtful contribution to the debate. > >As for suggestions tens of thousands have signed online petitions. >Really? So what? What minuscule percentage actually understood what >they were signing? > > >David > > > >----- Original Message ---- >From: Ralf Bendrath >To: governance@lists.cpsr.org; David Goldstein >Sent: Thursday, 18 June, 2009 12:19:55 PM >Subject: Re: [governance] The dawning of Internet censorship in Germany > >I don't want to sound like a supporter of Joe Baptista or Peter Dambier >here, but I also don't want unfounded things to be said about the >censorship conflict in Germany. So: > >David Goldstein schrieb: > > > To use the argument that blocking child pornography is ineffective is > > nonsensical. People still speed in cars yet there are laws against > > speeding. It certainly changes behaviour though. > >No. It's about stopping cars that (maybe accidentially) head to a wrong >direction instead of just arresting the wrong guy at the endpoint. So >much for analogies. > > > However given the childish arguments put forward by people like > > Dambier, I wouldn't expect there to be much knowledge on such issues. > >Don't troll unles needed, David. Especially without knowledge about the >situation in Germany. > >There have been many, many, and many more arguments raised in the Gernan >debate since April. Result: Total ignorance. > > > The issue is how far does such a list such as proposed by the German > > government, and also the Australian government, go. If it's used to > > block content such as child porn, great. If it goes further, then > > it's a problem. > >The fundamental problem is: We will never know. The list is run by the >German Federal Police, it's secret, and there is close to zero >oversight. No judge, no prescribed procedures for taking sites off the >(un-known black) list, no nothing. > >Ralf > > > > Access Yahoo!7 Mail on your mobile. Anytime. Anywhere. >Show me how: http://au.mobile.yahoo.com/mail >____________________________________________________________ >You received this message as a subscriber on the list: > governance@lists.cpsr.org >To be removed from the list, send any message to: > governance-unsubscribe@lists.cpsr.org > >For all list information and functions, see: > http://lists.cpsr.org/lists/info/governance From stelancel@gmail.com Tue Jun 23 05:24:12 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 4FEA63A6999 for ; Tue, 23 Jun 2009 05:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 46pR8M5bCUsV for ; Tue, 23 Jun 2009 05:24:11 -0700 (PDT) Received: from mail-fx0-f169.google.com (mail-fx0-f169.google.com [209.85.220.169]) by core3.amsl.com (Postfix) with ESMTP id 36AE83A6BD5 for ; Tue, 23 Jun 2009 05:24:11 -0700 (PDT) Received: by fxm17 with SMTP id 17so2404fxm.13 for ; Tue, 23 Jun 2009 05:24:23 -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=p9X2b3VN/ffblb4frLse6FIvJckWb0O3h8sZ5mNie8c=; b=PJMVDKE06P9kmrTKnlO1b8/X9E5E/e9ZaeveTt+fb4iA7ZbQiolceA1k+vib/JiFsP d+WMEPau9PgCLuaE6v5wKlnQttE85zIObdoDsRuY757fxQ5rVCHtqNyBMDXmY84RHSFS 35RA/xz0+2Xf36KXK0AZmoH+aya6QeAwQa03g= 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=b7T4Yx24Ga/b5ssYVmqfCptJmKOH3kIj3ZTG+d7vEldmwChW/m9DYK5EGSouxjBrW8 YPFWbjfkB4fXP1G0b/bUncttuIbUwdxe0q+sjPslYYL1zWmUH5LjlW8K+7UvYSb/bNs/ LhPZ8puMiDCl2O9u2ENVTQu0T/cpjE+SM/nNg= MIME-Version: 1.0 Received: by 10.239.150.144 with SMTP id n16mr593330hbb.132.1245759862904; Tue, 23 Jun 2009 05:24:22 -0700 (PDT) Date: Tue, 23 Jun 2009 14:24:22 +0200 Message-ID: <5b164ee60906230524u4fb41e3bnae9a66374200ec7c@mail.gmail.com> From: =?ISO-8859-1?Q?St=E9phane_Lancel?= To: iucg@ietf.org Content-Type: multipart/alternative; boundary=001485f5b1961a9866046d031228 Cc: idna-update@alvestrand.no Subject: [iucg] wikidna 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, 23 Jun 2009 12:24:12 -0000 --001485f5b1961a9866046d031228 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have updated the http://wikidna.org/index.php?title=3DIDNA_definitions pa= ge with the new text of John. St=E9phane. --001485f5b1961a9866046d031228 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have updated the http://wikidna.org/index.php?title=3DIDNA_definitions page wi= th the new text of John.
St=E9phane.

--001485f5b1961a9866046d031228-- From mfberny@gmail.com Tue Jun 23 05:41: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 B97EB28C2F0 for ; Tue, 23 Jun 2009 05:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 jd+MBWFweImi for ; Tue, 23 Jun 2009 05:41:02 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 5661B3A6881 for ; Tue, 23 Jun 2009 05:41:02 -0700 (PDT) Received: by ewy6 with SMTP id 6so45063ewy.37 for ; Tue, 23 Jun 2009 05:41:13 -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=9iBs4rtmNMlYjOwwPe2dV59mI4D+TYYmo5+mW9FEFuA=; b=aZy9N1Ze8iP+SyVlvKKisKWMELf7cIMO3OvJfdDCIGjLjOgv13FmgJZqcD+YCkgxLz tqqODGl5rnzGha0SihfYy7UJoCa+6BOjTNL3NROHB/2dwue0wk9HTIOSyqxfQ6CxOkJR Psv9WvYeaOATooAC7Zno0M45k+BAqkM6WBioY= 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=rl4+CUpJzzTAHR/sX4mYQWAePF7hx19y2CQvOwiXk3a5AlVwVQnvFDupQUjHEyxL9I tWE2ehnesIhC27DYxF4KwBhCVTzD9tDuqtx3KiVv4BGiEHHLuVorYGg/eEmJVZOidf+c Urs57bmp6S0yLkJIFRUVV6Aaqv0eHZlODWe7s= MIME-Version: 1.0 Received: by 10.210.128.5 with SMTP id a5mr6275175ebd.83.1245760873858; Tue, 23 Jun 2009 05:41:13 -0700 (PDT) In-Reply-To: <5b164ee60906230524u4fb41e3bnae9a66374200ec7c@mail.gmail.com> References: <5b164ee60906230524u4fb41e3bnae9a66374200ec7c@mail.gmail.com> Date: Tue, 23 Jun 2009 14:41:13 +0200 Message-ID: <58ee45520906230541g4f4cef3dncc9bf4f8809484a8@mail.gmail.com> From: Marie-France Berny To: internet users contributing group Content-Type: multipart/alternative; boundary=0015174c13b25c8846046d034e24 Cc: idna-update@alvestrand.no Subject: Re: [iucg] wikidna 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, 23 Jun 2009 12:41:03 -0000 --0015174c13b25c8846046d034e24 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 23 juin 2009 14:24, St=E9phane Lancel a =E9crit : > I have updated the http://wikidna.org/index.php?title=3DIDNA_definitionsp= age with the new text of John. > St=E9phane. Thank you! The best would be to amalgamate all the language support oriente= d definitions in a single ontology that could be kept updated along the project/rfc variations. Elisabeth suggested that? I have asked JFC if I could help reviewing the Interplus/Internet Plus documents so we could start building on ML-DNS for the semantic addressing for .fra. He said he is right now overwhelmed by his support of his seek parents. He proposed a meeting in Paris on the July 7+ week over the whole "Project .FRA" intertest. I will not be able to make it. Who could attend ? He suggests that we put a general presentation together that we could forward to IAB and Francophonie authorities (in addition to the document sent three weeks ago). The question is who could do that and what is the best approach (bottom up, top down, systemic?). I understand that Project FRA is staffing a little bit. They still look for one or two developpers to complete and deploy tests. This might help many t= o better understand how they could at last use or get rid of IDNA. Marie-France Berny --0015174c13b25c8846046d034e24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Le 23 juin 2009 14:24, St=E9phane Lancel <stelancel@gmail.com> a =E9crit :
I have updated the http://wikidna.org/index.php?title=3DIDNA_defin= itions page with the new text of John.
St=E9= phane.

Thank you! The best would be to amalgamate all the language suppor= t oriented definitions in a single ontology that could be kept updated alon= g the project/rfc variations. Elisabeth suggested that?

I have aske= d JFC if I could help reviewing the Interplus/Internet Plus documents so we= could start building on ML-DNS for the semantic addressing for .fra. He sa= id he is right now overwhelmed by his support of his seek parents. He propo= sed a meeting in Paris on the July 7+ week over the whole "Project .FR= A" intertest. I will not be able to make it. Who could attend ?

He suggests that we put a general presentation together that we could f= orward to IAB and Francophonie authorities (in addition to the document sen= t three weeks ago). The question is who could do that and what is the best = approach (bottom up, top down, systemic?).

I understand that Project FRA is staffing a little bit. They still look= for one or two developpers to complete and deploy tests. This might help m= any to better understand how they could at last use or get rid of IDNA.

Marie-France Berny

--0015174c13b25c8846046d034e24-- From jmabdp@gmail.com Tue Jun 23 18:23: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 BB8D93A6F0D for ; Tue, 23 Jun 2009 18:23:35 -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 LUL7STNd0ub7 for ; Tue, 23 Jun 2009 18:23:34 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 53AF13A6994 for ; Tue, 23 Jun 2009 18:23:34 -0700 (PDT) Received: by ewy6 with SMTP id 6so719223ewy.37 for ; Tue, 23 Jun 2009 18:23:47 -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=DFKcbZjQewjEhXiB2uMzqQZuSS+f9twNtdn40tP5qsI=; b=mLGnJ5nZIJTWZv0kjA6PibBjN+9vnFtAza6Qjl3H0OPw8tB7Knaqp+UZ4i6nNRC19u jfbG+OhCOEssynmJIyat3zMfMX0R0DYlbYF7XOtbtgvoH6fm7Itd8ibI4663QG24KyvR eEmpm/u/4joUjJ2OQ/9j/Er/KA9eWRh6dsnfg= 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=iFqcwj03Vg6JPdfCLHj9ikPYbacTBk+zEQKQKuInY38neERZauJcg+5iAEpmxUD43x uOxkW2fDBO52z+2FJWJ5Mn95jOoyAOascEAKDd3jw+LIv25dlSEZUdkQJ/PE1NoO77rr bQCb8O8x1B3UctOVZTNJr/UiOib8q+blMI5QE= MIME-Version: 1.0 Received: by 10.216.19.17 with SMTP id m17mr198464wem.187.1245806627255; Tue, 23 Jun 2009 18:23:47 -0700 (PDT) In-Reply-To: <58ee45520906230541g4f4cef3dncc9bf4f8809484a8@mail.gmail.com> References: <5b164ee60906230524u4fb41e3bnae9a66374200ec7c@mail.gmail.com> <58ee45520906230541g4f4cef3dncc9bf4f8809484a8@mail.gmail.com> Date: Wed, 24 Jun 2009 03:23:47 +0200 Message-ID: <6aad7a210906231823j670a5338s470d028a3b2c2ed@mail.gmail.com> From: jean-michel bernier de portzamparc To: internet users contributing group Content-Type: multipart/alternative; boundary=0016364c76ff79f70b046d0df56b Cc: idna-update@alvestrand.no Subject: Re: [iucg] wikidna 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: Wed, 24 Jun 2009 01:23:35 -0000 --0016364c76ff79f70b046d0df56b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marie-France, You also copied the IDNA list. Your last sentence may be quite confusing fo= r them. No IUCG participant so far wants to "get rid of IDNA"! However, it is true that the IDNA presentation will have to be bypassed if this WG is permitted to disregard its charter and did map at protocol level.None has posted for long to support this idea of a non-neutral international Internet, except may-be Mark Davis? Jean Michel Bernier ---------- Forwarded message ---------- From: Marie-France Berny Date: 2009/6/23 Subject: Re: [iucg] wikidna update To: internet users contributing group Cc: idna-update@alvestrand.no Le 23 juin 2009 14:24, St=E9phane Lancel a =E9crit : > I have updated the http://wikidna.org/index.php?title=3DIDNA_definitionsp= age with the new text of John. > St=E9phane. Thank you! The best would be to amalgamate all the language support oriente= d definitions in a single ontology that could be kept updated along the project/rfc variations. Elisabeth suggested that? I have asked JFC if I could help reviewing the Interplus/Internet Plus documents so we could start building on ML-DNS for the semantic addressing for .fra. He said he is right now overwhelmed by his support of his seek parents. He proposed a meeting in Paris on the July 7+ week over the whole "Project .FRA" intertest. I will not be able to make it. Who could attend ? He suggests that we put a general presentation together that we could forward to IAB and Francophonie authorities (in addition to the document sent three weeks ago). The question is who could do that and what is the best approach (bottom up, top down, systemic?). I understand that Project FRA is staffing a little bit. They still look for one or two developpers to complete and deploy tests. This might help many t= o better understand how they could at last use or get rid of IDNA. Marie-France Berny _______________________________________________ iucg mailing list iucg@ietf.org https://www.ietf.org/mailman/listinfo/iucg --0016364c76ff79f70b046d0df56b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marie-France,
You also copied the IDNA list. Your last sentence may be q= uite confusing for them.

No IUCG participant so far wants to "= get rid of IDNA"! However, it is true that the IDNA presentation will = have to be bypassed if this WG is permitted to disregard its charter and di= d map at protocol level.None has posted for long to support this idea of a = non-neutral international Internet, except may-be Mark Davis?

Jean Michel Bernier


---------- Fo= rwarded message ----------
From: Marie-Fra= nce Berny <mf= berny@gmail.com>
Date: 2009/6/23
Subject: Re: [iucg] wikidna update
To: internet users= contributing group <iucg@ietf.org&= gt;
Cc: idna-update@alvestr= and.no


Le 23 juin 2009 14:24, St=E9phane Lancel= <stelancel@gmail.com> a =E9crit :

I have updated the http://wikidna.org/index.php?title=3DIDNA_defin= itions page with the new text of John.
St=E9= phane.

Thank you! The best would be to amalgamate all the language = support oriented definitions in a single ontology that could be kept update= d along the project/rfc variations. Elisabeth suggested that?

I have asked JFC if I could help reviewing the Interplus/Internet Plus docu= ments so we could start building on ML-DNS for the semantic addressing for = .fra. He said he is right now overwhelmed by his support of his seek parent= s. He proposed a meeting in Paris on the July 7+ week over the whole "= Project .FRA" intertest. I will not be able to make it. Who could atte= nd ?

He suggests that we put a general presentation together that we could f= orward to IAB and Francophonie authorities (in addition to the document sen= t three weeks ago). The question is who could do that and what is the best = approach (bottom up, top down, systemic?).

I understand that Project FRA is staffing a little bit. They still look= for one or two developpers to complete and deploy tests. This might help m= any to better understand how they could at last use or get rid of IDNA.

Marie-France Berny


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


--0016364c76ff79f70b046d0df56b-- From jefsey@jefsey.com Tue Jun 30 06:30: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 2FE513A6E79 for ; Tue, 30 Jun 2009 06:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 gSzNFnLGO7AV for ; Tue, 30 Jun 2009 06:30:39 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 0B8173A6E6E for ; Tue, 30 Jun 2009 06:30:39 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:4861 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MLdOx-0005Rw-PC; Tue, 30 Jun 2009 06:29:36 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Jun 2009 15:29:30 +0200 To: iucg@ietf.org 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: <20090630133039.0B8173A6E6E@core3.amsl.com> Cc: idna-arabicscript@lists.irnic.ir Subject: [iucg] IDNA confusion 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, 30 Jun 2009 13:30:41 -0000 Marie France, I will comment in Franglish sor you can quote it to who you want. It will follows a metatechnic line that your interlocutors will not be familiar with. So, I will detail some aspects. I am tied with familly obligations, hence late on my promise to documents project .fra (more than one month). I apologize for that to everyone, friends and foes alike because it does not help their debate. >On Mon, Jun 29, 2009 at 07:21:22PM +0200, Marie-France Berny wrote: > > 2009/6/29 Andrew Sullivan > > > Please don't hijack this thread. > > ???? > >I mean that the thread was talking about one thing, and you have >introduced a different topic. It appears you're doing so unwittingly, >but I want not to conflate these two topics. I understand Andrew's fear. However, he himself acknowledges that he does not know if, from your point of view, this is or not the same topic. This very well identifies that the problem is not in the detail but in the architectural point of view. This should therefore be out of the WG concerns, except that the solution I agree and Vint disagree with is already documented in the WG Charter. No mapping at protocol level. > > > The mapping of lower-case non-ASCII characters with respect to upper-case > > > apparently-ASCII characters is _not_ the same question as the effects of > > > lower- and upper-case ASCII across the U-label/A-label boundary. Yes it is. In this case this is because the DNS casefolding obeys a particular orthotypography that conflicts with the French language orthotypography. The way Andrew describes the problem, you cannot solve this. The way they build and understand the internet (all the interoperable coputers via IETF packet switch networks - USC and RFC 3935) you cannot. The way we observe their internet as part of the online public communications and services ecosystem (French legal definition) the solution is built-in. This is the very common situation of our time that Edgar Morin has identified as "complex thinking", i.e. bottom/up (inductive) top/down (deductive) assisted reasoning. This problem is discussed with for centuries (Aristoteles, Vinci, Descartes, Kant, Wienner, Von Bertalanffy, Von Foerster, etc. ) with some recent progresses. The way it is eventually addressed in here (due to the practical daily global impact of IDNs) will most probably influence its resolution everywhere in science, politics, society, culture, etc. This is why there is a direct opposition between us and Unicode for years. French speakers, and Unicoders do not understand this problem the same way as others. The reason why is that the very purpose assigned : - to Unicode is to suppress the problem through globalization, i.e. English internationalization, localization and language filtering. - to the French language 470 years ago, on August 10: precisely to address that problem in being the language of the Law, i.e. the pregnancy of the social system saillances, if to speak as René Thom. > > I am sorry. I have not the slightest idea of what you are talking about. I > > read an attempt to come to a quick conclusion regarding punycode and where > > to carry mapping. Or am I wrong? > >Wrong, I'm afraid. The specific question was about ASCII characters >that _remain ASCII_ when using Punycode to transform the label. So >for instance, in > > abcdé > >and > > ABCDé > >the 'abcd' and 'ABCD' parts are not, strictly speaking, touched by >Punycode. Correct in their reading, and along Unicode's confusion between "capitales" and "majuscules". Unicode supports an International English able to quote foreign scripts and languages. By simplification we all have accepted it to some extend so one could use the English/DNS orthotypography instead of adding French (and others) orthotypography considerations to a prototype system. The result is that the French "a", "A" etc. are considered as a single casefoldable character, while they are not. This is not a DNS, nor a punycode issue, this is a Unicode issue. This means that the DNS is not concerned, punycode is to be informed, and Unicode is to be completed. >Under IDNA2003 there's a simple answer for this, because of >the way it works. Under IDNA2008, the earliest proposals did no >mapping at all, and we haven't settled what mapping if any will >happen. Therefore, there is a question about what to do with these >particular cases. This is already solved by the presentation layer. The issue is not how to address the problem, but how the Internet architecture does already address it. I accept that the impact on the Internet may be important. However, we tried to keep the things smooth, abiding by the Charter, documenting how we would extend IDNA on an as needed bassis. Most of the informed people supported us. When we have been attacked again, we had no choice but to start documenting how the presentation layers, and extended services, work in the Internet architecture, in order to try to reduce the number of alternative usages we saw being investigated. > > As far as I understand, there is one clarification missing. It is what do > > you define as "global" in here. Are French (and possibly Persian, and > > probably many others...) included? > >Yes, in the sense that there is one giant domain name system under >which everything has to fit, because the whole system is a tree >structure with one root. This is the way IETF understands the Internet. This has to be respected as much as possible because this is what insures the current economic and politic stability of the Internet. But the Internet architecture is built to support billions of (class and presentations) roots. The only possibility to keep things stable (at least to give time to understand the issue and fairly document it to politicians) is to present the current namespace as the semantic name space default, and to support IDNs in it. Project .fra should also give some time since it will be presented as a test-bed other language may benefit from and participate in. >(I'll leave aside for the moment the >possibility of "alternate roots", since every actual example of that >is in fact just a change of the servers holding the "unique root", and >not a change to the principle that there is a spot where the namespace >starts.) This is technically correct (except that TLD conflicts will introduce pollution), but do not takes into accound private, class, and presentation roots. We need to consider the virtual root matrix, as our dot-root experimentation documented it years ago, when we responded to the ICP-3 call for a community test-bed. However, at that time we discussed national matrices. Today we are speaking of individual matrices. >If you mean, "Will it support French, Persian, English, Chinese, >Arabic, and any other language Unicode supports in ways that are >completely natural to the readers and writers of those languages?" the >answer is, "No, and that was never the goal." Correct. This is our goal, this is not their goal. This was made very clear by Vint and James Seng. This is why we introduced the ML-DNS and promised to protect compatibility. What they did not understand is that "ML" does not stand specifically for "multilingual" but for "multi-layer" and as a result for "multi-ledger". In so doing they are constraning the Internet capacity (try to lock-out the presentation layer). >As several people have >said several times, the goal is not to be able to write literature in >the DNS. The goal is just to internationalize the DNS, subject to the >limitations of the existing DNS. Correct: this is their goal. There are two misunderestandings in this goal: - nobody talks of litterature, but of orthotypography, i.e. to respect the semantic implied by the typography. - no one ever wanted to internationalize the DNS nor to change it. The goal is to "internationalize" (we want to "globalise") the domain names. >One of those limitations turns out to be the (in my opinion >unfortunate) DNS property that it is case-preserving but >case-insensitive. This is a DNS feature. We have to accept it if we want to use the DNS. Actually it turns to be fortunate, because it simplifies the numbering (0-Z) of the domain name labels. >As a historical fact, ExAmPlE.org, example.org, >EXAMPLE.org, EXAMPLE.ORG, and example.ORG are all "equivalent" for the >matching rules. On my interpretation, the DNS server ought to return >an answer to any of those queries with the name as it appears in the >zone file, but some do other things (such as return a pointer to the >question section, which means you get back the form as you asked it). This is exactly what permits to use and trust the DNS. >What you are asking is, I'm sure, a completely natural extension of >that principle in your view: you want école.fra to match ECOLE.FRA. No. We want école.fra to match école.fra at the application layer (this is IDNA, not the DNS) and nothing else. The same as for every other non ACC >The problem is that this doesn't work the same way, because ecole.fra >and ECOLE.FRA also match each other, so now we have an ambiguous >combination. And that's only in the case where you actually know the >label is "in French" -- already an extremely complicated problem, >since we don't have a universally agreed-upon authority as to what >language any given word is in. (You can't learn it from the DNS >without either an additional query or special processing on the server >side, both of which rules are, as far as I understand, antirequisites >for the current work.) The DNS belongs to the service layer. What we discuss here belongs to the presentation layer. The relation between them is punycode. >Note that, in some contexts in English, it would be very surprising >that case didn't matter. If case were not important in English, then >we would have lost them some time ago (also, a signficant body of >poetic work would be affected). This is not a battle between people >who speak English and whose every natural impulse is accommodated >vs. everyone else. It's just a matter of finding the set of >compromises that will fit within the compromises that were already set >when the DNS became successful. As you fully understand, this is nothing of this kind. It is the technical capacity of the system to support people's specs or people to accept systems constraints. Who is the master, who is the slave (this is the way people will feel about it). Actually this is a pure RFC 3869: the merchant or the user. If mapping is made by the user, the merchant has no more control on him/her/ >All of the above said, as far as I know the mapping document is still >open for comment. If you know some way by which these mappings are >achievable, I'm sure everyone would love to hear them. We gave them the IUCG url. This does not speak to them. They need three things : - an I_D based documentation (I am late in folding all your contributions) - some runing code (we miss developpers) - a visible community test-bed, this is the project-fra (it progresses - I hope we have a good meeting in it on July 7th in Paris - anyone interested ?) On our side we need time, work and money. The project rendez-vous should be in october. Three months, a well documented work list for a few of us, and different funding sources (we already have a part-time professionnal facilitator [Laure-Emmanuelle] and a document publisher [Ségolène]) However, if they do not want to go on the IUCG or if the notes there are not clear enough, let remind them: 1. we comprehend genralized communications as made of three strata : telecoms, datacoms and metacoms. 2. as lead users we are interested in the Intersem, semantic, multilingual and semiotic international usage network for the people. So it addresses the metacoms needs. 3. the current datacoms stratum technologies do not offer the service pile we need to support the metacoms stratum. We therefore document the Interplus (pluggable layers users' systemic) Internet pile extension. The untouched Internet and the Interplus makes the Internet Plus we need. We document the Interplus so the Internet pile is unchanged. We are not particularly interested in IDNA, but for the user convenience it will be simpler to use IDNA when appropriate and benefit from its work. The only thing we need is the Internet to stay neutral (i.e. it could be replaced by another technology transparently to the Interplus and to the users). This means not to confuse apping at Network (protocol) and User (off-protocol) applications layers. jfc From jefsey@jefsey.com Tue Jun 30 18:38:13 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 9363B3A69F2 for ; Tue, 30 Jun 2009 18:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 l-pzPYPMudv9 for ; Tue, 30 Jun 2009 18:38:13 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 053813A6928 for ; Tue, 30 Jun 2009 18:38:13 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:1626 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MLomN-0006kH-HA; Tue, 30 Jun 2009 18:38:31 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Jul 2009 02:42:01 +0200 To: Andrew Sullivan , "Arabic Scripts IDNA" From: JFC Morfin In-Reply-To: <20090630151238.GB3059@shinkuro.com> References: <20090630151238.GB3059@shinkuro.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: <20090701013813.053813A6928@core3.amsl.com> Cc: 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: Wed, 01 Jul 2009 01:38:13 -0000 At 17:12 30/06/2009, Andrew Sullivan wrote: >and, in particular, if we want to be sensitive to such upper and >lower case when the data comes back to us from the DNS resolver level. Please, let not confuse : 1) the DNS layer, where you run the game the way you want according to your published rules, and the Application Domain Names. 2) French majuscules and upper cases. The U-label, A-label, etc. wording IMHO helps that confusion. Is Ecole.fra an U-label or an A-label? All I know is that it is an application domain name (like in "IDNA"). Also, that if the proposed text does not actually document the "ecole.fra, école.fra, Ecole.fra" case, this case will have to be documented during the IETF/LC. May be it is the best thing to do? so the whole IETF community may decide what does concern the whole community? jfc From vint@google.com Tue Jun 30 19:19:28 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 C2E8B3A69D3 for ; Tue, 30 Jun 2009 19:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 fHo6Cv7s4sX8 for ; Tue, 30 Jun 2009 19:19:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id B9FDB3A65A6 for ; Tue, 30 Jun 2009 19:18:44 -0700 (PDT) Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id n612InMg023280 for ; Wed, 1 Jul 2009 03:18:50 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1246414730; bh=xdmqQ9pJTtdxU2fIun92JmCcLEQ=; 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=W0Cf2rcNtyWAOhiEof+nd7ww qa+1x220Y+P7ONrqqdUls7n39Uwg7no36C1SlCZpYPEsGZfLEnrpK1N6kWbiiA== 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=qoIs2dsN69P6jfg9nWgNFkmwpDNC8KC1abIOmkCthmiIoIV9uUlUfJ9U9K8ZSSTla sKBXaVwfRmZJWWadd/KRQ== Received: from wa-out-1112.google.com (wahv33.prod.google.com [10.114.248.33]) by zps38.corp.google.com with ESMTP id n612IkbC019329 for ; Tue, 30 Jun 2009 19:18:47 -0700 Received: by wa-out-1112.google.com with SMTP id v33so116455wah.7 for ; Tue, 30 Jun 2009 19:18:46 -0700 (PDT) Received: by 10.114.173.8 with SMTP id v8mr14508829wae.169.1246414725363; Tue, 30 Jun 2009 19:18:45 -0700 (PDT) Received: from dhcp-172-19-70-104.mtv.corp.google.com (dhcp-172-19-70-104.mtv.corp.google.com [172.19.70.104]) by mx.google.com with ESMTPS id n6sm1292791wag.4.2009.06.30.19.18.42 (version=SSLv3 cipher=RC4-MD5); Tue, 30 Jun 2009 19:18:43 -0700 (PDT) Message-Id: From: Vint Cerf To: JFC Morfin In-Reply-To: <200907010138.n611cX3Q021352@ns1.irnic.ir> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 30 Jun 2009 22:18:40 -0400 References: <20090630151238.GB3059@shinkuro.com> <200907010138.n611cX3Q021352@ns1.irnic.ir> X-Mailer: Apple Mail (2.930.3) X-System-Of-Record: true Cc: Andrew Sullivan , iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: 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: Wed, 01 Jul 2009 02:19:28 -0000 jefsey, it cannot be an A-label since that is defined to include =20 "xn--" as a prefix. v On Jun 30, 2009, at 8:42 PM, JFC Morfin wrote: > At 17:12 30/06/2009, Andrew Sullivan wrote: >> and, in particular, if we want to be sensitive to such upper and =20 >> lower case when the data comes back to us from the DNS resolver =20 >> level. > > Please, let not confuse : > > 1) the DNS layer, where you run the game the way you want according =20= > to your published rules, and the Application Domain Names. > 2) French majuscules and upper cases. > > The U-label, A-label, etc. wording IMHO helps that confusion. Is =20 > Ecole.fra an U-label or an A-label? All I know is that it is an =20 > application domain name (like in "IDNA"). Also, that if the proposed =20= > text does not actually document the "ecole.fra, =E9cole.fra, =20 > Ecole.fra" case, this case will have to be documented during the =20 > IETF/LC. > > May be it is the best thing to do? so the whole IETF community may =20 > decide what does concern the whole community? > jfc > > _______________________________________________ > Idna-arabicscript mailing list > Arabic Script IDN Working Group (ASIWG) > Idna-arabicscript@lists.irnic.ir > http://lists.irnic.ir/mailman/listinfo/idna-arabicscript