From jefsey@jefsey.com Thu Oct 4 20:51:03 2012 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3DA21F84EB; Thu, 4 Oct 2012 20:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyBVqdxN3o26; Thu, 4 Oct 2012 20:51:02 -0700 (PDT) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id AABEC21F84EE; Thu, 4 Oct 2012 20:51:02 -0700 (PDT) Received: from i03v-62-35-238-138.d4.club-internet.fr ([62.35.238.138]:60901 helo=MORFIN-PC.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.77) (envelope-from ) id 1TJywE-0005ju-Eg; Thu, 04 Oct 2012 20:50:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 05 Oct 2012 05:50:53 +0200 To: John C Klensin ,dnsext@ietf.org From: JFC Morfin In-Reply-To: <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20121005035102.AABEC21F84EE@ietfa.amsl.com> Cc: IESG , "iab@iab.org IAB" , iucg , IUTF Subject: Re: [iucg] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 03:51:03 -0000 John, Thank you for this mail which has brought my attention to this critical issue. I fully support your position for two reasons: 1. It logically makes sense. It establishes a reasonable position while calling for at least some explanation. 2. I thought the key target was to keep the whole digital ecosystem name space consistent. I have engaged in the preparation of a complete review of the digital naming from the point of view of the IETF RFCs. The target is to consider how it could be kept interoperational with other technologies and needs, such as ML-DNS, semantic addressing, and content centric networking, etc. We (IUTF) globally call this work "IUse specifications" (Intelligent Use of available resources). This work is not trivial on the technical side or the linguistic side, as it studies naming from what it permits now, and not from what it was planned for. Extended label types are Internet DNS features that will certainly be retained in these specs and the current prototyping work does include the support of Binary labels for testing. The proposed sentence "This document obsoletes the use of the 2-bit combination defined by [RFC2671] to identify extended label types" is, therefore, at least premature. It would make the Internet DNS incompatible with the integrated universal digital naming syntax independent contribution that we planned to introduce in the coming months, but we can quickly produce a first draft if we feel that the IETF DNS might progressively, arbitrarily disintegrate in the meanwhile. jfc At 21:48 01/10/2012, John C Klensin wrote: >--On Sunday, September 30, 2012 07:53 -0700 The IESG > wrote: > > > > > The IESG has received a request from the DNS Extensions WG > > (dnsext) to consider the following document: > > - 'Extension Mechanisms for DNS (EDNS(0))' > > as Internet > > Standard > > > > The IESG plans to make a decision in the next few weeks, and > > solicits final comments on this action. Please send > > substantive comments to the ietf@ietf.org mailing lists by > > 2012-10-29. Exceptionally, comments may be sent to > > iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > The Domain Name System's wire protocol includes a number of > > fixed fields whose range has been or soon will be exhausted > > and does not allow requestors to advertise their > > capabilities to responders. This document describes > > backward compatible mechanisms for allowing the protocol to > > grow. > > > > This document updates the EDNS(0) specification (and > > obsoletes RFC 2671) based on feedback from deployment > > experience in several implementations. It also closes the > > IANA registry for extended labels created as part of RFC > > 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain > > Name System") which depends on the existence of extended > > labels. > >... > >Hi. Apologies for not noticing this earlier, but this >specification's deprecation of label types raises an issue that >the document doesn't seem to address. > >Deprecating RFC 2673 is one thing. Given deployment and >operational experience, I don't know of anyone who would offer a >strong defense of binary labels today. However, the document >doesn't offer a strong justification for deprecating label types >entirely other than, it seems, that there has been only one >example of their use and that failed. If that were the only >motivation, it would be a rather weak one, especially since >having a capability that we don't use (but conceivably might in >the future) would not appear to cause any harm. > >With the understanding that this is an example, not a proposal, >it may be useful to review some of the history and context for >IDNs. IDNA represents community consensus as to the right way >to proceed, but that consensus includes both people who believe >it is a good permanent strategy and people who believe it is a >good temporary/transition strategy until a better plan can be >developed and deployed. In particular, some of that latter >group were painfully aware of the rate at which EDNS0 was >deploying in the first half of the last decade, making them more >receptive to IDNA (or other strategies that did not depend on >changes to DNS servers or resolvers). > >So suppose the community really does decide that it wants >DNS-based IDNs and that it wants to see if they can be developed >and deployed within the existing DNS rather than moving to what >some have called DNSng. It is reasonably clear that what would >be called "just send 8" in the email community would not be >acceptable if only because there are DNS uses outside the public >network that use UTF-8 directly and others that use ISO 8859-1 >or other character coding and repertoires (RFC 6055 discusses >some related issues). The proposal/thought piece I produced in >2001-2002 (with urging from some DNS-expert colleagues) to >transition to a new, i18n-sensitive, Class might be part of the >solution, but it is now clear that it would not be sufficient >(at least without considerable special-casing that would violate >both 1034/1035 and current trends). A different label type that >would permit specialized interpretations of the labels might be >an important part of the puzzle. > >Would that be a good idea? I don't know. Personally, I believe >that some of the expectations of and demand for IDNs cannot be >met in the current DNS and that we should not try to go much >further than IDNA: if more is really needed, then it should be >accomplished either in an "above DNS" solution or by designing >and deploying DNS2. But I think it would be terribly unwise to >eliminate a facility that might be useful for i18n simply >because someone tried to use it for something entirely different >and that effort did not succeed. > >Therefore: >(1) Did the WG consider i18n and other issues and possibilities >before deciding to deprecate extended label types entirely? If >so, why aren't those considerations described in the document? >We don't have a lot of codes left in the RFC 1035 space on which >other label type models might be constructed. > >(2) Is there strong justification for deprecating extended label >types, e.g., evidence that they would cause harm? > >(3) If the answer to either of both of the above questions is >"no", wouldn't it be wiser to simply deprecate the use of binary >labels, urge great caution in allocating and using other label >types, and then move on rather than eliminating the facility? > >thanks, > john From john-ietf@jck.com Fri Oct 5 11:07:34 2012 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E7721F87FB; Fri, 5 Oct 2012 11:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM+N0BMU7LgT; Fri, 5 Oct 2012 11:07:34 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id CC48A21F87F9; Fri, 5 Oct 2012 11:07:33 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TKCJ8-000IeU-Sv; Fri, 05 Oct 2012 14:07:30 -0400 Date: Fri, 05 Oct 2012 14:07:21 -0400 From: John C Klensin To: JFC Morfin , dnsext@ietf.org Message-ID: <28FF79F3EE9E12A52095F3CC@JcK-HP8200.jck.com> References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IESG , "iab@iab.org IAB" , iucg , IUTF Subject: Re: [iucg] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:07:35 -0000 Hi. Jefsey's note shows me that I should clarify why I think the topic of deprecating labels types is worth the effort to discuss. Let me suggest a little calibration about one aspect of this discussion and its possible interactions with the plans Jefsey mentions and plans others might have. --On Friday, October 05, 2012 05:50 +0200 JFC Morfin wrote: >... > Extended label types are Internet DNS features that will > certainly be retained in these specs and the current > prototyping work does include the support of Binary labels for > testing. Because extended label types have never been successfully deployed and used, it would be better to describe them as a design opportunity than as a DNS feature. More important, what everyone who has looked closely at the "extended DNS" landscape seems to agree on is that the practical deployment time for new features is almost certain to be a decade or more. Some new features, like DNAME, can be designed so that upgraded servers have a mechanism for dealing with un-upgraded clients (resolvers and recursive servers) without loss of information or functionality. Others, like DNSSEC an binary labels, cannot. Even one decade is a rather long time in Internet years. Few communities have shown a willingness to sit around and wait that long for good solutions. Kludges and poor solutions that address only part of the problem are much more attractive and much more common. However, deploying a necessarily-incompatible DNSng would almost certainly take even longer. I assume that is one of the reasons we have so much interest in (or toleration for) EDNSx and incremental extension mechanisms. If there is any plausible possibility of developing new extensions that build on label types in the future, then I think it is a bad idea to deprecate the feature, no matter how many arguments are made about alternate mechanisms or the failure of one attempt. On the other hand, if the intent is to get rid of extension models that cannot be effectively deployed and used in a few years, then any future EDNS0 extension that would require a long deployment time before becoming useful should be prohibited by the spec too. I just don't see how one can have it both ways... again, unless it can be demonstrated that the existence of the label-type capability causes harm even if unused. best, john From jefsey@jefsey.com Fri Oct 26 11:06:19 2012 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EAC21F862E for ; Fri, 26 Oct 2012 11:06:18 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char FC hex): To: ...@qualcomm.com>,\n Martin D\374rst (duerst@it.[...] X-Spam-Flag: NO X-Spam-Score: -101.105 X-Spam-Level: X-Spam-Status: No, score=-101.105 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu-uRYkmBbMY for ; Fri, 26 Oct 2012 11:06:18 -0700 (PDT) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id 86C6B21F862D for ; Fri, 26 Oct 2012 11:06:18 -0700 (PDT) Received: from lns-c10k03-v-62-35-238-138.dsl.sta.abo.bbox.fr ([62.35.238.138]:51887 helo=MORFIN-PC.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.77) (envelope-from ) id 1TRoIO-00022r-KB; Fri, 26 Oct 2012 11:06:12 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 26 Oct 2012 20:06:08 +0200 To: Larry Masinter ,Robin Berjon , "plh@w3.org" , "Anne van Kesteren (annevk@opera.com)" , "Peter Saint-Andre (stpeter@stpeter.im)" , "Pete Resnick (presnick@qualcomm.com)" , Martin Dürst (duerst@it.aoyama.ac.jp) , "ted.ietf@gmail.com" From: JFC Morfin In-Reply-To: References: <50604C1A.7090901@gmx.de> <5060677F.4010802@arcanedomain.com> <943D8C4C-426C-464A-BE0B-3607E27CBE5E@gbiv.com> <50616BF7.2070008@w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20121026180618.86C6B21F862D@ietfa.amsl.com> X-Mailman-Approved-At: Fri, 26 Oct 2012 16:26:19 -0700 Cc: "www-archive@w3.org" , iucg , IUTF Subject: Re: [iucg] URL work in HTML 5 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 18:06:19 -0000 At 21:55 13/10/2012, Larry Masinter wrote: >I know there are a lot of private conversations about this, but I'd >like to try, in the time frame of the next W3C TPAC and IETF >meetings, to work out a solution to the issue of "forking" the URL >specifications. Does everyone know what the issues are? >Is everyone willing to talk about solutions? > >I think forking is harmful and unnecessary. > >Bcc: "public-ietf-w3c@w3.org" IETF W3C Liaison > "public-webapps@w3.org" W3C Web Applications group > chartered to work on something in W3C URL releated > "www-tag@w3.org" W3C Technical Architecture Group, since > we discussed it > " public-iri@w3.org" mailing list of IETF IRI working > group, responsible for IRI spec > >Did I leave anyone out? IUCG is certainly interested discussing this from an IUser point of view. We are currently preparing a Draft on the syntax of digital names for the whole digital ecosystem (WDE) with the same ambition of not forking/keeping interoperable the URL specs. We are in the early phase of working on an Intelligent Use Digital Name Server prototype to support different namespaces, addressing plans, including DNS, IPv4 and IPv6 requests. We focus on multilinguistic naming, wiki exchanges and semantic addressing. At this stage CCN (content centered networking) with early considerations on "wiki 3.0" is the matter. jfc NB. We are still small, emerging and disseminated so our present working approach is to start from a real prototype services experimentation. We are in line with the report to the IESG on the constraints met, for example by the French language semantic with the IDNA2008 RFCs (lack of support of majuscules) and the reliability issues discussed by the AD irt. the IDNA concept. We always said we would address this through the ML-DNS fringe to fringe architecture (the emerging IUTF area). Our interest includes "common names" and IPv6 address names (as local IPv6 addresses through IPv4 access) as well.