From jefsey@jefsey.com Sun Nov 1 16:06:44 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2FA53A694D for ; Sun, 1 Nov 2009 16:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.192 X-Spam-Level: **** X-Spam-Status: No, score=4.192 tagged_above=-999 required=5 tests=[AWL=-3.446, BAYES_99=3.5, FUZZY_CREDIT=1.238, J_CHICKENPOX_52=0.6, MANGLED_CREDIT=2.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 KWx8VQHjRdV2 for ; Sun, 1 Nov 2009 16:06:44 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 2BC943A6949 for ; Sun, 1 Nov 2009 16:06:44 -0800 (PST) Received: from eurolab.net2.nerim.net ([213.41.175.161]:4579 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1N4kRq-0006JW-M7; Sun, 01 Nov 2009 16:07:03 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 02 Nov 2009 01:06:55 +0100 To: comptoir@cafedu.com From: JFC Morfin In-Reply-To: References: <4aecfac0.8b13f30a.57ed.66c9SMTPIN_ADDED@mx.google.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: <20091102000644.2BC943A6949@core3.amsl.com> Cc: iucg@ietf.org Subject: Re: [iucg] [comptoir 580] Re: [comptoir 579] de Gaulejac 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, 02 Nov 2009 00:06:45 -0000 At 00:36 02/11/2009, Rémy Renardin wrote: >Je retrouve ici ta manière de modéliser. Tu vois la gestionnite >galopante qu'analyse Galejac comme une grosse bulle (de la taille de >la planète) anonymement indéfinie, mais qui nous recouvre tous de >ses incohérences, et nous les gonfle, nous les gonfle au point de >devoir exploser à la moindre saillance suffisamment acérée. Je suis >d'accord .... Oui. Une baudruche où on met la pression jusqu'au moment ou cela va exploser, la révolution globale contre l'américonerie. Il faut couper la mèche. >L'intérêt de Gaulejac est de donner une synthèse structurée de la >pathologie sur un noo-prolétariat dont l'existence est la même que >celle du prolétariat romain : la continuation de la consommation de >biens à crédit garantie par de son esclavage de la machine. Tu sais à quel point je rejoins cette analyse qui est le paradigme de Platon. Il y a le mort (prolétaire qui ne compte pas pour l'Etat), le vivant (les actionnaires, la vie est action) et le pilote. C'est la base de la cybernétique. >Nous savons. Mais malheureusement, tu n'as plus que toi à >convaincre. Tu as engagé le projet d'un lexique multilingue il y a >près de deux ans. Nous avons suivi à l'IETF et on a probablement >gagné un répit. Maintenant il faut exploiter. Je n'ai pas >d'objection, mais en quoi le débat avec Yeu nous aide-t-il ? N'y >perdons-nous pas du temps ? Je fais ça que je peux avec ça que j'ai. Il y le poids de la survie, de l'action et de l'âge. Il y a surtout la lenteur de la réflexion. Il ne me semble pas que l'on puisse propose un lexique. Il faut présenter un modèle commenté qui se tienne et semble clair à tous (ce qui compte n'est pas l'exactitude, mais la pertinence dans les noms et positions). Ensuite quiconque pourra faire de l'exégèse et de la daube. Mais un tel référentiel n'est pas simple. Comme tu le sais, mon espoir est l'adressage sémantique comme taxonomie ouverte. Mais il faut d'abord prototyper. Cordialement jfc From jefsey@jefsey.com Mon Nov 2 05:59:14 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 98C103A69CE for ; Mon, 2 Nov 2009 05:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.173 X-Spam-Level: * X-Spam-Status: No, score=1.173 tagged_above=-999 required=5 tests=[AWL=1.173, BAYES_50=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 Ut6KfhHIBgPC for ; Mon, 2 Nov 2009 05:59:07 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 969D03A69CB for ; Mon, 2 Nov 2009 05:59:07 -0800 (PST) Received: from 89-158-60-119.rev.dartybox.com ([89.158.60.119]:4067 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1N4xRN-0006I1-6n; Mon, 02 Nov 2009 05:59:25 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 02 Nov 2009 12:36:12 +0100 To: vesely@tana.it,iucg@ietf.org From: JFC Morfin In-Reply-To: <4AEC48BC.7030607@tana.it> References: <4AEC48BC.7030607@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: <20091102135907.969D03A69CB@core3.amsl.com> Cc: pubsoft@elists.isoc.org Subject: [iucg] Email practices (dis)respectful of European privacy directives 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, 02 Nov 2009 13:59:14 -0000 Allessandro, I went on your http://FixForwarding.org/wiki/standard_behavior. I wish to clearly understand your approach. If I am correct you say: - European Data Protection Directives (you do not document yet) are common sense. They are therefore a good starting point for global review. - SMTP as also being rooted in common sense could support them. There is however something architectural to add to it to make it naturally enforce these directives. - you propose to study how to address that addition and suggest a possible solution (I must say that not being familiar with SMTP intricacies I do not fully understand what to consider) I started documenting a store and forward/retreive solution a few years ago. Why not to create an IUCG Special Interest Group on the issue you could lead. The IUCG is just that: a place to debate, introduce IETF Drafts, and possibly architecturally ally towards a bette user experience of the Internet. Please look at: http://iucg.org/wiki/Applications_Area - I can give you an SIG Moderator access to the wiki and you will be free to build-up a proposition that can be disucssed on this list. Please do not object that IUCG is young. It is and it will be what we the lead users will build. I can also Moderate the theme until you feel at ease or found someone interested. Best jfc >Dear commissioner, >I am seeking cooperation on working out the specifications for >treating email addresses with full respect of privacy rules. >According to my analysis, both the (Simple) Mail Transfer Protocol >and the European Data Protection Directive (95/46/EC) are rooted in >common sense. However, except for some vaguely stated "netiquette" >principles, SMTP never made explicit those rules that Directive >95/46/EC subsequently formalized. Practices not complying with >privacy are illustrated in http://FixForwarding.org/wiki/standard_behavior > >The rest of that web site contains the sketch of a possible >solution. The aim is to provide a practical solution for companies >willing to comply with privacy directives. It should have the form >of an open source software add-on, amenable to IETF standardization; >not an opaquely operated service. > >I am a software developer and freelance IT consultant, and currently >have enough spare time to try and tackle this issue. Thus far, I >haven't been able to discuss my tentative solution with someone >acknowledgeable on privacy directives. Honestly, I'm not even sure >I'd be able to properly "launch" that solution once it's completed. >Isn't there an European group or association for that? I would like >to see an alternative to that American trend, incarnated e.g. by the >Messaging Anti-Abuse Working Group (MAAWG.org), that apparently >gives an unfair advantage to large operators. They end up >considering huge pools of email users who can be targeted with >minimal disruption by orchestrating a somewhat questionable behavior >among large mailbox providers, marketers, and email service >providers a la ReturnPath.net. In Europe, we have better privacy >laws and I would hope someone is doing something to put them into >effect, rather than letting foreign marketers take advantage from >not having to abide by. > >Thank you so much for your attention and your time. From vesely@tana.it Mon Nov 2 09:16:09 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 0D29028C200 for ; Mon, 2 Nov 2009 09:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 mz6-nkodQQv7 for ; Mon, 2 Nov 2009 09:16:01 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 9FA0D28C20E for ; Mon, 2 Nov 2009 09:15:58 -0800 (PST) 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, 02 Nov 2009 18:16:17 +0100 id 00000000005DC031.000000004AEF13E1.00001AF9 Message-ID: <4AEF13E0.6010704@tana.it> Date: Mon, 02 Nov 2009 18:16:16 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: JFC Morfin References: <4AEC48BC.7030607@tana.it> In-Reply-To: <4AEC48BC.7030607@tana.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: iucg@ietf.org Subject: Re: [iucg] Email practices (dis)respectful of European privacy directives 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, 02 Nov 2009 17:16:09 -0000 Hi JFC! (I drop cc pubsoft@elists.isoc.org, as I saw no replies there) > I went on your http://FixForwarding.org/wiki/standard_behavior. I wish > to clearly understand your approach. If I am correct you say: > > - European Data Protection Directives (you do not document yet) are > common sense. They are therefore a good starting point for global review. > - SMTP as also being rooted in common sense could support them. There is > however something architectural to add to it to make it naturally > enforce these directives. > - you propose to study how to address that addition and suggest a > possible solution (I must say that not being familiar with SMTP > intricacies I do not fully understand what to consider) Your understanding of my point is correct. Thank you for your interest. As you know, those EU directives are not exactly law, but just, as it goes, "directives". That's not exactly the status of IETF standards either, however intriguingly related they may appear. One striking difference is that the IETF features no "member states". In addition, people discussing protocols usually dodge legal issues; that's why the IETF would not have likely come out with definitions like those, given e.g. in http://www.cdt.org/privacy/eudirective/EU_Directive_.html#HD_NM_28 A user's mail server does not store any registration for subscriptions to mailing lists. Would such registration have a value for legal inquiries about mail abuse? I see European companies have problems complaining with paper-consent statements. > I started documenting a store and forward/retrieve solution a few years > ago. Why not to create an IUCG Special Interest Group on the issue you > could lead. The IUCG is just that: a place to debate, introduce IETF > Drafts, and possibly architecturally ally towards a better user > experience of the Internet. > > Please look at: http://iucg.org/wiki/Applications_Area - I can give you > an SIG Moderator access to the wiki and you will be free to build-up a > proposition that can be discussed on this list. Please do not object > that IUCG is young. It is and it will be what we the lead users will > build. I can also Moderate the theme until you feel at ease or found > someone interested. One problem is that there is a plethora of proposals on anti-spam, to the point that there is an anti-anti-spam barrier. I'm not sure how this can of worms suits the IUCG, so I just cc the list to see if someone says something... Best Ale From jefsey@jefsey.com Mon Nov 2 15:49:46 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 27D4C3A681F for ; Mon, 2 Nov 2009 15:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=2.179, 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 tiLa2pfnzGRx for ; Mon, 2 Nov 2009 15:49:45 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 4FACE3A67D7 for ; Mon, 2 Nov 2009 15:49:45 -0800 (PST) Received: from 89-158-60-119.rev.dartybox.com ([89.158.60.119]:1566 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1N56ex-0002GO-Ge; Mon, 02 Nov 2009 15:50:04 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 03 Nov 2009 00:47:51 +0100 To: Alessandro Vesely From: jefsey In-Reply-To: <4AEF13E0.6010704@tana.it> References: <4AEC48BC.7030607@tana.it> <4AEF13E0.6010704@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: <20091102234945.4FACE3A67D7@core3.amsl.com> Cc: iucg@ietf.org Subject: Re: [iucg] Email practices (dis)respectful of European privacy directives 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, 02 Nov 2009 23:49:46 -0000 At 18:16 02/11/2009, Alessandro Vesely wrote: >Your understanding of my point is correct. Thank you for your >interest. As you know, those EU directives are not exactly law, but >just, as it goes, "directives". That's not exactly the status of >IETF standards either, however intriguingly related they may appear. >One striking difference is that the IETF features no "member >states". In addition, people discussing protocols usually dodge >legal issues; that's why the IETF would not have likely come out >with definitions like those, given e.g. in >http://www.cdt.org/privacy/eudirective/EU_Directive_.html#HD_NM_28 > >A user's mail server does not store any registration for >subscriptions to mailing lists. Would such registration have a value >for legal inquiries about mail abuse? I see European companies have >problems complaining with paper-consent statements. May I suggest that we consider the EU Directive as a basis for Network Services Technical Specifications, translating it into technical specifications and possibly into architectural constraints, adding whatever inputs we might get from other similar national or international documents and user groups. This could then make an I_D we cpould ask Civil Rights organizations, GAC Members, IGF participants to review. Then the RFC Editor to publish it as an informative user contribution. This would belong to the http://iucg.org/wiki/Translating_Civil_Society_preocupations - I entered in the "privacy" section the European Text, it should simplified into legal requirements that could be extended. Then we could port it into technical requirements. >One problem is that there is a plethora of proposals on anti-spam, >to the point that there is an anti-anti-spam barrier. I'm not sure >how this can of worms suits the IUCG, so I just cc the list to see >if someone says something... Your idea is not so much to propose a specific solution, but to open a usage/technical debate to define what proposals should actually address. Best jfc From jefsey@jefsey.com Mon Nov 9 11:32:42 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33EFC3A6929 for ; Mon, 9 Nov 2009 11:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.745 X-Spam-Level: X-Spam-Status: No, score=0.745 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_50=0.001, 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 pE7TenJvvFJY for ; Mon, 9 Nov 2009 11:32:40 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 7E81A3A67A6 for ; Mon, 9 Nov 2009 11:32:40 -0800 (PST) Received: from 89-158-60-119.rev.dartybox.com ([89.158.60.119]:4113 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1N7Zz0-0003qZ-8E; Mon, 09 Nov 2009 11:32:59 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Nov 2009 20:32:52 +0100 To: iucg@ietf.org,housley@vigilsec.com, Lisa Dusseault From: JFC Morfin Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_249371937==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20091109193240.7E81A3A67A6@core3.amsl.com> Subject: [iucg] IUCG awaiting for IDNA2008 publication 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, 09 Nov 2009 19:32:42 -0000 --=====================_249371937==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear all, The number of participants in the IUCG is slowly growing. This is not yet the case, however, in terms of participant to discussions. But some important work is carried through notes based on the wiki pages. IDNA2010 The IUCG was created in the wake of the discussion on IDNA. This has led to the definition and preparatory work on Interplus/idnaplus. This work has to be put on hold for a few weeks because it would not be reasonable to discuss Interplus without prior knowledge of the final IDNA2008 text, once approved by the IESG. This is due to the review of this text by Editors: it has led to some possible wording rigidity that could result in possible architectural conflicts. So, until then we will continue collecting the inputs for IDNA2008bis (http://idna2010.org) towards an IDNA2008/IDNAPLUS based common IDNA2010 best practice. Current priorities Therefore, I propose that we proceed as follows during the comming three months: 1. lead users - focus on the very nature of the lead-usership and, therefore, of the industrial and societal location of the IUCG. I am working on a reduction of the first chapter of von Hippel's book "Democratizing Innovation", which summarizes this matter. A part of his findings is based upon a survey of the Apache community: we could discuss how this can be transposed to the IUCG and to @larges as an Internet lead-users community. 2. Intertesting - continue on the precautionary duty line and introduce an "Intertest" Draft, i.e. using the Internet as its own test-bed (both for technical and governance issues and their mutual influence) without risking the possibility of harming it. I intend on proposing a preliminary text on that subject in a few weeks time that is to be based upon ICANN ICP-3 and a compilation of various RFCs and I_Ds. 3. Architectural prototyping - build an interbox prototype. To do this, we have three possibilities: -- to extend Unbound and/or Bind to include the idnaplus and use a local root. -- to start from a packet-filter source that can be compiled under Windows and Linux. -- to develop a true OPES system as the basis of an interbox. This could be a sourceforge project. However, the WG/OPES mailing list has been closed. Therefore, I have to propose the restart of the WG/OPES mailing list, either as an IUCG mailing list or as a non-WG specialized mailing list, to all former participants. This depends on our ability to identify developers and interested participants in a working OPES based networked extended services (ONES) Special Interest Group. 4 Funding In the meanwhile, I will try to reorganize my own INTLNET non-profit structure in a way that it may better address the governance, adminance, and development issues. I will as well as introduce an R&D commercially based financing limited capacity for IUCG experimentations. This could serve as an experience for a better understanding of the IUCG "intertesting" capacity and capitalize on: 5. Test projects -- Projet.FRA - French semantic addressing space, also using the test ".FRA" gTLD (or multiledgered Top Level Domain should ICANN delay the plans it announced in 2007). This test will focus on the use of the semantic addressing space as an taxonomy (multilevel folksonomy) for an open ontology. -- Multilinc, Linguistic diversity cybernetics (multilinguistics) experimentation gathering a broad number of linguistic namespaces. This is obviously dependent on the IDNgTLD ICANN loyal behavior in managing their Fast Track project, since most of the TLDs should be entered in the root once they have been validated through Multilinc. -- and PERFIDA IDNAPLUS RFID support by people testing. 6. UTLD Multinic We should now concentrate on the documentation/development of an ML-DNS NIC manager in order to support user namesspaces (UTLDs), naming value added and extended services. This could use the france@large published PNI book http://www.lulu.com/content/paperback-book/pni/7143574 7. Intersem I suggest we start an Intersem oriented User Area in the coming weeks and try to work on an initial Area Charter. This will permit us to evaluate if a BOF on the matter would be the best way to proceed. Quarterly goal My goal is to be able to present an operational IUCG on January 21 at a public meeting at the Communications Museum in Paris, which is to be broadcasted to four other cities. The Internet Minister should attend. The theme is the Internet of the future. It will start with a debate between Louis Pouzin (father of the prompt, scripts, datagram, and e-mail), Vint Cerf, and Bob Khan the co-designers of the Internet as an application of Louis' catenet architecture (network of networks). I will introduce why and how the IUCG must bring forth its contribution; how its endeavors will shape a different future for the Internet of the users; how it needs ICANN to behave more loyally; and why an international enhanced cooperation is to be established (or to establish itself by itself) to manage the MultiLedgered DNS governance (UTLDs, classes, presentations, virtual root, SAS [semantic addressing system], a new value added domain name economy, IDv6, etc.). NB. "Fast Crash" We may face a potentially network damaging situation would ICANN disrespect their published gTLD introduction calendar as: - many projects have already gathered funding and started investing in file preparation and even some in name promotion. - this is perceived as a way to put pressure on IDNccTLD to sign an agreement with them including DNSSEC against an IDNA market sunrise IDNgTLD should share. This would be highly detrimental to the Multilingual Internet equilibrium (as if the ASCII Internet had not started with ".com", ".net"). This would call for IUCG to share in a "Fast Crash" @large user plan. The IUCG would have to organise and host an MDRS core (Multilingual Distributed Reference System) to support names, presentations, IDv6 grids, ports, classes, and semantic addresses as required by the interplus and its intertesting. If such a "Fast Crash" project was to be activated by ATLARGE, IUCG would use a IANA private use delegated (0xFF00-0xFFFE) classes. Since some could copy us or pollute the chosen user class, or even to use IETF reserved classes, a User Name and Number Adminance SIG would be activated, and would probably propose or join a BOF on this issue. Your comments are welcomed. jfc --=====================_249371937==.ALT Content-Type: text/html; charset="us-ascii" Dear all,

The number of participants in the IUCG is slowly growing. This is not yet the case, however, in terms of participant to discussions. But some important work is carried through notes based on the wiki pages.


IDNA2010

The IUCG was created in the wake of the discussion on IDNA. This has led to the definition and preparatory work on Interplus/idnaplus. This work has to be put on hold for a few weeks because it would not be reasonable to discuss Interplus without prior knowledge of the final IDNA2008 text, once approved by the IESG. This is due to the review of this text by Editors: it has led to some possible wording rigidity that could result in possible architectural conflicts.

So, until then we will continue collecting the inputs for IDNA2008bis (http://idna2010.org) towards an IDNA2008/IDNAPLUS based common IDNA2010 best practice.


Current priorities

Therefore, I propose that we proceed as follows during the comming three months:


1. lead users

- focus on the very nature of the lead-usership and, therefore, of the industrial and societal location of the IUCG. I am working on a reduction of the first chapter of von Hippel's book "Democratizing Innovation", which summarizes this matter. A part of his findings is based upon a survey of the Apache community: we could discuss how this can be transposed to the IUCG and to @larges as an Internet lead-users community.


2. Intertesting

- continue on the precautionary duty line and introduce an "Intertest" Draft, i.e. using the Internet as its own test-bed (both for technical and governance issues and their mutual influence) without risking the possibility of harming it. I intend on proposing a preliminary text on that subject in a few weeks time that is to be based upon ICANN ICP-3 and a compilation of various RFCs and I_Ds.


3. Architectural prototyping

- build an interbox prototype. To do this, we have three possibilities:
-- to extend Unbound and/or Bind to include the idnaplus and use a local root.
-- to start from a packet-filter source that can be compiled under Windows and Linux.
-- to develop a true OPES system as the basis of an interbox. This could be a sourceforge project.

However, the WG/OPES mailing list has been closed. Therefore, I have to propose the restart of the WG/OPES mailing list, either as an IUCG mailing list or as a non-WG specialized mailing list, to all former participants.

This depends on our ability to identify developers and interested participants in a working OPES based networked extended services (ONES) Special Interest Group.


4 Funding

In the meanwhile, I will try to reorganize my own INTLNET non-profit structure in a way that it may better address the governance, adminance, and development issues. I will as well as introduce an R&D commercially based financing limited capacity for IUCG experimentations. This could serve as an experience for a better understanding of the IUCG "intertesting" capacity and capitalize on:


5. Test projects

-- Projet.FRA - French semantic addressing space, also using the test ".FRA" gTLD (or multiledgered Top Level Domain should ICANN delay the plans it announced in 2007). This test will focus on the use of the semantic addressing space as an taxonomy (multilevel folksonomy) for an open ontology.

-- Multilinc, Linguistic diversity cybernetics (multilinguistics) experimentation gathering a broad number of linguistic namespaces. This is obviously dependent on the IDNgTLD ICANN loyal behavior in managing their Fast Track project, since most of the TLDs should be entered in the root once they  have been validated through Multilinc. 

-- and PERFIDA IDNAPLUS RFID support by people testing.


6. UTLD Multinic

We should now concentrate on the documentation/development of an ML-DNS NIC manager in order to support user namesspaces (UTLDs), naming value added and extended services. This could use the france@large published PNI book http://www.lulu.com/content/paperback-book/pni/7143574


7. Intersem

I suggest we start an Intersem oriented User Area in the coming weeks and try to work on an initial Area Charter. This will permit us to evaluate if a BOF on the matter would be the best way to proceed.


Quarterly goal

My goal is to be able to present an operational IUCG on January 21 at a public meeting at the Communications Museum in Paris, which is to be broadcasted to four other cities. The Internet Minister should attend. The theme is the Internet of the future. It will start with a debate between Louis Pouzin (father of the prompt, scripts, datagram, and e-mail), Vint Cerf, and Bob Khan the co-designers of the Internet as an application of Louis' catenet architecture (network of networks). I will introduce why and how the IUCG must bring forth its contribution; how its endeavors will shape a different future for the Internet of the users; how it needs ICANN to behave more loyally; and why an international enhanced cooperation is to be established (or to establish itself by itself) to manage the MultiLedgered DNS governance (UTLDs, classes, presentations, virtual root, SAS [semantic addressing system], a new value added domain name economy, IDv6, etc.).

NB. "Fast Crash"

We may face a potentially network damaging situation would ICANN disrespect their published gTLD introduction calendar as:

- many projects have already gathered funding and started investing in file preparation and even some in name promotion.
- this is perceived as a way to put pressure on IDNccTLD to sign an agreement with them including DNSSEC against an IDNA market sunrise IDNgTLD should share.

This would be highly detrimental to the Multilingual Internet equilibrium (as if the ASCII Internet had not started with ".com", ".net"). This would call for IUCG to share in a "Fast Crash" @large user plan. The IUCG would have to organise and host an MDRS core (Multilingual Distributed Reference System) to support names, presentations, IDv6 grids, ports, classes, and semantic addresses as required by the interplus and its intertesting. If such a "Fast Crash" project was to be activated by ATLARGE, IUCG would use a IANA private use delegated (0xFF00-0xFFFE) classes. Since some could copy us or pollute the chosen user class, or even to use IETF reserved classes, a User Name and Number Adminance SIG would be activated, and would probably propose or join a BOF on this issue.

Your comments are welcomed.

jfc

--=====================_249371937==.ALT-- From jefsey@jefsey.com Fri Nov 13 02:51:20 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 D697F3A6873 for ; Fri, 13 Nov 2009 02:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.888 X-Spam-Level: * X-Spam-Status: No, score=1.888 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_50=0.001, FRT_EXPERIENCE=2.333, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 9EcN+bU6BY8V for ; Fri, 13 Nov 2009 02:51:18 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 921EA3A6844 for ; Fri, 13 Nov 2009 02:51:18 -0800 (PST) Received: from 89-158-60-119.rev.dartybox.com ([89.158.60.119]:2572 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1N8tkm-0004Fc-9f; Fri, 13 Nov 2009 02:51:44 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Nov 2009 11:51:42 +0100 To: "comptoir@cafedu.com" , listegenerale@franceatlarge.org,iucg@ietf.org From: jefsey Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_92275234==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20091113105118.921EA3A6844@core3.amsl.com> Cc: ocl@gih.com, Lisa Dusseault , "Latif LADID \(\"The New Internet based on IPv6\"\)" Subject: [iucg] IPv6 et IDv6 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, 13 Nov 2009 10:51:20 -0000 --=====================_92275234==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Chers CafeduCompères, chers CaféduComères, Le mail envoyé hier au sujet d'IPv6 _ou_ IDv6 et sa longueur étaient bien entendu une provocation à la pensée. Envoyer trop, pour se protéger d'une synthèse adverse, et obtenir plus, par le sujet et le contenu des clarifications ponctuelles des uns et des autres Les réponses reçues de nos amis IPv6 sont trés claires. Latif, le stratège : IPv6 suit sa stratégie, mais supporte un jeu d'idées (pool of ideas) comme IDv6 qui peut aider. Olivier, l'IETF : allez-y et montrez par une démo (running code). Nous avons donc une convergence IPv6 _et_ IDv6. IDv6 n'a pas besoin d'IPv6, mais fonctionnera d'autant mieux qu'IPv6 sera là. IPv6 n'a pas besoin d'IDv6, mais il est probable qu'il ne démarrera pas sans lui. Le problème architectural était qu'IDv6 n'appartient pas vraiment au domaine IETF (sinon nous aurions des RFC à plus soif) ni à l'utilisation (sinon la TFF (IPv6 France) nous en rebattrait les oreilles au lieu de s'y être opposée). Il appartient à notre utilisation pilote de l'internet, c'est-à-dire une utilisation qui va plus loin que celle qui a été envisagée et qui doit donc être documentée, expérimentée, validée en elle-même pour faciliter l'utilisation des ressources proposées par l'IETF, en synergie avec les stratégies de l'IPv6 TF en cours. C'est le rôle de l'IUCG, c'est notre capacité. Mais comme tout le monde, nous avons besoin d'aide et pour cela et d'abord de reconnaissance. 1. de reconnaissance au niveau stratégique. Pour cela il fallait que le concept IDv6 soit reconnu comme "ami" et potentiellement "utile" à la fois dans le cadre IPv6TF et IETF. C'est fait. 2. Il faut que nous puissions suivre ce que cela implique en terme de travail de réflexion, de documentation, de contribution à l'effort commun, et de "démonstration" opérationnelle par du code source de notre architecture. Problème que nous discutions par ailleurs. Nous avons besoin d'aide pour quelque chose que nous savons, mais qui doit fonctionner avec des choses que nous ne savons pas (5500 RFC et des dizaines sur IPv6). Pour aider à cela, nous avons d'abord à dissiper une confusion fondamentale que nous avons vu poindre à l'IETF lors du débat sur un possible WG NAT6, des NAT pour IPv6. Cette confusion est une confusion de termes. Il n'y a RIEN de commun entre IDv6 et les NAT. Les NAT remplacent transitoirement sous IPv4 une réponse à l'absence d'IPv6. IDv6 peut aussi préparer sous IPv4 l'arrivée d'IPv6, mais ne pourra pleinement être utilisé qu'en environnement IPv6 (sans doute légèrement amélioré en fonction de l'expérience acquise sur les Interface ID). Cette confusion est levée par le principe de GRIDv6 qui est une collusion de sens entre : - la notion de grille au niveau des couches les plus basses (adressage physique) et non pas au niveau applicatif. Nous sommes entièrement d'accord avec Latif. - le vocabulaire IPv6 le plus strict pour considérer les implications de la reconnaissance d'une région IPv6 globale (Global Region IDv6) qui en fait étend l'adressage local IDv6 au monde entier via son inclusion dans IPv6, et dans IPv4 dans le cadre de l'utilisation d'Interplus. Je comprends très bien que la position actuelle de l'IPv6 TF et de l'ISOC soit concertée, mais sauf à ce que celle de l'ISOC soit fermée (ce dont j'ai un peu peur) alors que celle de la TF ne l'est manifestement pas. Mais je suis bien entendu aussi d'accord avec l'ami Charles Simon, pour dire qu'IPv6 tout seul n'est pas "sexy" pour des utilisateurs (cf. compte-rendu de Laure-Emmanuelle) considérés aussi débiles que le "dumb network". Il est tout à l'honneur du Chapitre France de le reconnaitre (et j'espère qu'il acceptera que "IPv6, IDv6, sont des noms qui vont bien ensemble, bien ensemble") afin que nous puissions tous avancer. Et j'espère qu'il pourra le faire entendre à l'ISOC Monde (bien que nous comprenions bien que par définition [RFC 3869] nombre de ses Sponsors soient orientés statUS-quo). Cordialement jfc >At 08:05 13/11/2009, Latif LADID \(\"The New Internet based on IPv6\"\) wrote: >JFC, > >ISOC world should focus on the right messages if the Internet >continuity and growth is its mission. I know it does so I won't take >Charles statement that seriously. > >We are discussing the creation of a political and business oriented >French v6 Council including high level representatives from the >French government and industry led by Patrick Grossetete, similar to >the German v6 Council which doing a great job and it looks like >Germany is going to achieve very promising results: >www.ipv6council.de > >ISP FREE has abundantly demonstrated that IPv6 is doable, so any >suggestions like yours can create a good pool of ideas to jump start >the deployment of IPv6 in France and this debate is highly beneficial. > >Talking about GRID, GRID is led by web-only oriented researchers and >they would highly benefit from an end to end infrastructure instead >of bombarding a NAT box with a lambda that it cannot even process properly. > >Cheers >Latif At 06:26 13/11/2009, Olivier MJ Crepin-Leblond wrote: >Bonjour Jefsey, > >je pense que toute idée nouvelle qui pourrait aider à >l'épanouissement de l'IPv6 est la bienvenue. >A vous de commencer le travail! J'attends avec impatience votre démo IDv6. >Meilleures salutations, > >Olivier --=====================_92275234==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Chers CafeduCompères, chers CaféduComères,

Le mail envoyé hier au sujet d'IPv6 _ou_ IDv6 et sa longueur étaient bien entendu une provocation à la pensée. Envoyer trop, pour se protéger d'une synthèse adverse, et obtenir plus, par le sujet et le contenu des clarifications ponctuelles des uns et des autres

Les réponses reçues de nos amis IPv6 sont trés claires. Latif, le stratège : IPv6 suit sa stratégie, mais supporte un jeu d'idées (pool of ideas) comme IDv6 qui peut aider. Olivier, l'IETF : allez-y et montrez par une démo (running code). Nous avons donc une convergence IPv6 _et_ IDv6. IDv6 n'a pas besoin d'IPv6, mais fonctionnera d'autant mieux qu'IPv6 sera là. IPv6 n'a pas besoin d'IDv6, mais il est probable qu'il ne démarrera pas sans lui.

Le problème architectural était qu'IDv6 n'appartient pas vraiment au domaine IETF (sinon nous aurions des RFC à plus soif) ni à l'utilisation (sinon la TFF (IPv6 France) nous en rebattrait les oreilles au lieu de s'y être opposée). Il appartient à notre utilisation pilote de l'internet, c'est-à-dire une utilisation qui va plus loin que celle qui a été envisagée et qui doit donc être documentée, expérimentée, validée en elle-même pour faciliter l'utilisation des ressources proposées par l'IETF, en synergie avec les stratégies de l'IPv6 TF en cours.

C'est le rôle de l'IUCG, c'est notre capacité. Mais comme tout le monde, nous avons besoin d'aide et pour cela et d'abord de reconnaissance.

1. de reconnaissance au niveau stratégique. Pour cela il fallait que le concept IDv6 soit reconnu comme "ami" et potentiellement "utile" à la fois dans le cadre IPv6TF et IETF. C'est fait.
2. Il faut que nous puissions suivre ce que cela implique en terme de travail de réflexion, de documentation, de contribution à l'effort commun, et de "démonstration" opérationnelle par du code source de notre architecture. Problème que nous discutions par ailleurs. Nous avons besoin d'aide pour quelque chose que nous savons, mais qui doit fonctionner avec des choses que nous ne savons pas (5500 RFC et des dizaines sur IPv6).

Pour aider à cela, nous avons d'abord à dissiper une confusion fondamentale que nous avons vu poindre à l'IETF lors du débat sur un possible WG NAT6, des NAT pour IPv6. Cette confusion est une confusion de termes. Il n'y a RIEN de commun entre IDv6 et les NAT. Les NAT remplacent transitoirement sous IPv4 une réponse à l'absence d'IPv6. IDv6 peut aussi préparer sous IPv4 l'arrivée d'IPv6, mais ne pourra pleinement être utilisé qu'en environnement IPv6 (sans doute légèrement amélioré en fonction de l'expérience acquise sur les Interface ID).

Cette confusion est levée par le principe de GRIDv6 qui est une collusion de sens entre :
- la notion de grille au niveau des couches les plus basses (adressage physique) et non pas au niveau applicatif.  Nous sommes entièrement d'accord avec Latif.
- le vocabulaire IPv6 le plus strict pour considérer les implications de la reconnaissance d'une région IPv6 globale (Global Region IDv6) qui en fait étend l'adressage local IDv6 au monde entier via son inclusion dans IPv6, et dans IPv4 dans le cadre de l'utilisation d'Interplus.

Je comprends très bien que la position actuelle de l'IPv6 TF et de l'ISOC soit concertée, mais sauf à ce que celle de l'ISOC soit fermée (ce dont j'ai un peu peur) alors que celle de la TF ne l'est manifestement pas. Mais je suis bien entendu aussi d'accord avec l'ami Charles Simon, pour dire qu'IPv6 tout seul n'est pas "sexy" pour des utilisateurs (cf. compte-rendu de Laure-Emmanuelle) considérés aussi débiles que le "dumb network". Il est tout à l'honneur du Chapitre France de le reconnaitre (et j'espère qu'il acceptera que "IPv6, IDv6, sont des noms qui vont bien ensemble, bien ensemble") afin que nous puissions tous avancer.  Et j'espère qu'il pourra le faire entendre à l'ISOC Monde (bien que nous comprenions bien que par définition [RFC 3869] nombre de ses Sponsors soient orientés statUS-quo).

Cordialement
jfc


At 08:05 13/11/2009, Latif LADID \(\"The New Internet based on IPv6\"\) wrote:
JFC,
 
ISOC world should focus on the right messages if the Internet continuity and growth is its mission. I know it does so I won’t take Charles statement that seriously.
 
We are discussing the creation of a political and business oriented French v6 Council including high level representatives from the French government and industry led by Patrick Grossetete, similar to the German v6 Council which doing a great job and it looks like Germany is going to achieve very promising results: www.ipv6council.de
 
ISP FREE has abundantly demonstrated that IPv6 is doable, so any suggestions like yours can create a good pool of ideas to jump start the deployment of IPv6 in France and this debate is highly beneficial.
 
Talking about GRID, GRID is led by web-only oriented researchers and they would highly benefit from an end to end infrastructure instead of bombarding a NAT box with a lambda that it cannot even process properly. 
 
Cheers
Latif
 At 06:26 13/11/2009, Olivier MJ Crepin-Leblond wrote:
Bonjour Jefsey,
 
je pense que toute idée nouvelle qui pourrait aider à l'épanouissement de l'IPv6 est la bienvenue.
A vous de commencer le travail! J'attends avec impatience votre démo IDv6.
Meilleures salutations,
 
Olivier
--=====================_92275234==.ALT-- From eblanconil@gmail.com Fri Nov 13 07:12:26 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 75D2A3A6AB8 for ; Fri, 13 Nov 2009 07:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 GmibKKBiv6Y5 for ; Fri, 13 Nov 2009 07:12:25 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 143703A6AB1 for ; Fri, 13 Nov 2009 07:12:24 -0800 (PST) Received: by fxm7 with SMTP id 7so3554591fxm.29 for ; Fri, 13 Nov 2009 07:12:52 -0800 (PST) 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=fDCiKX6EKkHaAqQB7AyQahIGoXHER3diwP69teSL68U=; b=hFhFuyZc4LOcJhtLHzGKTLiG8iRbzPP8qc5kBdfTvqy3cRlg8zv5VfzGVUJr9cS12z WBsY9dygyvHHjv+7liG9ltpKcdKFEyJ4K0lvz6zYQkF51AUV+HkXeloVBhZf3dwjOY+6 09zirTUm8iX8eNDo9NesgARFn5cOOylyIOUVg= 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=seNO1t5fuFF8+jjdfXAHnlnOJ075tiB654Pvu4BoL1iSNX5/CQSnZx9qLLG2mYcT3X ULNxKtAsNBayKYiX6r+By4hU3b3MB2cs3Tgn1ICKrjv25XNNd7TiiUSkmeeJ15oZZByb 01MmVv+PUnCRUl3s6yYgpLydvzSH8eltE6eVI= MIME-Version: 1.0 Received: by 10.216.86.16 with SMTP id v16mr1450825wee.162.1258125171970; Fri, 13 Nov 2009 07:12:51 -0800 (PST) In-Reply-To: <4afd3a6d.1e02be0a.3a34.ffffb2c5SMTPIN_ADDED@mx.google.com> References: <4afd3a6d.1e02be0a.3a34.ffffb2c5SMTPIN_ADDED@mx.google.com> Date: Fri, 13 Nov 2009 16:12:51 +0100 Message-ID: <6589127a0911130712m148fca68pa9dae91b30f496fc@mail.gmail.com> From: Elisabeth Blanconil To: comptoir@cafedu.com Content-Type: multipart/alternative; boundary=0016e6d588b9f5543104784217e3 Cc: ocl@gih.com, listegenerale@franceatlarge.org, iucg@ietf.org, Lisa Dusseault , "Latif LADID \(\"The New Internet based on IPv6\"\)" Subject: Re: [iucg] [comptoir 642] IPv6 et IDv6 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, 13 Nov 2009 15:12:26 -0000 --0016e6d588b9f5543104784217e3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jefsey, je sais que tu ne veux pas documenter simplement l'interplus tant que tu ne l'as pas mis en route, de fa=E7on =E0 prot=E9ger l'internet contre des copi= es partielles parasites, confusantes ou malveillantes avant que l'on puisse organiser la gouvernance de ce qu'il apporte. Toutefois, ne pourrais-tu pas tenter d'organiser une pr=E9sentation face =E0 face avec gens s=FBrs qui t'apporteraient du temps d=E9veloppement ? Je comprends et partage tes craintes. Mais peut-=EAtre pourrais-tu proc=E9d= er =E0 l'inverse, c'est =E0 dire d=E9crire les diff=E9rents modules de travail =E0= faire qui pourrait int=E9resser des d=E9veloppeurs. Sans expliquer l'ensemble. Pu= is faire signer un non-disclosure =E0 ceux qui voudraient participer sur la ba= se du challenge logiciel, au moins jusqu'=E0 la mise en d=E9monstration ou la diffusion de code ? Elisabeth. --0016e6d588b9f5543104784217e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jefsey,

je sais que tu ne veux pas documenter simplement l'inter= plus tant que tu ne l'as pas mis en route, de fa=E7on =E0 prot=E9ger l&= #39;internet contre des copies partielles parasites, confusantes ou malveil= lantes avant que l'on puisse organiser la gouvernance de ce qu'il a= pporte. Toutefois, ne pourrais-tu pas tenter d'organiser une pr=E9senta= tion face =E0 face avec gens s=FBrs qui t'apporteraient du temps d=E9ve= loppement ?

Je comprends et partage tes craintes. Mais peut-=EAtre pourrais-tu proc= =E9der =E0 l'inverse, c'est =E0 dire d=E9crire les diff=E9rents mod= ules de travail =E0 faire qui pourrait int=E9resser des d=E9veloppeurs. San= s expliquer l'ensemble. Puis faire signer un non-disclosure =E0 ceux qu= i voudraient participer sur la base du challenge logiciel, au moins jusqu&#= 39;=E0 la mise en d=E9monstration ou la diffusion de code ?

Elisabeth.
--0016e6d588b9f5543104784217e3-- From psuger@gmail.com Sat Nov 14 14:29:11 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81BAF3A67EC for ; Sat, 14 Nov 2009 14:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.116 X-Spam-Level: X-Spam-Status: No, score=0.116 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 zArMa2BLO4Rj for ; Sat, 14 Nov 2009 14:29:10 -0800 (PST) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 8E4B73A657C for ; Sat, 14 Nov 2009 14:29:10 -0800 (PST) Received: by bwz2 with SMTP id 2so4685564bwz.0 for ; Sat, 14 Nov 2009 14:29:41 -0800 (PST) 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=e1eeiqwzVdk0caRiG3+zoQPuOP1e8wuuHiIj+hKgUmQ=; b=a4ZjqkJcaAhOKNtgyQWw8doKrc9MFnQ+abkoZVZoQEUKoU1sMGX9D/9Dy+WgxV+JGk SvenUH3sksjJfVXViSLaormT7w8Xg/dWf9FQeDABydBWqRtsokzOVwsnweklcRqPL8l4 ZyoElVGlB/gljHPCTjfnZVQ04kc5MTsIJzC3E= 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=eKLoFoi39JqQ4PhnY/X1ravbjWfEN8WMNKHCRPeBYiagJcS4tPsfhSoFl8Qrq/37jD cWx+/MAUKijqJNOzvmn8pCWNVN28s7WOxa5nJBwIwg+575iy1q+l105vivtHYFKOsIvE fgkAMJqrQQ7T2Re7VIorAd2cOb6TU914oIUnY= MIME-Version: 1.0 Received: by 10.239.170.18 with SMTP id q18mr578764hbe.50.1258237780183; Sat, 14 Nov 2009 14:29:40 -0800 (PST) Date: Sat, 14 Nov 2009 23:29:40 +0100 Message-ID: <4e9b16b30911141429q4138295eo69e17b8a027f6d46@mail.gmail.com> From: Patrick Suger To: iucg@core3.amsl.com Content-Type: multipart/alternative; boundary=001485f2776cee4d3f04785c4ff2 Cc: comptoir@cafedu.com, listegenerale@franceatlarge.org Subject: [iucg] =?iso-8859-1?q?Pr=E9sentation_sur_Internationalisation_par?= =?iso-8859-1?q?_l=27IAB?= X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 22:29:11 -0000 --001485f2776cee4d3f04785c4ff2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Une partie des probl=E8mes recens=E9s par l'IAB en terme de multilinguistiq= ue. Sans doute =E0 =E9tudier tr=E8s attentivement tant pour ce qu'il y a que po= ur ce qu'il peut manquer. PS 2009/11/13 "Martin J. D=FCrst" For those who didn't attended yesterday's IETF Technical Plenary (or > like me, listened to it on the audio feed), here is a link to the slides > from the IAB presentation on Protocol Internationalization and Character > Encoding: > Jefsey, dont you think it could be worth building an IUCG page on linguisti= c support, introducing multilinguistics, multilingualization, mecalanguages, etc. --001485f2776cee4d3f04785c4ff2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Une partie des probl=E8mes recens=E9s par l'= IAB en terme de multilinguistique.
Sans doute =E0 =E9tudier tr=E8s atten= tivement tant pour ce qu'il y a que pour ce qu'il peut manquer.
= PS

2009/11/13 "Martin J. D=FCrst" <duerst@it.aoyama.ac.jp&= gt;

For those who didn't attended yesterday's IETF Technical Plenary (o= r
like me, listened to it on the audio feed), here is a link to the slides from the IAB presentation on Protocol Internationalization and Character Encoding:

Jefsey, dont you think it could be worth building an IUCG page on lin= guistic support, introducing multilinguistics, multilingualization, mecalan= guages, etc.
--001485f2776cee4d3f04785c4ff2-- From jefsey@jefsey.com Sat Nov 14 16:00:29 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 7F4273A6826 for ; Sat, 14 Nov 2009 16:00:29 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char E9 hex): Subject: Re: [iucg] Pr\351sentation sur I[...] X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SUBJECT_NEEDS_ENCODING=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 IXajdafC+W0I for ; Sat, 14 Nov 2009 16:00:28 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 3AB6C3A62C1 for ; Sat, 14 Nov 2009 16:00:28 -0800 (PST) Received: from 89-158-60-119.rev.dartybox.com ([89.158.60.119]:1836 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1N9SY5-0007sn-Lu; Sat, 14 Nov 2009 16:00:58 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 15 Nov 2009 00:59:52 +0100 To: internet users contributing group ,iucg@core3.amsl.com From: JFC Morfin Subject: Re: [iucg] Présentation sur Internationalisation par l'IAB In-Reply-To: <4e9b16b30911141429q4138295eo69e17b8a027f6d46@mail.gmail.co m> References: <4e9b16b30911141429q4138295eo69e17b8a027f6d46@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_225969453==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - core3.amsl.com 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: <20091115000028.3AB6C3A62C1@core3.amsl.com> Cc: comptoir@cafedu.com, listegenerale@franceatlarge.org 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, 15 Nov 2009 00:00:29 -0000 --=====================_225969453==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit At 23:29 14/11/2009, Patrick Suger wrote: >2009/11/13 "Martin J. Dürst" ><duerst@it.aoyama.ac.jp> > >For those who didn't attended yesterday's IETF Technical Plenary (or >like me, listened to it on the audio feed), here is a link to the slides >from the IAB presentation on Protocol Internationalization and Character >Encoding: >Jefsey, dont you think it could be worth building an IUCG page on >linguistic support, introducing multilinguistics, >multilingualization, mecalanguages, etc. >_______________________________________________ >iucg@ietf.org >https://www.ietf.org/mailman/listinfo/iucg Patrick, I think you are correct. I have proposed a framework for comments. This should be included in it. However all this calls for time. At the present time my priority is to try to establish a working ATLARGE framework, to get some recurent low financing for it, and some secretariat established. jfc --=====================_225969453==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit At 23:29 14/11/2009, Patrick Suger wrote:
2009/11/13 "Martin J. Dürst" <duerst@it.aoyama.ac.jp >

For those who didn't attended yesterday's IETF Technical Plenary (or
like me, listened to it on the audio feed), here is a link to the slides
from the IAB presentation on Protocol Internationalization and Character
Encoding:

Jefsey, dont you think it could be worth building an IUCG page on linguistic support, introducing multilinguistics, multilingualization, mecalanguages, etc.
_______________________________________________
iucg@ietf.org
https://www.ietf.org/mailman/listinfo/iucg

Patrick,

I think you are correct. I have proposed a framework for comments. This should be included in it. However all this calls for time. At the present time my priority is to try to establish a working ATLARGE framework, to get some recurent low financing for it, and some secretariat established.

jfc --=====================_225969453==.ALT-- From jefsey@jefsey.com Sat Nov 14 17:14: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 048993A6814 for ; Sat, 14 Nov 2009 17:14:22 -0800 (PST) X-Quarantine-ID: <4wHTXvbrSCGm> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char E9 hex): Subject: Re: [iucg] Pr\351sentation sur I[...] X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SUBJECT_NEEDS_ENCODING=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 4wHTXvbrSCGm for ; Sat, 14 Nov 2009 17:14:21 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 2C5463A6768 for ; Sat, 14 Nov 2009 17:14:21 -0800 (PST) Received: from 89-158-60-119.rev.dartybox.com ([89.158.60.119]:1836 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1N9SY5-0007sn-Lu; Sat, 14 Nov 2009 16:00:58 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 15 Nov 2009 00:59:52 +0100 To: internet users contributing group ,iucg@core3.amsl.com From: JFC Morfin Subject: Re: [iucg] Présentation sur Internationalisation par l'IAB In-Reply-To: <4e9b16b30911141429q4138295eo69e17b8a027f6d46@mail.gmail.co m> References: <4e9b16b30911141429q4138295eo69e17b8a027f6d46@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_225969453==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20091115011421.2C5463A6768@core3.amsl.com> Cc: comptoir@cafedu.com, listegenerale@franceatlarge.org 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, 15 Nov 2009 01:14:22 -0000 --=====================_225969453==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit At 23:29 14/11/2009, Patrick Suger wrote: >2009/11/13 "Martin J. Dürst" ><duerst@it.aoyama.ac.jp> > >For those who didn't attended yesterday's IETF Technical Plenary (or >like me, listened to it on the audio feed), here is a link to the slides >from the IAB presentation on Protocol Internationalization and Character >Encoding: >Jefsey, dont you think it could be worth building an IUCG page on >linguistic support, introducing multilinguistics, >multilingualization, mecalanguages, etc. >_______________________________________________ >iucg@ietf.org >https://www.ietf.org/mailman/listinfo/iucg Patrick, I think you are correct. I have proposed a framework for comments. This should be included in it. However all this calls for time. At the present time my priority is to try to establish a working ATLARGE framework, to get some recurent low financing for it, and some secretariat established. jfc --=====================_225969453==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit At 23:29 14/11/2009, Patrick Suger wrote:
2009/11/13 "Martin J. Dürst" <duerst@it.aoyama.ac.jp >

For those who didn't attended yesterday's IETF Technical Plenary (or
like me, listened to it on the audio feed), here is a link to the slides
from the IAB presentation on Protocol Internationalization and Character
Encoding:

Jefsey, dont you think it could be worth building an IUCG page on linguistic support, introducing multilinguistics, multilingualization, mecalanguages, etc.
_______________________________________________
iucg@ietf.org
https://www.ietf.org/mailman/listinfo/iucg

Patrick,

I think you are correct. I have proposed a framework for comments. This should be included in it. However all this calls for time. At the present time my priority is to try to establish a working ATLARGE framework, to get some recurent low financing for it, and some secretariat established.

jfc --=====================_225969453==.ALT-- From eblanconil@gmail.com Sun Nov 29 03:38:08 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 826E23A686B for ; Sun, 29 Nov 2009 03:38:08 -0800 (PST) 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 quOfmT3uEmUi for ; Sun, 29 Nov 2009 03:38:07 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 52E7C3A677D for ; Sun, 29 Nov 2009 03:38:07 -0800 (PST) Received: by ewy7 with SMTP id 7so3364792ewy.28 for ; Sun, 29 Nov 2009 03:37:57 -0800 (PST) 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=6gncIdIy76ceA7DmeaTVgGGQ6RdJ99iyGX2hujEYzxk=; b=iQkhEWuNYd1hMybxTSv23RfXQUHl0C6lT8TwiGAKq/jWH9VunXbFdC60KGqVQeSECq SLX6wcU3h+8Finqyll7QJtkDGKQDGpoqnxC6o9sFBRgUdw9+S7AMSmwtI7q0QJDAjfph l5RlJwgZLpogxsuaYRJyOB+RW2yr1/O0gBnNw= 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=cvbt1Uo3R8x07eNYIMZBtaEUIWKk2STNGv/ppGfwaAPUl1kQlvPqn+K3redCW6T3Se l87f5139JdlA3ihTbWB0DaYCr9L+UZRrXUFLnLnApezgJWkLXk14F5+H8GIHihQOJG4R 2eF6GaSYcM6czdOuxEa9WdEgL9Xo13leX2QWc= MIME-Version: 1.0 Received: by 10.216.90.77 with SMTP id d55mr1004904wef.146.1259494677375; Sun, 29 Nov 2009 03:37:57 -0800 (PST) In-Reply-To: <6aad7a210911290245g3a362c5bq7c041478b8c815d6@mail.gmail.com> References: <3FCFF859-FEB2-4586-98EA-401F0853F78E@google.com> <51F7F4AC-6E4D-406E-8B79-279A03D0CD47@frobbit.se> <4B124E63.4020003@nic.museum> <6aad7a210911290245g3a362c5bq7c041478b8c815d6@mail.gmail.com> Date: Sun, 29 Nov 2009 12:37:57 +0100 Message-ID: <6589127a0911290337pce185f9r8f78faba4a02e8a2@mail.gmail.com> From: Elisabeth Blanconil To: idna-update@alvestrand.no Content-Type: multipart/alternative; boundary=0016e6d7ea68d76bcd047980f481 Cc: internet users contributing group Subject: Re: [iucg] Consensus Call on Latin Sharp S and Greek Final Sigma 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, 29 Nov 2009 11:38:08 -0000 --0016e6d7ea68d76bcd047980f481 Content-Type: text/plain; charset=ISO-8859-1 OK for me. Filtering on the network (i.e. in my reading: outside of the user's own area) is prohibited by the Charter. Except if one changes the Charter and reopen the WG. Elisabeth Blanconil 2009/11/29 jean-michel bernier de portzamparc > +1 > > 2009/11/29 Cary Karp > > (1) Both characters should be PVALID >> >> /Cary >> _______________________________________________ >> Idna-update mailing list >> Idna-update@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/idna-update >> > > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > > --0016e6d7ea68d76bcd047980f481 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK for me. Filtering on the network (i.e. in my reading: outside of the use= r's own area) is prohibited by the Charter. Except if one changes the C= harter and reopen the WG.

Elisabeth Blanconil

2009/11/29 jean-michel bernier de portzamparc <jmabdp@gmail.com>
+1

2009/11/29 Cary Karp <ck@nic.museum&g= t;

(1) Both characters should be PVALID

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


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


--0016e6d7ea68d76bcd047980f481-- From jefsey@jefsey.com Sun Nov 29 04:03: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 AC3C63A6807 for ; Sun, 29 Nov 2009 04:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.457 X-Spam-Level: X-Spam-Status: No, score=0.457 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_ADOBE2=2.455, GB_I_LETTER=-2, 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 9i11y3EfvK2s for ; Sun, 29 Nov 2009 04:03:11 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 197323A6941 for ; Sun, 29 Nov 2009 04:03:11 -0800 (PST) Received: from 89-158-60-65.rev.dartybox.com ([89.158.60.65]:2810 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NEiUW-000661-FK; Sun, 29 Nov 2009 04:03:01 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 29 Nov 2009 13:01:53 +0100 To: iucg@ietf.org From: jefsey In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10180921==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20091129120311.197323A6941@core3.amsl.com> Cc: markdavis@google.com, emuller@adobe.com, Michel SUIGNARD , lisa Dusseault , vint Cerf , lisam@us.ibm.com Subject: Re: [iucg] Letter to Unicode Technical Committee on IDNA2008 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, 29 Nov 2009 12:03:12 -0000 --=====================_10180921==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit The following mail from Vint Cerf can be of interest to you as an IUCG participants. Consensus was to respect the charter and keep as many code points as PVALID. The IUCG Interplus SIG position is that in any case we do not mind as orthotypographic issues can be corrected by punyplus in using a local escape that will result in a different non-conflicting ASCII Internet Domain Name. Such an escape could be a special Unicode character, a special IUCG code point, or of syntaxic (format) nature. The quickest solution is syntaxic. The most advisable would be an ISO 10646 IDNA reserved code point area. The most probable is a syntaxic experiementation, followed by a IU/FLOSS IDNAPLUS reserved code point area, leading to an RFC for information and an ISO/JTC1 NWIP. Best jfc http://iucg.org At 22:57 28/11/2009, Vint Cerf wrote: >Note to the IDNABIS Working Group: >During processing of the Last Call responses, the Area Director >expressed discomfort with the state of consensus on the use of Latin >Small Letter Sharp S and Greek Small Letter Final Sigma. To gain >additional input on whether these should remain PVALID, I am sending >the letter below to the Unicode Technical Committee for its opinion. > >vint cerf > >------------------ > > >Ms. Lisa Moore >Chairman, Unicode Technical Committee >via email: lisam@us.ibm.com > >CC: >Eric Muller >Vice Chairman, Unicode Technical Committee >via email: emuller@adobe.com > >Mark Davis >President, Unicode Consortium >via email: markdavis@google.com > >28 November 2010 > >Dear Ms. Moore: > >I am writing to you in my role as chairman of the IDNABIS working >group, addressing this request to you as president of the Unicode >Consortium. As you know, treatment of the two characters, Greek >Small Letter Final Sigma (U+03C2) and Latin Small Letter Sharp S >(U+00DF) have been the source of considerable discussion during the >IDNABIS Working Group effort on specifying the IDNA2008 proposed >replacement of the IDNA2003 standard for the use of Unicode in >Internationalized Domain Names. Latin Capital Letter Sharp S >(U+1E9E) was added in Unicode version 5.1.0 but recommended rules >for its use were provided as shown below: > >Begin quote from Unicode Version 5.1.0 > >Tailored Casing Operations > >The Unicode Standard provides default casing operations. There are >circumstances in which the default operations need to be tailored >for specific locales or environments. Some of these tailorings have >data that is in the standard, in the SpecialCasing.txt file, notable >for the Turkish dotted capital I and dotless small i. In other >cases, more specialized tailored casing operations may be >appropriate. These include: >Titlecasing of IJ at the start of words in Dutch >Removal of accents when uppercasing letters in Greek >Uppercasing U+00DF ( ß ) LATIN SMALL LETTER SHARP S to the new >U+1E9E LATIN CAPITAL LETTER SHARP S > >However, these tailorings may or may not be desired, depending on >the implementation in question. > >In particular, capital sharp s is intended for typographical >representations of signage and uppercase titles, and other >environments where users require the sharp s to be preserved in >uppercase. Overall, such usage is rare. In contrast, standard German >orthography uses the string "SS" as uppercase mapping for small >sharp s. Thus, with the default Unicode casing operations, capital >sharp s will lowercase to small sharp s, but not the reverse: small >sharp s uppercases to "SS". In those instances where the reverse >casing operation is needed, a tailored operation would be required. > >End quote from Unicode Version 5.1.0 >In IDNA2003, Sharp S was mapped to "ss" by means of a casing >operation that mapped lower case Sharp S to uppercase "SS" and then >down to lowercase "ss". Registrations and lookups using the IDNA2003 >rules applied this mechanism. > >During the discussions in the IDNABIS Working Group on IDNA2008, a >strong consensus developed around not mapping for example for >registration purposes and also for preserving the property that the >IDNA2008-defined A-Label and U-Label forms be fully symmetric (i.e., >convertible into one another without change or loss). > > >During these same discussions, a consensus seemed to develop to >permit (ie. make "PVALID" in IDNA2008 parlance) Latin Small Letter >Sharp S (U+00DF) and Greek Small Letter Final Sigma (U+03C2). The >recommended casing actions of Unicode (i.e. toCaseFold) on Sharp S >and Final Sigma produce "ss" in the case of Sharp S and Greek Small >Letter Sigma (U+03C3) in the case of Final Sigma. > >To make the lowercase forms PVALID using the functional rules of >IDNA2008, exceptions were required to overcome the recommended >casing mechanics of Unicode (i.e. application of CaseFolding). >Note that IDNA2008 explicitly permits mapping for User Interface purposes: >a) draft-ietf-idnabis-protocol-17#section-5.2 >c) draft-ietf-idnabis-rationale-14#section-4.4 >d) draft-ietf-idnabis-rationale-14#section-6 >e) draft-ietf-idnabis-rationale-14#section-7.3 >f) draft-ietf-idnabis-mappings-05 > >If Small Letter Sharp S and Small Letter Final Sigma were to be made >DISALLOWED, these mapping provisions would permit these characters >to be handled as a User Interface matter prior to lookup. > >Because the practices of IDNA2003 are in conflict with the proposed >practices of IDNA2008, and because the Last Call discussions have >surfaced controversy over the incorporation of the two lowercase >forms in question, I request an organizational recommendation from >UTC as to the treatment of these characters. Taking into account the >prohibition of mapping on registration, which I take to be firm, and >the requirement that A-Label and U-Label forms must be unambiguously >convertible into each other, would the UTC recommend to exclude the >use of Small Letter Sharp S and Small Letter Final Sigma in >IDNA2008 by removing their exceptions and making each DISALLOWED? > >A prompt response would be much appreciated considering we have >delayed reporting the results of the IETF LAST CALL to the Internet >Engineering Steering Group while this matter is debated. > >Sincerely, > >Vinton Cerf >Chairman, IDNABIS Working Group of the Internet Engineering Task Force --=====================_10180921==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit The following mail from Vint Cerf can be of interest to you as an IUCG participants. Consensus was to respect the charter and keep as many code points as PVALID.

The IUCG Interplus SIG position is that in any case we do not mind as orthotypographic issues can be corrected by punyplus in using a local escape that will result in a different non-conflicting ASCII Internet Domain Name. Such an escape could be a special Unicode character, a special IUCG code point, or of syntaxic (format) nature. The quickest solution is syntaxic. The most advisable would be an ISO 10646 IDNA reserved code point area. The most probable is a syntaxic experiementation, followed by a IU/FLOSS IDNAPLUS reserved code point area, leading to an RFC for information and an ISO/JTC1 NWIP.

Best
jfc
http://iucg.org

At 22:57 28/11/2009, Vint Cerf wrote:
Note to the IDNABIS Working Group:
During processing of the Last Call responses, the Area Director expressed discomfort with the state of consensus on the use of Latin Small Letter Sharp S and  Greek Small Letter Final Sigma. To gain additional input on whether these should remain PVALID, I am sending the letter below to the Unicode Technical Committee for its opinion.

vint cerf

------------------


Ms. Lisa Moore
Chairman, Unicode Technical Committee
via email: lisam@us.ibm.com
 
CC:
Eric Muller
Vice Chairman, Unicode Technical Committee
via email: emuller@adobe.com
 
Mark Davis
President, Unicode Consortium
via email: markdavis@google.com
 
28 November 2010
 
Dear Ms. Moore:
 
I am writing to you in my role as chairman of the IDNABIS working group, addressing this request to you as president of the Unicode Consortium. As you know, treatment of the two characters, Greek Small Letter Final Sigma (U+03C2) and Latin Small Letter Sharp S (U+00DF) have been the source of considerable discussion during the IDNABIS Working Group effort on specifying the  IDNA2008 proposed replacement of the IDNA2003 standard for the use of Unicode in Internationalized Domain Names. Latin Capital Letter Sharp S (U+1E9E) was added in Unicode version 5.1.0 but recommended rules for its use were provided as shown below:
 
Begin quote from Unicode Version 5.1.0

Tailored Casing Operations

The Unicode Standard provides default casing operations. There are circumstances in which the default operations need to be tailored for specific locales or environments. Some of these tailorings have data that is in the standard, in the SpecialCasing.txt file, notable for the Turkish dotted capital I and dotless small i. In other cases, more specialized tailored casing operations may be appropriate. These include:
Titlecasing of IJ at the start of words in Dutch
Removal of accents when uppercasing letters in Greek
Uppercasing U+00DF ( ß ) LATIN SMALL LETTER SHARP S to the new U+1E9E LATIN CAPITAL LETTER SHARP S

However, these tailorings may or may not be desired, depending on the implementation in question.

In particular, capital sharp s is intended for typographical representations of signage and uppercase titles, and other environments where users require the sharp s to be preserved in uppercase. Overall, such usage is rare. In contrast, standard German orthography uses the string "SS" as uppercase mapping for small sharp s. Thus, with the default Unicode casing operations, capital sharp s will lowercase to small sharp s, but not the reverse: small sharp s uppercases to "SS". In those instances where the reverse casing operation is needed, a tailored operation would be required.

End quote from Unicode Version 5.1.0
In IDNA2003, Sharp S was mapped to "ss" by means of a casing operation that mapped lower case Sharp S to uppercase "SS" and then down to lowercase "ss". Registrations and lookups using the IDNA2003 rules applied this mechanism.
 
During the discussions in the IDNABIS Working Group on IDNA2008, a strong consensus developed around not mapping for example for registration purposes and also for preserving the property that the IDNA2008-defined A-Label and U-Label forms be fully symmetric (i.e., convertible into one another without change or loss).
 

During these same discussions, a consensus seemed to develop to permit (ie. make "PVALID" in IDNA2008 parlance) Latin Small Letter Sharp S (U+00DF) and Greek Small Letter Final Sigma (U+03C2). The recommended casing actions of Unicode (i.e. toCaseFold) on Sharp S and Final Sigma produce "ss" in the case of Sharp S and Greek Small Letter Sigma (U+03C3) in the case of Final Sigma.

To make the lowercase forms PVALID using the functional rules of IDNA2008, exceptions were required to overcome the recommended casing mechanics of Unicode (i.e. application of CaseFolding).
Note that IDNA2008 explicitly permits mapping for User Interface purposes:
a) draft-ietf-idnabis-protocol-17#section-5.2
c) draft-ietf-idnabis-rationale-14#section-4.4
d) draft-ietf-idnabis-rationale-14#section-6
e) draft-ietf-idnabis-rationale-14#section-7.3
f) draft-ietf-idnabis-mappings-05
 
If Small Letter Sharp S and Small Letter Final Sigma were to be made DISALLOWED, these mapping provisions would permit these characters to be handled as a User Interface matter prior to lookup.
 
Because the practices of IDNA2003 are in conflict with the proposed practices of IDNA2008, and because the Last Call discussions have surfaced controversy over the incorporation of the two lowercase forms in question, I request an organizational recommendation from UTC as to the treatment of these characters. Taking into account the prohibition of mapping on registration, which I take to be firm, and the requirement that A-Label and U-Label forms must be unambiguously convertible into each other, would the UTC recommend to exclude the use of Small Letter Sharp  S and Small Letter Final Sigma in IDNA2008 by removing their exceptions and making each DISALLOWED?
 
A prompt response would be much appreciated considering we have delayed reporting the results of the IETF LAST CALL to the Internet Engineering Steering Group while this matter is debated.
 
Sincerely,
 
Vinton Cerf
Chairman, IDNABIS Working Group of the Internet Engineering Task Force
--=====================_10180921==.ALT-- From xlegoff@gmail.com Sun Nov 29 04:16:09 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 519453A6783 for ; Sun, 29 Nov 2009 04:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.457 X-Spam-Level: X-Spam-Status: No, score=0.457 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_ADOBE2=2.455, GB_I_LETTER=-2, 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 VDn4dUlpZSKo for ; Sun, 29 Nov 2009 04:16:07 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 33CEB3A693D for ; Sun, 29 Nov 2009 04:16:06 -0800 (PST) Received: by ewy7 with SMTP id 7so3384964ewy.28 for ; Sun, 29 Nov 2009 04:15:56 -0800 (PST) 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=eXX/WEc8TqtI6Qv/oScQHKNxQ7FErSJFFe656o/ciMc=; b=v/XOroWuWoBRAMh3kdkrVLvNRPLpUoi5P3lsSixSF8J8SY3+K7pJL/sHNhOhKG05FJ 4siwOTlv0t+3PKX0ElfTXl03Wm0xyX3xmEw8wjvOM9u5xqmmLp/96RIqABVfhfPUNzog jVy39jHHyGepcZ/3WMhdSHZq7F5l20q3/9LCc= 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=xlXgHv9ckCVFZjXfG4FJVL6MEoMUek8tfNP+doZ2POws6GvDJfm1pu92ySRS52anze oVBViNtQiwOewj7Clx32j3jOHCd4VvOVPTwQuigpCqN82Zo8/rsMBa9iSqb+KEv+mAJT Mwac2B46d3E+NQ6lYuIOiStOy4l0HPCPllMIg= MIME-Version: 1.0 Received: by 10.216.87.16 with SMTP id x16mr1042040wee.106.1259496956424; Sun, 29 Nov 2009 04:15:56 -0800 (PST) In-Reply-To: <20091129120311.197323A6941@core3.amsl.com> References: <20091129120311.197323A6941@core3.amsl.com> Date: Sun, 29 Nov 2009 13:15:56 +0100 Message-ID: From: Xavier Legoff To: internet users contributing group Content-Type: multipart/alternative; boundary=0016e6dab150aef42d0479817c2b Cc: markdavis@google.com, emuller@adobe.com, Michel SUIGNARD , lisa Dusseault , vint Cerf , lisam@us.ibm.com Subject: Re: [iucg] Letter to Unicode Technical Committee on IDNA2008 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, 29 Nov 2009 12:16:09 -0000 --0016e6dab150aef42d0479817c2b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/11/29 jefsey > The following mail from Vint Cerf can be of interest to you as an IUCG > participants. Consensus was to respect the charter and keep as many code > points as PVALID. > This was the consensus we reached. And decided that the network as everything outside of the IU (Internet User) cybship. Best Xavier > > The IUCG Interplus SIG position is that in any case we do not mind as > orthotypographic issues can be corrected by punyplus in using a local esc= ape > that will result in a different non-conflicting ASCII Internet Domain Nam= e. > Such an escape could be a special Unicode character, a special IUCG code > point, or of syntaxic (format) nature. The quickest solution is syntaxic. > The most advisable would be an ISO 10646 IDNA reserved code point area. T= he > most probable is a syntaxic experiementation, followed by a IU/FLOSS > IDNAPLUS reserved code point area, leading to an RFC for information and = an > ISO/JTC1 NWIP. > > Best > jfc > http://iucg.org > > At 22:57 28/11/2009, Vint Cerf wrote: > > Note to the IDNABIS Working Group: > During processing of the Last Call responses, the Area Director expressed > discomfort with the state of consensus on the use of Latin Small Letter > Sharp S and Greek Small Letter Final Sigma. To gain additional input on > whether these should remain PVALID, I am sending the letter below to the > Unicode Technical Committee for its opinion. > > vint cerf > > ------------------ > > > Ms. Lisa Moore > Chairman, Unicode Technical Committee > via email: lisam@us.ibm.com > > CC: > Eric Muller > Vice Chairman, Unicode Technical Committee > via email: emuller@adobe.com > > Mark Davis > President, Unicode Consortium > via email: markdavis@google.com > > > 28 November 2010 > > Dear Ms. Moore: > > I am writing to you in my role as chairman of the IDNABIS working group, > addressing this request to you as president of the Unicode Consortium. As > you know, treatment of the two characters, Greek Small Letter Final Sigma > (U+03C2) and Latin Small Letter Sharp S (U+00DF) have been the source of > considerable discussion during the IDNABIS Working Group effort on > specifying the IDNA2008 proposed replacement of the IDNA2003 standard fo= r > the use of Unicode in Internationalized Domain Names. Latin Capital Lette= r > Sharp S (U+1E9E) was added in Unicode version 5.1.0 but recommended rules > for its use were provided as shown below: > > Begin quote from Unicode Version 5.1.0 > > *Tailored Casing Operations > * > The Unicode Standard provides default casing operations. There are > circumstances in which the default operations need to be tailored for > specific locales or environments. Some of these tailorings have data that= is > in the standard, in the SpecialCasing.txt file, notable for the Turkish *= dotted > capital I* and *dotless small i*. In other cases, more specialized > tailored casing operations may be appropriate. These include: > Titlecasing of IJ at the start of words in Dutch > Removal of accents when uppercasing letters in Greek > Uppercasing U+00DF ( =DF ) LATIN SMALL LETTER SHARP S to the new U+1E9E L= ATIN > CAPITAL LETTER SHARP S > > However, these tailorings may or may not be desired, depending on the > implementation in question. > > In particular, *capital sharp s* is intended for typographical > representations of signage and uppercase titles, and other environments > where users require the *sharp s* to be preserved in uppercase. Overall, > such usage is rare. In contrast, standard German orthography uses the str= ing > "SS" as uppercase mapping for *small sharp s*. Thus, with the default > Unicode casing operations, *capital sharp s* will lowercase to *small > sharp s*, but not the reverse: *small sharp s* uppercases to "SS". In > those instances where the reverse casing operation is needed, a tailored > operation would be required. > > End quote from Unicode Version 5.1.0 > In IDNA2003, Sharp S was mapped to "ss" by means of a casing operation th= at > mapped lower case Sharp S to uppercase "SS" and then down to lowercase "s= s". > Registrations and lookups using the IDNA2003 rules applied this mechanism= . > > During the discussions in the IDNABIS Working Group on IDNA2008, a strong > consensus developed around not mapping for example for registration purpo= ses > and also for preserving the property that the IDNA2008-defined A-Label an= d > U-Label forms be fully symmetric (i.e., convertible into one another with= out > change or loss). > > > During these same discussions, a consensus seemed to develop to permit (i= e. > make "PVALID" in IDNA2008 parlance) Latin Small Letter Sharp S (U+00DF) a= nd > Greek Small Letter Final Sigma (U+03C2). The recommended casing actions o= f > Unicode (i.e. toCaseFold) on Sharp S and Final Sigma produce "ss" in the > case of Sharp S and Greek Small Letter Sigma (U+03C3) in the case of Fina= l > Sigma. > > To make the lowercase forms PVALID using the functional rules of IDNA2008= , > exceptions were required to overcome the recommended casing mechanics of > Unicode (i.e. application of CaseFolding). > Note that IDNA2008 explicitly permits mapping for User Interface purposes= : > a) draft-ietf-idnabis-protocol-17#section-5.2 > c) draft-ietf-idnabis-rationale-14#section-4.4 > d) draft-ietf-idnabis-rationale-14#section-6 > e) draft-ietf-idnabis-rationale-14#section-7.3 > f) draft-ietf-idnabis-mappings-05 > > If Small Letter Sharp S and Small Letter Final Sigma were to be made > DISALLOWED, these mapping provisions would permit these characters to be > handled as a User Interface matter prior to lookup. > > Because the practices of IDNA2003 are in conflict with the proposed > practices of IDNA2008, and because the Last Call discussions have surface= d > controversy over the incorporation of the two lowercase forms in question= , I > request an organizational recommendation from UTC as to the treatment of > these characters. Taking into account the prohibition of mapping on > registration, which I take to be firm, and the requirement that A-Label a= nd > U-Label forms must be unambiguously convertible into each other, would th= e > UTC recommend to exclude the use of Small Letter Sharp S and Small Lette= r > Final Sigma in IDNA2008 by removing their exceptions and making each > DISALLOWED? > > A prompt response would be much appreciated considering we have delayed > reporting the results of the IETF LAST CALL to the Internet Engineering > Steering Group while this matter is debated. > > Sincerely, > > Vinton Cerf > Chairman, IDNABIS Working Group of the Internet Engineering Task Force > > > _______________________________________________ > iucg mailing list > iucg@ietf.org > https://www.ietf.org/mailman/listinfo/iucg > > --0016e6dab150aef42d0479817c2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2009/11/29 jefsey <jefsey@jefsey.com>
The following mail from Vint Cerf can be of interest to you as an IUCG participants. Consensus was to respect the charter and keep as many code points as PVALID.

This was the consensus we= reached. And decided that the network as everything outside of the IU (Int= ernet User) cybship.
Best
Xavier
=A0

The IUCG Interplus SIG position is that in any case we do not mind as orthotypographic issues can be corrected by punyplus in using a local escape that will result in a different non-conflicting ASCII Internet Domain Name. Such an escape could be a special Unicode character, a special IUCG code point, or of syntaxic (format) nature. The quickest solution is syntaxic. The most advisable would be an ISO 10646 IDNA reserved code point area. The most probable is a syntaxic experiementation, followed by a IU/FLOSS IDNAPLUS reserved code point area, leading to an RFC for information and an ISO/JTC1 NWIP.

Best
jfc
http://iucg.org

At 22:57 28/11/2009, Vint Cerf wrote:
Note to the IDNABIS Worki= ng Group:
During processing of the Last Call responses, the Area Director expressed discomfort with the state of consensus on the use of Latin Small Letter Sharp S and=A0 Greek Small Letter Final Sigma. To gain additional input on whether these should remain PVALID, I am sending the letter below to the Unicode Technical Committee for its opinion.

vint cerf

------------------


Ms. Lisa Moore
Chairman, Unicode Technical Committee
via email: lisam@us.i= bm.com
=A0
CC:
Eric Muller
Vice Chairman, Unicode Technical Committee
via email: emuller@a= dobe.com
=A0
Mark Davis
President, Unicode Consortium
via email: markdavis@google= .com

=A0
28 November 2010
=A0
Dear Ms. Moore:
=A0
I am writing to you in my role as chairman of the IDNABIS working group, addressing this request to you as president of the Unicode Consortium. As you know, treatment of the two characters, Greek Small Letter Final Sigma (U+03C2) and Latin Small Letter Sharp S (U+00DF) have been the source of considerable discussion during the IDNABIS Working Group effort on specifying the=A0 IDNA2008 proposed replacement of the IDNA2003 standard for the use of Unicode in Internationalized Domain Names. Latin Capital Letter Sharp S (U+1E9E) was added in Unicode version 5.1.0 but recommended rules for its use were provided as shown below:
=A0
Begin quote from Unicode Version 5.1.0

Tailored Casing Operations

The Unicode Standard provides default casing operations. There are circumstances in which the default operations need to be tailored for specific locales or environments. Some of these tailorings have data that is in the standard, in the SpecialCasing.txt file, notable for the Turkish dotted capital I and dotless small i. In other cases, more specialized tailored casing operations may be appropriate. These include:
Titlecasing of IJ at the start of words in Dutch
Removal of accents when uppercasing letters in Greek
Uppercasing U+00DF ( =DF ) LATIN SMALL LETTER SHARP S to the new U+1E9E LATIN CAPITAL LETTER SHARP S

However, these tailorings may or may not be desired, depending on the implementation in question.

In particular, capital sharp s is intended for typographical representations of signage and uppercase titles, and other environments where users require the sharp s to be preserved in uppercase. Overall, such usage is rare. In contrast, standard German orthography uses the string "SS" as uppercase mapping for small sharp s. Thus, with the default Unicode casing operations, capital sharp s will lowercase to small sharp s, but not the reverse: small sharp s uppercases to "SS". In those instances where the reverse casing operation is needed, a tailored operation would be required.

End quote from Unicode Version 5.1.0
In IDNA2003, Sharp S was mapped to "ss" by means of a casing operation that mapped lower case Sharp S to uppercase "SS" and then down to lowercase "ss". Registrations and lookups using the IDNA2003 rules applied this mechanism.
=A0
During the discussions in the IDNABIS Working Group on IDNA2008, a strong consensus developed around not mapping for example for registration purposes and also for preserving the property that the IDNA2008-defined A-Label and U-Label forms be fully symmetric (i.e., convertible into one another without change or loss).
=A0

During these same discussions, a consensus seemed to develop to permit (ie. make "PVALID" in IDNA2008 parlance) Latin Small Letter Sharp S (U+00DF) and Greek Small Letter Final Sigma (U+03C2). The recommended casing actions of Unicode (i.e. toCaseFold) on Sharp S and Final Sigma produce "ss" in the case of Sharp S and Greek Small Letter Sigma (U+03C3) in the case of Final Sigma.

To make the lowercase forms PVALID using the functional rules of IDNA2008, exceptions were required to overcome the recommended casing mechanics of Unicode (i.e. application of CaseFolding).
Note that IDNA2008 explicitly permits mapping for User Interface purposes:
a) draft-ietf-idnabis-protocol-17#section-5.2
c) draft-ietf-idnabis-rationale-14#section-4.4
d) draft-ietf-idnabis-rationale-14#section-6
e) draft-ietf-idnabis-rationale-14#section-7.3
f) draft-ietf-idnabis-mappings-05
=A0
If Small Letter Sharp S and Small Letter Final Sigma were to be made DISALLOWED, these mapping provisions would permit these characters to be handled as a User Interface matter prior to lookup.
=A0
Because the practices of IDNA2003 are in conflict with the proposed practices of IDNA2008, and because the Last Call discussions have surfaced controversy over the incorporation of the two lowercase forms in question, I request an organizational recommendation from UTC as to the treatment of these characters. Taking into account the prohibition of mapping on registration, which I take to be firm, and the requirement that A-Label and U-Label forms must be unambiguously convertible into each other, would the UTC recommend to exclude the use of Small Letter Sharp=A0 S and Small Letter Final Sigma in IDNA2008 by removing their exceptions and making each DISALLOWED?
=A0
A prompt response would be much appreciated considering we have delayed reporting the results of the IETF LAST CALL to the Internet Engineering Steering Group while this matter is debated.
=A0
Sincerely,
=A0
Vinton Cerf
Chairman, IDNABIS Working Group of the Internet Engineering Task Force

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


--0016e6dab150aef42d0479817c2b-- From psuger@gmail.com Sun Nov 29 16:49: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 6ACAB3A6781 for ; Sun, 29 Nov 2009 16:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 2WCMGZlYriyY for ; Sun, 29 Nov 2009 16:49:32 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id B52C63A6A0A for ; Sun, 29 Nov 2009 16:49:31 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so768273fga.13 for ; Sun, 29 Nov 2009 16:49:21 -0800 (PST) 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=GxyFbPvgJEWTiUqsV1VCUl6PYycQ+Ts5t5N8y4+s/rQ=; b=XyrSA/dOCYvQ0fSGgGL/+DNccM9sXFGlBFuQNwC9yPSjviYjoEaBAEOdtqmdyxcKoa taEV8Me5VaV2fYG9TXUHcZ03ROsYzUPykX13wBO168kDvS4INJWOn8FtnVTiZU0A5Jq7 ea2O2x2PovDCfsbTLyZKcASShK/ivDV3ZQkYg= 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=o2EjBCSUqkXLr6eqA9mH7OxkZ5qCA8Ps2u99KOke2kMuC3vfWUelsik4nyjNAbNGUQ 3JsVyKxpS6y/vdM2cErOt9zf9z8hTLZTa1DW5LFY/qijhEjrdElfdHvfhCm89Lp9uYMb wzmcF4B6Ajw4KkEZ04AdcZzOGhNz0yarYXleY= MIME-Version: 1.0 Received: by 10.239.141.159 with SMTP id c31mr365006hba.147.1259542160478; Sun, 29 Nov 2009 16:49:20 -0800 (PST) In-Reply-To: <3FCFF859-FEB2-4586-98EA-401F0853F78E@google.com> References: <3FCFF859-FEB2-4586-98EA-401F0853F78E@google.com> Date: Mon, 30 Nov 2009 01:49:20 +0100 Message-ID: <4e9b16b30911291649x4b639e10sc28fde2f43e446f1@mail.gmail.com> From: Patrick Suger To: Vint Cerf , IDNA update work , Lisa Dusseault Content-Type: multipart/alternative; boundary=001485f6c75a0e120904798c03d4 Cc: internet users contributing group Subject: Re: [iucg] Consensus Call on Latin Sharp S and Greek Final Sigma 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, 30 Nov 2009 00:49:33 -0000 --001485f6c75a0e120904798c03d4 Content-Type: text/plain; charset=ISO-8859-1 Dear Colleagues, as a "secretary" for our French speaking group, I skyped most of us this afternoon after receiving Mark's mail. The consensus is for (1) both PVALID. Applications can be biased the way they want but the network must be as neutral, simple, robust and dumb as possible. The more we wait, the more people will have to adapt. In the way we (lead users, with interplus in mind) consider the whole thing we agree with Mark, but NOT at network layers. These are consideration for what we call the user pseudo-network layer (same as French Majuscules we will certainly not drop!!!), i.e. in the middleware we transparently introduce between the dumb network-end and the user, i.e. the smart-plug extension Mark actually calls for. Here we will be able to host all the enhancements Unicode will want/accept to provide. Let say we want IDNA not in applications, but in a front-end application. With a netlocale parameter file. We would be interested in knowing if someone has already developped or plans to develop an IDNA2008 routine for tools like ISC hosts.exe? P. Suger. 2009/11/29 Vint Cerf > In consultation with the area director, issues were raised concerning > the consensus on the use of Latin small letter sharp S and Greek small > final sigma as PVALID in IDNA2008. > > I have copied the working group on a request for opinion from the > Unicode Technical Committee. > > By this message, I request a response from the Working Group on the > question: > > Should Latin Small Letter Sharp S and Greek Small Letter Final Sigma > be PVALID in IDNA2008 or not: > > Please Respond by choosing among the following: > > (1) Both characters should be PVALID > (2) Both characters should be DISALLOWED > (3) Only Latin Small Letter Sharp S should be PVALID > (4) Only Greek Small Letter Final Sigma should be PVALID > > Choices (3) and (4) create additional complexity in dealing with > IDNA2003 and IDNA2008 disparities > > During the Last Call, a number of objections were raised with regard > to choice (1) and this led the Area Director to question the rough > consensus that the WG submission to IESG claimed. > > It will be much appreciated if all working group members would respond > by December 8. > > thanks, > > vint cerf > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > --001485f6c75a0e120904798c03d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Colleagues,

as a "secretary" for our French speaking = group, I skyped most of us this afternoon after receiving Mark's mail. = The consensus is for

(1) both PVALID.

Applications can be bia= sed the way they want but the network must be as neutral, simple, robust an= d dumb as possible. The more we wait, the more people will have to adapt. <= br>
In the way we (lead users, with interplus in mind) consider the whole t= hing we agree with Mark, but NOT at network layers. These are consideration= for what we call the user pseudo-network layer (same as French Majuscules = we will certainly not drop!!!), i.e. in=A0 the middleware we transparently = introduce between the dumb network-end and the user, i.e. the smart-plug ex= tension Mark actually calls for. Here we will be able to host all the enhan= cements Unicode will want/accept to provide. Let say we want IDNA not in ap= plications, but in a front-end application. With a netlocale parameter file= .

We would be interested in knowing if someone has already developped or = plans to develop an IDNA2008 routine for tools like ISC hosts.exe?

= P. Suger.
=A0

2009/11/29 Vint Cerf <vint@google.com&g= t;
In consultation w= ith the area director, issues were raised concerning
the consensus on the use of Latin small letter sharp S and Greek small
final sigma as PVALID in IDNA2008.

I have copied the working group on a request for opinion from the
Unicode Technical Committee.

By this message, I request a response from the Working Group on the
question:

Should Latin Small Letter Sharp S and Greek Small Letter Final Sigma
be PVALID in IDNA2008 or not:

Please Respond by choosing among the following:

(1) Both characters should be PVALID
(2) Both characters should be DISALLOWED
(3) Only Latin Small Letter Sharp S should be PVALID
(4) Only Greek Small Letter Final Sigma should be PVALID

Choices (3) and (4) create additional complexity in dealing with
IDNA2003 and IDNA2008 disparities

During the Last Call, a number of objections were raised with regard
to choice (1) and this led the Area Director to question the rough
consensus that the WG submission to IESG claimed.

It will be much appreciated if all working group members would respond
by December 8.

thanks,

vint cerf

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

--001485f6c75a0e120904798c03d4-- From jefsey@jefsey.com Mon Nov 30 08:16:26 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 EB27628C11C for ; Mon, 30 Nov 2009 08:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=2.527, BAYES_00=-2.599, GB_I_LETTER=-2, 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 YAY3JZrzDwtr for ; Mon, 30 Nov 2009 08:16:25 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id D4AD03A6AA7 for ; Mon, 30 Nov 2009 08:16:25 -0800 (PST) Received: from 89-158-60-65.rev.dartybox.com ([89.158.60.65]:2815 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NF8v1-0001uW-JL; Mon, 30 Nov 2009 08:16:08 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 30 Nov 2009 17:16:01 +0100 To: "arabic Scripts IDNA" ,iucg@ietf.org From: jefsey Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10650406==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20091130161625.D4AD03A6AA7@core3.amsl.com> Cc: iucg@ietf.org, lisa Dusseault , lisa moore Subject: [iucg] consensus over PVALIDs 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, 30 Nov 2009 16:16:27 -0000 --=====================_10650406==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear all, Vint Cerf has called for a consensus. Actually we are in a multiconsensus configuration that the IETF does not support. We have three different trade consensuses (see below) which might conflict. In such a situation multiconsensus rules say that: 1. each group should define its own consensus 2. document the way each group's solution can interoperate with the two other groups. 3. document their consensus over that interoperation being possible or not possible. I read at least three different trade visions which are: 1. the internet designers : this is the bulk of the participants since we are on an IETF list. They consider the IDNA support of IDNs through LDH domain names. They wants a better performing IDNA because making the Internet working better is the mission of the IETF, and that is why the Internet work. Consensus is for PVALID. 2. the manufacturers : Unicode people (Mark, Shawn, etc). They know that costs and pains are higher in adaptation than in development. Also that small changes at the network level may imply big changes at the production and operation level. I note that (1) they worry about one letter (having an alternative) in two languages but do not care about Latin majuscules which represent 26 (no alternative) semantically damaging letters in a dominant set of languages (2) hence a necessary alternative or alteration to IDNA; (3) the real cost is in the delays. 3. the internet users : these are ccTLDs and lead users (@larges). We are used to work on a multiconsensus basis by necessity. We consider IETF Internet layers as value added dumb bandwidth we can use the way we need. We oppose mapping at protocol level as it impacts on the IDNA orthotypographic neutrality (and probably on network neutrality due to possible poor understandings by some developpers or too good understanding by some hackers.). We certainly share the concerns of Mark and Shawn, but we only are interested in them being _supported_when_ we need it, not _enforced_. Supported means at a layer we control. Enforced means at a layer we do not control. This is why we want the network layers to stay as dumb as they should be (RFC 1958, this is the whole IDNA2008 purpose as we see it); and why we include in our machines two extra layers for a smart pseudo-network (Interplus) where we can do everything we want (including ML-DNS transcoding and DNS resolution). I know the Interplus may represent at protocol and naming layers far worse a nightmare than NATs represent at addressing layer. But I did not develop it. I do think that it might be worth to address the danger it may represent if poorly used/governed rather than to oppose the messenger. jfc --=====================_10650406==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Dear all,

Vint Cerf has called for a consensus. Actually we are in a multiconsensus configuration that the IETF does not support. We have three different trade consensuses (see below) which might conflict. In such a situation multiconsensus rules say that:

1. each group should define its own consensus
2. document the way each group's solution can interoperate with the two other groups.
3. document their consensus over that interoperation being possible or not possible.

I read at least three different trade visions which are:

1. the internet designers : this is the bulk of the participants since we are on an IETF list. They consider the IDNA support of IDNs through LDH domain names. They wants a better performing IDNA because making the Internet working better is the mission of the IETF, and that is why the Internet work. Consensus is for PVALID.

2. the manufacturers : Unicode people (Mark, Shawn, etc). They know that  costs and pains are higher in adaptation than in development. Also that small changes at the network level may imply big changes at the production and operation level. I note that (1) they worry about one letter (having an alternative) in two languages but do not care about Latin majuscules which represent 26 (no alternative) semantically damaging letters in a dominant set of languages (2) hence a necessary alternative or alteration to IDNA; (3) the real cost is in the delays.

3. the internet users : these are ccTLDs and lead users (@larges). We are used to work on a multiconsensus basis by necessity. We consider IETF Internet layers as value added dumb bandwidth we can use the way we need. We oppose mapping at protocol level as it impacts on the IDNA orthotypographic neutrality (and probably on network neutrality due to possible poor understandings by some developpers or too good understanding by some hackers.). We certainly share the concerns of Mark and Shawn, but we only are interested in them being _supported_when_ we need it, not _enforced_. Supported means at a layer we control. Enforced means at a layer we do not control. This is why we want the network layers to stay as dumb as they should be (RFC 1958, this is the whole IDNA2008 purpose as we see it); and why we include in our machines two extra layers for a smart pseudo-network (Interplus) where we can do everything we want (including ML-DNS transcoding and DNS resolution). 

I know the Interplus may represent at protocol and naming layers far worse a nightmare than NATs represent at addressing layer. But I did not develop it. I do think that it might be worth to address the danger it may represent if poorly used/governed rather than to oppose the messenger.

jfc --=====================_10650406==.ALT-- From jmabdp@gmail.com Mon Nov 30 17:54:14 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 AF0D13A6AB2 for ; Mon, 30 Nov 2009 17:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 Wik3pDmBi3cW for ; Mon, 30 Nov 2009 17:54:13 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 5045B3A6885 for ; Mon, 30 Nov 2009 17:54:13 -0800 (PST) Received: by ywh15 with SMTP id 15so3791221ywh.5 for ; Mon, 30 Nov 2009 17:54:03 -0800 (PST) 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=Sns7aCEcbaZ+OdY+b5ZSZOboXhLQM8ceYsiHKUP/TpQ=; b=VLhFIHCQ3t4DpPC+/O1oZjsC2SmI8jyAPvSGvN7IuLsoEcrv2iVsvRMvKS1JBMTaEP a8SsqxuNgWg6N5+4gERBM7jg/NKI4zdn7S5AfX++VR+fl9wMJkKb2e7UTTr4YlieDMVe x61pHCMPvtstdiOIJ0LNO4zeVwPCtOMdheRAw= 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=jWbFtVaiawLfxA9GffERj7va5fy7K/of6EO1YCJ1gBfPzGkZ7jaTqWgyI44diC00gG jGmbKU/k5PP4AZc8ofkBFV2fUGNmwjHexNF0n/IsAvCRFZAPRiDgwhJaBe9EmcHjpu// cPpJFyudbE9dxq8cxa3e9gX/MydqtRLOgvK9E= MIME-Version: 1.0 Received: by 10.101.2.22 with SMTP id e22mr2173155ani.145.1259632441936; Mon, 30 Nov 2009 17:54:01 -0800 (PST) In-Reply-To: <20091130161625.D4AD03A6AA7@core3.amsl.com> References: <20091130161625.D4AD03A6AA7@core3.amsl.com> Date: Tue, 1 Dec 2009 02:54:01 +0100 Message-ID: <6aad7a210911301754j5552e568gfca77732df4c7ad6@mail.gmail.com> From: jean-michel bernier de portzamparc To: internet users contributing group Content-Type: multipart/alternative; boundary=001636c5961b3fcd880479a1089b Cc: lisa moore , IDNA update work , lisa Dusseault , arabic Scripts IDNA Subject: Re: [iucg] consensus over PVALIDs X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 01:54:14 -0000 --001636c5961b3fcd880479a1089b Content-Type: text/plain; charset=ISO-8859-1 I am afraid we also have traveling linguists to consider. I am quite unatease with specfic cases. I would prefer to discuss PVALIDIty criteria. What is we miss equivalent issues in less familiar languages? Why would the .gr Manager or the youth of Martin be of a particular impact on a global Internet protocol? Portzamparc 2009/11/30 jefsey > Dear all, > > Vint Cerf has called for a consensus. Actually we are in a multiconsensus > configuration that the IETF does not support. We have three different trade > consensuses (see below) which might conflict. In such a situation > multiconsensus rules say that: > > 1. each group should define its own consensus > 2. document the way each group's solution can interoperate with the two > other groups. > 3. document their consensus over that interoperation being possible or not > possible. > > I read at least three different trade visions which are: > > 1.* the internet designers* : this is the bulk of the participants since > we are on an IETF list. They consider the IDNA support of IDNs through LDH > domain names. They wants a better performing IDNA because making the > Internet working better is the mission of the IETF, and that is why the > Internet work. Consensus is for PVALID. > > 2.* the manufacturers* : Unicode people (Mark, Shawn, etc). They know > that costs and pains are higher in adaptation than in development. Also > that small changes at the network level may imply big changes at the > production and operation level. I note that (1) they worry about one letter > (having an alternative) in two languages but do not care about Latin > majuscules which represent 26 (no alternative) semantically damaging letters > in a dominant set of languages (2) hence a necessary alternative or > alteration to IDNA; (3) the real cost is in the delays. > > 3. *the internet users *: these are ccTLDs and lead users (@larges). We > are used to work on a multiconsensus basis by necessity. We consider IETF > Internet layers as value added dumb bandwidth we can use the way we need. We > oppose mapping at protocol level as it impacts on the IDNA orthotypographic > neutrality (and probably on network neutrality due to possible poor > understandings by some developpers or too good understanding by some > hackers.). We certainly share the concerns of Mark and Shawn, but we only > are interested in them being _*supported*_*when*_ we need it, not _* > enforced*_. Supported means at a layer we control. Enforced means at a > layer we do not control. This is why we want the network layers to stay as > dumb as they should be (RFC 1958, this is the whole IDNA2008 purpose as we > see it); and why we include in our machines two extra layers for a smart > pseudo-network (Interplus) where we can do everything we want (including > ML-DNS transcoding and DNS resolution). > > I know the Interplus may represent at protocol and naming layers far worse > a nightmare than NATs represent at addressing layer. But I did not develop > it. I do think that it might be worth to address the danger it may represent > if poorly used/governed rather than to oppose the messenger. > > jfc > > _______________________________________________ > iucg mailing list > iucg@ietf.org > https://www.ietf.org/mailman/listinfo/iucg > > --001636c5961b3fcd880479a1089b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am afraid we also have traveling linguists to consider.
I am quite una= tease with specfic cases.
I would prefer to discuss PVALIDIty criteria.<= br>What is we miss equivalent issues in less familiar languages?
Why wou= ld the .gr Manager or the youth of Martin be of a particular impact on a gl= obal Internet protocol?

Portzamparc


2009/11/30 jefsey <jefsey@jefsey.com>
Dear all,

Vint Cerf has called for a consensus. Actually we are in a multiconsensus configuration that the IETF does not support. We have three different trade consensuses (see below) which might conflict. In such a situation multiconsensus rules say that:

1. each group should define its own consensus
2. document the way each group's solution can interoperate with the two other groups.
3. document their consensus over that interoperation being possible or not possible.

I read at least three different trade visions which are:

1. the internet designers : this is the bulk of the participants since we are on an IETF list. They consider the IDNA support of IDNs through LDH domain names. They wants a better performing IDNA because making the Internet working better is the mission of the IETF, and that is why the Internet work. Consensus is for PVALID.

2. the manufacturers : Unicode people (Mark, Shawn, etc). They know that=A0 costs and pains are higher in adaptation than in development. Also that small changes at the network level may imply big changes at the production and operation level. I note that (1) they worry about one letter (having an alternative) in two languages but do not care about Latin majuscules which represent 26 (no alternative) semantically damaging letters in a dominant set of languages (2) hence a necessary alternative or alteration to IDNA; (3) the real cost is in the delays.

3. the internet users : these are ccTLDs and lead users (@larges). We are used to work on a multiconsensus basis by necessity. We consider IETF Internet layers as value added dumb bandwidth we can use the way we need. We oppose mapping at protocol level as it impacts on the IDNA orthotypographic neutrality (and probably on network neutrality due to possible poor understandings by some developpers or too good understanding by some hackers.). We certainly share the concerns of Mark and Shawn, but we only are interested in them being _supported_when_ we need it, not _enforced_. Supported means at a layer we control. Enforced means at a layer we do not control. This is why we want the network layers to stay as dumb as they should be (RFC 1958, this is the whole IDNA2008 purpose as we see it); and why we include in our machines two extra layers for a smart pseudo-network (Interplus) where we can do everything we want (including ML-DNS transcoding and DNS resolution).=A0

I know the Interplus may represent at protocol and naming layers far worse a nightmare than NATs represent at addressing layer. But I did not develop it. I do think that it might be worth to address the danger it may represent if poorly used/governed rather than to oppose the messenger.

jfc

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


--001636c5961b3fcd880479a1089b--