From enum-admin@ietf.org Tue Aug 1 11:03:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03584 for ; Tue, 1 Aug 2000 11:03:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29989; Tue, 1 Aug 2000 11:02:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29962 for ; Tue, 1 Aug 2000 11:02:09 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03317 for ; Tue, 1 Aug 2000 11:02:07 -0400 (EDT) Received: from [147.73.133.93] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id IAA06067; Tue, 1 Aug 2000 08:01:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 1 Aug 2000 11:00:31 -0400 To: rshockey@ix.netcom.com, ENUM@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] draft-ietf-enum-operation-00.txt Cc: Scott Bradner , John Klensin Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I heard that this document was discussed when I was not in the room (I had to be at LDAP Replication), I got email from Scott, run over, but arrived too late. Anyway, conclusion is that I will talk with Greg about these two issues: (1) TTL issues This was discussed a lot on the mailing list, and I proposal was to explicitly differ between the need for "fast" and "slow" updated, and how each one of these can be implemented. In the case of "slow" updates, I claim that it is ok to store the URI directly in the NAPTR, while when you need "fast" updates, you should store the data somewhere else, and have a URI referencing this "other" data storage in one NAPTR. (2) Other issues You can the same way have a need for storing information for other reasons than for "speed of updates", and those can include the need for authentication of the querying party before giving back information etc. We definitely need a separate draft talking about how this secondary service which will be referenced in both case (1) above and this point. (3) Section 4.2 I wrote: >>4.2 Second Level: Determining the service registrar and retrieving >>Resource records. >> >> The second level uses MX or SRV RRs to discover the NAPTR RRs to >> discover the URL for other service- identity of the appropriate >> service-specific directory such as an LDAP directory server, H.323 >> gatekeeper, or specific endpoint addresses. >> > >You do not use MX and SRV RRs to discover NAPTR RRs. I.e. section 4.2 doesn't explain how you really are using DNS or whatever to find the actual information you look for. The paragraph above is wrong. The only way I could understand (it might have been too early in the morning, but anyway) this part was by looking at the examples, which from my point of view is not about the same things as what is described in section 4.2. I.e. 4.2 says one thing, and the examples are doing something else. (4) About the examples A meta-issue: This wg is about how to find a URI given a E.164 number. We all know that. This decision was taken just because some people like myself belive that doing E.164 -> URI -> whatever service is better than doing directly E.164 -> whatever service just because one normally always need additional information than the E.164 to be able to use the "whatever service", and that that additional information in most cases can be part of the URI scheme defined by the "whatever service". A client which want to get more information given a E.164 need to know what to do. I claim that the correct thing a client should do is to query for NAPTRs for the E.164 and that way get back URIs, which can be used for further exploration for each one of the URI schemes the client supports. Greg in this draft directly query for the SRV RR which is created by the interest in "a specific srv-service" and the domainname which is given by the E.164. This means that the wg has two different ways a client can get more information. One is to look up a URI, and a second which is (from my point of view) guessing what service might be supported and query for the SRV. You all understand what I feel about this :-) but I want advice from the wg chair on what to do. Regardless of this discussion, I would like to have some more examples and ideas in the enum operations draft which uses the mechanisms defined in draft-ietf-enum-e164-dns. Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 4 07:53:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07016 for ; Fri, 4 Aug 2000 07:53:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08583; Fri, 4 Aug 2000 07:43:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08556 for ; Fri, 4 Aug 2000 07:43:48 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04984 for ; Fri, 4 Aug 2000 07:43:46 -0400 (EDT) Received: from [10.81.77.12] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id EAA06231 for ; Fri, 4 Aug 2000 04:43:10 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: Date: Fri, 4 Aug 2000 07:39:30 -0400 To: enum@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] New version of draft-ietf-enum-164-dns Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Some individuals came back to me with grammatical changes, and the IAB requested a change in the IANA Consideration Section to reflect the way they wanted to have it. The I-D is passed to the IESG, and I hope it will be on the IESG agenda next thursday. Regards, Patrik FYI: The changes between 02 and 03 are as follows. All of them are seen as changes as requested during last call: Document is spellchecked. Grammatical fixes in section 2, to make it more clear. For example "part from" changed to "with the exception of". Example 3.2.1 corrected so "This describes that the domain tele2.se is" is replaced by "This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is". IANA considerations changed FROM: >4. IANA considerations > > IANA is to create the E164.ARPA domain in the ARPA zone, and > delegate names in the zone to parties according to the ITU > recommendation E.164. The names allocated should be hierarchically > allocated according to the description in this document, and the > codes assigned in the E.164 recommendation by ITU. > > Delegations should be done after Expert Review, and the IESG will > appoint a designated expert. > TO: >4. IANA considerations > > This memo requests that the IANA delegate the E164.ARPA domain > following instructions to be provided by the IAB. Names within this > zone are to be delegated to parties according to the ITU > recommendation E.164. The names allocated should be hierarchic in > accordance with ITU Recommendation E.164, and the codes should > assigned in accordance with that Recommendation. > > Delegations should be done after Expert Review, and the IESG will > appoint a designated expert. Addition to the security considerations: > There are a number of countries (and other numbering environments) > in which there are multiple providers of call routing and > number/name-translation services. In these areas, any system that > permits users, or putative agents for users, to change routing or > supplier information may provide incentives for changes that are > actually unauthorized (and, in some cases, for denial of legitimate > change requests). Such environments should be designed with > adequate mechanisms for identification and authentication of those > requesting changes and for authorization of those changes. Appendix A and Examples corrected to reflect correct service field and flags in the NAPTR records used in the examples. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Aug 8 10:21:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05332 for ; Tue, 8 Aug 2000 10:21:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01550; Tue, 8 Aug 2000 10:19:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01526 for ; Tue, 8 Aug 2000 10:19:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04015; Tue, 8 Aug 2000 10:19:29 -0400 (EDT) Message-Id: <200008081419.KAA04015@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 08 Aug 2000 10:19:28 -0400 Subject: [Enum] I-D ACTION:draft-ietf-enum-e164-dns-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : E.164 number and DNS Author(s) : P. Faltstrom Filename : draft-ietf-enum-e164-dns-03.txt Pages : 13 Date : 07-Aug-00 This document discusses the use of DNS for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. Routing of the actual connection using the service selected using these methods is not discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-e164-dns-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-e164-dns-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000807142407.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-e164-dns-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-e164-dns-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000807142407.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Aug 8 14:45:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22204 for ; Tue, 8 Aug 2000 14:45:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05635; Tue, 8 Aug 2000 14:45:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05614 for ; Tue, 8 Aug 2000 14:45:09 -0400 (EDT) Received: from picard.noroff.no ([212.20.204.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21734 for ; Tue, 8 Aug 2000 14:45:07 -0400 (EDT) Received: by picard.noroff.no (Postfix, from userid 815) id 9155822003; Tue, 8 Aug 2000 21:28:19 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id D99A2B3802 for ; Tue, 8 Aug 2000 21:28:17 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA29579 for ietf-123-outbound.09@ietf.org; Tue, 8 Aug 2000 14:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA26843 for ; Tue, 8 Aug 2000 10:19:31 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04015; Tue, 8 Aug 2000 10:19:29 -0400 (EDT) Message-Id: <200008081419.KAA04015@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Tue, 08 Aug 2000 10:19:28 -0400 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre2 (http://amavis.org/) Subject: [Enum] I-D ACTION:draft-ietf-enum-e164-dns-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : E.164 number and DNS Author(s) : P. Faltstrom Filename : draft-ietf-enum-e164-dns-03.txt Pages : 13 Date : 07-Aug-00 This document discusses the use of DNS for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. Routing of the actual connection using the service selected using these methods is not discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-e164-dns-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-e164-dns-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000807142407.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-e164-dns-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-e164-dns-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000807142407.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 14:47:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16037 for ; Wed, 9 Aug 2000 14:47:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27094; Wed, 9 Aug 2000 14:42:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27069 for ; Wed, 9 Aug 2000 14:42:55 -0400 (EDT) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15933 for ; Wed, 9 Aug 2000 14:42:50 -0400 (EDT) Received: by dnspri.npac.com; id NAA25477; Wed, 9 Aug 2000 13:42:52 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma025221; Wed, 9 Aug 00 13:41:57 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Wed, 9 Aug 2000 13:41:04 -0500 Message-ID: From: James Yu To: "'paf@cisco.com'" Cc: "'ENUM@ietf.org'" Date: Wed, 9 Aug 2000 13:39:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] draft-ietf-enum-e164-dns-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Patrik, A few comments: - In several places, you mentioned that "An E.164 number, without any characters but leading '+' and digits, (result of step 2 in section 2 above) is the input to the NAPTR algorithm." Since '+' has been removed from the E.164 number during the "enum process" of formulating the DNS query, it is not clear how this leading '+' in the original E.164 number has anything to do with the NAPTR algorithm during the DNS process. I noticed that you specified to use the E.164 number in the form as specified in step 2 in section 2 (i.e., '+' plus the E.164 number) as the first operand in section 3.1.2. Is there a special reason that the leading '+' must be there? It would be better to discuss how to formulate/recover the E.164 number from the DNS query (which has the format of x.x.x.x.x.x.x.e164.arpa) without referring to the enum process (that formulates the DNS query) if we are addressing the NAPTR algorithm. - Page 5, section 3.2.2, 1st paragraph, 2nd to the last line: Please clarify which procedure is restarted with this new E.164 number. Is it the enum procedure or is it the tel procedure? I guess that you are talking about the enum process. So if the tel URL contains the same E.164 number, a loop is detected and the client shall not repeat the enum process. But if the tel URL contains a different E.164 number, then the enum process will start again. Or are you implying that the enum process will not restart for any E.164 number in the tel URL? - Editorial comments: * Page 2, step 1, 2nd line: Change "countrycode IDDD" to "country code." * Page 3, section 3.1, 2nd line: Incomplete sentence. It seems that you want to refer to a reference (for details) but also show some info. from that reference below the sentence. * Page 4, last paragraph: Change "a one" to "an" at the 1st line and "step" to "steps" at the last line. * Page 5, section 3.2.3, 1st paragraph, 2nd line: Change "countrycode" to "country code." * Section 6, 1st line: Change "has" to "have." James James Yu Principal Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue, NW, Suite 550 Washington, D.C. 20005 USA +1-202-533-2814 (B) +1-202-533-2976 (Fax) +1-202-256-1200 (Mobile) james.yu@neustar.com http://www.neustar.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 16:08:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18707 for ; Wed, 9 Aug 2000 16:08:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28284; Wed, 9 Aug 2000 16:04:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28255 for ; Wed, 9 Aug 2000 16:04:51 -0400 (EDT) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18531 for ; Wed, 9 Aug 2000 16:04:48 -0400 (EDT) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 92865A1 for ; Wed, 9 Aug 2000 22:04:20 +0200 (MET DST) Received: from [144.254.46.89] (ams-vpdn-client-88.cisco.com [144.254.46.89]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA09719 for ; Wed, 9 Aug 2000 22:04:18 +0200 (MET DST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: Date: Wed, 9 Aug 2000 22:00:20 +0200 To: ENUM@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 09.00 -0500 00-08-09, James Yu wrote: >- In several places, you mentioned that "An E.164 number, without any >characters but leading '+' and digits, (result of step 2 in section 2 above) >is the input to the NAPTR algorithm." Since '+' has been removed from the >E.164 number during the "enum process" of formulating the DNS query, it is >not clear how this leading '+' in the original E.164 number has anything to >do with the NAPTR algorithm during the DNS process. I have noticed that >you specified that the E.164 number if the form as specified in step 2 in >section 2 is used as the first operand. Is there a special reason that the >leading '+' must be there? Is there is a good reason (e.g., to indicate >that it is an international number)? It would be better to discuss how to >formulate/recover the E.164 number from the DNS query plus the leading '+' >without referring to the enum process if we are addressing the NAPTR >algorithm. Yes. In a future version it _might_ be the case that we can have a similar function for a non-E.164 number. So we made the choice of keeping the '+' to signal to the regexp rewrite that we are talking about a "real" E.164 number, as you think. >- Page 5, section 3.2.2, 1st paragraph, 2nd to the last line: > Please clarify which procedure is restarted with this new E.164 number. >Is it the enum procedure or is it the tel procedure? I guess that you are >talking about the enum process. So if the tel URL contains the same E.164 >number, a loop is detected and the client will not repeat the enum process. >But if the tel URL contains a different E.164 number, then the enum process >will start again. Or are you implying that the enum process will not >restart for any E.164 number in the tel URL? No, I am talking about the "tel" resolution. Someone have to talk about how to resolv a tel: URI given that the ENUM algorithm exist. Note that this is just an example. >- Editorial comments: > * Page 2, step 1, 2nd line: > Change "countrycode IDDD" to "country code." Ok. > * Page 3, section 3.1, 2nd line: > Incomplete sentence. It seems that you want to refer to a reference (for >details) but also show some info. from that reference below the sentence. Ok. A reference is missing. > * Page 4, last paragraph: > Change "a one" to "an" at the 1st line and "step" to "steps" at the last >line. Ok. > * Page 5, section 3.2.3, 1st paragraph, 2nd line: > Change "countrycode" to "country code." Ok > * Section 6, 1st line: > Change "has" to "have." Ok. paf > >James Yu >Principal Technical Industry Liaison >NeuStar Inc. >1120 Vermont Avenue, NW, >Suite 550 >Washington, D.C. 20005 >USA >+1-202-533-2814 (B) >+1-202-533-2976 (Fax) >+1-202-256-1200 (Mobile) >james.yu@neustar.com >http://www.neustar.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 16:13:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18913 for ; Wed, 9 Aug 2000 16:13:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28460; Wed, 9 Aug 2000 16:13:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28429 for ; Wed, 9 Aug 2000 16:13:34 -0400 (EDT) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18894 for ; Wed, 9 Aug 2000 16:13:31 -0400 (EDT) Received: by dnspri.npac.com; id PAA28636; Wed, 9 Aug 2000 15:13:33 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma028398; Wed, 9 Aug 00 15:13:02 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Wed, 9 Aug 2000 15:12:09 -0500 Message-ID: From: James Yu To: "'paf@cisco.com'" Cc: "'enum@ietf.org'" Date: Wed, 9 Aug 2000 15:10:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA28430 Subject: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik, Please see the comments below. James > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Wednesday, August 09, 2000 3:10 PM > To: James Yu > Cc: 'enum' > Subject: Re: draft-ietf-enum-e164-dns-03.txt > > > At 09.00 -0500 00-08-09, James Yu wrote: > >- In several places, you mentioned that "An E.164 number, > without any > >characters but leading '+' and digits, (result of step 2 in > section 2 above) > >is the input to the NAPTR algorithm." Since '+' has been > removed from the > >E.164 number during the "enum process" of formulating the > DNS query, it is > >not clear how this leading '+' in the original E.164 number > has anything to > >do with the NAPTR algorithm during the DNS process. I > have noticed that > >you specified that the E.164 number if the form as specified > in step 2 in > >section 2 is used as the first operand. Is there a special > reason that the > >leading '+' must be there? Is there is a good reason (e.g., > to indicate > >that it is an international number)? It would be better to > discuss how to > >formulate/recover the E.164 number from the DNS query plus > the leading '+' > >without referring to the enum process if we are addressing the NAPTR > >algorithm. > > Yes. In a future version it _might_ be the case that we can have a > similar function for a non-E.164 number. So we made the choice of > keeping the '+' to signal to the regexp rewrite that we are talking > about a "real" E.164 number, as you think. Don't know whether it is a good idea to mix real E.164 numbers and non-E.164 numbers. Non-E.164 (E.164 like) number can use something like pe164. May be you are trying to use E2U for those numbers to avoid defining a new one? But see the reason below that there will be other "international" numbering plans that may use enum-like process. So it would be fine to create a new "numbering plan" name for those non-E.164 numbers. For that reason, I suggest that we don't add '+' for the NAPTR part of the process in e164.arpa/enum. There may be other numbering plans that can use enum. As indicated in the I-D on the "roam" service, cellular roaming actually requires mapping from E.212 (International Mobile Station Identification or IMSI) to URL(s) and/or from E.214 (Mobile Global Title) to URL in addition to E.164 to URL mapping. Since enum addresses E.164 only, so e212.arpa and/or e214.arpa has/have not been proposed to the enum group. But the basic enum concept/process will apply to any other numbering plans that require mapping from a number under that numbering plan to URL(s). Once enum process is stable, John Loughney, myself or someone else may start proposing e212.arpa and/or e214.arpa or some others using enum-like process. > > >- Page 5, section 3.2.2, 1st paragraph, 2nd to the last line: > > Please clarify which procedure is restarted with this new > E.164 number. > >Is it the enum procedure or is it the tel procedure? I > guess that you are > >talking about the enum process. So if the tel URL contains > the same E.164 > >number, a loop is detected and the client will not repeat > the enum process. > >But if the tel URL contains a different E.164 number, then > the enum process > >will start again. Or are you implying that the enum process will not > >restart for any E.164 number in the tel URL? > > No, I am talking about the "tel" resolution. Someone have to talk > about how to resolv a tel: URI given that the ENUM algorithm exist. > Note that this is just an example. I know the text is about the tel URL. But the phrase is not clear. Does it mean (the current text) that if tel URL is returned in the NAPTR record and the client decides to use it, the client will always (re-)start the enum process because the tel URL contains a POTS (E.164) number unless the POTS number is the same as the one used in the previous enum process (loop detected)? That's the clarification I asked in the previous message. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 16:31:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19573 for ; Wed, 9 Aug 2000 16:31:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28830; Wed, 9 Aug 2000 16:31:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28805 for ; Wed, 9 Aug 2000 16:31:09 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19532 for ; Wed, 9 Aug 2000 16:31:07 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d32.cc.telcordia.com [128.96.11.32]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e79KOQR25519; Wed, 9 Aug 2000 16:24:26 -0400 (EDT) Message-ID: <3991BDFC.36FA8D87@research.telcordia.com> Date: Wed, 09 Aug 2000 16:24:28 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: James Yu CC: "'paf@cisco.com'" , "'enum@ietf.org'" Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrick, I agree with James that the inclusion of "+" in the enum process is not necessary. An E.164 number is a sequence of digits. "+" is only used for better readability, just like "-" in between digits. I will raise another point of "tel" URL in a separate email. --Hong James Yu wrote: > Patrik, > > Please see the comments below. > > James > > > -----Original Message----- > > From: Patrik Fältström [mailto:paf@cisco.com] > > Sent: Wednesday, August 09, 2000 3:10 PM > > To: James Yu > > Cc: 'enum' > > Subject: Re: draft-ietf-enum-e164-dns-03.txt > > > > > > At 09.00 -0500 00-08-09, James Yu wrote: > > >- In several places, you mentioned that "An E.164 number, > > without any > > >characters but leading '+' and digits, (result of step 2 in > > section 2 above) > > >is the input to the NAPTR algorithm." Since '+' has been > > removed from the > > >E.164 number during the "enum process" of formulating the > > DNS query, it is > > >not clear how this leading '+' in the original E.164 number > > has anything to > > >do with the NAPTR algorithm during the DNS process. I > > have noticed that > > >you specified that the E.164 number if the form as specified > > in step 2 in > > >section 2 is used as the first operand. Is there a special > > reason that the > > >leading '+' must be there? Is there is a good reason (e.g., > > to indicate > > >that it is an international number)? It would be better to > > discuss how to > > >formulate/recover the E.164 number from the DNS query plus > > the leading '+' > > >without referring to the enum process if we are addressing the NAPTR > > >algorithm. > > > > Yes. In a future version it _might_ be the case that we can have a > > similar function for a non-E.164 number. So we made the choice of > > keeping the '+' to signal to the regexp rewrite that we are talking > > about a "real" E.164 number, as you think. > > Don't know whether it is a good idea to mix real E.164 numbers and non-E.164 > numbers. Non-E.164 (E.164 like) number can use something like pe164. May > be you are trying to use E2U for those numbers to avoid defining a new one? > But see the reason below that there will be other "international" numbering > plans that may use enum-like process. So it would be fine to create a new > "numbering plan" name for those non-E.164 numbers. For that reason, I > suggest that we don't add '+' for the NAPTR part of the process in > e164.arpa/enum. > > There may be other numbering plans that can use enum. As indicated in the > I-D on the "roam" service, cellular roaming actually requires mapping from > E.212 (International Mobile Station Identification or IMSI) to URL(s) and/or > from E.214 (Mobile Global Title) to URL in addition to E.164 to URL mapping. > Since enum addresses E.164 only, so e212.arpa and/or e214.arpa has/have not > been proposed to the enum group. But the basic enum concept/process will > apply to any other numbering plans that require mapping from a number under > that numbering plan to URL(s). Once enum process is stable, John Loughney, > myself or someone else may start proposing e212.arpa and/or e214.arpa or > some others using enum-like process. > > > > > >- Page 5, section 3.2.2, 1st paragraph, 2nd to the last line: > > > Please clarify which procedure is restarted with this new > > E.164 number. > > >Is it the enum procedure or is it the tel procedure? I > > guess that you are > > >talking about the enum process. So if the tel URL contains > > the same E.164 > > >number, a loop is detected and the client will not repeat > > the enum process. > > >But if the tel URL contains a different E.164 number, then > > the enum process > > >will start again. Or are you implying that the enum process will not > > >restart for any E.164 number in the tel URL? > > > > No, I am talking about the "tel" resolution. Someone have to talk > > about how to resolv a tel: URI given that the ENUM algorithm exist. > > Note that this is just an example. > > I know the text is about the tel URL. But the phrase is not clear. Does it > mean (the current text) that if tel URL is returned in the NAPTR record and > the client decides to use it, the client will always (re-)start the enum > process because the tel URL contains a POTS (E.164) number unless the POTS > number is the same as the one used in the previous enum process (loop > detected)? That's the clarification I asked in the previous message. > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 16:36:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19710 for ; Wed, 9 Aug 2000 16:36:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28932; Wed, 9 Aug 2000 16:35:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28900 for ; Wed, 9 Aug 2000 16:35:33 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19691 for ; Wed, 9 Aug 2000 16:35:31 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d32.cc.telcordia.com [128.96.11.32]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e79KUUR26070; Wed, 9 Aug 2000 16:30:31 -0400 (EDT) Message-ID: <3991BF68.D03A4BB2@research.telcordia.com> Date: Wed, 09 Aug 2000 16:30:32 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: James Yu CC: "'paf@cisco.com'" , "'enum@ietf.org'" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] "tel:" URL for ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Patrick, I would like to raise a point about the usage of "tel:" URL in the context of ENUM. In RFC2806, "tel:" URL also includes local numbers, plus other constructs such as ISDN subaddress, post-dial digits, etc. Do you think it would be better to include a sentence or two in your draft to restrict the usage of "tel:" URL to only E.164 numbers in the NAPTR RRs? --Hong _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 16:48:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19944 for ; Wed, 9 Aug 2000 16:48:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29175; Wed, 9 Aug 2000 16:48:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29146 for ; Wed, 9 Aug 2000 16:48:35 -0400 (EDT) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19941 for ; Wed, 9 Aug 2000 16:48:34 -0400 (EDT) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id D7799A1; Wed, 9 Aug 2000 22:48:04 +0200 (MET DST) Received: from [144.254.46.89] (ams-vpdn-client-88.cisco.com [144.254.46.89]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA14418; Wed, 9 Aug 2000 22:48:00 +0200 (MET DST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 9 Aug 2000 22:44:35 +0200 To: James Yu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] RE: draft-ietf-enum-e164-dns-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 15.07 -0500 00-08-09, James Yu wrote: > > Yes. In a future version it _might_ be the case that we can have a >> similar function for a non-E.164 number. So we made the choice of >> keeping the '+' to signal to the regexp rewrite that we are talking >> about a "real" E.164 number, as you think. > >Don't know whether it is a good idea to mix real E.164 numbers and non-E.164 >numbers. Non-E.164 (E.164 like) number can use something like pe164. May >be you are trying to use E2U for those numbers to avoid defining a new one? >But see the reason below that there will be other "international" numbering >plans that may use enum-like process. So it would be fine to create a new >"numbering plan" name for those non-E.164 numbers. For that reason, I >suggest that we don't add '+' for the NAPTR part of the process in >e164.arpa/enum. What I was thinking of was something which in the NAPTR recursive process was some way for the rewrite of the telephone number might rewrite a non-e164 number (without leading '+') into one which is a E.164 number (and vice versa). I.e. I felt together with Ericsson people (and others) that it is important that you when defining the rewrite rule in the regular expression can write one which matches (or not) on only E.164 numbers or not. I have no ide whether this will be used or not, but people have adviced me all along to keep the '+' if possible. Phone people that is. >There may be other numbering plans that can use enum. As indicated in the >I-D on the "roam" service, cellular roaming actually requires mapping from >E.212 (International Mobile Station Identification or IMSI) to URL(s) and/or >from E.214 (Mobile Global Title) to URL in addition to E.164 to URL mapping. A similar service can also use NAPTR in a similar way. I would not say "enum"... >Since enum addresses E.164 only, so e212.arpa and/or e214.arpa has/have not >been proposed to the enum group. But the basic enum concept/process will >apply to any other numbering plans that require mapping from a number under >that numbering plan to URL(s). Yes. I understand. >Once enum process is stable, John Loughney, >myself or someone else may start proposing e212.arpa and/or e214.arpa or >some others using enum-like process. Ok. > > No, I am talking about the "tel" resolution. Someone have to talk >> about how to resolv a tel: URI given that the ENUM algorithm exist. >> Note that this is just an example. > >I know the text is about the tel URL. But the phrase is not clear. Does it >mean (the current text) that if tel URL is returned in the NAPTR record and >the client decides to use it, the client will always (re-)start the enum >process because the tel URL contains a POTS (E.164) number unless the POTS >number is the same as the one used in the previous enum process (loop >detected)? That's the clarification I asked in the previous message. It is intended to be unclear as noone have written/updated the tel: URI spec to define what path to take. Both are possible. I made the choice to NOT write about this in this spec. The tel: URI spec needs to be updated. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 16:55:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20060 for ; Wed, 9 Aug 2000 16:55:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29290; Wed, 9 Aug 2000 16:55:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29261 for ; Wed, 9 Aug 2000 16:55:37 -0400 (EDT) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20055 for ; Wed, 9 Aug 2000 16:55:36 -0400 (EDT) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id CDBA7A7; Wed, 9 Aug 2000 22:55:06 +0200 (MET DST) Received: from [144.254.46.89] (ams-vpdn-client-88.cisco.com [144.254.46.89]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA15420; Wed, 9 Aug 2000 22:55:02 +0200 (MET DST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <3991BDFC.36FA8D87@research.telcordia.com> References: <3991BDFC.36FA8D87@research.telcordia.com> Date: Wed, 9 Aug 2000 22:50:48 +0200 To: Hong Liu , James Yu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Cc: "'enum@ietf.org'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 16.24 -0400 00-08-09, Hong Liu wrote: >I agree with James that the inclusion of "+" in the enum process is not >necessary. An E.164 number is a sequence of digits. "+" is only used >for better >readability, just like "-" in between digits. "Other" people working with telephone numbers has told me that they want the '+' there to be able to distinguish between a number which is "converted" into a full E.164 number from a local one (in a closed numbering plan or such) and not. For me, being able to know the difference seems to be "a good thing". And you have to have VERY strong arguments for _NOT_ have the '+' there, and not only "it is not needed". >I will raise another point of "tel" URL in a separate email. Ok. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 16:55:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20072 for ; Wed, 9 Aug 2000 16:55:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29326; Wed, 9 Aug 2000 16:55:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29303 for ; Wed, 9 Aug 2000 16:55:43 -0400 (EDT) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20057 for ; Wed, 9 Aug 2000 16:55:42 -0400 (EDT) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 11E6FE7; Wed, 9 Aug 2000 22:55:13 +0200 (MET DST) Received: from [144.254.46.89] (ams-vpdn-client-88.cisco.com [144.254.46.89]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA15426; Wed, 9 Aug 2000 22:55:08 +0200 (MET DST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <3991BF68.D03A4BB2@research.telcordia.com> References: <3991BF68.D03A4BB2@research.telcordia.com> Date: Wed, 9 Aug 2000 22:51:38 +0200 To: Hong Liu , James Yu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: "'enum@ietf.org'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: "tel:" URL for ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 16.30 -0400 00-08-09, Hong Liu wrote: >I would like to raise a point about the usage of "tel:" URL in the context of >ENUM. In RFC2806, "tel:" URL also includes local numbers, plus other >constructs >such as ISDN subaddress, post-dial digits, etc. Do you think it >would be better >to include a sentence or two in your draft to restrict the usage of "tel:" URL >to only E.164 numbers in the NAPTR RRs? No. The use of tel: URI in the draft is non-normative as it is in an example. I think RFC 2806 should be updated to make things more clear. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 16:56:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20097 for ; Wed, 9 Aug 2000 16:56:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29398; Wed, 9 Aug 2000 16:56:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29367 for ; Wed, 9 Aug 2000 16:56:27 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20089 for ; Wed, 9 Aug 2000 16:56:20 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d32.cc.telcordia.com [128.96.11.32]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e79KtiR27201; Wed, 9 Aug 2000 16:55:44 -0400 (EDT) Message-ID: <3991C552.7B0DAAE2@research.telcordia.com> Date: Wed, 09 Aug 2000 16:55:46 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: "'paf@cisco.com'" CC: "'enum@ietf.org'" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] draft-ietf-enum-e164-dns-03.txt: protocol and services Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Patrick, I notice that in Example 1 of the new draft, the protocol of the NAPTR RR for email was changed from "smtp+E2U" to "mailto+E2U". I am wondering why it was changed that way. According to the definition of NAPTR, the service field is "protocol+rs". I am not sure if "mailto" can be regarded as a protocol, unless my understanding of "protocol" is wrong. In a corridor discussion with Greg and Richard in Pittsburgh after the ENUM session, we realized that the interplay between a protocol and a service is more complicated than it seems. Basically, a protocol may enable more than one service. For example, SMTP can be used for email, voice messaging and Internet fax. Similarly, SIP can be used for VoIP calls and IM. The question is how we can encode both the protocol and the service information, given the current definition of NAPTR. It is obvious that some of the URL schemes used in ENUM are not sufficient to convey the service intended. Is there any way out of this? --Hong _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 17:34:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21206 for ; Wed, 9 Aug 2000 17:34:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00211; Wed, 9 Aug 2000 17:33:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00178 for ; Wed, 9 Aug 2000 17:33:40 -0400 (EDT) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21202 for ; Wed, 9 Aug 2000 17:33:38 -0400 (EDT) Received: by dnspri.npac.com; id QAA23255; Wed, 9 Aug 2000 16:33:38 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma023234; Wed, 9 Aug 00 16:33:19 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Wed, 9 Aug 2000 16:32:26 -0500 Message-ID: From: James Yu To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Cc: enum@ietf.org Date: Wed, 9 Aug 2000 16:30:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] RE: draft-ietf-enum-e164-dns-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > >Don't know whether it is a good idea to mix real E.164 > numbers and non-E.164 > >numbers. Non-E.164 (E.164 like) number can use something > like pe164. May > >be you are trying to use E2U for those numbers to avoid > defining a new one? > >But see the reason below that there will be other > "international" numbering > >plans that may use enum-like process. So it would be fine > to create a new > >"numbering plan" name for those non-E.164 numbers. For that > reason, I > >suggest that we don't add '+' for the NAPTR part of the process in > >e164.arpa/enum. > > What I was thinking of was something which in the NAPTR recursive > process was some way for the rewrite of the telephone number might > rewrite a non-e164 number (without leading '+') into one which is a > E.164 number (and vice versa). > > I.e. I felt together with Ericsson people (and others) that it is > important that you when defining the rewrite rule in the regular > expression can write one which matches (or not) on only E.164 numbers > or not. > > I have no ide whether this will be used or not, but people have > adviced me all along to keep the '+' if possible. Phone people that > is. I'm still not clear about this. The '+' is not part of the enum DNS query (only x.x.x.x.x.x.e164.arpa instead of x.x.x.x.x.x.+.e164.arpa). So for the NAPTR algorithm to use the E.164 number, it has to retrieve the E.164 number in the DNS query (e.g., get everything before .e164.arpa, remove all the dots and reverse the order of the digit to recover the original E.164 number). If '+' is needed, then '+' is added to the front of the E.164 number. I assume that the client is not asked to remember the output of step 2 in section 2. The rewrite rule will be applied to the string in the DNS query and that string does not have '+' in it. That is why I'm not clear about the '+' discussed in your I-D. Also, a client may send a DNS query to a local DNS server for resolution. Does the local DNS server continue the DNS resolution process when it receives NAPTR records (may be it depends on the type of NAPTR RRs returned)? I guess that if the NAPTR is for a SRV record, the local DNS server will go to the NS specified by the "target" to retrieve SRV RR(s). So the client performs the six steps described in section 2 but it is the local DNS server that performs the DNS resolution. The local DNS server then is required to add the '+' to the E.164 number using the rewrite rule if it needs to continue the DNS resolution process. But only the client knows that the DNS process is related to enum. The local DNS server only performs routine DNS process (including NAPTR) and may not know that the DNS query is about enum. Is it correct? James _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 17:39:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21422 for ; Wed, 9 Aug 2000 17:39:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00315; Wed, 9 Aug 2000 17:36:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00283 for ; Wed, 9 Aug 2000 17:36:14 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21281 for ; Wed, 9 Aug 2000 17:36:11 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d32.cc.telcordia.com [128.96.11.32]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e79LZQR29018; Wed, 9 Aug 2000 17:35:27 -0400 (EDT) Message-ID: <3991CEA0.D90512F6@research.telcordia.com> Date: Wed, 09 Aug 2000 17:35:28 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: James Yu , "'enum@ietf.org'" Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt References: <3991BDFC.36FA8D87@research.telcordia.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik, Please see my comments in between lines. --Hong Patrik Fältström wrote: > At 16.24 -0400 00-08-09, Hong Liu wrote: > >I agree with James that the inclusion of "+" in the enum process is not > >necessary. An E.164 number is a sequence of digits. "+" is only used > >for better > >readability, just like "-" in between digits. > > "Other" people working with telephone numbers has told me that they > want the '+' there to be able to distinguish between a number which > is "converted" into a full E.164 number from a local one (in a closed > numbering plan or such) and not. > I would like to hear what the "other" people say about this. It may help to have an example to show why it is needed. As far as I understand, ENUM is about mapping an E.164 number to a set of URIs. The input to ENUM is an E.164 number. I don't know why and where non-E.164 numbers come into play here. > > For me, being able to know the difference seems to be "a good thing". > And you have to have VERY strong arguments for _NOT_ have the '+' > there, and not only "it is not needed". > The problem here is that I don't see any VERY strong arguments for having the "+" there either. I remain to be convinced. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 17:39:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21452 for ; Wed, 9 Aug 2000 17:39:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00440; Wed, 9 Aug 2000 17:39:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00359 for ; Wed, 9 Aug 2000 17:39:21 -0400 (EDT) Received: from cqmx.corp.comsat.com (cqmx.corp.comsat.com [134.133.184.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21434 for ; Wed, 9 Aug 2000 17:39:19 -0400 (EDT) From: Andrew.Gallant@comsat.com Received: from cqgate5.cmc.comsat.com ([134.133.162.20]) by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 9 Aug 2000 17:38:42 -0400 Received: from ccMail by cqgate5.cmc.comsat.com (IMA Internet Exchange 3.13) id 000EFA61; Wed, 9 Aug 2000 17:42:02 -0400 Mime-Version: 1.0 Date: Wed, 9 Aug 2000 17:35:18 -0400 Message-ID: <000EFA61.C22277@comsat.com> To: James Yu , Hong Liu Cc: "'paf@cisco.com'" , "'enum@ietf.org'" Subject: Re[2]: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Content-Type: multipart/mixed; boundary="IMA.Boundary.2237585690" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This is a Mime message, which your current mail reader may not understand. Parts of the message will appear as text. To process the remainder, you will need to use a Mime compatible mail reader. Contact your vendor for details. --IMA.Boundary.2237585690 Content-Type: text/plain; charset="US-ASCII" Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit Sorry, all. I haven't looked at "+" in the enum process, but I don't agree that "+" is only for readability. What's the context (public international or not)? What's the usage (such as whether you've got a number as opposed to a dialing string)? Here are two ITU-T data points, plus (oops!) a personal experience that shows what can go wrong. 1. From E.164 (5/97): In accordance with Recommendation E.123, the symbol "+" is recommended to indicate that an international prefix is required. [Many but not all countries use 00 as an international prefix.] 2. From E.123 (1988 Blue Book - now being revised): ... A procedural symbol is a symbol which tells the user how to dial. ... The international prefix symbol should be + (plus) and should precede the country code in the international number. It serves to remind the subscriber to dial the international prefix which differs from country to country and also SERVES TO IDENTIFY THE NUMBER FOLLOWING AS THE INTERNATIONAL TELEPHONE NUMBER. [emphasis added - didn't really mean to shout] 3. Ye personal experience. Several numbering plan changes ago, a colleague from the UK left a message with his home number. I tried to call him back and failed. I tried everything, but nothing worked. Next day I called his office. He apologized. Here's what happened. The message I got had a number beginning with 44. I assumed it was the UK country code. Wrong! He lived so far outside London that his UK number at the time began with 44. When I finally tried + 44 44 ... I finally got through. -Andy =========(note: email address change)========= Andrew Gallant (andrew.gallant@lmco.com); LMGT Lockheed Martin Global Telecommunications, Inc. 6560 Rock Spring Drive; Bethesda, MD 20817 USA Tel: +1 301 214 3264; Fax: +1 301 214 7226 --IMA.Boundary.2237585690 Content-Type: text/plain; charset="US-ASCII"; name="RFC822 message headers" Content-Description: cc:Mail note part Content-Disposition: inline; filename="RFC822 message headers" Content-Transfer-Encoding: 7bit Received: from ro.ctd.comsat.com ([134.133.40.45]) by cqgate5.cmc.comsat.com with SMTP (IMA Internet Exchange 3.13) id 000EF80C; Wed, 9 Aug 2000 16:36:16 -0400 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ro.ctd.comsat.com with smtp (Exim 2.12 #8) id 13McVY-0000MZ-00 for andrew.gallant@comsat.com; Wed, 9 Aug 2000 16:31:24 -0400 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28836; Wed, 9 Aug 2000 16:31:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28805 for ; Wed, 9 Aug 2000 16:31:09 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19532 for ; Wed, 9 Aug 2000 16:31:07 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d32.cc.telcordia.com [128.96.11.32]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e79KOQR25519; Wed, 9 Aug 2000 16:24:26 -0400 (EDT) Message-ID: <3991BDFC.36FA8D87@research.telcordia.com> Date: Wed, 09 Aug 2000 16:24:28 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: James Yu CC: "'paf@cisco.com'" , "'enum@ietf.org'" Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt References: Content-Type: text/plain; charset=iso-8859-1 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id QAA28836 --IMA.Boundary.2237585690-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 18:10:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22015 for ; Wed, 9 Aug 2000 18:10:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00967; Wed, 9 Aug 2000 18:07:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00937 for ; Wed, 9 Aug 2000 18:07:01 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21984 for ; Wed, 9 Aug 2000 18:06:59 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d32.cc.telcordia.com [128.96.11.32]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e79M6OR00050; Wed, 9 Aug 2000 18:06:24 -0400 (EDT) Message-ID: <3991D5E2.572360D8@research.telcordia.com> Date: Wed, 09 Aug 2000 18:06:26 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: Andrew.Gallant@comsat.com CC: James Yu , "'paf@cisco.com'" , "'enum@ietf.org'" Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt References: <000EFA61.C22277@comsat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Andy, Thanks for the clarification. I agree with you that from a user perspective, "+" means more than just for readability. The problem we are discussing here is whether "+" is needed for ENUM process given the fact that the input is a canonical E.164 number already. I would like to hear from you and others. Thanks! --Hong Andrew.Gallant@comsat.com wrote: > Sorry, all. I haven't looked at "+" in the enum process, but I don't > agree that "+" is only for readability. What's the context (public > international or not)? What's the usage (such as whether you've got a > number as opposed to a dialing string)? > > Here are two ITU-T data points, plus (oops!) a personal experience > that shows what can go wrong. > > 1. From E.164 (5/97): > > In accordance with Recommendation E.123, the symbol "+" is recommended > to indicate that an international prefix is required. > > [Many but not all countries use 00 as an international prefix.] > > 2. From E.123 (1988 Blue Book - now being revised): > > ... A procedural symbol is a symbol which tells the user how to dial. > > ... The international prefix symbol should be + (plus) and should > precede the country code in the international number. It serves to > remind the subscriber to dial the international prefix which differs > from country to country and also SERVES TO IDENTIFY THE NUMBER > FOLLOWING AS THE INTERNATIONAL TELEPHONE NUMBER. > > [emphasis added - didn't really mean to shout] > > 3. Ye personal experience. > > Several numbering plan changes ago, a colleague from the UK left a > message with his home number. I tried to call him back and failed. I > tried everything, but nothing worked. Next day I called his office. > He apologized. > > Here's what happened. The message I got had a number beginning with > 44. I assumed it was the UK country code. Wrong! He lived so far > outside London that his UK number at the time began with 44. When I > finally tried + 44 44 ... I finally got through. > > -Andy _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 18:20:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22091 for ; Wed, 9 Aug 2000 18:20:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01199; Wed, 9 Aug 2000 18:20:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01167 for ; Wed, 9 Aug 2000 18:20:04 -0400 (EDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22077 for ; Wed, 9 Aug 2000 18:20:00 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id SAA28959; Wed, 9 Aug 2000 18:09:42 -0400 (EDT) Date: Wed, 9 Aug 2000 18:09:42 -0400 From: Michael Mealling To: James Yu Cc: "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , enum@ietf.org Subject: Re: [Enum] RE: draft-ietf-enum-e164-dns-03.txt Message-ID: <20000809180942.K28321@bailey.dscga.com> Reply-To: michaelm@netsol.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: ; from james.yu@neustar.com on Wed, Aug 09, 2000 at 04:30:56PM -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Wed, Aug 09, 2000 at 04:30:56PM -0500, James Yu wrote: > > >Don't know whether it is a good idea to mix real E.164 > > numbers and non-E.164 > > >numbers. Non-E.164 (E.164 like) number can use something > > like pe164. May > > >be you are trying to use E2U for those numbers to avoid > > defining a new one? > > >But see the reason below that there will be other > > "international" numbering > > >plans that may use enum-like process. So it would be fine > > to create a new > > >"numbering plan" name for those non-E.164 numbers. For that > > reason, I > > >suggest that we don't add '+' for the NAPTR part of the process in > > >e164.arpa/enum. > > > > What I was thinking of was something which in the NAPTR recursive > > process was some way for the rewrite of the telephone number might > > rewrite a non-e164 number (without leading '+') into one which is a > > E.164 number (and vice versa). > > > > I.e. I felt together with Ericsson people (and others) that it is > > important that you when defining the rewrite rule in the regular > > expression can write one which matches (or not) on only E.164 numbers > > or not. > > > > I have no ide whether this will be used or not, but people have > > adviced me all along to keep the '+' if possible. Phone people that > > is. > > I'm still not clear about this. The '+' is not part of the enum DNS query > (only x.x.x.x.x.x.e164.arpa instead of x.x.x.x.x.x.+.e164.arpa). So for > the NAPTR algorithm to use the E.164 number, it has to retrieve the E.164 > number in the DNS query (e.g., get everything before .e164.arpa, remove all > the dots and reverse the order of the digit to recover the original E.164 > number). If '+' is needed, then '+' is added to the front of the E.164 > number. I assume that the client is not asked to remember the output of > step 2 in section 2. The rewrite rule will be applied to the string in the > DNS query and that string does not have '+' in it. That is why I'm not > clear about the '+' discussed in your I-D. Actually Patrik's draft is clear that the input to the NAPTR rewrite rule is the original e.164 number without the dashes and not the actual domain-name. The NAPTR docs are very clear that you can never use a Key as an input to a rewrite rule and that once you've started doing the NAPTR rewrite algorithm that you cannot change what string its acting on.... See Section 3.1.1 of http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-03.txt Specification for use of NAPTR Resource Records The input is an E.164 encoded telephone number. The output is a Uniform Resource Identifier in its absolute form according to the 'absoluteURI' production in the Collected ABNF found in RFC2396[5] An E.164 number, without any characters but leading '+' and digits, (result of step 2 in section 2 above) is the input to the NAPTR algorithm. I think you might be confusing the e.164 phone number (the Application Unique String) with the database Key which is the number without any characters at all and the DNS DDDS Database key format which is what has to be a valid domain-name.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 9 22:00:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25504 for ; Wed, 9 Aug 2000 22:00:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04020; Wed, 9 Aug 2000 22:00:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03981 for ; Wed, 9 Aug 2000 22:00:10 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25495 for ; Wed, 9 Aug 2000 22:00:07 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d32.cc.telcordia.com [128.96.11.32] (may be forged)) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7A1xaR06973; Wed, 9 Aug 2000 21:59:37 -0400 (EDT) Message-ID: <39920C89.ADEAFF44@research.telcordia.com> Date: Wed, 09 Aug 2000 21:59:38 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: michaelm@netsol.com CC: enum@ietf.org Subject: Re: [Enum] RE: draft-ietf-enum-e164-dns-03.txt References: <20000809180942.K28321@bailey.dscga.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Hi, Michael, I am glad that you join the discussion here. I have some questions regarding the NAPTR algorithm in the context of ENUM. I would appreciate that you could clarify them for me: (1) In draft-ietf-urn-naptr-rr-04.txt Section 4, the basic NAPTR algorithm is presented. It says that "the algorithm starts with a string and some known key..." So does it mean that the input to the NAPTR algorithm contains two parameters, one for the string, another for the known key? In the context of ENUM, do you mean that the string is an E.164 number, without any characters but leading '+' and digits, say +4689761234, while the key is the domain name derived from the string, say 4.3.2.1.6.7.9.8.6.4.e164.arpa? If that is the case, then the input to the NAPTR algorithm is both +4689761234 and 4.3.2.1.6.7.9.8.6.4.e164.arpa . In other words, one needs to change the wording in Section 3 of draft-ietf-enum-e164-dns-03.txt regarding the input to the NAPTR algorithm. (2) In dratf-ietf-urn-ddds-00.txt, a more generic algorithm is presented in Section 3.3. The description of this algorithm is somewhat different from the one above. In this case, the DDDS algorithm seems to imply that there is only one input, i.e., the Application Unique String. The first step of the algorithm is to apply the First Well Known Rule to the Application Unique String to produce a Key. To map ENUM into the DDDS context, I have the following correspondence: Application Unique String: an E.164 number without any characters but leading '+' and digits, say +4689761234. This is the input to DDDS algorithm. First Well Known Rule: Step 3 to 6 in Section 2 of draft-ietf-enum-e164-dns-03.txt. (Initial) Key: the domain name derived from the string, say 4.3.2.1.6.7.9.8.6.4.e164.arpa Any subsequent substitutions shall be applied to the Application Unique String, i.e. +4689761234. Personally, I would like to see the ENUM protocol in draft-ietf-enum-e164-dns-03.txt modeled after the DDDS framework than the transient NAPTR draft, just like what you did with URI/URN resolution in draft-ietf-urn-uri-res-ddds-00.txt. It seems to me by reading your draft-ietf-urn-dns-ddds-database-00.txt, the NAPTR algorithm is a special case of the DDDS algorithm where the database is DNS and the RR is NAPTR, and ENUM is just another application using DDDS with DNS and NAPTR. I am not sure how much more work needs to be put into rewriting draft-ietf-enum-e164-dns-03.txt to do that. (3) In the case of ENUM, which document we should use as reference to NAPTR, draft-ietf-urn-naptr-rr-04.txt or dratf-ietf-urn-ddds-00.txt plus draft-ietf-urn-dns-ddds-database-00.txt? It does not seem to me that the two are totally consistent. I personally like the latter better. (4) In DDDS/NAPTR algorithm, does it apply to only the first matched NATPR RR satisfying the services for the application or all NATPR RRs satisfying the services? The reason I ask this question is that in ENUM, an application may like to check all the NAPTR RRs before deciding on which one to use, say SIP call is preferred by the callee but the caller can only send email. Here suppose both have the same service E2U. (5) In the NAPTR definition, it seems that the flag field dictates what can be put in the regexp and replacement field. For example, the "U" flag requires that the regexp field cannot be empty while the replacement field should be empty; the "A" and "S" flags requires that the regexp field be empty while the replacement field cannot. Is this the right interpretation? How about the "P" flag and the empty flag? What is the implication of each on the regexp and replacement fields? (6) Since ENUM only returns URIs, does it mean that only the "U" flag and the empty flag can be used in the NAPTR RRs for ENUM? In other words, are "A", "P" and "S" f;lags not allowed for ENUM NAPTR RRs? Thanks again for the help! Best regards, --Hong Michael Mealling wrote: > Actually Patrik's draft is clear that the input to the NAPTR rewrite > rule is the original e.164 number without the dashes and not the > actual domain-name. The NAPTR docs are very clear that you can never > use a Key as an input to a rewrite rule and that once you've started > doing the NAPTR rewrite algorithm that you cannot change what string > its acting on.... > > See Section 3.1.1 of > http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-03.txt > > Specification for use of NAPTR Resource Records > > The input is an E.164 encoded telephone number. The output is a > Uniform Resource Identifier in its absolute form according to the > 'absoluteURI' production in the Collected ABNF found in RFC2396[5] > > An E.164 number, without any characters but leading '+' and digits, > (result of step 2 in section 2 above) is the input to the NAPTR > algorithm. > > I think you might be confusing the e.164 phone number (the Application > Unique String) with the database Key which is the number without > any characters at all and the DNS DDDS Database key format which is > what has to be a valid domain-name.... > > -MM > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 01:50:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05182 for ; Thu, 10 Aug 2000 01:50:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11589; Thu, 10 Aug 2000 01:49:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11534 for ; Thu, 10 Aug 2000 01:49:46 -0400 (EDT) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05170 for ; Thu, 10 Aug 2000 01:49:45 -0400 (EDT) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id E7718A7; Thu, 10 Aug 2000 07:49:14 +0200 (MET DST) Received: from [144.254.46.89] (ams-vpdn-client-88.cisco.com [144.254.46.89]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id HAA28856; Thu, 10 Aug 2000 07:49:12 +0200 (MET DST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: References: Date: Thu, 10 Aug 2000 07:29:12 +0200 To: James Yu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] RE: draft-ietf-enum-e164-dns-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 16.30 -0500 00-08-09, James Yu wrote: >I'm still not clear about this. The '+' is not part of the enum DNS query >(only x.x.x.x.x.x.e164.arpa instead of x.x.x.x.x.x.+.e164.arpa). So for >the NAPTR algorithm to use the E.164 number, it has to retrieve the E.164 >number in the DNS query (e.g., get everything before .e164.arpa, remove all >the dots and reverse the order of the digit to recover the original E.164 >number). If '+' is needed, then '+' is added to the front of the E.164 >number. I assume that the client is not asked to remember the output of >step 2 in section 2. The rewrite rule will be applied to the string in the >DNS query and that string does not have '+' in it. That is why I'm not >clear about the '+' discussed in your I-D. No, the steps that have to be taken is _exactly_ what is written in the spec: (1) Take the E.164 number (2) Remove all characters part from leading '+' and digits (3) Remove the '+' (4) Reverse the order of digits (5) Add '.' between digits (6) Add ".e164.arpa." at the end (7) Look up NAPTR in DNS (8) If NAPTR is non-terminal apply rewrite rule to output of (2) and query for new NAPTRs again which you apply output of (2) to That is what you _have_ to do. >Also, a client may send a DNS query to a local DNS server for resolution. Of course. >Does the local DNS server continue the DNS resolution process when it >receives NAPTR records (may be it depends on the type of NAPTR RRs >returned)? I don't understand. Do you ask whether the local resolving DNS server is doing the NAPTR resolution? The answer to that question is "no". The client have to do that as the client is the one which know what the input to the NAPTR algorithm is for E2U. You can not when using NAPTR take for granted that what the regexp is applied to can be extracted from the domainname. >I guess that if the NAPTR is for a SRV record, the local DNS >server will go to the NS specified by the "target" to retrieve SRV RR(s). I don't see how SRVs can be included in the ENUM mechanism... >So the client performs the six steps described in section 2 but it is the >local DNS server that performs the DNS resolution. The local DNS server >then is required to add the '+' to the E.164 number using the rewrite rule >if it needs to continue the DNS resolution process. But only the client >knows that the DNS process is related to enum. The local DNS server only >performs routine DNS process (including NAPTR) and may not know that the DNS >query is about enum. Is it correct? The DNS part of this is only querying for DNS RRs, and does not do anything else regarding NAPTR rewrites. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 01:50:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05193 for ; Thu, 10 Aug 2000 01:50:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11630; Thu, 10 Aug 2000 01:49:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11603 for ; Thu, 10 Aug 2000 01:49:54 -0400 (EDT) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05172 for ; Thu, 10 Aug 2000 01:49:53 -0400 (EDT) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id C15D0E4; Thu, 10 Aug 2000 07:49:22 +0200 (MET DST) Received: from [144.254.46.89] (ams-vpdn-client-88.cisco.com [144.254.46.89]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id HAA28861; Thu, 10 Aug 2000 07:49:17 +0200 (MET DST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <3991D5E2.572360D8@research.telcordia.com> References: <000EFA61.C22277@comsat.com> <3991D5E2.572360D8@research.telcordia.com> Date: Thu, 10 Aug 2000 07:35:38 +0200 To: Hong Liu , Andrew.Gallant@comsat.com From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Cc: James Yu , "'enum@ietf.org'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 18.06 -0400 00-08-09, Hong Liu wrote: >The problem we are discussing here is whether "+" is needed for ENUM >process given the >fact that the input is a canonical E.164 number already. I would >like to hear from you >and others. Thanks! I say it once again, and only one more time. If you try to write regular expressions which is to work on both E.164 numbers and non-E.164 numbers (see example from email from Andrew) it is extremely nice to have the '+' which indicates what kind of number we are talking about. ITU specifications explicitly talks about the '+'. See more text from Andrews document. In the case that one is using a closed numbering plan and is in the future going to mix E.164 numbers and his closed numbering plan together, and apply a modified version of ENUM, it is nice to have the '+'. Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 01:50:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05204 for ; Thu, 10 Aug 2000 01:50:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11565; Thu, 10 Aug 2000 01:49:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11518 for ; Thu, 10 Aug 2000 01:49:41 -0400 (EDT) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05168 for ; Thu, 10 Aug 2000 01:49:40 -0400 (EDT) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 32501A2; Thu, 10 Aug 2000 07:49:10 +0200 (MET DST) Received: from [144.254.46.89] (ams-vpdn-client-88.cisco.com [144.254.46.89]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id HAA28851; Thu, 10 Aug 2000 07:49:02 +0200 (MET DST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <3991C552.7B0DAAE2@research.telcordia.com> References: <3991C552.7B0DAAE2@research.telcordia.com> Date: Thu, 10 Aug 2000 07:21:23 +0200 To: Hong Liu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: "'enum@ietf.org'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: draft-ietf-enum-e164-dns-03.txt: protocol and services Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 16.55 -0400 00-08-09, Hong Liu wrote: >I notice that in Example 1 of the new draft, the protocol of the NAPTR RR for >email was changed from "smtp+E2U" to "mailto+E2U". I am wondering why it was >changed that way. Because people wanted: - The protocol specification should tell what protocol is in use. It should be possible to register "arbitrary such things" in the future, where more than one might use the same URI scheme. - URI schemes themselves can be used as protocols. So, having a name as protocol in one example which is different from the URI scheme was very confusing. >According to the definition of NAPTR, the service field is "protocol+rs". I am >not sure if "mailto" can be regarded as a protocol, unless my understanding of >"protocol" is wrong. protocol can be whatever. It's just a textual string. >For example, SMTP can be used for email, voice messaging and Internet >fax. Exactly. >Similarly, SIP can be used for VoIP calls and IM. The question is how we >can encode both the protocol and the service information, given the current >definition of NAPTR. It is obvious that some of the URL schemes used >in ENUM are >not sufficient to convey the service intended. Is there any way out of this? By writing a new RFC which defines new protocols in the E2U "rs" in the NAPTR in ENUM which talks about "sending a fax via email, i.e. sending fax using a mailto URI", "sending a voicemail via email, i.e. sending voicemail using a mailto URI" etc. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 07:53:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16576 for ; Thu, 10 Aug 2000 07:53:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16760; Thu, 10 Aug 2000 07:51:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16735 for ; Thu, 10 Aug 2000 07:51:49 -0400 (EDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16496 for ; Thu, 10 Aug 2000 07:51:49 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id HAA01012; Thu, 10 Aug 2000 07:41:34 -0400 (EDT) Date: Thu, 10 Aug 2000 07:41:34 -0400 From: Michael Mealling To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Hong Liu , "'enum@ietf.org'" Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt: protocol and services Message-ID: <20000810074134.B963@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <3991C552.7B0DAAE2@research.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.2i In-Reply-To: ; from paf@cisco.com on Thu, Aug 10, 2000 at 07:21:23AM +0200 Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit On Thu, Aug 10, 2000 at 07:21:23AM +0200, Patrik Fältström wrote: > At 16.55 -0400 00-08-09, Hong Liu wrote: >>According to the definition of NAPTR, the service field is "protocol+rs". I am >>not sure if "mailto" can be regarded as a protocol, unless my understanding of >>"protocol" is wrong. > > protocol can be whatever. It's just a textual string. Correct. By 'protocol' we mean a way of doing things that is specific to the Application. For example, in the URI Resolution Application we created a protocol string called THTTP. THTTP (RFC 2169) is a profile of how to use HTTP 1.1 for URN resolution. We decided on using the string "thttp" as the protocol instead of just "http" since what you need in this field is a protocol that is specific to your Application. Just putting "http" or "smtp" in there isn't sufficient unless you specify that you use the entire protocol "as-is". In the case of ENUM this is 'ok'. In the future I envision a new document that describes new ENUM specific protocol profiles such as "voicemail" or "instantmessage" which then uses the URI scheme to specify exactly how that voicemail or instantmessage is sent. > >For example, SMTP can be used for email, voice messaging and Internet > >fax. > > Exactly. > > >Similarly, SIP can be used for VoIP calls and IM. The question is how we > >can encode both the protocol and the service information, given the current > >definition of NAPTR. It is obvious that some of the URL schemes used > >in ENUM are > >not sufficient to convey the service intended. Is there any way out of this? > > By writing a new RFC which defines new protocols in the E2U "rs" in > the NAPTR in ENUM which talks about "sending a fax via email, i.e. > sending fax using a mailto URI", "sending a voicemail via email, i.e. > sending voicemail using a mailto URI" etc. Yep.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 08:51:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19190 for ; Thu, 10 Aug 2000 08:51:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17677; Thu, 10 Aug 2000 08:51:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17599 for ; Thu, 10 Aug 2000 08:51:03 -0400 (EDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19132 for ; Thu, 10 Aug 2000 08:51:01 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id IAA01125; Thu, 10 Aug 2000 08:40:44 -0400 (EDT) Date: Thu, 10 Aug 2000 08:40:44 -0400 From: Michael Mealling To: Hong Liu Cc: michaelm@netsol.com, enum@ietf.org Subject: Re: [Enum] RE: draft-ietf-enum-e164-dns-03.txt Message-ID: <20000810084044.A1080@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <20000809180942.K28321@bailey.dscga.com> <39920C89.ADEAFF44@research.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <39920C89.ADEAFF44@research.telcordia.com>; from lhong@research.telcordia.com on Wed, Aug 09, 2000 at 09:59:38PM -0400 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Wed, Aug 09, 2000 at 09:59:38PM -0400, Hong Liu wrote: > (1) In draft-ietf-urn-naptr-rr-04.txt Section 4, the basic NAPTR algorithm is > presented. It says that "the algorithm starts with a string and some known > key..." So does it mean that the input to the NAPTR algorithm contains > two parameters, one for the string, another for the known key? Not really. It just means we used sloppy language. That should read "the algorithm starts with a string and some predefined rule". This, among others, is why we're working on the DDDS documents. Since those documents are new it didn't seem fair to make ENUM wait 6 months on the DDDS documents, thus we decided to send draft-ietf-urn-naptr-rr-04.txt forward. It will be obsoleted by the DDDS documents when they are approved. > In the context of ENUM, do you mean that the string is an E.164 number, > without any characters but leading '+' and digits, say +4689761234, while > the key is the domain name derived from the string, say > 4.3.2.1.6.7.9.8.6.4.e164.arpa? > > If that is the case, then the input to the NAPTR algorithm is > both +4689761234 and 4.3.2.1.6.7.9.8.6.4.e164.arpa . In other words, > one needs to change the wording in Section 3 of > draft-ietf-enum-e164-dns-03.txt regarding the input to the NAPTR algorithm. Nope. We just need to update draft-ietf-urn-naptr-rr-04.txt with the newer, better, faster DDDS documents. While draft-ietf-urn-naptr-rr-04.txt is technically accurate, it just won't cut it in the long term... > (2) In dratf-ietf-urn-ddds-00.txt, a more generic algorithm is presented > in Section 3.3. The description of this algorithm is somewhat different > from the one above. In this case, the DDDS algorithm seems to imply > that there is only one input, i.e., the Application Unique String. The first > step of the algorithm is to apply the First > Well Known Rule to the Application Unique String to produce a Key. Yep. Much clearer isn't it.... > To map ENUM into the DDDS context, I have the following correspondence: > Application Unique String: an E.164 number without any characters but > leading '+' and digits, say +4689761234. This is the input to DDDS algorithm. Yep.... > First Well Known Rule: Step 3 to 6 in Section 2 of > draft-ietf-enum-e164-dns-03.txt. Actually no. The First Well Known Rule is Database agnostic and since the domain-name specific portions of draft-ietf-urn-naptr-rr-04.txt are steps 3-6, the First Well Known Rule should only be steps 1-2. Which is essentially saying that the First Well Known Rule returns the entire Application Unique String unmodified. > (Initial) Key: the domain name derived from the string, say > 4.3.2.1.6.7.9.8.6.4.e164.arpa The Key is derived from the Rule, but yes, for your example your first real key would look like what would come out of step 6. > Any subsequent substitutions shall be applied to the Application Unique > String, i.e. +4689761234. Yep... > Personally, I would like to see the ENUM protocol in > draft-ietf-enum-e164-dns-03.txt modeled after the DDDS framework than the > transient NAPTR draft, just like what you did with URI/URN resolution in > draft-ietf-urn-uri-res-ddds-00.txt. I think that's everyones long term intent. It just didn't seem fair to make you guys wait on the URN group to wake up and deal with these documents. > It seems to me by reading your draft-ietf-urn-dns-ddds-database-00.txt, the > NAPTR algorithm is a special case of the DDDS algorithm where the database > is DNS and the RR is NAPTR, and ENUM is just another application using > DDDS with DNS and NAPTR. I am not sure how much more work needs to be > put into rewriting draft-ietf-enum-e164-dns-03.txt to do that. 100% correct! Actually, if you read Patrik's draft closely most of it is already in there. > (3) In the case of ENUM, which document we should use as reference to NAPTR, > draft-ietf-urn-naptr-rr-04.txt or dratf-ietf-urn-ddds-00.txt plus > draft-ietf-urn-dns-ddds-database-00.txt? It does not seem to me that the > two are totally consistent. I personally like the latter better. As do I but since the DDDS documents are new it wouldn't be prudent to make ENUM wait another 6-8 months for the DDDS documents to go through the process. The two sets of documents are technically consistent and that should be sufficient for now. If, in the future, someone comes up with new ENUM specific services or even a new DDDS Database (go noodle on that one for a while! ;-), then I think it would be very appropriate to bring those documents in line with the DDDS ones... > (4) In DDDS/NAPTR algorithm, does it apply to only the first matched NATPR RR > satisfying the services for the application or all NATPR RRs satisfying the > services? The reason I ask this question is that in ENUM, an application may > like to check all the NAPTR RRs before deciding on which one to use, say > SIP call is preferred by the callee but the caller can only send email. > Here suppose both have the same service E2U. All. As long as the regex matches and they are of the same Order (not preference), you get to select based on whatever criteria in the Service field you want.... > (5) In the NAPTR definition, it seems that the flag field dictates what > can be put in the regexp and replacement field. For example, the "U" > flag requires that the regexp field cannot be empty while the replacement > field should be empty; the "A" and "S" flags requires that the regexp field > be empty while the replacement field cannot. Is this the right interpretation? Actually no. If the flag is 'U' then, since the replacement field is a dname and not a text field you can't stick the URL in it. In the case where the flag is either an 'S' or 'A' then it can be in either. It depends on how complex the rule is. In the case where there is really no regular expression to be used you can stick the domain-name in the replacement field. Its just an optimization for domain-name compression. Due to recent changes in domain-name compression concensus, we could have dropped the replacement field entirely. We decided to keep it just so we didn't change existing code. Its fairly harmless... > How about the "P" flag and the empty flag? I doubt if the "P" flag means much to ENUM. Plus ENUM gets to decide which of these it wants to use. Patrik's draft only allows "U" for now. "P" was used so that folks could excape out of the NAPTR algorithm and do some something called WIRE that was an interesting idea but never really took off. > What is the implication of each on the regexp and replacement fields? Same as above which is: nearly everything goes in the regexp field except in the special case where the regexp match exactly and the replacement is a static domain-name then you can just stick the domain-name in the replacement field. Here's an example from the URI Application: One common case is where a particular URN is flat. ISBN numbers make a good example. Let's supposes there was this mammoth ISBN database running via THTTP on port 5000 on the host "public.isbn.org". In this case you just want to map 'urn:isbn:foo' to "public.isbn.org port 5000 via THTTP". You could do this: IN NAPTR 0 0 "s" "thttp+I2L+I2LS" "!urn:isbn:.*!thttp.isbn.org" . (then you'd have an SRV record that further contains the port and real hostname) See how the regular expression contains no back refernce? It isn't required since no real part of the URI is used in the replacement section. Its just simply saying "if it matches then just always go here". Due to DNS requirements at the time we were forced to move this special case out to a new dname field that could be compressed. Thus giving us this: IN NAPTR 0 0 "s" "thttp+I2L+I2LS" "" thttp.isbn.org > (6) Since ENUM only returns URIs, does it mean that only the "U" flag and > the empty flag can be used in the NAPTR RRs for ENUM? In other words, are > "A", "P" and "S" f;lags not allowed for ENUM NAPTR RRs? Patrik's draft only mentions "U" so I'm assuming that "A", "S", and "P" are not defined for ENUM. So no, they are not allowed. > Thanks again for the help! Anytime. Thanks for the nice comments on the DDDS stuff. If you have any comments or suggestions for those documents I'd be happy to have them! -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 09:49:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22578 for ; Thu, 10 Aug 2000 09:49:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19206; Thu, 10 Aug 2000 09:49:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19180 for ; Thu, 10 Aug 2000 09:49:13 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22546 for ; Thu, 10 Aug 2000 09:49:12 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA17473 for ; Thu, 10 Aug 2000 08:49:13 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id IAA09819 for ; Thu, 10 Aug 2000 08:49:11 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Thu, 10 Aug 2000 08:49:00 -0500 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 09:48:59 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Hong Liu'" Cc: "'enum@ietf.org'" Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Thu, 10 Aug 2000 09:48:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > -----Original Message----- > From: Hong Liu [mailto:lhong@research.telcordia.com] > > Andy, > > Thanks for the clarification. I agree with you that from a > user perspective, "+" means > more than just for readability. > > The problem we are discussing here is whether "+" is needed > for ENUM process given the > fact that the input is a canonical E.164 number already. I > would like to hear from you > and others. Thanks! IMO, the + is nice, but isn't enough if we really want to think of this + as a way to distinguish e.164 from some other numbering schemes we might want to implement in DNS the future. If the DNS query is made to domain e164.arpa, perhaps use of the + is redundant and not particularly helful for the future anyway? Bert albert.e.manfredi@boeing.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 10:28:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24741 for ; Thu, 10 Aug 2000 10:28:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20264; Thu, 10 Aug 2000 10:27:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20239 for ; Thu, 10 Aug 2000 10:27:11 -0400 (EDT) Received: from NETSOL-NIC-EX03.prod.netsol.com ([216.168.234.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24688 for ; Thu, 10 Aug 2000 10:27:10 -0400 (EDT) Received: by netsol-nic-ex03.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 10:23:13 -0400 Message-ID: From: "Conley, Pat" To: "'enum@ietf.org'" Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Thu, 10 Aug 2000 10:23:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A question for those advocating the "+". If it is _allowed_ will it actually be _required_ to identify a E.164 number (as opposed to a private number)? Pat Patrick Conley Director, Business Development Telecommunications Sector Network Solutions - Registry pconley@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 10:41:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25442 for ; Thu, 10 Aug 2000 10:41:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20702; Thu, 10 Aug 2000 10:40:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20675 for ; Thu, 10 Aug 2000 10:40:24 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25419 for ; Thu, 10 Aug 2000 10:40:23 -0400 (EDT) Received: from [193.150.248.21] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id HAA24250; Thu, 10 Aug 2000 07:38:56 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> References: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> Date: Thu, 10 Aug 2000 16:37:44 +0200 To: "Manfredi, Albert E" , "'Hong Liu'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Cc: "'enum@ietf.org'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 09.48 -0400 00-08-10, Manfredi, Albert E wrote: >If the DNS query is made to domain e164.arpa, perhaps use of the + is >redundant and not particularly helful for the future anyway? If we start using some more interesting parts of the NAPTR algorithms/possibilities, it is possible to have an input to the algorithm (output of first well-known-rule) that is either a full E.164 number or some other kind of telephone number. Let's say that we have for phone numbers in Sweden the TLD e164.se. A phone number in Sweden can look like "08-978777", which without the '-' is 08978777. Let's store that in DNS: 7.7.7.8.7.9.8.0.e164.se. What do we now do? Well, we can use the string we got 08978777 as input to a NAPTR rewrite mechanism where the flag field is empty, and because of that forces the rewrite to loop. We can then store 7.7.7.8.7.9.8.0.e164.se. IN NAPTR 10 10 "" "" "![0-9].*!foo.se!" . In parallell we have the full E.164 number +46-8-978777 (the same number) which have the DNS record 7.7.7.8.7.9.8.6.4.e164.arpa. That NAPTR can look like 7.7.7.8.7.9.8.6.4.e164.arpa. IN NAPTR 10 10 "" "" "![0-9].*!foo.se!" . Now, at foo.se, we want to distinguish between the "referals" which have been made from non-E.164 numbers and the ones which uses the full number (think of the two as two different dialling plans). How do we do that? Well, the input to the algorithms are 08978777 and +468978777, and because of this different. We can because of that have two different NAPTR RRs at foo.se as follows: foo.se. IN NAPTR 10 10 "u" "mailto+E2U" "!+.*!mailto:e164@foo.se!" . foo.se. IN NAPTR 10 10 "u" "mailto+E2U" "![0-9].*!mailto:local@foo.se!" . Note that the regular expressions are different, and because of that only one of the two will match, and according to the NAPTR algorithm one should use the regexp which matches given that the repacement field is empty. Also, note (of course) that the URIs which should be used are different. So, I _really_ want the '+' there so it is simpler to know that we are talking about a real E.164 number and not something else (regardless of what it is) when dealling with regular expressions. As usual, Michael will jump in if I have made an error :-) paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 10:46:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25772 for ; Thu, 10 Aug 2000 10:46:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20859; Thu, 10 Aug 2000 10:45:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20830 for ; Thu, 10 Aug 2000 10:45:34 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25739 for ; Thu, 10 Aug 2000 10:45:32 -0400 (EDT) Received: from [193.150.248.21] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id HAA26407; Thu, 10 Aug 2000 07:44:54 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 10 Aug 2000 16:43:53 +0200 To: "Conley, Pat" , "'enum@ietf.org'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 10.23 -0400 00-08-10, Conley, Pat wrote: >If it is _allowed_ will it actually be _required_ to identify >a E.164 number (as opposed to a private number)? Yes. See my latest message with a more complicated example with two different rewrite rules for a private number and an E.164 one, where two different regular expressions matches. Also, see the story which Andrew wrote earlier today (or yesterday). It is about time people start using E.164 numbers (with leading '+') on their buissness cards so one can call them. I.e. explicitly stating with a '+' that one talk about a real E.164 number "is a good thing"(tm), and ALSO follows what ITU has asked for. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 10:57:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26253 for ; Thu, 10 Aug 2000 10:57:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21138; Thu, 10 Aug 2000 10:54:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21113 for ; Thu, 10 Aug 2000 10:54:22 -0400 (EDT) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26098 for ; Thu, 10 Aug 2000 10:54:20 -0400 (EDT) Received: by dnspri.npac.com; id JAA03423; Thu, 10 Aug 2000 09:54:20 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma003336; Thu, 10 Aug 00 09:54:06 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Aug 2000 09:53:13 -0500 Message-ID: From: James Yu To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "'michael@bailey.dscga.com'" Cc: enum@ietf.org Date: Thu, 10 Aug 2000 09:51:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA21114 Subject: [Enum] RE: draft-ietf-enum-e164-dns-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik, Mike, I'll ask a few basic DNS questions which may help me in understanding the enum process. Let's assume that my desktop PC in my office needs to launch a enum/DNS query. It (the DNS client/resolver) follows the 6 steps described section 2 to formulate the DNS query. Since I'm in an enterprise environment, there is a local DNS server that does the caching and DNS resolutions. So my PC sends the query to that local DNS server which then tries to resolve the DNS query. Question#1: Does this local DNS server know anything about enum? All those digits in the DNS queries are just zones to it. Is it correct? Now, the local DNS server receives all the NAPTR RRs from for a particular E.164 number related enum/DNS query. Question#2: Does the local DNS server returns all those NAPTR RRs to the client on my PC or does it continue the DNS resolution process including applying the rewrite rules and launching the DNS query to fetch additional RRs indicated in the NAPTR RRs? I'll also need to read the I-Ds mentioned by Hong and Mike. James > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Thursday, August 10, 2000 1:29 AM > To: James Yu > Cc: enum@ietf.org > Subject: RE: draft-ietf-enum-e164-dns-03.txt > > > At 16.30 -0500 00-08-09, James Yu wrote: > >I'm still not clear about this. The '+' is not part of the > enum DNS query > >(only x.x.x.x.x.x.e164.arpa instead of > x.x.x.x.x.x.+.e164.arpa). So for > >the NAPTR algorithm to use the E.164 number, it has to > retrieve the E.164 > >number in the DNS query (e.g., get everything before > .e164.arpa, remove all > >the dots and reverse the order of the digit to recover the > original E.164 > >number). If '+' is needed, then '+' is added to the front > of the E.164 > >number. I assume that the client is not asked to remember > the output of > >step 2 in section 2. The rewrite rule will be applied to the > string in the > >DNS query and that string does not have '+' in it. That is > why I'm not > >clear about the '+' discussed in your I-D. > > No, the steps that have to be taken is _exactly_ what is > written in the spec: > > (1) Take the E.164 number > (2) Remove all characters part from leading '+' and digits > (3) Remove the '+' > (4) Reverse the order of digits > (5) Add '.' between digits > (6) Add ".e164.arpa." at the end > (7) Look up NAPTR in DNS > (8) If NAPTR is non-terminal apply rewrite rule to output of (2) > and query for new NAPTRs again which you apply output of (2) to > > That is what you _have_ to do. > > >Also, a client may send a DNS query to a local DNS server > for resolution. > > Of course. > > >Does the local DNS server continue the DNS resolution process when it > >receives NAPTR records (may be it depends on the type of NAPTR RRs > >returned)? > > I don't understand. Do you ask whether the local resolving DNS server > is doing the NAPTR resolution? The answer to that question is "no". > The client have to do that as the client is the one which know what > the input to the NAPTR algorithm is for E2U. You can not when using > NAPTR take for granted that what the regexp is applied to can be > extracted from the domainname. > > >I guess that if the NAPTR is for a SRV record, the local DNS > >server will go to the NS specified by the "target" to > retrieve SRV RR(s). > > I don't see how SRVs can be included in the ENUM mechanism... > > >So the client performs the six steps described in section 2 > but it is the > >local DNS server that performs the DNS resolution. The > local DNS server > >then is required to add the '+' to the E.164 number using > the rewrite rule > >if it needs to continue the DNS resolution process. But > only the client > >knows that the DNS process is related to enum. The local > DNS server only > >performs routine DNS process (including NAPTR) and may not > know that the DNS > >query is about enum. Is it correct? > > The DNS part of this is only querying for DNS RRs, and does not do > anything else regarding NAPTR rewrites. > > paf > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 11:04:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26669 for ; Thu, 10 Aug 2000 11:04:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21571; Thu, 10 Aug 2000 11:01:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21546 for ; Thu, 10 Aug 2000 11:01:14 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26497 for ; Thu, 10 Aug 2000 11:01:12 -0400 (EDT) Received: from [193.150.248.21] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id IAA01938; Thu, 10 Aug 2000 08:00:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 10 Aug 2000 16:59:04 +0200 To: James Yu , "'michael@bailey.dscga.com'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] RE: draft-ietf-enum-e164-dns-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 09.51 -0500 00-08-10, James Yu wrote: >Let's assume that my desktop PC in my office needs to launch a enum/DNS >query. It (the DNS client/resolver) follows the 6 steps described section 2 >to formulate the DNS query. Since I'm in an enterprise environment, there >is a local DNS server that does the caching and DNS resolutions. So my PC >sends the query to that local DNS server which then tries to resolve the DNS >query. > >Question#1: Does this local DNS server know anything about enum? No. Nothing at all. It only knows that you query for Owner: 1.2.3.4.5.5.6.7.8.e164.arpa. (or whatever) Type: NAPTR Class: IN Nothing else. The data in the record is passed back to your computer. >All >those digits in the DNS queries are just zones to it. Is it correct? Yes. >Now, the local DNS server receives all the NAPTR RRs from for a particular >E.164 number related enum/DNS query. Yes. >Question#2: Does the local DNS server returns all those NAPTR RRs to the >client on my PC or does it continue the DNS resolution process including >applying the rewrite rules and launching the DNS query to fetch additional >RRs indicated in the NAPTR RRs? Yes, it returns all of them. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 11:04:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26686 for ; Thu, 10 Aug 2000 11:04:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21349; Thu, 10 Aug 2000 10:59:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21322 for ; Thu, 10 Aug 2000 10:59:12 -0400 (EDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26365 for ; Thu, 10 Aug 2000 10:59:10 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id KAA01540; Thu, 10 Aug 2000 10:48:38 -0400 (EDT) Date: Thu, 10 Aug 2000 10:48:37 -0400 From: Michael Mealling To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: "Manfredi, Albert E" , "'Hong Liu'" , "'enum@ietf.org'" Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Message-ID: <20000810104837.D1365@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.2i In-Reply-To: ; from paf@cisco.com on Thu, Aug 10, 2000 at 04:37:44PM +0200 Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit On Thu, Aug 10, 2000 at 04:37:44PM +0200, Patrik Fältström wrote: > As usual, Michael will jump in if I have made an error :-) Looked fine to me.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 11:09:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26892 for ; Thu, 10 Aug 2000 11:09:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21822; Thu, 10 Aug 2000 11:06:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21797 for ; Thu, 10 Aug 2000 11:06:49 -0400 (EDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26810 for ; Thu, 10 Aug 2000 11:06:47 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id KAA01553; Thu, 10 Aug 2000 10:56:24 -0400 (EDT) Date: Thu, 10 Aug 2000 10:56:24 -0400 From: Michael Mealling To: James Yu Cc: "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , enum@ietf.org Message-ID: <20000810105624.E1365@bailey.dscga.com> Reply-To: michaelm@netsol.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: ; from james.yu@neustar.com on Thu, Aug 10, 2000 at 09:51:46AM -0500 Subject: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Thu, Aug 10, 2000 at 09:51:46AM -0500, James Yu wrote: > I'll ask a few basic DNS questions which may help me in understanding the > enum process. No problem... > Let's assume that my desktop PC in my office needs to launch a enum/DNS > query. It (the DNS client/resolver) follows the 6 steps described section 2 > to formulate the DNS query. Since I'm in an enterprise environment, there > is a local DNS server that does the caching and DNS resolutions. So my PC > sends the query to that local DNS server which then tries to resolve the DNS > query. > > Question#1: Does this local DNS server know anything about enum? All > those digits in the DNS queries are just zones to it. Is it correct? Correct. This is actually a strength since it allows DNS to act as it always has. No additional software is needed in the server. You _can_ start optimizing stuff by making the server ENUM aware so that it puts potentially useful information in the additional information field of the DNS packet. This optimization on the server side is a MAY not a MUST. > Now, the local DNS server receives all the NAPTR RRs from for a particular > E.164 number related enum/DNS query. Yep.... > Question#2: Does the local DNS server returns all those NAPTR RRs to the > client on my PC or does it continue the DNS resolution process including > applying the rewrite rules and launching the DNS query to fetch additional > RRs indicated in the NAPTR RRs? Nope. The local DNS server is dumb with respect to ENUM and NAPTR. The DNS server simply return the NAPTR records for the dname you request. Its up to your client (PC) to actually do the rewrites and issue any further DNS requests.... > I'll also need to read the I-Ds mentioned by Hong and Mike. Read teh DDDS ones first and then the draft-ietf-urn-naptr-rr-04.txt document. It'll make more sense that way... -Mm -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 11:30:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28363 for ; Thu, 10 Aug 2000 11:30:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22502; Thu, 10 Aug 2000 11:28:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22475 for ; Thu, 10 Aug 2000 11:28:02 -0400 (EDT) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28117 for ; Thu, 10 Aug 2000 11:28:00 -0400 (EDT) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Aug 2000 17:27:43 +0200 Message-ID: <98388C05D464D111B61800805F1504160123E888@p-ibis.issy.cnet.fr> From: BARNOLE Valerie FTRD/DAC/ISS To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Cc: "'enum@ietf.org'" , "Manfredi, Albert E" , "'Hong Liu'" Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Thu, 10 Aug 2000 17:27:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA22476 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit So a user dialing on his PC a number with a "+" in front indicates to the system that it has to look through e164.arpa rather than in the originating country of the call, namely Sweden and e164.se in your example ? A maybe trivial question : How does the system knows that it has to go through telia.se rather than through e164.se in case Telia operator decided to put its customers numbers in a DNS zone telia.se for any reason ? end of message _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Valérie Barnole FTR&D/DAC/ACE tel. : + 33 1 45 29 58 39 fax : + 33 1 46 29 31 42 mail to : valerie.barnole@francetelecom.fr -----Message d'origine----- De: Patrik Fältström [mailto:paf@cisco.com] Date: jeudi 10 août 2000 16:38 À: Manfredi, Albert E; 'Hong Liu' Cc: 'enum@ietf.org' Objet: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt At 09.48 -0400 00-08-10, Manfredi, Albert E wrote: >If the DNS query is made to domain e164.arpa, perhaps use of the + is >redundant and not particularly helful for the future anyway? If we start using some more interesting parts of the NAPTR algorithms/possibilities, it is possible to have an input to the algorithm (output of first well-known-rule) that is either a full E.164 number or some other kind of telephone number. Let's say that we have for phone numbers in Sweden the TLD e164.se. A phone number in Sweden can look like "08-978777", which without the '-' is 08978777. Let's store that in DNS: 7.7.7.8.7.9.8.0.e164.se. What do we now do? Well, we can use the string we got 08978777 as input to a NAPTR rewrite mechanism where the flag field is empty, and because of that forces the rewrite to loop. We can then store 7.7.7.8.7.9.8.0.e164.se. IN NAPTR 10 10 "" "" "![0-9].*!foo.se!" . In parallell we have the full E.164 number +46-8-978777 (the same number) which have the DNS record 7.7.7.8.7.9.8.6.4.e164.arpa. That NAPTR can look like 7.7.7.8.7.9.8.6.4.e164.arpa. IN NAPTR 10 10 "" "" "![0-9].*!foo.se!" . Now, at foo.se, we want to distinguish between the "referals" which have been made from non-E.164 numbers and the ones which uses the full number (think of the two as two different dialling plans). How do we do that? Well, the input to the algorithms are 08978777 and +468978777, and because of this different. We can because of that have two different NAPTR RRs at foo.se as follows: foo.se. IN NAPTR 10 10 "u" "mailto+E2U" "!+.*!mailto:e164@foo.se!" . foo.se. IN NAPTR 10 10 "u" "mailto+E2U" "![0-9].*!mailto:local@foo.se!" . Note that the regular expressions are different, and because of that only one of the two will match, and according to the NAPTR algorithm one should use the regexp which matches given that the repacement field is empty. Also, note (of course) that the URIs which should be used are different. So, I _really_ want the '+' there so it is simpler to know that we are talking about a real E.164 number and not something else (regardless of what it is) when dealling with regular expressions. As usual, Michael will jump in if I have made an error :-) paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 11:51:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29677 for ; Thu, 10 Aug 2000 11:51:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23200; Thu, 10 Aug 2000 11:46:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23175 for ; Thu, 10 Aug 2000 11:46:28 -0400 (EDT) Received: from relay.cwplc.com (relay.cwplc.com [194.6.6.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29257 for ; Thu, 10 Aug 2000 11:46:26 -0400 (EDT) Received: from gb-cwc-brt-msw2.isops.cwcom.co.uk ([148.185.176.7]) by relay.cwplc.com (Pro-8.9.3/8.9.3) with ESMTP id QAA28600 for ; Thu, 10 Aug 2000 16:46:30 +0100 (BST) Received: from gbcwcbrti002.isops.cwcom.co.uk (unverified) by gb-cwc-brt-msw2.isops.cwcom.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 10 Aug 2000 16:41:04 +0100 Received: by gbcwcbrti002.isops.cwcom.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 16:30:40 +0100 Message-Id: <29B7C7A8E3E4D111ABDB0000F8086400072BF384@gbcwcbrtm003.isops.cwcom.co.uk> From: "Rosbotham, Paul" To: "'enum@ietf.org'" Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Thu, 10 Aug 2000 16:47:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Not at all an expert on DNS, but would tend to agree with Bert on this. I thought the very fact that the query is to domain e164.arpa indicates that the number is E.164, not a private numbering plan etc. Therefore, the "+" seems redundant. My assumption had been that if a non-E.164 number were offered, a different domain would be used. The E.164 number doesn't contain the "+", it's added for readability reasons to remind the caller that (s)he'd better add 00, 011 or whatever is used locally (mobiles actually let you key "+" in many countries). Internal to the network, the E.164 number carried is just the digits, not with a leading "+". Of course, there is the luxury in the switched network of having a nature of address field to indicate what type of number it is (national or international), but we won't go into that... Andy G is right when he says that the "+" aids readability, but that's at a user interface level and I thought we were talking about protocol internals here. Not going to die in a ditch over this, but it does seem to me that if you have a domain of e164.arpa, e164 numbers only should be used... Paul > -----Original Message----- > From: Manfredi, Albert E [SMTP:Albert.Manfredi@PHL.Boeing.com] > Sent: 10 August 2000 14:49 > To: 'Hong Liu' > Cc: 'enum@ietf.org' > Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt > > > -----Original Message----- > > From: Hong Liu [mailto:lhong@research.telcordia.com] > > > > Andy, > > > > Thanks for the clarification. I agree with you that from a > > user perspective, "+" means > > more than just for readability. > > > > The problem we are discussing here is whether "+" is needed > > for ENUM process given the > > fact that the input is a canonical E.164 number already. I > > would like to hear from you > > and others. Thanks! > > IMO, the + is nice, but isn't enough if we really want to think of this + > as > a way to distinguish e.164 from some other numbering schemes we might want > to implement in DNS the future. > > If the DNS query is made to domain e164.arpa, perhaps use of the + is > redundant and not particularly helful for the future anyway? > > Bert > albert.e.manfredi@boeing.com > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum ********************************************************************** This message may contain information which is confidential or privileged. If you are not the intended recipient, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy. ********************************************************************** _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 11:51:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29702 for ; Thu, 10 Aug 2000 11:51:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23160; Thu, 10 Aug 2000 11:46:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23133 for ; Thu, 10 Aug 2000 11:46:19 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29253 for ; Thu, 10 Aug 2000 11:46:16 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d32.cc.telcordia.com [128.96.11.32]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7AFieR06747; Thu, 10 Aug 2000 11:44:40 -0400 (EDT) Message-ID: <3992CDE9.1A658D6A@research.telcordia.com> Date: Thu, 10 Aug 2000 11:44:41 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: "Manfredi, Albert E" , "'enum@ietf.org'" , michaelm@netsol.com, james.yu@neustar.com Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt References: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik, Thanks for giving out the example in the email. Now I understand the need to distinguish a true E.164 number from other national or corporate numbering plan, when ALL these services are hosted by the SAME service provider. Your example builds on three assumptions: (1) The ENUM mechanism, not ENUM itself, will be used in situations other than E.164 to URI mapping. (2) A service provider may co-host NAPTR RRs for the different ENUM-like services of the same user. (Here I use the word "user" in a very loose way.) (3) The application has the knowledge of which numbering plan it is using; otherwise it will not know which name space to query in the first place. Hence, the application knows which _service_ it is requesting. I would not argue whether (1) is really within the charter of ENUM, but let's assume that this is going to happen independent of whether ENUM include other similar services or not. I just want to emphasize that there will be many ENUM-like _services_ coexisting, and they are in fact _different_ services. (Personally, I think it is a good thing to see the same mechanism be used in various situations.) I acknowledge the need to distinguish the services by the way a phone number is presented, but I would argue that by just putting a '+' for an E.164 number is not sufficient to address the need. How are you going to tell one non-E164 number from another non-E164 number? In this case, '+' will not be able to do much. To solve this problem, I would suggest that we use the 'rs' field instead. This proposal builds on the emails from both James Yu and Al Manfredi. Specifically, 'E2U' is currently defined for ENUM. For other numbering plans, others can also define 'E212toU' for IMSI, 'E214toU' for global title, 'UPT2U' for UPT number, 'SE2U' for national numbers in Sweden, etc... Of course, this is an idea, the exact details need to be worked out. The point here is each additional service can be distinguished by defining a new service code point in 'rs'. By reading the DDDS algorithm in draft-ietf-urn-ddds-00.txt, the application MUST check the services field after the substitution to decide whether the resulting string. This proposal has the following advantages: First, this provides an extensible way of using ENUM in many other similar applications without clashing the name space. Second, it helps to tell people why it is important to define E2U in ENUM. Third, by removing '+' specifically for E.164, it makes the ENUM algorithm uniform in treating any numbering plans. However, it has one disadvantage: the resolution system may need to return all the NAPTR RRs to the application. But since it normally at the last step of the resolution process, I would not expect too many records to be returned for a particular 'user'. --Hong Patrik Fältström wrote: > At 09.48 -0400 00-08-10, Manfredi, Albert E wrote: > >If the DNS query is made to domain e164.arpa, perhaps use of the + is > >redundant and not particularly helful for the future anyway? > > If we start using some more interesting parts of the NAPTR > algorithms/possibilities, it is possible to have an input to the > algorithm (output of first well-known-rule) that is either a full > E.164 number or some other kind of telephone number. > > Let's say that we have for phone numbers in Sweden the TLD e164.se. > > A phone number in Sweden can look like "08-978777", which without the > '-' is 08978777. > > Let's store that in DNS: > > 7.7.7.8.7.9.8.0.e164.se. > > What do we now do? > > Well, we can use the string we got 08978777 as input to a NAPTR > rewrite mechanism where the flag field is empty, and because of that > forces the rewrite to loop. > > We can then store > > 7.7.7.8.7.9.8.0.e164.se. IN NAPTR 10 10 "" "" "![0-9].*!foo.se!" . > > In parallell we have the full E.164 number +46-8-978777 (the same > number) which have the DNS record 7.7.7.8.7.9.8.6.4.e164.arpa. > > That NAPTR can look like > > 7.7.7.8.7.9.8.6.4.e164.arpa. IN NAPTR 10 10 "" "" "![0-9].*!foo.se!" . > > Now, at foo.se, we want to distinguish between the "referals" which > have been made from non-E.164 numbers and the ones which uses the > full number (think of the two as two different dialling plans). How > do we do that? > > Well, the input to the algorithms are 08978777 and +468978777, and > because of this different. We can because of that have two different > NAPTR RRs at foo.se as follows: > > foo.se. IN NAPTR 10 10 "u" "mailto+E2U" "!+.*!mailto:e164@foo.se!" . > foo.se. IN NAPTR 10 10 "u" "mailto+E2U" "![0-9].*!mailto:local@foo.se!" . > > Note that the regular expressions are different, and because of that > only one of the two will match, and according to the NAPTR algorithm > one should use the regexp which matches given that the repacement > field is empty. > > Also, note (of course) that the URIs which should be used are different. > > So, I _really_ want the '+' there so it is simpler to know that we > are talking about a real E.164 number and not something else > (regardless of what it is) when dealling with regular expressions. > > As usual, Michael will jump in if I have made an error :-) > > paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 11:55:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00060 for ; Thu, 10 Aug 2000 11:55:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23414; Thu, 10 Aug 2000 11:52:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23321 for ; Thu, 10 Aug 2000 11:52:24 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29761 for ; Thu, 10 Aug 2000 11:52:22 -0400 (EDT) Received: from [193.150.248.21] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id IAA24555; Thu, 10 Aug 2000 08:51:30 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <98388C05D464D111B61800805F1504160123E888@p-ibis.issy.cnet.fr> References: <98388C05D464D111B61800805F1504160123E888@p-ibis.issy.cnet.fr> Date: Thu, 10 Aug 2000 17:47:28 +0200 To: BARNOLE Valerie FTRD/DAC/ISS From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Cc: "'enum@ietf.org'" , "Manfredi, Albert E" , "'Hong Liu'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 17.27 +0200 00-08-10, BARNOLE Valerie FTRD/DAC/ISS wrote: > >So a user dialing on his PC a number with a "+" in front indicates to the >system that it has to look through e164.arpa rather than in the originating >country of the call, namely Sweden and e164.se in your example ? No, I have not even started talking about the interface to the applications, but if _I_ wrote an application I would probably do it that way. >A maybe trivial question : >How does the system knows that it has to go through telia.se rather than >through e164.se in case Telia operator decided to put its customers numbers >in a DNS zone telia.se for any reason ? Because it knows that E.164 numbers are handled in the e164.arpa domain, and the closed numbering plan somewhere else. When writing a spec for any closed numbering plan, you have to spec what TLD _that_ closed numbering plan is to use. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 12:05:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01763 for ; Thu, 10 Aug 2000 12:05:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23958; Thu, 10 Aug 2000 12:02:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23932 for ; Thu, 10 Aug 2000 12:02:14 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01191 for ; Thu, 10 Aug 2000 12:02:12 -0400 (EDT) Received: from [193.150.248.21] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id JAA29137; Thu, 10 Aug 2000 09:00:45 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <3992CDE9.1A658D6A@research.telcordia.com> References: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> <3992CDE9.1A658D6A@research.telcordia.com> Date: Thu, 10 Aug 2000 17:58:39 +0200 To: Hong Liu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Cc: "Manfredi, Albert E" , "'enum@ietf.org'" , michaelm@netsol.com, james.yu@neustar.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11.44 -0400 00-08-10, Hong Liu wrote: >Your example builds on three assumptions: >(1) The ENUM mechanism, not ENUM itself, will be used in situations other >than E.164 to URI mapping. >(2) A service provider may co-host NAPTR RRs for the different ENUM-like >services of the same user. (Here I use the word "user" in a very loose way.) >(3) The application has the knowledge of which numbering plan it is using; >otherwise it will not know which name space to query in the first place. >Hence, the application knows which _service_ it is requesting. Correct. >I would not argue whether (1) is really within the charter of ENUM, but let's >assume that this is going to happen independent of whether ENUM include other >similar services or not. I just want to emphasize that there will be many >ENUM-like _services_ coexisting, and they are in fact _different_ services. >(Personally, I think it is a good thing to see the same mechanism be used in >various situations.) I agree completely. >I acknowledge the need to distinguish the services by the way a phone number >is presented, but I would argue that by just putting a '+' for an E.164 >number is not sufficient to address the need. How are you going to tell one >non-E164 number from another non-E164 number? In this case, '+' will not be >able to do much. They can for each numbering plan tell exactly what input string they are using for their version of the NAPTR algorithm. My personal one might be "Take the number, add the string 'paf' in front of the digits" in step 2, so the number "42" (I only have 2 digits in the phone numbers in my numbering plan) will be turned into "paf42" before starting matching in regexp in NAPTRs. >To solve this problem, I would suggest that we use the 'rs' field instead. >This proposal builds on the emails from both James Yu and Al Manfredi. >Specifically, 'E2U' is currently defined for ENUM. For other numbering plans, >others can also define 'E212toU' for IMSI, 'E214toU' for global title, >'UPT2U' for UPT number, 'SE2U' for national numbers in Sweden, etc... Of >course, this is an idea, the exact details need to be worked out. The point >here is each additional service can be distinguished by defining a new >service code point in 'rs'. Ok. >By reading the DDDS algorithm in draft-ietf-urn-ddds-00.txt, the application >MUST check the services field after the substitution to decide whether the >resulting string. That is absolutely correct. >This proposal has the following advantages: First, this provides an >extensible way of using ENUM in many other similar applications without >clashing the name space. Second, it helps to tell people why it is important >to define E2U in ENUM. Third, by removing '+' specifically for E.164, it >makes the ENUM algorithm uniform in treating any numbering plans. However, it >has one disadvantage: the resolution system may need to return all the NAPTR >RRs to the application. It always pass back all NAPTRs. And, I still don't understand why we should not follow the recommendation from ITU. Is it because you don't want to include the '+' in the regexp? Is it because you feel "!.*!mailto:kalle@foo.se!" is weird when it tries to match "+468978777", and that matching "468978777" is better? I.e. you say "Third, by removing '+' specifically for E.164, it makes the ENUM algorithm uniform in treating any numbering plans.". I don't get this. ITU have asked the '+ to be there first of all, and secondly I ask how it can become "uniform"? >But since it normally at the last step of the >resolution process, I would not expect too many records to be returned for a >particular 'user'. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 12:11:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02786 for ; Thu, 10 Aug 2000 12:11:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24091; Thu, 10 Aug 2000 12:08:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24060 for ; Thu, 10 Aug 2000 12:08:21 -0400 (EDT) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02325 for ; Thu, 10 Aug 2000 12:08:19 -0400 (EDT) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Aug 2000 18:08:02 +0200 Message-ID: <98388C05D464D111B61800805F1504160123E88B@p-ibis.issy.cnet.fr> From: BARNOLE Valerie FTRD/DAC/ISS To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , BARNOLE Valerie FTRD/DAC/ISS Cc: "'enum@ietf.org'" , "Manfredi, Albert E" , "'Hong Liu'" Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Thu, 10 Aug 2000 18:07:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA24061 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I understand that an E.164 numberis stored in e164.arpa. and that as long as the system identifies the dialled number as an E.164 one (that means first digits = country code, and not regional code for instance), he knows how to handle it and where to search. What I do not see clearly is the case of what you may call competing closed numbering plans : in my example the national swedish one, the telia customers one (where are gathered the blocks of numbers allocated by the swedish regulator to this operator. The system will need something to know somethig in order to append the same dialled swedish national number either with e164.se or telia.se. You may answer that the calling party will dial differently, and that will be the hint for the system, but it is getting rather complicated... Maybe I did not get what you mean with "When writing a spec for any closed numbering plan, you have to spec what TLD _that_ closed numbering plan is to use." Thanks in advance if you can clarify. end of message _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Valérie Barnole FTR&D/DAC/ACE tel. : + 33 1 45 29 58 39 fax : + 33 1 46 29 31 42 mail to : valerie.barnole@francetelecom.fr -----Message d'origine----- De: Patrik Fältström [mailto:paf@cisco.com] Date: jeudi 10 août 2000 17:47 À: BARNOLE Valerie FTRD/DAC/ISS Cc: 'enum@ietf.org'; Manfredi, Albert E; 'Hong Liu' Objet: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt At 17.27 +0200 00-08-10, BARNOLE Valerie FTRD/DAC/ISS wrote: > >So a user dialing on his PC a number with a "+" in front indicates to the >system that it has to look through e164.arpa rather than in the originating >country of the call, namely Sweden and e164.se in your example ? No, I have not even started talking about the interface to the applications, but if _I_ wrote an application I would probably do it that way. >A maybe trivial question : >How does the system knows that it has to go through telia.se rather than >through e164.se in case Telia operator decided to put its customers numbers >in a DNS zone telia.se for any reason ? Because it knows that E.164 numbers are handled in the e164.arpa domain, and the closed numbering plan somewhere else. When writing a spec for any closed numbering plan, you have to spec what TLD _that_ closed numbering plan is to use. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 12:57:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04804 for ; Thu, 10 Aug 2000 12:57:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24710; Thu, 10 Aug 2000 12:57:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24679 for ; Thu, 10 Aug 2000 12:56:59 -0400 (EDT) Received: from cqmx.corp.comsat.com (cqmx.corp.comsat.com [134.133.184.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04801 for ; Thu, 10 Aug 2000 12:56:59 -0400 (EDT) From: Andrew.Gallant@comsat.com Received: from cqgate6.cmc.comsat.com ([134.133.162.21]) by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Thu, 10 Aug 2000 12:56:20 -0400 Received: from ccMail by cqgate6.cmc.comsat.com (IMA Internet Exchange 3.13) id 000C2C86; Thu, 10 Aug 2000 13:02:54 -0400 Mime-Version: 1.0 Date: Thu, 10 Aug 2000 12:09:32 -0400 Message-ID: <000C2C86.C22219@comsat.com> To: "Manfredi; Albert E" , "'Hong Liu'" , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: "'enum@ietf.org'" Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit Subject: [Enum] limit "e164 number" scope (re: draft-ietf-enum-e164-dns-...) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit For now I suggest that a limited scope of the term "E.164 number" would be helpful and timely. In-scope would be, in effect, numbers that an international switch could handle. This implies: a number begins with a valid E.164 CC; an international switch could route on that CC; and the use is public telecommunications. Private numbers and even national (significant) numbers would be out of scope (again, for now). Roughly speaking, here an "E.164 number" is what you could use for an international call via the PSTN. That's a useful subset of numbers. In the US one would dial 011-800- as an international freephone call. In other countries one might dial 00-800- for the "same" call. This is represented as +800-. This is NOT the same as 1-800-<7-digits> or 1-888-<7-digits>, because these are toll-free numbers in the US. In other words, 800 as a CC is very different from 800 as a non-geographic NPA in the US. Note that + may be a useful way to identify an in-scope number, since international numbers are commonly written with a + to alert the user. Limiting the scope is a practical approach. It involves number format, valid CC, and intended use. It's not meant to preclude future work to extend or generalize from enum. I'm suggesting that it will help get to a workable enum for a definable set of numbers. Thanks for listening. Recall that E.164 and E.123 are Recommendations and not requirements, and please remember my usual disclaimer. -Andy =========(note: email address change)========= Andrew Gallant (andrew.gallant@lmco.com); LMGT Lockheed Martin Global Telecommunications, Inc. 6560 Rock Spring Drive; Bethesda, MD 20817 USA Tel: +1 301 214 3264; Fax: +1 301 214 7226 _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 13:02:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05055 for ; Thu, 10 Aug 2000 13:02:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24926; Thu, 10 Aug 2000 13:02:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24903 for ; Thu, 10 Aug 2000 13:02:04 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05036 for ; Thu, 10 Aug 2000 13:02:04 -0400 (EDT) Received: from [193.150.248.21] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id KAA29146; Thu, 10 Aug 2000 10:01:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <98388C05D464D111B61800805F1504160123E88B@p-ibis.issy.cnet.fr> References: <98388C05D464D111B61800805F1504160123E88B@p-ibis.issy.cnet.fr> Date: Thu, 10 Aug 2000 18:59:29 +0200 To: BARNOLE Valerie FTRD/DAC/ISS From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Cc: "'enum@ietf.org'" , "Manfredi, Albert E" , "'Hong Liu'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 18.07 +0200 00-08-10, BARNOLE Valerie FTRD/DAC/ISS wrote: >The system will need something to know >somethig in order to append the same dialled swedish national number either >with e164.se or telia.se. You may answer that the calling party will dial >differently, and that will be the hint for the system, but it is getting >rather complicated... > >Maybe I did not get what you mean with "When writing a spec for any closed >numbering plan, you have to spec what TLD _that_ closed numbering plan is to >use." I think I talk about the same things as you. When talking about a closed numbering plan, you need to define it, where in DNS it "hooks in" in the form of two things (at least): (1) What string is the input to the NAPTR algorithm? (2) What top-domain the reversed number is to hook into? Now, a NAPTR which have no flags is to be applied to the initial string defined in (1), and the result of that regexp rewrite is to be a domainname which is replacing the domainname just used. A new NAPTR is looked up and _the_same_ string as in (1) is applied to that regexp. My claim is that one day it might be the case that this recursive process might actually in some way translate the domainname one produces from the ENUM wg (by choosing e164.arpa in step (2) above) into the same domainname one produces from some _future_ definition of how to use an ENUM-like algorithm (by choosing some other domain in step (2) above). In this same domainname which you then use in the second step in the recursive process of NAPTR resolution you will have regular expressions, and I really want to make it possible for people to distinguish in the regular expression (if one wants to) the two numbers (defined in step (1) above in the two paths). If one want to, of course the regexp can be made to match strings both with and without the leading '+', but if we don't have the '+' in the beginning of E.164 it will not be possible to distinguish between them. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 13:43:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06366 for ; Thu, 10 Aug 2000 13:43:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25642; Thu, 10 Aug 2000 13:43:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25611 for ; Thu, 10 Aug 2000 13:43:13 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06359 for ; Thu, 10 Aug 2000 13:43:12 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA20764 for ; Thu, 10 Aug 2000 12:43:12 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id MAA13970 for ; Thu, 10 Aug 2000 12:43:10 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Thu, 10 Aug 2000 12:42:59 -0500 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 13:42:58 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBD99@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'BARNOLE Valerie FTRD/DAC/ISS'" , =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Cc: "'enum@ietf.org'" Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Thu, 10 Aug 2000 13:42:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA25612 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Folks, Is this even an enum wg issue? How one types the number in the PC is important, but I don't think it belongs here. How the PC sends out the DNS query does matter, and the fact that a query is sent to e164.arpa indicates that the PC has understood the request to be for an e.164 number. The way the request is typed into the PC is up to the application programmer, I would think. Using + is probably a great idea, but do we in enum care? Maybe the request is typed in a little Windows dialog box, where e164 is one of the selections you might check. If other requests are formatted in the future, for non-e.164 numbers, then they would be made to a different domain, not e164.arpa. Or am I missing something here? Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: BARNOLE Valerie FTRD/DAC/ISS > [mailto:valerie.barnole@rd.francetelecom.fr] > Sent: Thursday, August 10, 2000 11:28 AM > To: 'Patrik Fältström' > Cc: 'enum@ietf.org'; Manfredi, Albert E; 'Hong Liu' > Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt > > > > So a user dialing on his PC a number with a "+" in front > indicates to the > system that it has to look through e164.arpa rather than in > the originating > country of the call, namely Sweden and e164.se in your example ? > A maybe trivial question : > How does the system knows that it has to go through telia.se > rather than > through e164.se in case Telia operator decided to put its > customers numbers > in a DNS zone telia.se for any reason ? > > end of message > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > Valérie Barnole > > FTR&D/DAC/ACE > > tel. : + 33 1 45 29 58 39 > fax : + 33 1 46 29 31 42 > > mail to : valerie.barnole@francetelecom.fr > > > > -----Message d'origine----- > De: Patrik Fältström [mailto:paf@cisco.com] > Date: jeudi 10 août 2000 16:38 > À: Manfredi, Albert E; 'Hong Liu' > Cc: 'enum@ietf.org' > Objet: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt > > > At 09.48 -0400 00-08-10, Manfredi, Albert E wrote: > >If the DNS query is made to domain e164.arpa, perhaps use of the + is > >redundant and not particularly helful for the future anyway? > > If we start using some more interesting parts of the NAPTR > algorithms/possibilities, it is possible to have an input to the > algorithm (output of first well-known-rule) that is either a full > E.164 number or some other kind of telephone number. > > Let's say that we have for phone numbers in Sweden the TLD e164.se. > > A phone number in Sweden can look like "08-978777", which without the > '-' is 08978777. > > Let's store that in DNS: > > 7.7.7.8.7.9.8.0.e164.se. > > What do we now do? > > Well, we can use the string we got 08978777 as input to a NAPTR > rewrite mechanism where the flag field is empty, and because of that > forces the rewrite to loop. > > We can then store > > 7.7.7.8.7.9.8.0.e164.se. IN NAPTR 10 10 "" "" "![0-9].*!foo.se!" . > > In parallell we have the full E.164 number +46-8-978777 (the same > number) which have the DNS record 7.7.7.8.7.9.8.6.4.e164.arpa. > > That NAPTR can look like > > 7.7.7.8.7.9.8.6.4.e164.arpa. IN NAPTR 10 10 "" "" "![0-9].*!foo.se!" . > > Now, at foo.se, we want to distinguish between the "referals" which > have been made from non-E.164 numbers and the ones which uses the > full number (think of the two as two different dialling plans). How > do we do that? > > Well, the input to the algorithms are 08978777 and +468978777, and > because of this different. We can because of that have two different > NAPTR RRs at foo.se as follows: > > foo.se. IN NAPTR 10 10 "u" "mailto+E2U" "!+.*!mailto:e164@foo.se!" . > foo.se. IN NAPTR 10 10 "u" "mailto+E2U" > "![0-9].*!mailto:local@foo.se!" . > > Note that the regular expressions are different, and because of that > only one of the two will match, and according to the NAPTR algorithm > one should use the regexp which matches given that the repacement > field is empty. > > Also, note (of course) that the URIs which should be used are > different. > > So, I _really_ want the '+' there so it is simpler to know that we > are talking about a real E.164 number and not something else > (regardless of what it is) when dealling with regular expressions. > > As usual, Michael will jump in if I have made an error :-) > > paf > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 13:46:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06489 for ; Thu, 10 Aug 2000 13:46:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25732; Thu, 10 Aug 2000 13:45:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25707 for ; Thu, 10 Aug 2000 13:45:55 -0400 (EDT) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06484 for ; Thu, 10 Aug 2000 13:45:54 -0400 (EDT) Received: by dnspri.npac.com; id MAA29801; Thu, 10 Aug 2000 12:45:53 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma029736; Thu, 10 Aug 00 12:45:36 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Aug 2000 12:44:43 -0500 Message-ID: From: James Yu To: "'michaelm@netsol.com'" , =?iso-8859-1?Q?=27Pa?= =?iso-8859-1?Q?trik_F=E4ltstr=F6m=27?= Cc: enum@ietf.org Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Thu, 10 Aug 2000 12:43:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA25708 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik, Mike, Thanks. James > -----Original Message----- > From: Michael Mealling [mailto:michael@bailey.dscga.com] > Sent: Thursday, August 10, 2000 10:56 AM > To: James Yu > Cc: 'Patrik Fältström'; enum@ietf.org > Subject: [Enum] Re: draft-ietf-enum-e164-dns-03.txt > > > On Thu, Aug 10, 2000 at 09:51:46AM -0500, James Yu wrote: > > I'll ask a few basic DNS questions which may help me in > understanding the > > enum process. > > No problem... > > > Let's assume that my desktop PC in my office needs to > launch a enum/DNS > > query. It (the DNS client/resolver) follows the 6 steps > described section 2 > > to formulate the DNS query. Since I'm in an enterprise > environment, there > > is a local DNS server that does the caching and DNS > resolutions. So my PC > > sends the query to that local DNS server which then tries > to resolve the DNS > > query. > > > > Question#1: Does this local DNS server know anything about > enum? All > > those digits in the DNS queries are just zones to it. Is > it correct? > > Correct. This is actually a strength since it allows DNS to act as it > always has. No additional software is needed in the server. You _can_ > start optimizing stuff by making the server ENUM aware so that it > puts potentially useful information in the additional information > field of the DNS packet. This optimization on the server side > is a MAY > not a MUST. > > > Now, the local DNS server receives all the NAPTR RRs from > for a particular > > E.164 number related enum/DNS query. > > Yep.... > > > Question#2: Does the local DNS server returns all those > NAPTR RRs to the > > client on my PC or does it continue the DNS resolution > process including > > applying the rewrite rules and launching the DNS query to > fetch additional > > RRs indicated in the NAPTR RRs? > > Nope. The local DNS server is dumb with respect to ENUM and NAPTR. The > DNS server simply return the NAPTR records for the dname you request. > Its up to your client (PC) to actually do the rewrites and issue any > further DNS requests.... > > > > I'll also need to read the I-Ds mentioned by Hong and Mike. > > Read teh DDDS ones first and then the draft-ietf-urn-naptr-rr-04.txt > document. It'll make more sense that way... > > -Mm > > -- > -------------------------------------------------------------- > ------------------ > Michael Mealling | Vote Libertarian! | > www.rwhois.net/michael > Sr. Research Engineer | www.ga.lp.org/gwinnett | > ICQ#: 14198821 > Network Solutions | www.lp.org | > michaelm@netsol.com > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 13:52:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06695 for ; Thu, 10 Aug 2000 13:52:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25864; Thu, 10 Aug 2000 13:51:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25829 for ; Thu, 10 Aug 2000 13:51:39 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06683 for ; Thu, 10 Aug 2000 13:51:38 -0400 (EDT) Received: from [193.150.248.21] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id KAA23745; Thu, 10 Aug 2000 10:50:16 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20000810105624.E1365@bailey.dscga.com> References: <20000810105624.E1365@bailey.dscga.com> Date: Thu, 10 Aug 2000 19:49:14 +0200 To: Michael Mealling , James Yu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 10.56 -0400 00-08-10, Michael Mealling wrote: >Read teh DDDS ones first and then the draft-ietf-urn-naptr-rr-04.txt >document. It'll make more sense that way... And when the DDDS documents are ready (all three of them) it will replace the existing RFC and draft-ietf-urn-naptr-rr-04.txt. So the confusion today is on it's way to be resolved. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 14:01:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07339 for ; Thu, 10 Aug 2000 14:01:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26236; Thu, 10 Aug 2000 14:00:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26212 for ; Thu, 10 Aug 2000 14:00:57 -0400 (EDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07260 for ; Thu, 10 Aug 2000 14:00:54 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA02157; Thu, 10 Aug 2000 13:50:30 -0400 (EDT) Date: Thu, 10 Aug 2000 13:50:30 -0400 From: Michael Mealling To: "Manfredi, Albert E" Cc: "'BARNOLE Valerie FTRD/DAC/ISS'" , "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , "'enum@ietf.org'" Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Message-ID: <20000810135029.N1365@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <4102273CEB77D211869200805FE6F5939EBD99@xch-phl-01.he.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <4102273CEB77D211869200805FE6F5939EBD99@xch-phl-01.he.boeing.com>; from Albert.Manfredi@PHL.Boeing.com on Thu, Aug 10, 2000 at 01:42:57PM -0400 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Thu, Aug 10, 2000 at 01:42:57PM -0400, Manfredi, Albert E wrote: > Or am I missing something here? I think the issue is more along the lines of allowing future extenstibility. I.e. if we don't put the "+" in there now then it makes it much harder for us to work around it in the future. Much like the issue surrounding the MIME version header. Its supposed to never change from version 1.0 but it was thought best to put it in there "just in case" we realized something latter. I.e. if you put the "+" in there now it doesn't cause any real pain. But in the future if you want to tell the difference and it isn't there then it makes life really suck.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 14:54:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10258 for ; Thu, 10 Aug 2000 14:54:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26969; Thu, 10 Aug 2000 14:53:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26941 for ; Thu, 10 Aug 2000 14:53:26 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10215 for ; Thu, 10 Aug 2000 14:53:26 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA02409 for ; Thu, 10 Aug 2000 13:53:27 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id NAA07258 for ; Thu, 10 Aug 2000 13:53:26 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Thu, 10 Aug 2000 13:53:12 -0500 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 14:53:11 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBD9B@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'michaelm@netsol.com'" Cc: "'enum@ietf.org'" Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Thu, 10 Aug 2000 14:53:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > -----Original Message----- > From: Michael Mealling [mailto:michael@bailey.dscga.com] > > On Thu, Aug 10, 2000 at 01:42:57PM -0400, Manfredi, Albert E wrote: > > Or am I missing something here? > > I think the issue is more along the lines of allowing future > extenstibility. > I.e. if we don't put the "+" in there now then it makes it much > harder for us to work around it in the future. Much like the issue > surrounding the MIME version header. Its supposed to never change from > version 1.0 but it was thought best to put it in there "just in case" > we realized something latter. > > I.e. if you put the "+" in there now it doesn't cause any real pain. > But in the future if you want to tell the difference and it > isn't there > then it makes life really suck.... [Chuckle.] The counter argument is very simple, however, and has been made a couple of times: use of + does not nearly provide enough flexibility for the future anyway. All that does is make use of e.164 clear. It offers little for growth. It provides few options for specifying _other_ numbering plans. It seems that the consensus is that the actual request is sent to DNS as 1.2.3.4.5.6...7.8.e164.arpa, without a +. If that's the case, then the + issue only applies to how the user types a request in his computer. Let's leave that aside, since it really is not enum material. As far as the DNS goes, the more "obvious" way to handle future non-e164 DNS requests for telephone numbers is to request them to other than e164.arpa. For example, you might type a telephone number in the Italian numbering plan, and that request might go out as 1.2.3.4.5.6...7.8.9.numeri.telecomitalia.it, which might be a server that in turn converts the numbers to e.164 for the request, perhaps. (Or perhaps it only converts to e.164 the requests for international numbers, and returns directly the URIs for Italian numbers.) Point being, the DNS request for e.164 will be easily differentiated from DNS requests for anything different. A + is either not applicable to enum (because it doesn't appear in the actual DNS request), or it is not necessary (if you assume it _should_ appear in the actual DNS query), IMO. Bert albert.e.manfredi@boeing.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 15:09:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11134 for ; Thu, 10 Aug 2000 15:09:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27423; Thu, 10 Aug 2000 15:08:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27342 for ; Thu, 10 Aug 2000 15:08:52 -0400 (EDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11108 for ; Thu, 10 Aug 2000 15:08:52 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Thu, 10 Aug 2000 14:04:18 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 10 Aug 2000 14:06:49 -0500 Message-ID: From: "Jeff Hinchey" To: "Rosbotham, Paul" , "'enum@ietf.org'" Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Thu, 10 Aug 2000 14:06:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C002FE.1E58D1E0" X-Orig: Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C002FE.1E58D1E0 Content-Type: text/plain; charset="iso-8859-1" I agree fully. An E.164 number is by ITU definition a fully qualified, globally unique public number. This implies the number includes the CC. Although national and local numbers may be E.164 compliant and can be prefixed with CC or CC/NDC to form an E.164, they are not E.164 numbers. Nor are private numbers. As Paul suggests, if a number is not in fully qualified E.164 format then it belongs under a different domain and the discussion over the need for a "+" is irrelevant. -----Original Message----- From: Rosbotham, Paul [mailto:Paul.Rosbotham@cwcom.co.uk] Sent: Thursday, August 10, 2000 11:47 AM To: 'enum@ietf.org' Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Not at all an expert on DNS, but would tend to agree with Bert on this. I thought the very fact that the query is to domain e164.arpa indicates that the number is E.164, not a private numbering plan etc. Therefore, the "+" seems redundant. My assumption had been that if a non-E.164 number were offered, a different domain would be used. The E.164 number doesn't contain the "+", it's added for readability reasons to remind the caller that (s)he'd better add 00, 011 or whatever is used locally (mobiles actually let you key "+" in many countries). Internal to the network, the E.164 number carried is just the digits, not with a leading "+". Of course, there is the luxury in the switched network of having a nature of address field to indicate what type of number it is (national or international), but we won't go into that... Andy G is right when he says that the "+" aids readability, but that's at a user interface level and I thought we were talking about protocol internals here. Not going to die in a ditch over this, but it does seem to me that if you have a domain of e164.arpa, e164 numbers only should be used... Paul > -----Original Message----- > From: Manfredi, Albert E [SMTP:Albert.Manfredi@PHL.Boeing.com] > Sent: 10 August 2000 14:49 > To: 'Hong Liu' > Cc: 'enum@ietf.org' > Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt > > > -----Original Message----- > > From: Hong Liu [mailto:lhong@research.telcordia.com] > > > > Andy, > > > > Thanks for the clarification. I agree with you that from a > > user perspective, "+" means > > more than just for readability. > > > > The problem we are discussing here is whether "+" is needed > > for ENUM process given the > > fact that the input is a canonical E.164 number already. I > > would like to hear from you > > and others. Thanks! > > IMO, the + is nice, but isn't enough if we really want to think of this + > as > a way to distinguish e.164 from some other numbering schemes we might want > to implement in DNS the future. > > If the DNS query is made to domain e164.arpa, perhaps use of the + is > redundant and not particularly helful for the future anyway? > > Bert > albert.e.manfredi@boeing.com > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum ********************************************************************** This message may contain information which is confidential or privileged. If you are not the intended recipient, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy. ********************************************************************** _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01C002FE.1E58D1E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt

I agree fully.

An E.164 number is by ITU definition a fully = qualified, globally unique public number. This implies the number = includes the CC. Although national and local numbers may be E.164 = compliant and can be prefixed with CC or CC/NDC to form an E.164, they = are not E.164 numbers. Nor are private numbers.

As Paul suggests, if a number is not in fully = qualified E.164 format then it belongs under a different domain and the = discussion over the need for a "+" is irrelevant.

-----Original Message-----
From: Rosbotham, Paul [mailto:Paul.Rosbotham@cwcom.c= o.uk]
Sent: Thursday, August 10, 2000 11:47 AM
To: 'enum@ietf.org'
Subject: RE: [Enum] Re: = draft-ietf-enum-e164-dns-03.txt


Not at all an expert on DNS, but would tend to agree = with Bert on this.  I
thought the very fact that the query is to domain = e164.arpa indicates that
the number is E.164, not a private numbering plan = etc.  Therefore, the "+"
seems redundant.  My assumption had been that = if a non-E.164 number were
offered, a different domain would be used.

The E.164 number doesn't contain the "+", = it's added for readability reasons
to remind the caller that (s)he'd better add 00, 011 = or whatever is used
locally (mobiles actually let you key "+" = in many countries).  Internal to
the network, the E.164 number carried is just the = digits, not with a leading
"+".  Of course, there is the luxury = in the switched network of having a
nature of address field to indicate what type of = number it is (national or
international), but we won't go into that...

Andy G is right when he says that the "+" = aids readability, but that's at a
user interface level and I thought we were talking = about protocol internals
here.

Not going to die in a ditch over this, but it does = seem to me that if you
have a domain of e164.arpa, e164 numbers only should = be used...

Paul

> -----Original Message-----
> From: Manfredi, Albert E = [SMTP:Albert.Manfredi@PHL.Boeing.com]
> Sent: 10 August 2000 14:49
> To:   'Hong Liu'
> Cc:   'enum@ietf.org'
> Subject:      RE: = [Enum] Re: draft-ietf-enum-e164-dns-03.txt
>
> > -----Original Message-----
> > From: Hong Liu [mailto:lhong@research.telco= rdia.com]
> >
> > Andy,
> >
> > Thanks for the clarification. I agree with = you that from a
> > user perspective, "+" = means
> > more than just for readability.
> >
> > The problem we are discussing here is = whether "+" is needed
> > for ENUM process given the
> > fact that the input is a canonical E.164 = number already. I
> > would like to hear from you
> > and others. Thanks!
>
> IMO, the + is nice, but isn't enough if we = really want to think of this +
> as
> a way to distinguish e.164 from some other = numbering schemes we might want
> to implement in DNS the future.
>
> If the DNS query is made to domain e164.arpa, = perhaps use of the + is
> redundant and not particularly helful for the = future anyway?
>
> Bert
> albert.e.manfredi@boeing.com
>
> = _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum

***************************************************************= *******
This message may contain information which is = confidential or privileged.
If you are not the intended recipient, please advise = the sender immediately
by reply e-mail and delete this message and any = attachments
without retaining a copy. 

***************************************************************= *******

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

------_=_NextPart_001_01C002FE.1E58D1E0-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 15:11:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11234 for ; Thu, 10 Aug 2000 15:11:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27482; Thu, 10 Aug 2000 15:10:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27447 for ; Thu, 10 Aug 2000 15:10:43 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11189 for ; Thu, 10 Aug 2000 15:10:43 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA12537 for ; Thu, 10 Aug 2000 15:10:43 -0400 (EDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA12483; Thu, 10 Aug 2000 15:10:42 -0400 (EDT) Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr) id OAA03216 for ; Thu, 10 Aug 2000 14:10:40 -0500 (CDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id OAA27336; Thu, 10 Aug 2000 14:10:38 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Aug 2000 14:06:03 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F4133704051018@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , BARNOLE Valerie FTRD/DAC/ISS Cc: "'enum@ietf.org'" , "Manfredi, Albert E" , "'Hong Liu'" Date: Thu, 10 Aug 2000 14:06:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Enum] Address completion vs private dialing plans Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I think we are talking about two different things. One is the proper handling of private dialing plans. The second is an implementation of an address completion facility using DNS. We need to distinguish between them. The address completion facility takes a dialed string of digits and applies logic to determine 1) What dialing plan (or local service codes) if any the dialed digits correspond to and 2) what if any prefix needs to be added or stripped to construct a valid and unique number within that dial plan. The example Patrick illustrates A swedish address completion facility. Given that I am in Sweden, I resolve the digits received using the ENUM process using a hard-coded num.se domain. Through the DDDS mechanisms, I eventually get to a "fully qualified" E164 number and begin the ENUM process. Stated more generally, address completion takes as input a topological "location" and an input string and results in a numbering plan identifier and a set of digits unique to that number plan. Of course, this is a fantastic facility, but totally out-of-scope for ENUM except to keep options open for other cool stuff using the same mechanism. So, in the spirit of "+" to keep things open, I believe we need to go a bit deeper. In the general case, the ENUM algoritmn really takes as input both a string of digits and the identifier of the dial-plan in which the digits are unique. The dial plan identifier is used to select the domain suffix for the DNS lookup and to select between various candidate remapping rules. Patrick recognized that the RegExp algorithm needs the dialplan identifier in order to operate as an address completion facility and proposed using "+" as the e164 identifier. I would argue that we should address this need in a more complete way and should explicitly identifing the numbering plan as part of the input to the NAPTR algorithm. So, rather than use +e164digits as the input, why do not we use something like numberingplan+e164digits. This is far more powerful than just looking for a "+" and guessing about which "other" is to be used. This also addresses another complication that arises with the use of DNAMEs in conjunction with NAPTRs. I may arive at the same NAPTR set using numerous paths defined in by my clients dial-plan tables: 2.2.7.2.dal.lucent.com (a 4 digit site-wide extension reached by simply dialing four digits) and 2.2.7.2.1.0.1.lucent.com (A 7 digit corporate location+extension VPN dialing plan reached by dialing 8+location+extension) and 2.2.7.2.3.3.7.2.7.9.nanp.us (the NANP plan reached by dialing 9+10 digits) and 2.2.7.2.3.3.7.2.7.9.1.e164.arpa (The E164 GSTN plan reached by dialing 011+e164 number in the US.) where the e164.arpa, and lucent.com are a Cnames pointing back to 2.2.7.2.dal.lucent.com and nanp.us has a Dname pointing to 1.e164.arpa. Now I can have a set of four NAPTR entries, one with a different re-write for each of the "dialplans". With the numbering plan identified, one could more easily determine which regexp to use where the current proposal would leave you guessing. Greg V. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 15:11:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11245 for ; Thu, 10 Aug 2000 15:11:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27520; Thu, 10 Aug 2000 15:10:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27455 for ; Thu, 10 Aug 2000 15:10:44 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11192 for ; Thu, 10 Aug 2000 15:10:44 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA12575 for ; Thu, 10 Aug 2000 15:10:44 -0400 (EDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA12507; Thu, 10 Aug 2000 15:10:43 -0400 (EDT) Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr) id OAA03231 for ; Thu, 10 Aug 2000 14:10:40 -0500 (CDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id OAA27339; Thu, 10 Aug 2000 14:10:40 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Aug 2000 14:06:05 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F4133704051019@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: michaelm@netsol.com, "Manfredi, Albert E" Cc: "'BARNOLE Valerie FTRD/DAC/ISS'" , =?ISO-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "'enum@ietf.org'" Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Thu, 10 Aug 2000 14:06:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA27456 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit And the MIME-version: 1.0 heading was a major protocol engineering error. Because we did not define how the core MIME spec was supposed to be extended, we are in a situation where the mime-version header must always be present and the version must always be 1.0 and hence, the entire header is now useless bagage. If we intend "+" in ENUM to be for future extensibility, we need to clearly understand how it is to be used to extend the protocol. Greg V. -----Original Message----- From: Michael Mealling [mailto:michael@bailey.dscga.com] Sent: Thursday, August 10, 2000 12:51 PM To: Manfredi, Albert E Cc: 'BARNOLE Valerie FTRD/DAC/ISS'; 'Patrik Fältström'; 'enum@ietf.org' Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt On Thu, Aug 10, 2000 at 01:42:57PM -0400, Manfredi, Albert E wrote: > Or am I missing something here? I think the issue is more along the lines of allowing future extenstibility. I.e. if we don't put the "+" in there now then it makes it much harder for us to work around it in the future. Much like the issue surrounding the MIME version header. Its supposed to never change from version 1.0 but it was thought best to put it in there "just in case" we realized something latter. I.e. if you put the "+" in there now it doesn't cause any real pain. But in the future if you want to tell the difference and it isn't there then it makes life really suck.... -MM -- ---------------------------------------------------------------------------- ---- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 15:13:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11276 for ; Thu, 10 Aug 2000 15:13:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27623; Thu, 10 Aug 2000 15:13:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27594 for ; Thu, 10 Aug 2000 15:13:23 -0400 (EDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11273 for ; Thu, 10 Aug 2000 15:13:22 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id PAA02400; Thu, 10 Aug 2000 15:03:06 -0400 (EDT) Date: Thu, 10 Aug 2000 15:03:06 -0400 From: Michael Mealling To: "Manfredi, Albert E" Cc: "'michaelm@netsol.com'" , "'enum@ietf.org'" Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Message-ID: <20000810150305.V1365@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <4102273CEB77D211869200805FE6F5939EBD9B@xch-phl-01.he.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <4102273CEB77D211869200805FE6F5939EBD9B@xch-phl-01.he.boeing.com>; from Albert.Manfredi@PHL.Boeing.com on Thu, Aug 10, 2000 at 02:53:10PM -0400 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Thu, Aug 10, 2000 at 02:53:10PM -0400, Manfredi, Albert E wrote: > > -----Original Message----- > > From: Michael Mealling [mailto:michael@bailey.dscga.com] > > > > On Thu, Aug 10, 2000 at 01:42:57PM -0400, Manfredi, Albert E wrote: > > > Or am I missing something here? > > > > I think the issue is more along the lines of allowing future > > extenstibility. > > I.e. if we don't put the "+" in there now then it makes it much > > harder for us to work around it in the future. Much like the issue > > surrounding the MIME version header. Its supposed to never change from > > version 1.0 but it was thought best to put it in there "just in case" > > we realized something latter. > > > > I.e. if you put the "+" in there now it doesn't cause any real pain. > > But in the future if you want to tell the difference and it > > isn't there > > then it makes life really suck.... > > [Chuckle.] > > The counter argument is very simple, however, and has been made a couple of > times: use of + does not nearly provide enough flexibility for the future > anyway. All that does is make use of e.164 clear. It offers little for > growth. It provides few options for specifying _other_ numbering plans. By itself, yes. > It seems that the consensus is that the actual request is sent to DNS as > 1.2.3.4.5.6...7.8.e164.arpa, without a +. If that's the case, then the + > issue only applies to how the user types a request in his computer. Let's > leave that aside, since it really is not enum material. Sure. But the plus is stripped before that. Its not the DNS stuff that is using the "+" its the NAPTR rewrite rule. The regular expression is applied to the original, non-DNS encoded number. The issue is whether you want to remove the plus from _that_ string. > As far as the DNS goes, the more "obvious" way to handle future non-e164 DNS > requests for telephone numbers is to request them to other than e164.arpa. > For example, you might type a telephone number in the Italian numbering > plan, and that request might go out as > 1.2.3.4.5.6...7.8.9.numeri.telecomitalia.it, which might be a server that in > turn converts the numbers to e.164 for the request, perhaps. (Or perhaps it > only converts to e.164 the requests for international numbers, and returns > directly the URIs for Italian numbers.) > > Point being, the DNS request for e.164 will be easily differentiated from > DNS requests for anything different. A + is either not applicable to enum > (because it doesn't appear in the actual DNS request), or it is not > necessary (if you assume it _should_ appear in the actual DNS query), IMO. The issue isn't really evident during the first iteration through the DDDS algorithm. Its more evident and useful if the NAPTR record does not contain a "u" flag and thus indicates that the output of the regular expression is NOT an ENUM endpoint but a new domain-name for which more NAPTR records will be requested. These new domain-names may not be in the e164.arpa zone so you may have cross over with other numbering schemes. This is specifically warned about in the DDDS DNS doc and its suggested solution is to just not delegate two rewrite paths into the same zone. But having the plus in the number that is used as the input to the rewrite rule is a good way to make sure this doesn't happen. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 15:14:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11305 for ; Thu, 10 Aug 2000 15:14:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27696; Thu, 10 Aug 2000 15:14:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27671 for ; Thu, 10 Aug 2000 15:14:28 -0400 (EDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11302 for ; Thu, 10 Aug 2000 15:14:27 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id PAA02411; Thu, 10 Aug 2000 15:04:01 -0400 (EDT) Date: Thu, 10 Aug 2000 15:04:01 -0400 From: Michael Mealling To: "Vaudreuil, Greg M (Greg)" Cc: michaelm@netsol.com, "Manfredi, Albert E" , "'BARNOLE Valerie FTRD/DAC/ISS'" , "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , "'enum@ietf.org'" Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Message-ID: <20000810150401.W1365@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <6B57F36F4FF9D111B30A0008C7F4133704051019@exdal1.ons.octel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <6B57F36F4FF9D111B30A0008C7F4133704051019@exdal1.ons.octel.com>; from gregv@lucent.com on Thu, Aug 10, 2000 at 02:06:04PM -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Thu, Aug 10, 2000 at 02:06:04PM -0500, Vaudreuil, Greg M (Greg) wrote: > And the MIME-version: 1.0 heading was a major protocol engineering error. > Because we did not define how the core MIME spec was supposed to be > extended, we are in a situation where the mime-version header must always be > present and the version must always be 1.0 and hence, the entire header is > now useless bagage. If we intend "+" in ENUM to be for future > extensibility, we need to clearly understand how it is to be used to extend > the protocol. 100% aggreement on that one! -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 15:35:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11926 for ; Thu, 10 Aug 2000 15:35:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28423; Thu, 10 Aug 2000 15:35:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28397 for ; Thu, 10 Aug 2000 15:34:59 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11884 for ; Thu, 10 Aug 2000 15:34:58 -0400 (EDT) Received: from [193.150.248.21] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id MAA13166; Thu, 10 Aug 2000 12:34:13 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <6B57F36F4FF9D111B30A0008C7F4133704051018@exdal1.ons.octel.com> References: <6B57F36F4FF9D111B30A0008C7F4133704051018@exdal1.ons.octel.com> Date: Thu, 10 Aug 2000 21:31:19 +0200 To: "Vaudreuil, Greg M (Greg)" , BARNOLE Valerie FTRD/DAC/ISS From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: "'enum@ietf.org'" , "Manfredi, Albert E" , "'Hong Liu'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: Address completion vs private dialing plans Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 14.06 -0500 00-08-10, Vaudreuil, Greg M (Greg) wrote: >So, rather than use +e164digits as the input, why do not we use something >like numberingplan+e164digits. This is far more powerful than just looking >for a "+" and guessing about which "other" is to be used. This is exactly what I am after, but didn't want to specify _how_ the private numbering plan was specified. I think what Greg suggests is an interesting example, especially with the "numberingplan" string being empty for E.164. Reason for the latter is that I explicitly am stubborn as this document is in last call, and IF we find a solution to this without doing fundamental changes to the document (such as removing the '+') then the document can become an RFC _really_soon_now_. Else, we have to reissue the last call. Not an argument for not doing "the right thing", but an argument to _really_ verify whether we want to start "all over again". I know all of you want to implement this and get some experience! I am _not_ a party which implements this scheme. I am just the editor and want to have things done so I can do other things (like being Area Director for Applications Area :-). I.e. the '+' has been there in the NAPTR algorithm all along, so it is not anything new. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 15:35:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11937 for ; Thu, 10 Aug 2000 15:35:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28464; Thu, 10 Aug 2000 15:35:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28436 for ; Thu, 10 Aug 2000 15:35:02 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11886 for ; Thu, 10 Aug 2000 15:35:02 -0400 (EDT) Received: from [193.150.248.21] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id MAA13093; Thu, 10 Aug 2000 12:34:02 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <4102273CEB77D211869200805FE6F5939EBD9B@xch-phl-01.he.boeing.com> References: <4102273CEB77D211869200805FE6F5939EBD9B@xch-phl-01.he.boeing.com> Date: Thu, 10 Aug 2000 21:27:02 +0200 To: "Manfredi, Albert E" , "'michaelm@netsol.com'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Cc: "'enum@ietf.org'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 14.53 -0400 00-08-10, Manfredi, Albert E wrote: >It seems that the consensus is that the actual request is sent to DNS as >1.2.3.4.5.6...7.8.e164.arpa, without a +. If that's the case, then the + >issue only applies to how the user types a request in his computer. Let's >leave that aside, since it really is not enum material. You have to differ between the DNS request and what is the input to the NAPTR algorithm. In DNS we have no '+', in the NAPTR algorithm we have. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 15:39:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12003 for ; Thu, 10 Aug 2000 15:39:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28552; Thu, 10 Aug 2000 15:39:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28524 for ; Thu, 10 Aug 2000 15:39:15 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11997 for ; Thu, 10 Aug 2000 15:39:13 -0400 (EDT) Received: from research.telcordia.com (lhong-pc [192.4.8.89]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7AJcQR17294; Thu, 10 Aug 2000 15:38:26 -0400 (EDT) Message-ID: <399304B2.2BC80CD7@research.telcordia.com> Date: Thu, 10 Aug 2000 15:38:26 -0400 From: Hong Liu X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: "Manfredi, Albert E" , "'enum@ietf.org'" , michaelm@netsol.com, james.yu@neustar.com Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt References: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> <3992CDE9.1A658D6A@research.telcordia.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik, Mike and others, It seems that the discussion on whether '+' is needed in ENUM algorithm leads to the issue of extensibility of ENUM algorithm for other applications. The question here is how to differentiate one resolution service from another, when the NAPTR RRs for different services are hosted by the same server. For the sake of simplicity, lets assume that all resolution services are concerned about mapping a number to a set of URIs using NAPTR. They differ with the numbering plans each deals with. I have seen two proposals so far: (1) The one proposed by Patrik. The essence of this proposal is to distinguish each service by prepending a service-specific string before the number. In this case, the ENUM service, which deals with fully qualified E.164 numbers, will use '+' as the distinguishing flag. In fact, it could be anything as long as it is unique for E.164 identification. Along this line, you may want to prepend a string 'imsi' for E.212 and 'gtt' for E.214, ... etc. The key points for this proposal are: (a) For each service, the Application Unique String (using DDDS terminology) structure is different by the service-specific prefix. (b) The substitution regexp can be fine tuned to each specific service using the service-specific prefix. (2) The second proposal by me is to treat all numbers, be it E.164 or others, as a sequence of digits. The service will be differentiate from the 'rs' field of the NAPTR record. In this case, we will have E2U for E.164, IMSI2U for E.212, GTT2U for E.214,... etc. So the key points here are: (a) The Application Unique String will have the same structure, just a sequence of digits without any service-specific prefix. (This is what I meant by uniform in a previous email.) (b) Services are differentiated by the 'rs' field in the NAPTR RRs. In many cases, the substitution regexp will be the same for all numbering plans, i.e. always matched. Both approaches accomplish the same goal, though I personally think the second proposal is a cleaner way to enable extensibility for ENUM mechanisms. But I would like to hear from the list how other people think. It is no longer the '+' issue, it is the service extensibility and differentiation issue. Note that both proposals requires that the client have a priori knowledge about which service to request from a given the number, i.e., which name space to query. The only difference is that in (1) the client needs to translate this knowledge to a service specific prefix, while in (2) the client needs to translate this knowledge to a service code point in 'rs'. The standardization of both the prefix and the code point are equally tricky. Provisioning of NATPR RRs for (2) MAY be simpler for regexp. It also allows aggregation of services, say "mailto+E2U+IMSI2U+SE2U" when you want different numbering plans all converge on sending a email to you. Anyway, I will stop here. --Hong Patrik Fältström wrote: > >I acknowledge the need to distinguish the services by the way a phone number > >is presented, but I would argue that by just putting a '+' for an E.164 > >number is not sufficient to address the need. How are you going to tell one > >non-E164 number from another non-E164 number? In this case, '+' will not be > >able to do much. > > They can for each numbering plan tell exactly what input string they > are using for their version of the NAPTR algorithm. My personal one > might be "Take the number, add the string 'paf' in front of the > digits" in step 2, so the number "42" (I only have 2 digits in the > phone numbers in my numbering plan) will be turned into "paf42" > before starting matching in regexp in NAPTRs. > > >To solve this problem, I would suggest that we use the 'rs' field instead. > >This proposal builds on the emails from both James Yu and Al Manfredi. > >Specifically, 'E2U' is currently defined for ENUM. For other numbering plans, > >others can also define 'E212toU' for IMSI, 'E214toU' for global title, > >'UPT2U' for UPT number, 'SE2U' for national numbers in Sweden, etc... Of > >course, this is an idea, the exact details need to be worked out. The point > >here is each additional service can be distinguished by defining a new > >service code point in 'rs'. > > Ok. > > >By reading the DDDS algorithm in draft-ietf-urn-ddds-00.txt, the application > >MUST check the services field after the substitution to decide whether the > >resulting string. > > That is absolutely correct. > > >This proposal has the following advantages: First, this provides an > >extensible way of using ENUM in many other similar applications without > >clashing the name space. Second, it helps to tell people why it is important > >to define E2U in ENUM. Third, by removing '+' specifically for E.164, it > >makes the ENUM algorithm uniform in treating any numbering plans. However, it > >has one disadvantage: the resolution system may need to return all the NAPTR > >RRs to the application. > > It always pass back all NAPTRs. > > And, I still don't understand why we should not follow the > recommendation from ITU. > > Is it because you don't want to include the '+' in the regexp? > > Is it because you feel "!.*!mailto:kalle@foo.se!" is weird when it > tries to match "+468978777", and that matching "468978777" is better? > > I.e. you say "Third, by removing '+' specifically for E.164, it makes > the ENUM algorithm uniform in treating any numbering plans.". > > I don't get this. ITU have asked the '+ to be there first of all, and > secondly I ask how it can become "uniform"? > > >But since it normally at the last step of the > >resolution process, I would not expect too many records to be returned for a > >particular 'user'. > > paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 15:43:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12052 for ; Thu, 10 Aug 2000 15:43:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28674; Thu, 10 Aug 2000 15:42:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28637 for ; Thu, 10 Aug 2000 15:42:43 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12043 for ; Thu, 10 Aug 2000 15:42:43 -0400 (EDT) Received: from [193.150.248.21] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id MAA14698; Thu, 10 Aug 2000 12:38:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 10 Aug 2000 21:36:09 +0200 To: "Jeff Hinchey" , "Rosbotham, Paul" , "'enum@ietf.org'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 14.06 -0500 00-08-10, Jeff Hinchey wrote: >As Paul suggests, if a number is not in fully qualified E.164 format >then it belongs under a different domain and the discussion over the >need for a "+" is irrelevant. No, as the NAPTR might not give back an endpoint, but instead the rewrite will give back a domainname which a _new_ NAPTR query is to queried for. So, just because the first NAPTR have a name in a certain domain doesn't mean that the leaf node NAPTR you finally get back is in the same domain. The whole idea with NAPTR and the recursive algorithm is that one can and should reuse records in DNS. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Aug 10 23:54:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22527 for ; Thu, 10 Aug 2000 23:54:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04050; Thu, 10 Aug 2000 23:53:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04024 for ; Thu, 10 Aug 2000 23:53:54 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22523 for ; Thu, 10 Aug 2000 23:53:53 -0400 (EDT) Received: from [193.150.248.21] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id UAA25153; Thu, 10 Aug 2000 20:52:40 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <399304B2.2BC80CD7@research.telcordia.com> References: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> <3992CDE9.1A658D6A@research.telcordia.com> <399304B2.2BC80CD7@research.telcordia.com> Date: Fri, 11 Aug 2000 05:32:03 +0200 To: Hong Liu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Cc: "Manfredi, Albert E" , "'enum@ietf.org'" , michaelm@netsol.com, james.yu@neustar.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 15.38 -0400 00-08-10, Hong Liu wrote: >(2) The second proposal by me is to treat all numbers, be it E.164 >or others, as a >sequence of digits. The service will be differentiate from the 'rs' >field of the >NAPTR record. In this case, we will have E2U for E.164, IMSI2U for >E.212, GTT2U >for E.214,... etc. Two things: (1) I am not saying you should not do this (aswell). What myself and Michael says is that it is unnessecary to remove the ability to distinguish in the regexp between numbering plans (2) This I-D is for _proposed_ standard, next step is draft standard. The distinction between them is as follows (see RFC 2026): Proposed Standard: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. Draft Standard: A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. Elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful. The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. The Working Group chair is responsible for documenting the specific implementations which qualify the specification for Draft or Internet Standard status along with documentation about testing of the interoperation of these implementations. The documentation must include information about the support of each of the individual options and features. This documentation should be submitted to the Area Director with the protocol action request. (see Section 6) A Draft Standard must be well-understood and known to be quite stable, both in its semantics and as a basis for developing an implementation. A Draft Standard may still require additional or more widespread field experience, since it is possible for implementations based on Draft Standard specifications to demonstrate unforeseen behavior when subjected to large-scale use in production environments. A Draft Standard is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered. In most circumstances, it is reasonable for vendors to deploy implementations of Draft Standards into a disruption sensitive environment. So, if I am wrong, we can "fix" this when we have more experience, when someone have written something about (I see these documents missing): - Use of LDAP as second step in E.164 resolution on the internet after the ENUM resolution (among others, VPIM people want this) - Use of ENUM-like services when having a closed numbering plan - Use of ENUM-like services with "sub-addressing" (or whatever it is called) - Use of ENUM in various countries (like USA and Sweden) where different schemes of number portability is in use already - The DDDS documents ready I would not be surprised if we need to change things before going to "draft" standard, and maybe we even have to restart at "proposed". I think this whole debate is premature, and that we today need the I-D as RFC so people can implement this stuff, so we get the experience we need to produce the next round of documents in the IETF (not necessary in the ENUM wg). As it is today, this spec is only an I-D which is a living target, can not be referenced, and because of that it is hard for for example the VPIM people to really start working on what they have knowledge about. Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 07:09:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09220 for ; Fri, 11 Aug 2000 07:09:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14469; Fri, 11 Aug 2000 07:09:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14393 for ; Fri, 11 Aug 2000 07:08:58 -0400 (EDT) Received: from p-mail2.cnet.fr ([192.144.74.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09209 for ; Fri, 11 Aug 2000 07:08:58 -0400 (EDT) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Aug 2000 13:08:23 +0200 Message-ID: <98388C05D464D111B61800805F1504160123E893@p-ibis.issy.cnet.fr> From: BARNOLE Valerie FTRD/DAC/ISS To: "'Vaudreuil, Greg M (Greg)'" Cc: "'enum@ietf.org'" , "Manfredi, Albert E" , "'Hong Liu'" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: RE: [Enum] Address completion vs private dialing plans Date: Fri, 11 Aug 2000 13:08:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA14394 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Greg, you're right in distinguishing both issues. A few considerations I have : 1)Even if the matter of identifying the numbering plan is not the hardcore of ENUM WG work, I think it is an important issue for the development of ENUM services. By now, I just don't figure out which is the best way to proceed for the dialling user (the calling party)and I do not know where is the best place/mailing list to discuss it. Maybe the solution can be proprietary to a computer manufacturer or to a telco. I really just do not have in mind all the possibilities. 2)To the US examples you quoted, I would add : 2.2.7.2.3.3.7.2.7.9.telcosp.us (the [local loop ?] telco subscribers or telecommunications service provider's plan reached by dialing 9+ 10 digits of this telco/sp subscribers' numbers) 3)I agree with what you say : "Stated more generally, address completion takes as input a topological "location" and an input string and results in a numbering plan identifier and a set of digits unique to that number plan. Of course, this is a fantastic facility, but totally out-of-scope for ENUM except to keep options open for other cool stuff using the same mechanism." I think this input of topological "location" will have to be looked at carefully according to mobility, I think in another WG or in relationship with another WG. The important thing is indeed to keep ENUM open, because it is the key to its widespread use in my opinion. end of message _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Valérie Barnole FTR&D/DAC/ACE tel. : + 33 1 45 29 58 39 fax : + 33 1 46 29 31 42 mail to : valerie.barnole@francetelecom.fr -----Message d'origine----- De: Vaudreuil, Greg M (Greg) [mailto:gregv@lucent.com] Date: jeudi 10 août 2000 21:06 À: Patrik Fältström; BARNOLE Valerie FTRD/DAC/ISS Cc: 'enum@ietf.org'; Manfredi, Albert E; 'Hong Liu' Objet: [Enum] Address completion vs private dialing plans I think we are talking about two different things. One is the proper handling of private dialing plans. The second is an implementation of an address completion facility using DNS. We need to distinguish between them. The address completion facility takes a dialed string of digits and applies logic to determine 1) What dialing plan (or local service codes) if any the dialed digits correspond to and 2) what if any prefix needs to be added or stripped to construct a valid and unique number within that dial plan. The example Patrick illustrates A swedish address completion facility. Given that I am in Sweden, I resolve the digits received using the ENUM process using a hard-coded num.se domain. Through the DDDS mechanisms, I eventually get to a "fully qualified" E164 number and begin the ENUM process. Stated more generally, address completion takes as input a topological "location" and an input string and results in a numbering plan identifier and a set of digits unique to that number plan. Of course, this is a fantastic facility, but totally out-of-scope for ENUM except to keep options open for other cool stuff using the same mechanism. So, in the spirit of "+" to keep things open, I believe we need to go a bit deeper. In the general case, the ENUM algoritmn really takes as input both a string of digits and the identifier of the dial-plan in which the digits are unique. The dial plan identifier is used to select the domain suffix for the DNS lookup and to select between various candidate remapping rules. Patrick recognized that the RegExp algorithm needs the dialplan identifier in order to operate as an address completion facility and proposed using "+" as the e164 identifier. I would argue that we should address this need in a more complete way and should explicitly identifing the numbering plan as part of the input to the NAPTR algorithm. So, rather than use +e164digits as the input, why do not we use something like numberingplan+e164digits. This is far more powerful than just looking for a "+" and guessing about which "other" is to be used. This also addresses another complication that arises with the use of DNAMEs in conjunction with NAPTRs. I may arive at the same NAPTR set using numerous paths defined in by my clients dial-plan tables: 2.2.7.2.dal.lucent.com (a 4 digit site-wide extension reached by simply dialing four digits) and 2.2.7.2.1.0.1.lucent.com (A 7 digit corporate location+extension VPN dialing plan reached by dialing 8+location+extension) and 2.2.7.2.3.3.7.2.7.9.nanp.us (the NANP plan reached by dialing 9+10 digits) and 2.2.7.2.3.3.7.2.7.9.1.e164.arpa (The E164 GSTN plan reached by dialing 011+e164 number in the US.) where the e164.arpa, and lucent.com are a Cnames pointing back to 2.2.7.2.dal.lucent.com and nanp.us has a Dname pointing to 1.e164.arpa. Now I can have a set of four NAPTR entries, one with a different re-write for each of the "dialplans". With the numbering plan identified, one could more easily determine which regexp to use where the current proposal would leave you guessing. Greg V. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 09:43:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15532 for ; Fri, 11 Aug 2000 09:43:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15938; Fri, 11 Aug 2000 09:30:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15913 for ; Fri, 11 Aug 2000 09:30:42 -0400 (EDT) Received: from cqmx.corp.comsat.com (cqmx.corp.comsat.com [134.133.184.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14673 for ; Fri, 11 Aug 2000 09:30:42 -0400 (EDT) From: Andrew.Gallant@comsat.com Received: from cqgate5.cmc.comsat.com ([134.133.162.20]) by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Fri, 11 Aug 2000 09:29:11 -0400 Received: from ccMail by cqgate5.cmc.comsat.com (IMA Internet Exchange 3.13) id 000F2F3E; Fri, 11 Aug 2000 09:32:29 -0400 Mime-Version: 1.0 Date: Fri, 11 Aug 2000 09:27:48 -0400 Message-ID: <000F2F3E.C22277@comsat.com> To: enum@ietf.org Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit Subject: [Enum] follow-ups - some post-presentation data Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Here are two follow-ups on the E.164 and NP presentations to the enum wg session last week in Pittsburgh. They are: - Brief history of E.164 publication, and - Q-series recs/supps on NP from SG11. 1. Brief history of E.164 publication (based on information in the current version, the fourth issue, dated 05/97): - Rec E.163, first issue 1964. - Rec E.164, revised at all subsequent Plenary Assemblies. - Rec E.163, merged with Recommendation E.164 in 1991. - Rec E.164, first issue 1984, in a Red Book fascicle. - Rec E.164, second issue 1988, in a Blue Book fascicle. - Rec E.164, third issue 1991, as an individual document, and merged with Recommendation E.163. - Rec E.164, fourth issue 1997, incorporates Recs E.160 and E.162. In 1997, Rec. E.164 itself did not contain the list of E.164 country codes. That list is maintained separately as an Annex to the series of Operational Bulletins. 2. There are two recommendations and three supplements in the Q-series from SG11. The five documents are: - Rec. Q.769.1 (12/99), "Signalling System No. 7 - ISDN user part enhancements for the support of number portability", 24 pages. - Rec. Q.2769.1 (06/00), "Support of number portability information across B-ISUP", 14 pages. - Supp. 3 (05/98) to Series Q, "Number portability - Scope and capability set 1 architecture", 48 pages. - Supp. 4 (05/98) to Series Q, "Number portability - Capability set 1 requirements for service provider portability (All call query and Onward routing)", 28 pages. - Supp. 5 (03/99) to Series Q, "Number portability - Capability set 2 requirements for service provider portability (Query on release and Dropback)", 48 pages. More information can be found at the ITU web site. -Andy (andrew.gallant@lmco.com) _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 10:39:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19983 for ; Fri, 11 Aug 2000 10:39:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17479; Fri, 11 Aug 2000 10:39:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17452 for ; Fri, 11 Aug 2000 10:39:41 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19968 for ; Fri, 11 Aug 2000 10:39:39 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d24.cc.telcordia.com [128.96.11.24] (may be forged)) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7BEXpR27690; Fri, 11 Aug 2000 10:33:52 -0400 (EDT) Message-ID: <39940ED0.64F7DCEF@research.telcordia.com> Date: Fri, 11 Aug 2000 10:33:52 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: "Manfredi, Albert E" , "'enum@ietf.org'" , michaelm@netsol.com, james.yu@neustar.com Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt References: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> <3992CDE9.1A658D6A@research.telcordia.com> <399304B2.2BC80CD7@research.telcordia.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik, I would like to clarify a few points here: (1) I am as interested as anyone else on the list to move the protocol spec into the RFC status, so that everybody can implement. We are implementing it now. (2) In the spirit of moving forward, the changes I proposed can be accommodated in the next revision of this document. (3) Regarding the current document, the only change I suggested, including a few others, is just to remove the '+' from the input string. This is _not_ a very significant change. I don't see it in anyway will delay the document from becoming an RFC because of that. (4) Even if you go with the prefix+digits scheme, you still need to define new service code for usage of ENUM in a non-E164 case, since E2U as currently defined, only works for E.164 to URI mapping. In that sense, the two proposals may complement each other as a last resort. The bottom line: if the document is just for E.164 number mapping, the '+' part is redundant. Since you suggested that we delay consideration of using ENUM in other scenarios, then any hook, such as '+', should be removed to leave this issue open for future considerations. As many people pointed out on the list, '+' is just a kludge for a bigger problem of service differentiation. --Hong Patrik Fältström wrote: > Two things: > > (1) I am not saying you should not do this (aswell). What myself and > Michael says is that it is unnessecary to remove the ability to > distinguish in the regexp between numbering plans > > (2) This I-D is for _proposed_ standard, next step is draft standard. > > The distinction between them is as follows (see RFC 2026): > > I would not be surprised if we need to change things before going to > "draft" standard, and maybe we even have to restart at "proposed". > > I think this whole debate is premature, and that we today need the > I-D as RFC so people can implement this stuff, so we get the > experience we need to produce the next round of documents in the IETF > (not necessary in the ENUM wg). As it is today, this spec is only an > I-D which is a living target, can not be referenced, and because of > that it is hard for for example the VPIM people to really start > working on what they have knowledge about. > > Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 10:50:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20696 for ; Fri, 11 Aug 2000 10:50:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17792; Fri, 11 Aug 2000 10:49:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17763 for ; Fri, 11 Aug 2000 10:49:01 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20592 for ; Fri, 11 Aug 2000 10:49:00 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA20245 for ; Fri, 11 Aug 2000 10:49:01 -0400 (EDT) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA20135; Fri, 11 Aug 2000 10:48:59 -0400 (EDT) Received: from buzz.ons.octel.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr) id KAA05668 for ; Fri, 11 Aug 2000 10:48:57 -0400 (EDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id JAA29605; Fri, 11 Aug 2000 09:48:56 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Aug 2000 09:44:23 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F4133704051041@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Hong Liu Cc: "Manfredi, Albert E" , "'enum@ietf.org'" , michaelm@netsol.com, james.yu@neustar.com Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Fri, 11 Aug 2000 09:44:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA17764 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I believe the core ENUM specification is now receiving the significant community review it deserves as the community begins to understand this rather complex protocol. (ENUM is depenent upon DNS and NAPTR, both complex entities in their own rights.) There are open questions about a few known design choices. It is unfortuate that this discussion has begun in earnest only after the submission to the IESG for last call. However, late as it may be, I believe we must still address the questions concerning the design choices, and if necessary, make changes to the specification. While changes may be introduced after proposed standard, our history suggests that substantial changes can only be made if the origional protocol is a failure and has seen little use. If limited sucess is achieved, then we are stuck with patching deficiencies in a backward compatable manner, usually by adding otherwise unnecessary complexity and resulting interoperability difficulty. ENUM is a "core" application protocol that is expected to be used by many important new applications. It certianly is one that "materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet". By this observation, I do not suggest that we need to wait for implementation experience, but it is certianly worth putting forth a well understood proposal. How the protocol is extended is an especially important thing to understand and document before implementations are deployed that preclude anticipated extensions. Greg V. -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Thursday, August 10, 2000 10:32 PM To: Hong Liu Cc: Manfredi, Albert E; 'enum@ietf.org'; michaelm@netsol.com; james.yu@neustar.com Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt At 15.38 -0400 00-08-10, Hong Liu wrote: >(2) The second proposal by me is to treat all numbers, be it E.164 >or others, as a >sequence of digits. The service will be differentiate from the 'rs' >field of the >NAPTR record. In this case, we will have E2U for E.164, IMSI2U for >E.212, GTT2U >for E.214,... etc. Two things: (1) I am not saying you should not do this (aswell). What myself and Michael says is that it is unnessecary to remove the ability to distinguish in the regexp between numbering plans (2) This I-D is for _proposed_ standard, next step is draft standard. The distinction between them is as follows (see RFC 2026): Proposed Standard: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that "materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet". A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. Draft Standard: A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. Elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful. The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. The Working Group chair is responsible for documenting the specific implementations which qualify the specification for Draft or Internet Standard status along with documentation about testing of the interoperation of these implementations. The documentation must include information about the support of each of the individual options and features. This documentation should be submitted to the Area Director with the protocol action request. (see Section 6) A Draft Standard must be well-understood and known to be quite stable, both in its semantics and as a basis for developing an implementation. A Draft Standard may still require additional or more widespread field experience, since it is possible for implementations based on Draft Standard specifications to demonstrate unforeseen behavior when subjected to large-scale use in production environments. A Draft Standard is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered. In most circumstances, it is reasonable for vendors to deploy implementations of Draft Standards into a disruption sensitive environment. So, if I am wrong, we can "fix" this when we have more experience, when someone have written something about (I see these documents missing): - Use of LDAP as second step in E.164 resolution on the internet after the ENUM resolution (among others, VPIM people want this) - Use of ENUM-like services when having a closed numbering plan - Use of ENUM-like services with "sub-addressing" (or whatever it is called) - Use of ENUM in various countries (like USA and Sweden) where different schemes of number portability is in use already - The DDDS documents ready I would not be surprised if we need to change things before going to "draft" standard, and maybe we even have to restart at "proposed". I think this whole debate is premature, and that we today need the I-D as RFC so people can implement this stuff, so we get the experience we need to produce the next round of documents in the IETF (not necessary in the ENUM wg). As it is today, this spec is only an I-D which is a living target, can not be referenced, and because of that it is hard for for example the VPIM people to really start working on what they have knowledge about. Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 10:50:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20707 for ; Fri, 11 Aug 2000 10:50:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17837; Fri, 11 Aug 2000 10:49:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17807 for ; Fri, 11 Aug 2000 10:49:05 -0400 (EDT) Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20596 for ; Fri, 11 Aug 2000 10:49:03 -0400 (EDT) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA24030 for ; Fri, 11 Aug 2000 10:49:04 -0400 (EDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA23989; Fri, 11 Aug 2000 10:49:03 -0400 (EDT) Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr) id JAA29368 for ; Fri, 11 Aug 2000 09:48:59 -0500 (CDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id JAA29611; Fri, 11 Aug 2000 09:49:00 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Aug 2000 09:44:26 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F4133704051042@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: BARNOLE Valerie FTRD/DAC/ISS Cc: "'enum@ietf.org'" , "Manfredi, Albert E" , "'Hong Liu'" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: RE: [Enum] Address completion vs private dialing plans Date: Fri, 11 Aug 2000 09:44:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA17810 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Not seeing any dissent, I see at least two uses of the ENUM mechanism (DNS+NAPTR) beyond the resolution of E.164 numbers. I argue the ENUM document should be clear enough to ensure that these applications are not precluded in the future. 1) resolution of private dial plans 2) Address completion For the use with private dialing plans, we have a strawman proposal to use the + as a separator between a dialplan identifier and the digits of the dialplan. In the current context, having a bare "+" signifies the default dialing plan, E.164. Clearly NATPRs for both private dialing plans and for public dialing plans can coexist at the same node in the DNS tree. In this case, the ENUM document should be very clear what should happen if a client encounters one or more NAPTR records that match something other than a bare "+". I understand the Regexp will simply not match the initial key and the entry will be ignored.... is this the case? Without text, implementations may assume only NAPTRs that operate on E164 numbers will be returned and never use the RegExp for matching, only doing the obvious simplification to select the appropriate NAPTR on service, order, and preference only. Note, I am not asking for specification of numbering plans, simply ensuring that they can be added using at least the current strawman proposal. For use as an address completion facility, we have a proposal that would use NAPTR rewrite rules and itteration to transform an incomplete number into a complete number in some dialing plan such as e164. It is not clear to me if a separate delimiter is needed from "+" to distinguish matches on an incomplete number vs a complete number in a defined numbering plan. I hope Patrick can provide greater clarity to his proposal for exactly how a client can identify whether it needs to apply itteration..... My guess is that this application will not clash with ENUM because 1) It uses a set of distinguished topological doman suffixes e.g., num.se and 2) Non-terminal e.g., other than "u", status flags are illegal in ENUM, and 3) the client clearly understands it is not using a complete telephone number (private or public). From my understanding, NATPRs for address completion and for ENUM resolution should never occure at the same node in the DNS tree. If this is so, then we can simply clarify the existing document with no protocol changes. (unless we want another less-ambigious separator character than "+" or we see value in explicit designation of the e164 numbering plan.) Comments? Greg V. -----Original Message----- From: BARNOLE Valerie FTRD/DAC/ISS [mailto:valerie.barnole@rd.francetelecom.fr] Sent: Friday, August 11, 2000 6:08 AM To: Vaudreuil, Greg M (Greg) Cc: 'enum@ietf.org'; Manfredi, Albert E; 'Hong Liu'; Patrik Fältström Subject: RE: [Enum] Address completion vs private dialing plans Greg, you're right in distinguishing both issues. A few considerations I have : 1)Even if the matter of identifying the numbering plan is not the hardcore of ENUM WG work, I think it is an important issue for the development of ENUM services. By now, I just don't figure out which is the best way to proceed for the dialling user (the calling party)and I do not know where is the best place/mailing list to discuss it. Maybe the solution can be proprietary to a computer manufacturer or to a telco. I really just do not have in mind all the possibilities. 2)To the US examples you quoted, I would add : 2.2.7.2.3.3.7.2.7.9.telcosp.us (the [local loop ?] telco subscribers or telecommunications service provider's plan reached by dialing 9+ 10 digits of this telco/sp subscribers' numbers) 3)I agree with what you say : "Stated more generally, address completion takes as input a topological "location" and an input string and results in a numbering plan identifier and a set of digits unique to that number plan. Of course, this is a fantastic facility, but totally out-of-scope for ENUM except to keep options open for other cool stuff using the same mechanism." I think this input of topological "location" will have to be looked at carefully according to mobility, I think in another WG or in relationship with another WG. The important thing is indeed to keep ENUM open, because it is the key to its widespread use in my opinion. end of message _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Valérie Barnole FTR&D/DAC/ACE tel. : + 33 1 45 29 58 39 fax : + 33 1 46 29 31 42 mail to : valerie.barnole@francetelecom.fr -----Message d'origine----- De: Vaudreuil, Greg M (Greg) [mailto:gregv@lucent.com] Date: jeudi 10 août 2000 21:06 À: Patrik Fältström; BARNOLE Valerie FTRD/DAC/ISS Cc: 'enum@ietf.org'; Manfredi, Albert E; 'Hong Liu' Objet: [Enum] Address completion vs private dialing plans I think we are talking about two different things. One is the proper handling of private dialing plans. The second is an implementation of an address completion facility using DNS. We need to distinguish between them. The address completion facility takes a dialed string of digits and applies logic to determine 1) What dialing plan (or local service codes) if any the dialed digits correspond to and 2) what if any prefix needs to be added or stripped to construct a valid and unique number within that dial plan. The example Patrick illustrates A swedish address completion facility. Given that I am in Sweden, I resolve the digits received using the ENUM process using a hard-coded num.se domain. Through the DDDS mechanisms, I eventually get to a "fully qualified" E164 number and begin the ENUM process. Stated more generally, address completion takes as input a topological "location" and an input string and results in a numbering plan identifier and a set of digits unique to that number plan. Of course, this is a fantastic facility, but totally out-of-scope for ENUM except to keep options open for other cool stuff using the same mechanism. So, in the spirit of "+" to keep things open, I believe we need to go a bit deeper. In the general case, the ENUM algoritmn really takes as input both a string of digits and the identifier of the dial-plan in which the digits are unique. The dial plan identifier is used to select the domain suffix for the DNS lookup and to select between various candidate remapping rules. Patrick recognized that the RegExp algorithm needs the dialplan identifier in order to operate as an address completion facility and proposed using "+" as the e164 identifier. I would argue that we should address this need in a more complete way and should explicitly identifing the numbering plan as part of the input to the NAPTR algorithm. So, rather than use +e164digits as the input, why do not we use something like numberingplan+e164digits. This is far more powerful than just looking for a "+" and guessing about which "other" is to be used. This also addresses another complication that arises with the use of DNAMEs in conjunction with NAPTRs. I may arive at the same NAPTR set using numerous paths defined in by my clients dial-plan tables: 2.2.7.2.dal.lucent.com (a 4 digit site-wide extension reached by simply dialing four digits) and 2.2.7.2.1.0.1.lucent.com (A 7 digit corporate location+extension VPN dialing plan reached by dialing 8+location+extension) and 2.2.7.2.3.3.7.2.7.9.nanp.us (the NANP plan reached by dialing 9+10 digits) and 2.2.7.2.3.3.7.2.7.9.1.e164.arpa (The E164 GSTN plan reached by dialing 011+e164 number in the US.) where the e164.arpa, and lucent.com are a Cnames pointing back to 2.2.7.2.dal.lucent.com and nanp.us has a Dname pointing to 1.e164.arpa. Now I can have a set of four NAPTR entries, one with a different re-write for each of the "dialplans". With the numbering plan identified, one could more easily determine which regexp to use where the current proposal would leave you guessing. Greg V. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 11:50:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23259 for ; Fri, 11 Aug 2000 11:50:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18989; Fri, 11 Aug 2000 11:50:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18958 for ; Fri, 11 Aug 2000 11:50:41 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23250 for ; Fri, 11 Aug 2000 11:50:37 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d24.cc.telcordia.com [128.96.11.24]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7BFnkR01940; Fri, 11 Aug 2000 11:49:47 -0400 (EDT) Message-ID: <3994209C.B487BE0B@research.telcordia.com> Date: Fri, 11 Aug 2000 11:49:48 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: "Vaudreuil, Greg M (Greg)" CC: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Manfredi@research.telcordia.com, Albert E , "'enum@ietf.org'" , michaelm@netsol.com, james.yu@neustar.com Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt References: <6B57F36F4FF9D111B30A0008C7F4133704051041@exdal1.ons.octel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Greg, I share the some concerns as described in your email. Please see my additional comments in between lines below. Cheers, --Hong "Vaudreuil, Greg M (Greg)" wrote: > I believe the core ENUM specification is now receiving the significant > community review it deserves as the community begins to understand this > rather complex protocol. (ENUM is depenent upon DNS and NAPTR, both complex > entities in their own rights.) > The paradox we are facing today in the ENUM WG is that we are refering to NAPTR, which is also undergoing some changes recently. Personally, I think the DDDS documents explain the concepts and algorithm much better than the new NAPTR document. But I guess we are racing against time... > > There are open questions about a few known design choices. It is > unfortuate that this discussion has begun in earnest only after the > submission to the IESG for last call. However, late as it may be, I believe > we must still address the questions concerning the design choices, and if > necessary, make changes to the specification. > Agree. In the spirit of moving forward, if we are going to advance the document to RFC, then we need to clearly document what the open issues are, and _not_ make any design choice on any of these issues. For example, leaving the '+' in the algorithm is clearly biased towards the prefix+digit proposal, which has not been carefully thought out. While the discussions on this topic leads to a bigger problem for extensibility, it was pronounced as "premature". If it is premature, then the '+' is not needed because: (1) The major argument for keeping it is to have a way to tell an E.164 number from a non-E164 number. This argument is no longer valid if we are to delay the consideration of using ENUM for non-E164 numbering plans. (2) Taking '+' out will not affect in any way the operations of ENUM for E.164 to URI mapping. (3) Removing '+' requires little modification of the existing document, which can then pass on to RFC status. (4) It also leaves the door open for future considerations on service differentiation when the proposal(s) for doing so becomes mature. > > While changes may be introduced after proposed standard, our history > suggests that substantial changes can only be made if the origional protocol > is a failure and has seen little use. If limited sucess is achieved, then > we are stuck with patching deficiencies in a backward compatable manner, > usually by adding otherwise unnecessary complexity and resulting > interoperability difficulty. > Totally agree. > > ENUM is a "core" application protocol that is expected to be used by many > important new applications. It certianly is one that "materially affects > the core Internet protocols or that specifies behavior that may have > significant operational impact on the Internet". By this observation, I do > not suggest that we need to wait for implementation experience, but it is > certianly worth putting forth a well understood proposal. How the protocol > is extended is an especially important thing to understand and document > before implementations are deployed that preclude anticipated extensions. > Yes. Extensibility is critical for ENUM mechanisms to be widely deployed in an interoperable manner. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 13:00:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25895 for ; Fri, 11 Aug 2000 13:00:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19845; Fri, 11 Aug 2000 12:59:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19815 for ; Fri, 11 Aug 2000 12:59:33 -0400 (EDT) Received: from p-mail2.cnet.fr ([192.144.74.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25853 for ; Fri, 11 Aug 2000 12:59:32 -0400 (EDT) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Aug 2000 18:13:03 +0200 Message-ID: <98388C05D464D111B61800805F1504160123E894@p-ibis.issy.cnet.fr> From: BARNOLE Valerie FTRD/DAC/ISS To: "'Hong Liu'" , =?iso-8859-1?Q?Patrik_F=E4?= =?iso-8859-1?Q?ltstr=F6m?= Cc: "Manfredi, Albert E" , "'enum@ietf.org'" , michaelm@netsol.com, james.yu@neustar.com Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Fri, 11 Aug 2000 18:13:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA19816 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Hong, I think that the "+" issue conveys the question of the openness of the ENUM algorithm use. Strictly speaking, if I consider that this algorithm only applies to E.164 numbers (CC followed by N(S)N), I agree : there is no use for step 2 of the ENUM procedure, let's remove in one step all non-digits characters. So there's only E2U. To be drastic, even from step 1, a number with "+" should be considered as incorrect. So it means to me that if another type of number(corporate number or else)than E.164 is dialled, it has to finally result in an E.164 formatted number to be handled through ENUM from step 1. If not, it does not work. It may be a way to proceed but is it really what we want ? I see it difficult to solve by adding a new service code for every private plan. So I do not see a way out of this either than considering only E.164 formatted numbers or adding a hint of the numbering plan (at least, keeping the door open to give this hint by keeping "+" like it is by now in the draft and maybe adding some words to justify). In my view, you will find the same issue with another application (I do not quote UPT2U, because UPT numbers are E.164 numbers under CC 878 and I do not quote IMSI2U, because of the non-availability to the public of IMSIs for fraud prevention reasons). Other ITU numbers or identifyers that might be used are built on the E.164 kind of model, with "national like" part (like after the MCC in the IMSIs). So I would be in favor of keeping "+" but maybe I did not understand everything. end of message _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Valérie Barnole FTR&D/DAC/ACE tel. : + 33 1 45 29 58 39 fax : + 33 1 46 29 31 42 mail to : valerie.barnole@francetelecom.fr -----Message d'origine----- De: Hong Liu [mailto:lhong@research.telcordia.com] Date: vendredi 11 août 2000 16:34 À: Patrik Fältström Cc: Manfredi, Albert E; 'enum@ietf.org'; michaelm@netsol.com; james.yu@neustar.com Objet: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Patrik, I would like to clarify a few points here: (1) I am as interested as anyone else on the list to move the protocol spec into the RFC status, so that everybody can implement. We are implementing it now. (2) In the spirit of moving forward, the changes I proposed can be accommodated in the next revision of this document. (3) Regarding the current document, the only change I suggested, including a few others, is just to remove the '+' from the input string. This is _not_ a very significant change. I don't see it in anyway will delay the document from becoming an RFC because of that. (4) Even if you go with the prefix+digits scheme, you still need to define new service code for usage of ENUM in a non-E164 case, since E2U as currently defined, only works for E.164 to URI mapping. In that sense, the two proposals may complement each other as a last resort. The bottom line: if the document is just for E.164 number mapping, the '+' part is redundant. Since you suggested that we delay consideration of using ENUM in other scenarios, then any hook, such as '+', should be removed to leave this issue open for future considerations. As many people pointed out on the list, '+' is just a kludge for a bigger problem of service differentiation. --Hong Patrik Fältström wrote: > Two things: > > (1) I am not saying you should not do this (aswell). What myself and > Michael says is that it is unnessecary to remove the ability to > distinguish in the regexp between numbering plans > > (2) This I-D is for _proposed_ standard, next step is draft standard. > > The distinction between them is as follows (see RFC 2026): > > I would not be surprised if we need to change things before going to > "draft" standard, and maybe we even have to restart at "proposed". > > I think this whole debate is premature, and that we today need the > I-D as RFC so people can implement this stuff, so we get the > experience we need to produce the next round of documents in the IETF > (not necessary in the ENUM wg). As it is today, this spec is only an > I-D which is a living target, can not be referenced, and because of > that it is hard for for example the VPIM people to really start > working on what they have knowledge about. > > Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 13:32:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27249 for ; Fri, 11 Aug 2000 13:32:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20406; Fri, 11 Aug 2000 13:32:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20381 for ; Fri, 11 Aug 2000 13:32:17 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27243 for ; Fri, 11 Aug 2000 13:32:16 -0400 (EDT) Received: from [195.198.39.72] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id KAA14697; Fri, 11 Aug 2000 10:31:24 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <39940ED0.64F7DCEF@research.telcordia.com> References: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> <3992CDE9.1A658D6A@research.telcordia.com> <399304B2.2BC80CD7@research.telcordia.com> <39940ED0.64F7DCEF@research.telcordia.com> Date: Fri, 11 Aug 2000 19:23:15 +0200 To: Hong Liu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Cc: "Manfredi, Albert E" , "'enum@ietf.org'" , michaelm@netsol.com, james.yu@neustar.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 10.33 -0400 00-08-11, Hong Liu wrote: >(3) Regarding the current document, the only change I suggested, including a >few others, is just to remove the '+' from the input string. This is _not_ a >very significant change. I don't see it in anyway will delay the document >from becoming an RFC because of that. Can everyone that do care please let me know ASAP whether: (a) You think the '+' makes sense (b) You think the '+' should go away Just be clear in your email (no arguments or explanation on why you think one way or another), and I can help the wg chair and the AD to find consensus. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 13:37:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27489 for ; Fri, 11 Aug 2000 13:37:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20537; Fri, 11 Aug 2000 13:36:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20512 for ; Fri, 11 Aug 2000 13:36:50 -0400 (EDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27457 for ; Fri, 11 Aug 2000 13:36:48 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA04311; Fri, 11 Aug 2000 13:26:19 -0400 (EDT) Date: Fri, 11 Aug 2000 13:26:19 -0400 From: Michael Mealling To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Hong Liu , "Manfredi, Albert E" , "'enum@ietf.org'" , michaelm@netsol.com, james.yu@neustar.com Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Message-ID: <20000811132619.F3856@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> <3992CDE9.1A658D6A@research.telcordia.com> <399304B2.2BC80CD7@research.telcordia.com> <39940ED0.64F7DCEF@research.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.2i In-Reply-To: ; from paf@cisco.com on Fri, Aug 11, 2000 at 07:23:15PM +0200 Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit On Fri, Aug 11, 2000 at 07:23:15PM +0200, Patrik Fältström wrote: > At 10.33 -0400 00-08-11, Hong Liu wrote: > >(3) Regarding the current document, the only change I suggested, including a > >few others, is just to remove the '+' from the input string. This is _not_ a > >very significant change. I don't see it in anyway will delay the document > >from becoming an RFC because of that. > > Can everyone that do care please let me know ASAP whether: > > (a) You think the '+' makes sense > (b) You think the '+' should go away I pick "a". If its there you can ignore it. If it isn't then you can't... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 13:42:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27776 for ; Fri, 11 Aug 2000 13:42:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20733; Fri, 11 Aug 2000 13:42:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20698 for ; Fri, 11 Aug 2000 13:42:28 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27769 for ; Fri, 11 Aug 2000 13:42:27 -0400 (EDT) Received: from [195.198.39.72] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id KAA19243; Fri, 11 Aug 2000 10:41:34 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <6B57F36F4FF9D111B30A0008C7F4133704051042@exdal1.ons.octel.com> References: <6B57F36F4FF9D111B30A0008C7F4133704051042@exdal1.ons.octel.com> Date: Fri, 11 Aug 2000 19:35:26 +0200 To: "Vaudreuil, Greg M (Greg)" , BARNOLE Valerie FTRD/DAC/ISS From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] Address completion vs private dialing plans Cc: "'enum@ietf.org'" , "Manfredi, Albert E" , "'Hong Liu'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 09.44 -0500 00-08-11, Vaudreuil, Greg M (Greg) wrote: >I hope >Patrick can provide greater clarity to his proposal for exactly how a client >can identify whether it needs to apply itteration..... In NAPTR (if that is what you talk about), the recursion is identified by having an empty flag field. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 18:01:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06494 for ; Fri, 11 Aug 2000 18:01:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23600; Fri, 11 Aug 2000 17:57:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23575 for ; Fri, 11 Aug 2000 17:57:45 -0400 (EDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06323 for ; Fri, 11 Aug 2000 17:57:44 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.154.61]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA11599; Fri, 11 Aug 2000 17:57:24 -0400 (EDT) Message-Id: <4.3.1.2.20000811125551.00d8e4d0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 11 Aug 2000 16:58:58 -0500 To: michaelm@netsol.com, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Richard Shockey Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Cc: Hong Liu , "Manfredi, Albert E" , "'enum@ietf.org'" , michaelm@netsol.com, Scott Bradner , mankin@east.isi.edu In-Reply-To: <20000811132619.F3856@bailey.dscga.com> References: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> <3992CDE9.1A658D6A@research.telcordia.com> <399304B2.2BC80CD7@research.telcordia.com> <39940ED0.64F7DCEF@research.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA23576 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 01:26 PM 8/11/2000 -0400, Michael Mealling wrote: >On Fri, Aug 11, 2000 at 07:23:15PM +0200, Patrik Fältström wrote: > > At 10.33 -0400 00-08-11, Hong Liu wrote: > > >(3) Regarding the current document, the only change I suggested, > including a > > >few others, is just to remove the '+' from the input string. This is > _not_ a > > >very significant change. I don't see it in anyway will delay the document > > >from becoming an RFC because of that. > > > > Can everyone that do care please let me know ASAP whether: > > > > (a) You think the '+' makes sense > > (b) You think the '+' should go away > >I pick "a". > >If its there you can ignore it. If it isn't then you can't... Chair hat off ... I pick a (a) for Mike's specific reasons. Chair hat on again... It is regrettable but understandable that we are, once again, at this late stage and have these issues come up. The issue is then what is the manner by which dialing plans other than e164 can be identified and does the use of '+' in the current expression preclude any future extensions in such a manner that the core protocol becomes essentially useless to implementers. Does this meet the definition of a "showstopper" that would bring the document back from the IESG for some additional review and comments. In the first place lets remind ourselves what this document is about. ########## Title : E.164 number and DNS Author(s) : P. Faltstrom Filename : draft-ietf-enum-e164-dns-03.txt This document discusses the use of DNS for storage of E.164 numbers. ########### 1. The draft under discussion is _not_ about the use of DNS and generic numbering/dialing plans public or private. Therefore the use of the '+' is both useful and correct within the context of a document that is focused on the e.164 namespace and follows ITU guidelines on expression. 2. Do we need work on DNS and other numbering/dialing plans? Obviously yes but I submit that e164-dns-03 is not the document to do that. We clearly have need for such work and I think it is reasonable and appropriate that it be added to our work list in the upcoming months and added to our goals and milestones. 3. This is a proposed standard and not a draft standard. We are all familiar with the process that defines how a protocol moves from proposed to draft based on actual implementation experience. I'm suggesting that we need to move forward in that direction _now_ with all deliberate speed. Quite often in the IETF we define a proposed standard only to find out very very quickly that it does not meet all of the necessary criterion for wide scale deployment. In my personal experience the situation with Internet Fax standard RFC 2305 (Simple mode) eventually leading to RFC 2532 (Extended mode) offers a limited example. The debate surrounding 2305 was quite difficult, consequently areas of the document were left deliberately ambiguous or cut out in a wholesale manner until the very shell of a protocol was left. In fact that is what we have done here with Patricks draft during the past year. Does the use of the "+" in the regexp preclude any future resolution of this issue? Does it exclude other ways of extending ENUM in the future? IMHO ..No. I have not seen one argument that states that keeping this requirement in would totally preclude, in the future, the use of some other form of expression to achieve the desired goal of number plan identification, such as the use of the service selector. If you don't want to use the '+' in the future fine ..ignore it ..but by itself it _might_ be expanded to accomplish the desired goal. Operational experience should decide whether this is redundant or not. This should be the goal of _future_ work not the current document. That will be my recommendation to the AD's. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 314.503.0640 Fax to EMail 815.333.1237 (Preferred for Fax) DC Number 202.533.2811 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 19:36:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08139 for ; Fri, 11 Aug 2000 19:36:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24554; Fri, 11 Aug 2000 19:33:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24529 for ; Fri, 11 Aug 2000 19:33:53 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08092 for ; Fri, 11 Aug 2000 19:33:53 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d24.cc.telcordia.com [128.96.11.24] (may be forged)) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7BNWfR21032; Fri, 11 Aug 2000 19:32:41 -0400 (EDT) Message-ID: <39948D1A.BD47692A@research.telcordia.com> Date: Fri, 11 Aug 2000 19:32:42 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: Richard Shockey CC: michaelm@netsol.com, "Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=" , "Manfredi, Albert E" , "'enum@ietf.org'" , Scott Bradner , mankin@east.isi.edu Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt References: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> <3992CDE9.1A658D6A@research.telcordia.com> <399304B2.2BC80CD7@research.telcordia.com> <39940ED0.64F7DCEF@research.telcordia.com> <4.3.1.2.20000811125551.00d8e4d0@127.0.0.1> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Richard, Patrik and others, I am in favor of moving this document forward, though I have concerns about how the current design choice may impact future extentions. From the discussions surrouding the inclusion/exclusion of '+', I recognize the need for a generic mechanism that includes both the numbering plan hint and the service selector. The two proposals are in fact complementary to each other. In the current document, E2U is defined exclusively for E.164 to URI mapping. If we are to use the same algorithm for non-E164 numbers, such as national or corporate dialing plans, we need to define new service selectors for those as well in order to be semantically consistent. If we are to adopt the 'numberplan+digits' as the generic structure for ENUM-like Application Unique String, then for E.164, I suggest we do it all the way, such as 'e164+digits' as the input string to NAPTR. If we decide to use '+' as it is, then I suggest that a paragraph be added in the document clarifying the semantics of '+' as a numbering plan indicator. Just my suggestion as an alternative to the inclusion/exclusion of '+'. Regards, --Hong Richard Shockey wrote: > At 01:26 PM 8/11/2000 -0400, Michael Mealling wrote: > >On Fri, Aug 11, 2000 at 07:23:15PM +0200, Patrik Fältström wrote: > > > At 10.33 -0400 00-08-11, Hong Liu wrote: > > > >(3) Regarding the current document, the only change I suggested, > > including a > > > >few others, is just to remove the '+' from the input string. This is > > _not_ a > > > >very significant change. I don't see it in anyway will delay the document > > > >from becoming an RFC because of that. > > > > > > Can everyone that do care please let me know ASAP whether: > > > > > > (a) You think the '+' makes sense > > > (b) You think the '+' should go away > > > >I pick "a". > > > >If its there you can ignore it. If it isn't then you can't... > > Chair hat off ... I pick a (a) for Mike's specific reasons. > > Chair hat on again... It is regrettable but understandable that we are, > once again, at this late stage and have these issues come up. > > The issue is then what is the manner by which dialing plans other than e164 > can be identified and does the use of '+' in the current expression > preclude any future extensions in such a manner that the core protocol > becomes essentially useless to implementers. > > Does this meet the definition of a "showstopper" that would bring the > document back from the IESG for some additional review and comments. > > In the first place lets remind ourselves what this document is about. > > ########## > > Title : E.164 number and DNS > Author(s) : P. Faltstrom > Filename : draft-ietf-enum-e164-dns-03.txt > > This document discusses the use of DNS for storage of E.164 numbers. > > ########### > > 1. The draft under discussion is _not_ about the use of DNS and generic > numbering/dialing plans public or private. Therefore the use of the '+' is > both useful and correct within the context of a document that is focused on > the e.164 namespace and follows ITU guidelines on expression. > > 2. Do we need work on DNS and other numbering/dialing plans? Obviously > yes but I submit that e164-dns-03 is not the document to do that. We > clearly have need for such work and I think it is reasonable and > appropriate that it be added to our work list in the upcoming months and > added to our goals and milestones. > > 3. This is a proposed standard and not a draft standard. We are all > familiar with the process that defines how a protocol moves from proposed > to draft based on actual implementation experience. I'm suggesting that we > need to move forward in that direction _now_ with all deliberate speed. > > Quite often in the IETF we define a proposed standard only to find out very > very quickly that it does not meet all of the necessary criterion for wide > scale deployment. In my personal experience the situation with Internet Fax > standard RFC 2305 (Simple mode) eventually leading to RFC 2532 (Extended > mode) offers a limited example. The debate surrounding 2305 was quite > difficult, consequently areas of the document were left deliberately > ambiguous or cut out in a wholesale manner until the very shell of a > protocol was left. In fact that is what we have done here with Patricks > draft during the past year. > > Does the use of the "+" in the regexp preclude any future resolution of > this issue? Does > it exclude other ways of extending ENUM in the future? > > IMHO ..No. I have not seen one argument that states that keeping this > requirement in would totally preclude, in the future, the use of some other > form of expression to achieve the desired goal of number plan > identification, such as the use of the service selector. If you don't want > to use the '+' in the future fine ..ignore it ..but by itself it _might_ > be expanded to accomplish the desired goal. Operational experience should > decide whether this is redundant or not. This should be the goal of > _future_ work not the current document. > > That will be my recommendation to the AD's. > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Richard Shockey > Senior Technical Industry Liaison > NeuStar Inc. > 1120 Vermont Avenue N.W. > Suite 550 > Washington DC. 20005 > Voice 314.503.0640 > Fax to EMail 815.333.1237 (Preferred for Fax) > DC Number 202.533.2811 > INTERNET Mail & IFAX : rich.shockey@neustar.com > or rshockey@ix.netcom.com > http://www.neustar.com > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 20:24:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08775 for ; Fri, 11 Aug 2000 20:24:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24982; Fri, 11 Aug 2000 20:24:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24947 for ; Fri, 11 Aug 2000 20:24:34 -0400 (EDT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08762 for ; Fri, 11 Aug 2000 20:24:33 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.177.148]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id UAA21337; Fri, 11 Aug 2000 20:23:59 -0400 (EDT) Message-Id: <4.3.1.2.20000811191016.00c1a7c0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 11 Aug 2000 19:24:50 -0500 To: Hong Liu From: Richard Shockey Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Cc: michaelm@netsol.com, =?iso-8859-1?Q?=22Patrik_F=E4ltstr=F6m=22?= , "Manfredi, Albert E" , "'enum@ietf.org'" , Scott Bradner , mankin@east.isi.edu In-Reply-To: <39948D1A.BD47692A@research.telcordia.com> References: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> <3992CDE9.1A658D6A@research.telcordia.com> <399304B2.2BC80CD7@research.telcordia.com> <39940ED0.64F7DCEF@research.telcordia.com> <4.3.1.2.20000811125551.00d8e4d0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 07:32 PM 8/11/2000 -0400, Hong Liu wrote: >Richard, Patrik and others, > >I am in favor of moving this document forward, though I have concerns >about how >the current design choice may impact future extentions. So do we all but as I think I made clear ..we have not created something that is cast in concrete. These are excellent points you have raised here, much appreciated and central to the ongoing process of protocol development beyond _proposed_ standard. Its just unfortunate that we're having this discussion at this point in time. > From the discussions surrouding the inclusion/exclusion of '+', I > recognize the >need for a generic mechanism that includes both the numbering plan hint >and the >service selector. The two proposals are in fact complementary to each >other. In >the current document, E2U is defined exclusively for E.164 to URI mapping. >If we >are to use the same algorithm for non-E164 numbers, such as national or >corporate >dialing plans, we need to define new service selectors for those as well >in order >to be semantically consistent. Agreed... >If we are to adopt the 'numberplan+digits' as the generic structure for >ENUM-like >Application Unique String, then for E.164, I suggest we do it all the way, >such as >'e164+digits' as the input string to NAPTR. If we decide to use '+' as it >is, then >I suggest that a paragraph be added in the document clarifying the >semantics of >'+' as a numbering plan indicator. Lets assume, for purposes of argument that '+' remains for the time being. Is there any language you'd like to suggest here... about the usage of '+' ambiguous or unambiguous but leaving the door open for enhancements in a future ID, which I'd hope you'd write? :-) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 314.503.0640 Fax to EMail 815.333.1237 (Preferred for Fax) DC Number 202.533.2811 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Aug 11 23:52:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13662 for ; Fri, 11 Aug 2000 23:52:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA26709; Fri, 11 Aug 2000 23:51:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA26678 for ; Fri, 11 Aug 2000 23:51:56 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13659 for ; Fri, 11 Aug 2000 23:51:55 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d24.cc.telcordia.com [128.96.11.24] (may be forged)) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7C3ofR27518; Fri, 11 Aug 2000 23:50:41 -0400 (EDT) Message-ID: <3994C98F.3B1C109C@research.telcordia.com> Date: Fri, 11 Aug 2000 23:50:39 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: Richard Shockey CC: michaelm@netsol.com, "Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=" , "Manfredi, Albert E" , "'enum@ietf.org'" , Scott Bradner , mankin@east.isi.edu Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt References: <4102273CEB77D211869200805FE6F5939EBD96@xch-phl-01.he.boeing.com> <3992CDE9.1A658D6A@research.telcordia.com> <399304B2.2BC80CD7@research.telcordia.com> <39940ED0.64F7DCEF@research.telcordia.com> <4.3.1.2.20000811125551.00d8e4d0@127.0.0.1> <4.3.1.2.20000811191016.00c1a7c0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Richard, Patrik, and others, Thanks for the nice comments. I personally learned a lot from the email exchanges in the last few days. Assuming that we will leave '+' as it is in the document, then I would like to add a note at the end of the ENUM procedure, i.e. Section 2, as something like the following: "Note: The output of Step 2 above, i.e., an E.164 number without any characters but the leading '+' and digits, is the input string to the NAPTR algorithm. The leading '+' is the E.164 numbering plan indicator, which SHALL be used in conjuction with the service selector E2U defined in Section 3.1.2 in all NAPTR resource records with a non-empty service field for E.164 to URI mapping. Other numbering plans MAY make use of the ENUM procedure defined above for telephone number to URI mapping with the following modifications: - Specification of an unique numbering plan indicator other than '+'; - Specification of a service selector other than 'E2U'; - Specification of the root domain name other than 'e164.arpa'; However, these specifications are outside of the scope of this document. It is envisioned that other numbering plan indicators and service selectors will be defined in a future document to accommodate multiple numbering plans using the same ENUM mechanism. " The language above is rough, as they are coming out of the top of my head. Please feel free to make modifications as you see fit. Not that I am stubborn, but I do feel that if we are to define 'numberplan+digits' as the generic structure for the input string to NAPTR, it is better to change '+digits' to 'e164+digits' _now_ than later. I am more concerned about the massive number of NAPTR RRs to be populated in the DNS databases after this document becomes an RFC. As we have already seen, the input string format does dictate the regexp format in a NAPTR RR. Why is it so difficult to change? Anyway, I will accept the consensus of the group. Richard Shockey wrote: > >If we are to adopt the 'numberplan+digits' as the generic structure for > >ENUM-like > >Application Unique String, then for E.164, I suggest we do it all the way, > >such as > >'e164+digits' as the input string to NAPTR. If we decide to use '+' as it > >is, then > >I suggest that a paragraph be added in the document clarifying the > >semantics of > >'+' as a numbering plan indicator. > > Lets assume, for purposes of argument that '+' remains for the time > being. Is there any language you'd like to suggest here... about the usage > of '+' ambiguous or unambiguous but leaving the door open for > enhancements in a future ID, which I'd hope you'd write? :-) > Sure, I will write an ID addressing extension issues for the next IETF meeting, with some other folks who are interested in this topic. Regards, --Hong _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Aug 12 09:19:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01221 for ; Sat, 12 Aug 2000 09:19:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06639; Sat, 12 Aug 2000 09:18:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06565 for ; Sat, 12 Aug 2000 09:18:36 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01218 for ; Sat, 12 Aug 2000 09:18:34 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA07235 for ; Sat, 12 Aug 2000 09:18:35 -0400 (EDT) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA07212; Sat, 12 Aug 2000 09:18:33 -0400 (EDT) Received: from buzz.ons.octel.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr) id JAA05749 for ; Sat, 12 Aug 2000 09:18:31 -0400 (EDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id IAA04713; Sat, 12 Aug 2000 08:18:29 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Sat, 12 Aug 2000 08:13:55 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F4133704051066@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: Hong Liu , Richard Shockey Cc: michaelm@netsol.com, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Manfredi, Albert E" , "'enum@ietf.org'" , Scott Bradner , mankin@east.isi.edu Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Sat, 12 Aug 2000 08:13:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA06566 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I am also concerned with the number of NAPTR records that may proliferate if we require a separate service selector for each numbering plan. In my previous example where a typical corporate node may have four numbering plan entries, (164, corporate-wide private, local site extension, national) we need to consider that multiplied by say six services for 24 records! In most cases, the resulting URL does not depend upon the input string, that is, it does not matter what number or dialplan was used to find it. I would like to see E2U explicitly support other numbering plans. This can be done by noting that + is the dialplan separator. If no dialplan is indicated, then the NAPTR applies to all numbering plans. If a particular NATPR record is intended to be limited to only E164 numbers, than the E164 dialplan indicator is explicitly indicated with e164+digits. If an unknown dialplan is indicated in the returned NAPTR record, the record is ignored (No match is found). Note that this is completely compatable with the existing proposal. Because only E164 is discussed, a default for all dialplans behaves as the current text. Greg V. -----Original Message----- From: Hong Liu [mailto:lhong@research.telcordia.com] Sent: Friday, August 11, 2000 10:51 PM To: Richard Shockey Cc: michaelm@netsol.com; Patrik Fältström; Manfredi, Albert E; 'enum@ietf.org'; Scott Bradner; mankin@east.isi.edu Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Richard, Patrik, and others, Thanks for the nice comments. I personally learned a lot from the email exchanges in the last few days. Assuming that we will leave '+' as it is in the document, then I would like to add a note at the end of the ENUM procedure, i.e. Section 2, as something like the following: "Note: The output of Step 2 above, i.e., an E.164 number without any characters but the leading '+' and digits, is the input string to the NAPTR algorithm. The leading '+' is the E.164 numbering plan indicator, which SHALL be used in conjuction with the service selector E2U defined in Section 3.1.2 in all NAPTR resource records with a non-empty service field for E.164 to URI mapping. Other numbering plans MAY make use of the ENUM procedure defined above for telephone number to URI mapping with the following modifications: - Specification of an unique numbering plan indicator other than '+'; - Specification of a service selector other than 'E2U'; - Specification of the root domain name other than 'e164.arpa'; However, these specifications are outside of the scope of this document. It is envisioned that other numbering plan indicators and service selectors will be defined in a future document to accommodate multiple numbering plans using the same ENUM mechanism. " The language above is rough, as they are coming out of the top of my head. Please feel free to make modifications as you see fit. Not that I am stubborn, but I do feel that if we are to define 'numberplan+digits' as the generic structure for the input string to NAPTR, it is better to change '+digits' to 'e164+digits' _now_ than later. I am more concerned about the massive number of NAPTR RRs to be populated in the DNS databases after this document becomes an RFC. As we have already seen, the input string format does dictate the regexp format in a NAPTR RR. Why is it so difficult to change? Anyway, I will accept the consensus of the group. Richard Shockey wrote: > >If we are to adopt the 'numberplan+digits' as the generic structure for > >ENUM-like > >Application Unique String, then for E.164, I suggest we do it all the way, > >such as > >'e164+digits' as the input string to NAPTR. If we decide to use '+' as it > >is, then > >I suggest that a paragraph be added in the document clarifying the > >semantics of > >'+' as a numbering plan indicator. > > Lets assume, for purposes of argument that '+' remains for the time > being. Is there any language you'd like to suggest here... about the usage > of '+' ambiguous or unambiguous but leaving the door open for > enhancements in a future ID, which I'd hope you'd write? :-) > Sure, I will write an ID addressing extension issues for the next IETF meeting, with some other folks who are interested in this topic. Regards, --Hong _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Aug 12 11:52:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03268 for ; Sat, 12 Aug 2000 11:52:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08011; Sat, 12 Aug 2000 11:51:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07986 for ; Sat, 12 Aug 2000 11:51:53 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03260 for ; Sat, 12 Aug 2000 11:51:51 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d24.cc.telcordia.com [128.96.11.24]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7CFoRR18088; Sat, 12 Aug 2000 11:50:27 -0400 (EDT) Message-ID: <39957244.A5B2600A@research.telcordia.com> Date: Sat, 12 Aug 2000 11:50:28 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: "Vaudreuil, Greg M (Greg)" CC: Richard Shockey , michaelm@netsol.com, "Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=" , "Manfredi, Albert E" , "'enum@ietf.org'" , Scott Bradner , mankin@east.isi.edu Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt References: <6B57F36F4FF9D111B30A0008C7F4133704051066@exdal1.ons.octel.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Greg, You have raised a number of good points. I have some additional comments in between the lines below. Cheers, --Hong "Vaudreuil, Greg M (Greg)" wrote: > I am also concerned with the number of NAPTR records that may proliferate if > we require a separate service selector for each numbering plan. In my > previous example where a typical corporate node may have four numbering plan > entries, (164, corporate-wide private, local site extension, national) we > need to consider that multiplied by say six services for 24 records! In most > cases, the resulting URL does not depend upon the input string, that is, it > does not matter what number or dialplan was used to find it. > The issue here is how fine-grained we want to differentiate the services offered by ENUM. In general, the numbering plan indicator provides more detailed information than the corresponding service selector. What I have in mind is the following: (1) For each numbering plan defined by ITU-T, say E.xxx, define exxx+digits as the numbering plan indicator and ExxxToU as the service selector; (2) For each national numbering plan, define YY+digits as the numbering plan indicator and YYtoU as the service selector. Here YY is the two letters for each country as defined by ISO 3166; (3) For other corporate or private numbering plans, define a 'private' numbering plan indicator and use something like 'P2U' as the service selector; Note here 'P2U' serves as a generic service selector for private number to URI mapping. (1) and (2) can be standardized easily, using the schemes already established by other standards bodies. For (3), we probably do not, and cannot, standardize the plan indicator for two reasons: first, it is 'private' anyway; second, there are two many of them. Note that it is the numbering plan indicator, not the service selector, that makes the NAPTR RRs different, i.e., the regexp part. If you can find a way to combine different numbering plans into a single regexp, consolidating service selectors is easy, just use the '+', e.g. 'mailto+E2U+US2U+P2U'. > > I would like to see E2U explicitly support other numbering plans. This can > be done by noting that + is the dialplan separator. If no dialplan is > indicated, then the NAPTR applies to all numbering plans. If a particular > NATPR record is intended to be limited to only E164 numbers, than the E164 > dialplan indicator is explicitly indicated with e164+digits. > > If an unknown dialplan is indicated in the returned NAPTR record, the record > is ignored (No match is found). > Basically, you have suggested two things here: (1) Overload or generalize the semantics of 'E2U' from 'E.164 to URI' to 'Telephone Number to URI'. This is a very good idea in that we do not need to worry about choosing different service selectors when using ENUM. If the WG decides to go this route, then I suggest we use a different name instead, such as 'T2U' because 'E2U' suggests something for E.164. I don't use 'N2U' since I do not want to confuse that with existing URN service selectors such as 'N2I'. (2) The default or 'ANY/ALL' construct for all numbering plans. This is also a very good idea for consolidating different NAPTR RRs when we don't care which numbering plan is used to reach those records. However, I see one problem: it assumes that the client knows a priori what the NAPTR RRs look like before it launches the query, i.e., the regexp in the NAPTR RR ignores the numbering plan indicator. On the other hand, you can always write a regexp in such a way that it ignores anything upto the '+' (and including '+') in the input string to accomplish the same goal. The problem here is the 'disconnect' between the client who lauches the query, and the user who provisions the NAPTR RRs. Both have a way to ignore the numbering plan if they choose to, but neither can assume what the other side may do. To make the NAPTR algorithm work, I would think that the burden should be put on the shoulder of the user who provisions the RRs. In this way, the client always starts with some numbering plan according to the digits received, the user can consolidate the records for all numbering plans if he/she chooses to do so. > > Note that this is completely compatable with the existing proposal. Because > only E164 is discussed, a default for all dialplans behaves as the current > text. > > Greg V. > > -----Original Message----- > From: Hong Liu [mailto:lhong@research.telcordia.com] > Sent: Friday, August 11, 2000 10:51 PM > To: Richard Shockey > Cc: michaelm@netsol.com; Patrik Fältström; Manfredi, Albert E; > 'enum@ietf.org'; Scott Bradner; mankin@east.isi.edu > Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt > > Richard, Patrik, and others, > > Thanks for the nice comments. I personally learned a lot from the email > exchanges in the last few days. Assuming that we will leave '+' as it is in > the > document, then I would like to add a note at the end of the ENUM procedure, > i.e. Section 2, as something like the following: > > "Note: The output of Step 2 above, i.e., an E.164 number without any > characters > but the leading '+' and digits, is the input string to the NAPTR algorithm. > The > leading '+' is the E.164 numbering plan indicator, which SHALL be used in > conjuction with the service selector E2U defined in Section 3.1.2 in all > NAPTR > resource records with a non-empty service field for E.164 to URI mapping. > > Other numbering plans MAY make use of the ENUM procedure defined above for > telephone number to URI mapping with the following modifications: > - Specification of an unique numbering plan indicator other than '+'; > - Specification of a service selector other than 'E2U'; > - Specification of the root domain name other than 'e164.arpa'; > However, these specifications are outside of the scope of this document. It > is > envisioned that other numbering plan indicators and service selectors will > be > defined in a future document to accommodate multiple numbering plans using > the > same ENUM mechanism. " > > The language above is rough, as they are coming out of the top of my head. > Please feel free to make modifications as you see fit. > > Not that I am stubborn, but I do feel that if we are to define > 'numberplan+digits' as the generic structure for the input string to NAPTR, > it > is better to change '+digits' to 'e164+digits' _now_ than later. I am more > concerned about the massive number of NAPTR RRs to be populated in the DNS > databases after this document becomes an RFC. As we have already seen, the > input string format does dictate the regexp format in a NAPTR RR. Why is it > so > difficult to change? Anyway, I will accept the consensus of the group. > > Richard Shockey wrote: > > > >If we are to adopt the 'numberplan+digits' as the generic structure for > > >ENUM-like > > >Application Unique String, then for E.164, I suggest we do it all the > way, > > >such as > > >'e164+digits' as the input string to NAPTR. If we decide to use '+' as it > > >is, then > > >I suggest that a paragraph be added in the document clarifying the > > >semantics of > > >'+' as a numbering plan indicator. > > > > Lets assume, for purposes of argument that '+' remains for the time > > being. Is there any language you'd like to suggest here... about the > usage > > of '+' ambiguous or unambiguous but leaving the door open for > > enhancements in a future ID, which I'd hope you'd write? :-) > > > > Sure, I will write an ID addressing extension issues for the next IETF > meeting, > with some other folks who are interested in this topic. > > Regards, > > --Hong > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Aug 14 02:06:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01141 for ; Mon, 14 Aug 2000 02:06:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08370; Mon, 14 Aug 2000 02:06:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08341 for ; Mon, 14 Aug 2000 02:06:01 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01134 for ; Mon, 14 Aug 2000 02:06:01 -0400 (EDT) Received: from research.telcordia.com (mmc-11-as5200-d24.cc.telcordia.com [128.96.11.24]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7E5oVR17124; Mon, 14 Aug 2000 01:50:31 -0400 (EDT) Message-ID: <399788A8.B714B81F@research.telcordia.com> Date: Mon, 14 Aug 2000 01:50:32 -0400 From: Hong Liu Organization: Telcordia Technologies Applied Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: paf@cisco.com CC: enum@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] Clarifications on E2U Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Patrik, I have the following questions regarding the definition of E2U in the protocol document, most of which are of editorial nature: (1) Output: One or more URLs Do you mean one or more URIs? (2) Error Conditions: a) E.164 number not in the numbering plan Do you mean the E.164 number is not in use or it is not a valid E.164 number? b) E.164 number in the numbering plan, but no URLs exist for that number Do you mean that the E.164 number is not listed? Should URL be URI? c) Service unavailable Do you mean that the NAPTR RRs returned do not contain the service E2U? (3) Is it necessary to add IANA considerations for registration of such services? Thanks for the clarifications, --Hong _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Aug 14 09:56:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08554 for ; Mon, 14 Aug 2000 09:56:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12782; Mon, 14 Aug 2000 09:55:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12752 for ; Mon, 14 Aug 2000 09:55:49 -0400 (EDT) Received: from NETSOL-NIC-EX03.prod.netsol.com ([216.168.234.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08536 for ; Mon, 14 Aug 2000 09:55:48 -0400 (EDT) Received: by netsol-nic-ex03.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Aug 2000 09:51:34 -0400 Message-ID: From: "Conley, Pat" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , Hong Liu Cc: "Manfredi, Albert E" , "'enum@ietf.org'" , "Mealling, Michael" , james.yu@neustar.com Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Mon, 14 Aug 2000 09:51:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA12753 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit (a) "+" makes sense More future flexibility... almost no cost -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Friday, August 11, 2000 1:23 PM To: Hong Liu Cc: Manfredi, Albert E; 'enum@ietf.org'; michaelm@netsol.com; james.yu@neustar.com Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt At 10.33 -0400 00-08-11, Hong Liu wrote: >(3) Regarding the current document, the only change I suggested, including a >few others, is just to remove the '+' from the input string. This is _not_ a >very significant change. I don't see it in anyway will delay the document >from becoming an RFC because of that. Can everyone that do care please let me know ASAP whether: (a) You think the '+' makes sense (b) You think the '+' should go away Just be clear in your email (no arguments or explanation on why you think one way or another), and I can help the wg chair and the AD to find consensus. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Aug 14 10:18:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09323 for ; Mon, 14 Aug 2000 10:18:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13201; Mon, 14 Aug 2000 10:18:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13174 for ; Mon, 14 Aug 2000 10:18:18 -0400 (EDT) Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09318 for ; Mon, 14 Aug 2000 10:18:16 -0400 (EDT) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA21280 for ; Mon, 14 Aug 2000 10:18:17 -0400 (EDT) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA17544; Mon, 14 Aug 2000 10:15:20 -0400 (EDT) Received: from buzz.ons.octel.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr) id KAA06466 for ; Mon, 14 Aug 2000 10:15:17 -0400 (EDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id JAA26067; Mon, 14 Aug 2000 09:15:07 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 14 Aug 2000 09:10:33 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F413370405109E@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: Hong Liu Cc: Richard Shockey , michaelm@netsol.com, =?ISO-8859-1?Q?Patrik__F=E4ltstr=F6m?= , "Manfredi, Albert E" , "'enum@ietf.org'" , Scott Bradner , mankin@east.isi.edu Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Date: Mon, 14 Aug 2000 09:10:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA13175 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit >The problem here is the 'disconnect' between the client who lauches the query, >and the user who provisions the NAPTR RRs. Both have a way to ignore the >numbering plan if they choose to, but neither can assume what the other side may >do. To make the NAPTR algorithm work, I would think that the burden should be >put on the shoulder of the user who provisions the RRs. In this way, the client >always starts with some numbering plan according to the digits received, the >user can consolidate the records for all numbering plans if he/she chooses to do >so. You have nailed the crux of the problem for the existing ENUM document. We need to clearly define the behavior of the client upon receipt of NAPTR's that have unrecognized components. Which which unrecognized components are "errors" and which are "extensions" need to be clearly identified to use this mechanism in more interesting ways going forward. The easiest resolution seems to be to indicate that E2U can only be used for E164 numbers, and drop the "+". The "+" without defined semantics is at best useless and at worst a limitation on future extensibility. Vague references in email to using the "+" in the future to somehow distinguish between address completion and ENUM resolution are not adequate. Greg V. -----Original Message----- From: Hong Liu [mailto:lhong@research.telcordia.com] Sent: Saturday, August 12, 2000 10:50 AM To: Vaudreuil, Greg M (Greg) Cc: Richard Shockey; michaelm@netsol.com; Patrik Fältström; Manfredi, Albert E; 'enum@ietf.org'; Scott Bradner; mankin@east.isi.edu Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt Greg, You have raised a number of good points. I have some additional comments in between the lines below. Cheers, --Hong "Vaudreuil, Greg M (Greg)" wrote: > I am also concerned with the number of NAPTR records that may proliferate if > we require a separate service selector for each numbering plan. In my > previous example where a typical corporate node may have four numbering plan > entries, (164, corporate-wide private, local site extension, national) we > need to consider that multiplied by say six services for 24 records! In most > cases, the resulting URL does not depend upon the input string, that is, it > does not matter what number or dialplan was used to find it. > The issue here is how fine-grained we want to differentiate the services offered by ENUM. In general, the numbering plan indicator provides more detailed information than the corresponding service selector. What I have in mind is the following: (1) For each numbering plan defined by ITU-T, say E.xxx, define exxx+digits as the numbering plan indicator and ExxxToU as the service selector; (2) For each national numbering plan, define YY+digits as the numbering plan indicator and YYtoU as the service selector. Here YY is the two letters for each country as defined by ISO 3166; (3) For other corporate or private numbering plans, define a 'private' numbering plan indicator and use something like 'P2U' as the service selector; Note here 'P2U' serves as a generic service selector for private number to URI mapping. (1) and (2) can be standardized easily, using the schemes already established by other standards bodies. For (3), we probably do not, and cannot, standardize the plan indicator for two reasons: first, it is 'private' anyway; second, there are two many of them. Note that it is the numbering plan indicator, not the service selector, that makes the NAPTR RRs different, i.e., the regexp part. If you can find a way to combine different numbering plans into a single regexp, consolidating service selectors is easy, just use the '+', e.g. 'mailto+E2U+US2U+P2U'. > > I would like to see E2U explicitly support other numbering plans. This can > be done by noting that + is the dialplan separator. If no dialplan is > indicated, then the NAPTR applies to all numbering plans. If a particular > NATPR record is intended to be limited to only E164 numbers, than the E164 > dialplan indicator is explicitly indicated with e164+digits. > > If an unknown dialplan is indicated in the returned NAPTR record, the record > is ignored (No match is found). > Basically, you have suggested two things here: (1) Overload or generalize the semantics of 'E2U' from 'E.164 to URI' to 'Telephone Number to URI'. This is a very good idea in that we do not need to worry about choosing different service selectors when using ENUM. If the WG decides to go this route, then I suggest we use a different name instead, such as 'T2U' because 'E2U' suggests something for E.164. I don't use 'N2U' since I do not want to confuse that with existing URN service selectors such as 'N2I'. (2) The default or 'ANY/ALL' construct for all numbering plans. This is also a very good idea for consolidating different NAPTR RRs when we don't care which numbering plan is used to reach those records. However, I see one problem: it assumes that the client knows a priori what the NAPTR RRs look like before it launches the query, i.e., the regexp in the NAPTR RR ignores the numbering plan indicator. On the other hand, you can always write a regexp in such a way that it ignores anything upto the '+' (and including '+') in the input string to accomplish the same goal. The problem here is the 'disconnect' between the client who lauches the query, and the user who provisions the NAPTR RRs. Both have a way to ignore the numbering plan if they choose to, but neither can assume what the other side may do. To make the NAPTR algorithm work, I would think that the burden should be put on the shoulder of the user who provisions the RRs. In this way, the client always starts with some numbering plan according to the digits received, the user can consolidate the records for all numbering plans if he/she chooses to do so. > > Note that this is completely compatable with the existing proposal. Because > only E164 is discussed, a default for all dialplans behaves as the current > text. > > Greg V. > > -----Original Message----- > From: Hong Liu [mailto:lhong@research.telcordia.com] > Sent: Friday, August 11, 2000 10:51 PM > To: Richard Shockey > Cc: michaelm@netsol.com; Patrik Fältström; Manfredi, Albert E; > 'enum@ietf.org'; Scott Bradner; mankin@east.isi.edu > Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt > > Richard, Patrik, and others, > > Thanks for the nice comments. I personally learned a lot from the email > exchanges in the last few days. Assuming that we will leave '+' as it is in > the > document, then I would like to add a note at the end of the ENUM procedure, > i.e. Section 2, as something like the following: > > "Note: The output of Step 2 above, i.e., an E.164 number without any > characters > but the leading '+' and digits, is the input string to the NAPTR algorithm. > The > leading '+' is the E.164 numbering plan indicator, which SHALL be used in > conjuction with the service selector E2U defined in Section 3.1.2 in all > NAPTR > resource records with a non-empty service field for E.164 to URI mapping. > > Other numbering plans MAY make use of the ENUM procedure defined above for > telephone number to URI mapping with the following modifications: > - Specification of an unique numbering plan indicator other than '+'; > - Specification of a service selector other than 'E2U'; > - Specification of the root domain name other than 'e164.arpa'; > However, these specifications are outside of the scope of this document. It > is > envisioned that other numbering plan indicators and service selectors will > be > defined in a future document to accommodate multiple numbering plans using > the > same ENUM mechanism. " > > The language above is rough, as they are coming out of the top of my head. > Please feel free to make modifications as you see fit. > > Not that I am stubborn, but I do feel that if we are to define > 'numberplan+digits' as the generic structure for the input string to NAPTR, > it > is better to change '+digits' to 'e164+digits' _now_ than later. I am more > concerned about the massive number of NAPTR RRs to be populated in the DNS > databases after this document becomes an RFC. As we have already seen, the > input string format does dictate the regexp format in a NAPTR RR. Why is it > so > difficult to change? Anyway, I will accept the consensus of the group. > > Richard Shockey wrote: > > > >If we are to adopt the 'numberplan+digits' as the generic structure for > > >ENUM-like > > >Application Unique String, then for E.164, I suggest we do it all the > way, > > >such as > > >'e164+digits' as the input string to NAPTR. If we decide to use '+' as it > > >is, then > > >I suggest that a paragraph be added in the document clarifying the > > >semantics of > > >'+' as a numbering plan indicator. > > > > Lets assume, for purposes of argument that '+' remains for the time > > being. Is there any language you'd like to suggest here... about the > usage > > of '+' ambiguous or unambiguous but leaving the door open for > > enhancements in a future ID, which I'd hope you'd write? :-) > > > > Sure, I will write an ID addressing extension issues for the next IETF > meeting, > with some other folks who are interested in this topic. > > Regards, > > --Hong > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Aug 14 12:07:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13457 for ; Mon, 14 Aug 2000 12:07:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15057; Mon, 14 Aug 2000 12:06:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15027 for ; Mon, 14 Aug 2000 12:06:51 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13426 for ; Mon, 14 Aug 2000 12:06:49 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA22603 for ; Mon, 14 Aug 2000 12:06:50 -0400 (EDT) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA22597 for ; Mon, 14 Aug 2000 12:06:50 -0400 (EDT) Received: from buzz.ons.octel.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr) id MAA20923 for ; Mon, 14 Aug 2000 12:06:49 -0400 (EDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id LAA02270 for ; Mon, 14 Aug 2000 11:06:49 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 14 Aug 2000 11:02:14 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F41337040510A5@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: "'enum@ietf.org'" Date: Mon, 14 Aug 2000 11:02:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Enum] Itternation in ENUM, a disconnect with DDDS? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I have been working on a number of "use cases" with ENUM and discovered I don't know how to do a number of common numbering-plan actions using NAPTRs. Is this a major issue? 1) Renumbering: The telephone system (at least in the US) frequently renumbers entire blocks of numbers to use another prefix. This is commonly called "area code split". When doing such a split, there is typically a period of "permissive dialing" where one can dial either a new number or the older number. In the cases I am most familiar with, the renaming changes a prefix. (I have seen in other countries where new digits are added or where digits may even be deleted ... I have no idea if there is a "permissive" interval in these transitions) In DNS, the DNAME record provides a perfect fit structurally, by enabling an entry in the DNS that results in a DNS prefix substitution and a new query. However, this power does not assist in the construction of the correct URI from the retreived NAPTRs. Using DNAME, one can have two paths to reach the same node in the tree. If the resulting URI has telephone number components within it, the NAPTR replacment algoritm potentially needs to be different for each of the two paths, in one case replacing an "old" prefix and in the other, not. Where in "normal" DNS, the substitution and re-query with Cnames and Dnames is transparent to the client, in ENUM using NAPTRs, it is not. So, rather than using DNAMEs, I figured you could use NAPTRs and use itteration to get the "preferred" number, and then requery. The DDDS logic supports the itterative query and ultimately returns the approprate set of NAPTRs... But because the Regexp applies to the ORIGINAL string, it did not solve the problem, it simply pushed more work on the client. When I try to apply the regexp to derive the URI, there is a good chance based on the query path that the right substitution won't happen. 2) Address Completion: While this is technically out-of-scope, we have been making design decisions based on being able to apply different Regexp logic to E164 and incomplete e164 numbers. (Whether to keep or ditch the "+".) If one queries using an incomplete number using a locally significant DNS root, such as 1.1.2.3.4.5.6.7.8.9.nanp.us, one could be returned a NAPTR record with a regexp that results in a full e164 number and causes a subsequent query for the complete e164 record 1.1.2.3.4.5.6.7.8.9.1.e164.arpa. So far, easy and useful. However, I encounter the same problem as above. Again, assuming the URI has telephone number components within it, the E164 node needs to potentially have two NAPTR entries, one for each of the two paths used to retreive the records. The poor sucker trying to make his IPtelephone work now needs to figure out all the possible paths to construct a rule-set that reliably works. When combined with short digit (local) dialing and private numbering, we can end up with tens of NAPTR records for a few simple services. There are a number of other interesting examples in this space... For ENUM, it seems clear to me we need to provide a variation on DDDS that permits the query itterations to modify the initial string, not just the query. Without it, each end-node, each NAPTR record set needs to be modified each time there is a structural change or addition to the numbering plan..... Can we modify the rules to say that the replacement algorithm applies to an "un-dot-stuffed, un-prefixed" DNS string returned in the NAME field of the DNS response containing the NAPTRs? It seems that would work for at least the two examples above, using either DNAME, CNAME, or other NAPTR itteration. Comments? Greg V. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Aug 15 03:38:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09232 for ; Tue, 15 Aug 2000 03:38:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29583; Tue, 15 Aug 2000 03:37:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29552 for ; Tue, 15 Aug 2000 03:37:45 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09226 for ; Tue, 15 Aug 2000 03:37:42 -0400 (EDT) Received: from [193.150.249.245] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id AAA27071; Tue, 15 Aug 2000 00:36:57 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <399788A8.B714B81F@research.telcordia.com> References: <399788A8.B714B81F@research.telcordia.com> Date: Tue, 15 Aug 2000 09:27:56 +0200 To: Hong Liu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] Clarifications on E2U Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 01.50 -0400 00-08-14, Hong Liu wrote: >(1) Output: One or more URLs >Do you mean one or more URIs? Correct. All occurences of "URL" will be changed to "URI". >(2) Error Conditions: >a) E.164 number not in the numbering plan >Do you mean the E.164 number is not in use or it is not a valid E.164 >number? Not a number in the numbering plan for whatever reasons. I.e. some number which a user claim is a E.164 number which there is no NAPTR RR. From my perspective, it doesn't matter what the problem is. If a "dialogue" asks me on a webpage to enter a E.164 number, and I enter "+123", what kind of problem is that? From the softwares perspective, no NAPTR is in DNS for various reasons. >b) E.164 number in the numbering plan, but no URLs exist for that number > >Do you mean that the E.164 number is not listed? Should URL be URI? A number which is correct (for example by having (a) above, but the software knows by checking the assignment plans that a E.164 is valid, is in use, but no NAPTR exist in DNS. >c) Service unavailable >Do you mean that the NAPTR RRs returned do not contain the service E2U? No, that the URL which is in the NAPTR "doesn't work". >(3) Is it necessary to add IANA considerations for registration of such >services? No. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Aug 15 03:40:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09260 for ; Tue, 15 Aug 2000 03:40:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29648; Tue, 15 Aug 2000 03:39:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29623 for ; Tue, 15 Aug 2000 03:39:03 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09244 for ; Tue, 15 Aug 2000 03:39:01 -0400 (EDT) Received: from [193.150.249.245] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id AAA27162; Tue, 15 Aug 2000 00:37:46 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <6B57F36F4FF9D111B30A0008C7F41337040510A5@exdal1.ons.octel.com> References: <6B57F36F4FF9D111B30A0008C7F41337040510A5@exdal1.ons.octel.com> Date: Tue, 15 Aug 2000 09:34:29 +0200 To: "Vaudreuil, Greg M (Greg)" , "'enum@ietf.org'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] Itternation in ENUM, a disconnect with DDDS? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11.02 -0500 00-08-14, Vaudreuil, Greg M (Greg) wrote: >But because the Regexp applies to the ORIGINAL string, it did not >solve the problem, it simply pushed more work on the client. When I try to >apply the regexp to derive the URI, there is a good chance based on the >query path that the right substitution won't happen. I agree it would be interesting to both be able to change the orginal string and give back the next domainname to use. But that is not the case. So, one have to in the terminal NAPTR write a regexp which matches all different kind of input strings, and one common one is '.*', i.e. match everything. >2) Address Completion: > >If one queries using an incomplete number using a locally significant DNS >root, such as 1.1.2.3.4.5.6.7.8.9.nanp.us, one could be returned a NAPTR >record with a regexp that results in a full e164 number and causes a >subsequent query for the complete e164 record >1.1.2.3.4.5.6.7.8.9.1.e164.arpa. So far, easy and useful. > >However, I encounter the same problem as above. Again, assuming the URI has >telephone number components within it, the E164 node needs to potentially >have two NAPTR entries, one for each of the two paths used to retreive the >records. The poor sucker trying to make his IPtelephone work now needs to >figure out all the possible paths to construct a rule-set that reliably >works. When combined with short digit (local) dialing and private >numbering, we can end up with tens of NAPTR records for a few simple >services. Well, I rather think the NAPTR should look like: 1.1.2.3.4.5.6.7.8.9.1.e164.arpa. IN NAPTR "U" "E2U+LDAP" "!(.*)!ldap://....\1" . ...where the .... is replaced by a correct LDAP URI content. You can also do 1.1.2.3.4.5.6.7.8.9.1.e164.arpa. IN NAPTR "U" "mailto+E2U" "!(.*)!mailto:\1@foo.se" . etc etc I.e. in some cases it is a good thing to keep the orginal string. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Aug 15 10:33:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15890 for ; Tue, 15 Aug 2000 10:33:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03781; Tue, 15 Aug 2000 10:31:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03760 for ; Tue, 15 Aug 2000 10:31:55 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15869 for ; Tue, 15 Aug 2000 10:31:53 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA27018 for ; Tue, 15 Aug 2000 10:31:50 -0400 (EDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA26986; Tue, 15 Aug 2000 10:31:50 -0400 (EDT) Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr) id JAA13296 for ; Tue, 15 Aug 2000 09:31:46 -0500 (CDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id JAA11648; Tue, 15 Aug 2000 09:31:46 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Aug 2000 09:27:12 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F41337040510CC@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "'enum@ietf.org'" Subject: RE: [Enum] Itternation in ENUM, a disconnect with DDDS? Date: Tue, 15 Aug 2000 09:27:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA03761 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit In both examples you provided, the substitution only works if it is trivial, that is, if the replacement string completely replaces the original string. The current draft permits much more interesting and non-interoperable combinations. For a typical corporate network, want to set up NAPTR entries representing services at a given site. The following would be an expected set: *.dallas.num.lucent.com IN NAPTR "U" "mailto+E2U" "!(.*)mailto:\+19727332\1@@lucent.com" . IN NAPTR "U" "mailto+E2U" "!(.*)LDAP:\LDAP.lucent.com/cn=+19727332\1@" . IN NAPTR "U" "tel+E2U" "!(.*)tel:+19727332\1@!" . *.7.2.3.3.7.2.7.9.1.e164.arpa IN DNAME: dallas.num.lucent.com *.nanp.us IN DNAME: 1.e164.arpa If the origional String: 2722 queried as 2.2.7.2.dallas.num.lucent.com, it would yield: +19727332722@lucent.com. If the original string was +19727332722, queried as 2.2.7.2.3.3.7.2.7.9.1.e164.arpa, it would yield: +1972733+19727332722@lucent.com If the original string was +727332722, queried as 2.2.7.2.3.3.7.2.7.9.nanp.us, it would yield: +19727339727332722@lucent.com ...Three different results for the same number. I do not believe duplicating the rule-set at each leaf-node in the DNS tree or placing multiple NAPTRs for each path at each leaf-node are acceptable answers. The alternatives seem: 1) Permit only trivial regexp (replacement only) in NAPTR for ENUM 2) Permit only trivial DNS structures, limit DNS structures to only include one path to a given node i.e., no DNAME, CNAME, or itterative NAPTR 3) Carefully describe the interactions between interesting Regexp and DNS structure..... It was not obvious to me. 4) Extend / Change NAPTR for ENUM to take advantage of DNS structures by permiting use of the NAME field in DNS responses in the construction of the URI. I prefer 4 because it provides useful expressive power while dramatically simplying the provisioning and configuration of real-world ENUM services. Am I making sense? Greg V. -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Tuesday, August 15, 2000 2:34 AM To: Vaudreuil, Greg M (Greg); 'enum@ietf.org' Subject: Re: [Enum] Itternation in ENUM, a disconnect with DDDS? At 11.02 -0500 00-08-14, Vaudreuil, Greg M (Greg) wrote: >But because the Regexp applies to the ORIGINAL string, it did not >solve the problem, it simply pushed more work on the client. When I try to >apply the regexp to derive the URI, there is a good chance based on the >query path that the right substitution won't happen. I agree it would be interesting to both be able to change the orginal string and give back the next domainname to use. But that is not the case. So, one have to in the terminal NAPTR write a regexp which matches all different kind of input strings, and one common one is '.*', i.e. match everything. >2) Address Completion: > >If one queries using an incomplete number using a locally significant DNS >root, such as 1.1.2.3.4.5.6.7.8.9.nanp.us, one could be returned a NAPTR >record with a regexp that results in a full e164 number and causes a >subsequent query for the complete e164 record >1.1.2.3.4.5.6.7.8.9.1.e164.arpa. So far, easy and useful. > >However, I encounter the same problem as above. Again, assuming the URI has >telephone number components within it, the E164 node needs to potentially >have two NAPTR entries, one for each of the two paths used to retreive the >records. The poor sucker trying to make his IPtelephone work now needs to >figure out all the possible paths to construct a rule-set that reliably >works. When combined with short digit (local) dialing and private >numbering, we can end up with tens of NAPTR records for a few simple >services. Well, I rather think the NAPTR should look like: 1.1.2.3.4.5.6.7.8.9.1.e164.arpa. IN NAPTR "U" "E2U+LDAP" "!(.*)!ldap://....\1" . ...where the .... is replaced by a correct LDAP URI content. You can also do 1.1.2.3.4.5.6.7.8.9.1.e164.arpa. IN NAPTR "U" "mailto+E2U" "!(.*)!mailto:\1@foo.se" . etc etc I.e. in some cases it is a good thing to keep the orginal string. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Aug 15 13:51:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20378 for ; Tue, 15 Aug 2000 13:51:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06337; Tue, 15 Aug 2000 13:51:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06306 for ; Tue, 15 Aug 2000 13:51:38 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20363; Tue, 15 Aug 2000 13:51:30 -0400 (EDT) Message-Id: <200008151751.NAA20363@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: enum@ietf.org From: The IESG Date: Tue, 15 Aug 2000 13:51:30 -0400 Subject: [Enum] Protocol Action: E.164 number and DNS to Proposed Standard Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org The IESG has approved the Internet-Draft 'E.164 number and DNS' as a Proposed Standard. This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary This document defines a way to use the DNS for storage of E.164 numbers. More specifically, it defines how DNS can be used for identifying available services related to one E.164 number. Routing of any actual connections using the service selected using these methods is not discussed. Through transformation of E.164 numbers into DNS names and the use of existing DNS services like delegation through NS records, and use of NAPTR records in DNS, one can look up what services are available for a specific domainname in a decentralized way with distributed management of the different levels in the lookup process. The process results in one or more Uniform Resource Identifiers being returned to the requester to identify the available services. Working Group Summary This proposal was supported by the enum working group and no significant issues were raised during IETF last call. Protocol Quality The document was reviewed by Scott Bradner for the IESG. Notes to RFC Editor: Prior to publication, please (1) Replace the string "URL" with "URI" (4 occurrances in Section 3.1.2 and 1 in Appendix A (2) Please change the following text in the IANA Consideration Section (section 4): From: Delegations should be done after Expert Review, and the IESG will appoint a designated expert. to: Delegations in the zone e614.arpa (not delegations in delegated domains of e164.arpa) should be done after Expert Review, and the IESG will appoint a designated expert. (3) Please change second paragraph in section 5: From: The caching in DNS can make the propagation time for a change take the same amount of time as the time to live for the NAPTR and SRV[10] records in the zone that is changed. The TTL should because of that be kept to a minimum. The use of this in an environment where IP-addresses are for hire (for example when using DHCP[11]) must therefore be done very carefully. to: The caching in DNS can make the propagation time for a change take the same amount of time as the time to live for the NAPTR record in the zone that is changed. The use of this in an environment where IP-addresses are for hire (for example when using DHCP[11]) must therefore be done very carefully. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Aug 15 14:45:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21769 for ; Tue, 15 Aug 2000 14:45:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07153; Tue, 15 Aug 2000 14:45:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07124 for ; Tue, 15 Aug 2000 14:45:09 -0400 (EDT) Received: from picard.noroff.no ([212.20.204.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21762 for ; Tue, 15 Aug 2000 14:45:06 -0400 (EDT) Received: by picard.noroff.no (Postfix, from userid 815) id 28E222201F; Tue, 15 Aug 2000 21:29:54 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id 11754B3802 for ; Tue, 15 Aug 2000 21:29:52 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA23906 for ietf-123-outbound.09@ietf.org; Tue, 15 Aug 2000 13:55:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id NAA23884 for ; Tue, 15 Aug 2000 13:51:32 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20363; Tue, 15 Aug 2000 13:51:30 -0400 (EDT) Message-Id: <200008151751.NAA20363@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: enum@ietf.org From: The IESG Date: Tue, 15 Aug 2000 13:51:30 -0400 X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 Subject: [Enum] Protocol Action: E.164 number and DNS to Proposed Standard Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org The IESG has approved the Internet-Draft 'E.164 number and DNS' as a Proposed Standard. This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary This document defines a way to use the DNS for storage of E.164 numbers. More specifically, it defines how DNS can be used for identifying available services related to one E.164 number. Routing of any actual connections using the service selected using these methods is not discussed. Through transformation of E.164 numbers into DNS names and the use of existing DNS services like delegation through NS records, and use of NAPTR records in DNS, one can look up what services are available for a specific domainname in a decentralized way with distributed management of the different levels in the lookup process. The process results in one or more Uniform Resource Identifiers being returned to the requester to identify the available services. Working Group Summary This proposal was supported by the enum working group and no significant issues were raised during IETF last call. Protocol Quality The document was reviewed by Scott Bradner for the IESG. Notes to RFC Editor: Prior to publication, please (1) Replace the string "URL" with "URI" (4 occurrances in Section 3.1.2 and 1 in Appendix A (2) Please change the following text in the IANA Consideration Section (section 4): From: Delegations should be done after Expert Review, and the IESG will appoint a designated expert. to: Delegations in the zone e614.arpa (not delegations in delegated domains of e164.arpa) should be done after Expert Review, and the IESG will appoint a designated expert. (3) Please change second paragraph in section 5: From: The caching in DNS can make the propagation time for a change take the same amount of time as the time to live for the NAPTR and SRV[10] records in the zone that is changed. The TTL should because of that be kept to a minimum. The use of this in an environment where IP-addresses are for hire (for example when using DHCP[11]) must therefore be done very carefully. to: The caching in DNS can make the propagation time for a change take the same amount of time as the time to live for the NAPTR record in the zone that is changed. The use of this in an environment where IP-addresses are for hire (for example when using DHCP[11]) must therefore be done very carefully. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Aug 15 18:00:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28506 for ; Tue, 15 Aug 2000 18:00:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09496; Tue, 15 Aug 2000 17:59:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09460 for ; Tue, 15 Aug 2000 17:58:59 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28392 for ; Tue, 15 Aug 2000 17:58:56 -0400 (EDT) Received: from [193.150.249.245] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id OAA26218; Tue, 15 Aug 2000 14:58:16 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <6B57F36F4FF9D111B30A0008C7F41337040510CC@exdal1.ons.octel.com> References: <6B57F36F4FF9D111B30A0008C7F41337040510CC@exdal1.ons.octel.com> Date: Tue, 15 Aug 2000 23:51:12 +0200 To: "Vaudreuil, Greg M (Greg)" , "'enum@ietf.org'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] Itternation in ENUM, a disconnect with DDDS? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 09.27 -0500 00-08-15, Vaudreuil, Greg M (Greg) wrote: >*.dallas.num.lucent.com > > IN NAPTR "U" "mailto+E2U" "!(.*)mailto:\+19727332\1@@lucent.com" . > IN NAPTR "U" "mailto+E2U" "!(.*)LDAP:\LDAP.lucent.com/cn=+19727332\1@" . > IN NAPTR "U" "tel+E2U" "!(.*)tel:+19727332\1@!" . First, these are not syntactically correct regular expressions, and secondly, given the way ENUM is written at the moment, you have either multiple regexps, like (I corrected the regexp errors): IN NAPTR "U" "mailto+E2U" "![^+](.*)!mailto:+19727332\1@lucent.com!" . IN NAPTR "U" "mailto+E2U" "!+(.*)!mailto:+\1@lucent.com!" . I.e. given that people know the rules, it is not hard to make regexps that work. So, the original question was whether you need to know "what paths" have been taken, and my response is "yes" you need to know that. But, does it matter? paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 16 01:35:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11417 for ; Wed, 16 Aug 2000 01:35:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20771; Wed, 16 Aug 2000 01:35:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20746 for ; Wed, 16 Aug 2000 01:35:12 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10524; Wed, 16 Aug 2000 01:30:15 -0400 (EDT) Received: from [193.150.249.245] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id WAA07571; Tue, 15 Aug 2000 22:29:39 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: Date: Wed, 16 Aug 2000 07:17:16 +0200 To: enum@ietf.org, IESG From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Paragraph addition due to last-call-comments, draft-ietf-enum-e164-dns Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org In discussions between myself, the chair of the working group and the area director in charge, we have made the decision that the discussions on the mailing list concludes that we want the following paragraph added: >2.1 Special note about the '+' > >The '+' is kept in stage 2 in section 2 to flag that the number which >the regular expression is operating on is a E.164 number. Future work >will be needed to determine how other numbering plans (such as closed >ones) might be identified. It is possible, but not definite, that they >would use a similar mechanism as the one described in this document. This is based on the fact that people want to have clearifications about why the '+' is there, but there is definitely not consensus in the wg to remove the '+'. A majority of the comments I got back in private email was in favour of keeping the '+'. I will ask this paragraph to be added. Patrik Faltstrom Document Editor _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 16 06:51:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21631 for ; Wed, 16 Aug 2000 06:51:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23785; Wed, 16 Aug 2000 06:50:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23757 for ; Wed, 16 Aug 2000 06:50:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21606; Wed, 16 Aug 2000 06:49:59 -0400 (EDT) Message-Id: <200008161049.GAA21606@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 16 Aug 2000 06:49:59 -0400 Subject: [Enum] I-D ACTION:draft-pfautz-na-enum-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Administrative Requirements for Deployment of ENUM in North America Author(s) : P. Pfautz Filename : draft-pfautz-na-enum-00.txt Pages : 6 Date : 15-Aug-00 This document discusses a number of the administrative issues that must be resolved before effective deployment of ENUM[2,3] services in complex environments with number portability and multiple providers for using DNS for translation of E.164 (telephone) numbers. North America is examined critically because its environment may be more complex than most and because current deregulation trends may drive other countries/regions in similar directions. In particular the current mechanisms for number administration and number portability in North America will require establishment of a new administrative function for managing the domain name entries for ported numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-na-enum-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pfautz-na-enum-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-pfautz-na-enum-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000815110712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pfautz-na-enum-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pfautz-na-enum-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000815110712.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 16 08:38:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23411 for ; Wed, 16 Aug 2000 08:38:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24868; Wed, 16 Aug 2000 08:36:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24839 for ; Wed, 16 Aug 2000 08:36:37 -0400 (EDT) Received: from picard.noroff.no ([212.20.204.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23391 for ; Wed, 16 Aug 2000 08:36:33 -0400 (EDT) Received: by picard.noroff.no (Postfix, from userid 815) id E971722003; Wed, 16 Aug 2000 15:21:24 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id A5C14B3802 for ; Wed, 16 Aug 2000 15:21:22 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA26651 for ietf-123-outbound.09@ietf.org; Wed, 16 Aug 2000 07:45:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA26358 for ; Wed, 16 Aug 2000 06:49:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21606; Wed, 16 Aug 2000 06:49:59 -0400 (EDT) Message-Id: <200008161049.GAA21606@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Wed, 16 Aug 2000 06:49:59 -0400 X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 Subject: [Enum] I-D ACTION:draft-pfautz-na-enum-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Administrative Requirements for Deployment of ENUM in North America Author(s) : P. Pfautz Filename : draft-pfautz-na-enum-00.txt Pages : 6 Date : 15-Aug-00 This document discusses a number of the administrative issues that must be resolved before effective deployment of ENUM[2,3] services in complex environments with number portability and multiple providers for using DNS for translation of E.164 (telephone) numbers. North America is examined critically because its environment may be more complex than most and because current deregulation trends may drive other countries/regions in similar directions. In particular the current mechanisms for number administration and number portability in North America will require establishment of a new administrative function for managing the domain name entries for ported numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-na-enum-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pfautz-na-enum-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-pfautz-na-enum-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000815110712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pfautz-na-enum-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pfautz-na-enum-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000815110712.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Aug 21 04:01:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28284 for ; Mon, 21 Aug 2000 04:01:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27760; Mon, 21 Aug 2000 03:58:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27733 for ; Mon, 21 Aug 2000 03:58:54 -0400 (EDT) Received: from esebh03nok.ntc.nokia.com (esebh03nok.ntc.nokia.com [131.228.118.244]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28195 for ; Mon, 21 Aug 2000 03:58:53 -0400 (EDT) From: john.loughney@nokia.com Received: by esebh03nok with Internet Mail Service (5.5.2650.10) id ; Mon, 21 Aug 2000 10:58:54 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DEE6C@eseis04nok> To: enum@ietf.org Date: Mon, 21 Aug 2000 10:58:51 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Enum] IETF 48 Meeting Minutes Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi all, Are the meeting minutes available? thanks, John _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Aug 23 09:39:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11394 for ; Wed, 23 Aug 2000 09:39:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11222; Wed, 23 Aug 2000 09:36:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11191 for ; Wed, 23 Aug 2000 09:36:31 -0400 (EDT) Received: from cqmx.corp.comsat.com (cqmx.corp.comsat.com [134.133.184.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11370 for ; Wed, 23 Aug 2000 09:36:31 -0400 (EDT) From: Andrew.Gallant@comsat.com Received: from cqgate5.cmc.comsat.com ([134.133.162.20]) by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 23 Aug 2000 09:35:42 -0400 Received: from ccMail by cqgate5.cmc.comsat.com (IMA Internet Exchange 3.13) id 001221E2; Wed, 23 Aug 2000 09:39:31 -0400 Mime-Version: 1.0 Date: Wed, 23 Aug 2000 09:39:45 -0400 Message-ID: <001221E2.C22277@comsat.com> To: enum@ietf.org Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit Subject: [Enum] follow-up: ISDN subaddresses are not part of E.164 numbers Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit There was a question on ISDN subaddresses and E.164 during the enum session in Pittsburgh. This email is a follow-up to that. Summary: ISDN subaddresses are not part of E.164 numbers. Details: 1. From some archives: a. I.331 = E.164, since sometimes Recs were/are dual-numbered. b. I.330 (11/88), "ISDN numbering and addressing principles". c. E.331 (10/91), "Minimum user-terminal interface for a human user entering address information into an ISDN terminal". 2. From I.330: "5.4.3 Special attention is drawn to the fact that subaddressing is not to be considered as part of the numbering plan, but constitutes an intrinsic part of ISDN addressing capabilities. The subaddress shall be conveyed in a transparent way as a separate entity from both ISDN number and user-to-user information. See also Recommendation I.334." This is consistent with the current E.164, in Annex B. 3. From E.331, Section 5: "The start of a dialled sub-address is indicated by a star ["*"] ... The end of a dialled address (including sub-address, if any ... ) is indicated by a square ["#"]." Conclusions: a. ISDN subaddresses are not part of E.164 numbers. b. Therefore, ISDN subaddresses are out of scope for enum. c. Outside the ISDN-specific realm, it's not clear what ISDN subaddresses mean, and you probably couldn't make them work uniformly in the PSTN (GSTN?) anyway. d. I wish I had thought of all that when the question came up. So for now, IMHO, case closed. -Andy andrew.gallant@lmco.com tel: +1 301-214-3264 fax: +1 301-214-7226 _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum