From daemon@optimus.ietf.org Mon Jun 3 13:38:30 2002 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 NAA25076 for ; Mon, 3 Jun 2002 13:38:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19647 for enum-archive@odin.ietf.org; Mon, 3 Jun 2002 13:38: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 NAA18879; Mon, 3 Jun 2002 13:27:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18847 for ; Mon, 3 Jun 2002 13:27:14 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24787 for ; Mon, 3 Jun 2002 13:26:45 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g53HQhc26208 for ; Mon, 3 Jun 2002 13:26:43 -0400 Message-Id: <5.1.0.14.2.20020603125252.024e35b0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Jun 2002 13:32:19 -0400 To: enum@ietf.org From: Richard Shockey Subject: Re: [Enum] EPP for E.164 - Start Last Call ??? In-Reply-To: <1C1EEC765F843E44996971A80682118B014B1427@opwinex02.corp.il luminet.com> 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 09:14 AM 5/23/2002 -0700, you wrote: >We want to bring to everyone's attention to the draft for provisioning >E.164 numbers using EPP in a registry >environment. >http://search.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-00.txt. >This draft was accepted as an ENUM working group item at the 53rd >IETF. We would like to solicit comments for this draft so we can make >changes, if necessary, to the draft before the June 24th cut off date for >the 54th IETF in Japan. We would like to move forward, as expediently as >possible, because the ENUM forum is very interested in having this draft >move to RFC before they adopt it into their provisioning process. I'd like to re-note this message sent to the list earlier and poll the list for any objections to taking this to Last Call as a Informational document ASAP. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Jun 4 08:03:59 2002 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 IAA24502 for ; Tue, 4 Jun 2002 08:03:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA23205 for enum-archive@odin.ietf.org; Tue, 4 Jun 2002 08:04: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 HAA22340; Tue, 4 Jun 2002 07:52:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21522 for ; Tue, 4 Jun 2002 07:44:45 -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 HAA23558; Tue, 4 Jun 2002 07:44:13 -0400 (EDT) Message-Id: <200206041144.HAA23558@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, 04 Jun 2002 07:44:13 -0400 Subject: [Enum] I-D ACTION:draft-stastny-enum-scenarios-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 : Scenarios for ENUM and ENUM-like Systems Author(s) : R. Stastny Filename : draft-stastny-enum-scenarios-00.txt Pages : 18 Date : 03-Jun-02 This document analyzes scenarios for ENUM and ENUM-like Systems, both for ENUM used by End Users and also for ENUM-like Systems used by operators for network-specific or infrastructure purposes. It also gives some examples of ENUM Usage and proposes a new URI scheme to be used with ENUM. This may allow a way forward for the definition of ENUM Services and also for the definition of the required URIs and their parameters. This document therefore deals with information stored in the ENUM and the look-up process and the usage of the information retived in this look up process. It does not deal with the administrative process related to the population of the relevant zones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stastny-enum-scenarios-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-stastny-enum-scenarios-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-stastny-enum-scenarios-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: <20020603130047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stastny-enum-scenarios-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-stastny-enum-scenarios-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020603130047.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Jun 4 10:16:29 2002 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 KAA29768 for ; Tue, 4 Jun 2002 10:16:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00847 for enum-archive@odin.ietf.org; Tue, 4 Jun 2002 10:16: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 KAA00391; Tue, 4 Jun 2002 10:07: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 KAA00363 for ; Tue, 4 Jun 2002 10:07:09 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29292 for ; Tue, 4 Jun 2002 10:06:38 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g54E6bc13573 for ; Tue, 4 Jun 2002 10:06:37 -0400 Message-Id: <5.1.0.14.2.20020604101200.045b93b8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Jun 2002 10:12:09 -0400 To: enum@ietf.org From: Richard Shockey Subject: Fwd: [Enum] I-D ACTION:draft-stastny-enum-scenarios-00.txt 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 >To: IETF-Announce: ; >CC: enum@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Date: Tue, 04 Jun 2002 07:44:13 -0400 >Subject: [Enum] I-D ACTION:draft-stastny-enum-scenarios-00.txt >Sender: enum-admin@ietf.org >X-Mailman-Version: 1.0 >List-Id: Enum Discussion List >X-BeenThere: enum@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Scenarios for ENUM and ENUM-like Systems > Author(s) : R. Stastny > Filename : draft-stastny-enum-scenarios-00.txt > Pages : 18 > Date : 03-Jun-02 > >This document analyzes scenarios for ENUM and ENUM-like Systems, both >for ENUM used by End Users and also for ENUM-like Systems used by >operators for network-specific or infrastructure purposes. It also >gives some examples of ENUM Usage and proposes a new URI scheme to be >used with ENUM. This may allow a way forward for the definition of >ENUM Services and also for the definition of the required URIs and >their parameters. >This document therefore deals with information stored in the ENUM and >the look-up process and the usage of the information retived in this >look up process. >It does not deal with the administrative process related to the >population of the relevant zones. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-stastny-enum-scenarios-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-stastny-enum-scenarios-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-stastny-enum-scenarios-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. >Content-Type: text/plain >Content-ID: <20020603130047.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-stastny-enum-scenarios-00.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Jun 5 12:01:20 2002 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 MAA04662 for ; Wed, 5 Jun 2002 12:01:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15986 for enum-archive@odin.ietf.org; Wed, 5 Jun 2002 12:01: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 LAA14363; Wed, 5 Jun 2002 11:51: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 LAA14334 for ; Wed, 5 Jun 2002 11:51:09 -0400 (EDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04238 for ; Wed, 5 Jun 2002 11:50:36 -0400 (EDT) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA01703; Wed, 5 Jun 2002 08:54:12 -0700 Message-Id: <5.1.1.2.2.20020605084828.03327c48@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 05 Jun 2002 08:49:35 -0700 To: Richard Shockey From: Dave Crocker Subject: Re: [Enum] EPP for E.164 - Start Last Call ??? Cc: enum@ietf.org In-Reply-To: <5.1.0.14.2.20020603125252.024e35b0@popd.ix.netcom.com> References: <1C1EEC765F843E44996971A80682118B014B1427@opwinex02.corp.il luminet.com> 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 11:32 AM 6/3/2002 -0400, Richard Shockey wrote: >I'd like to re-note this message sent to the list earlier and poll the >list for any objections to taking this to Last Call as a Informational >document ASAP. EPP is IETF standards track. ENUM is IETF standards track. Why should not the use of ENUM for EPP also be standards track? I believe it has sufficient utility and that it was developed and reviewed in the appropriate IETF manner. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Jun 5 13:20:27 2002 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 NAA07834 for ; Wed, 5 Jun 2002 13:20:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20250 for enum-archive@odin.ietf.org; Wed, 5 Jun 2002 13:20: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 NAA20023; Wed, 5 Jun 2002 13:10: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 NAA19992 for ; Wed, 5 Jun 2002 13:10:48 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07188 for ; Wed, 5 Jun 2002 13:10:19 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g55H9kB11599; Wed, 5 Jun 2002 13:09:46 -0400 Message-Id: <5.1.0.14.2.20020605131356.045f8548@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Jun 2002 13:15:19 -0400 To: Dave Crocker From: Richard Shockey Subject: Re: [Enum] EPP for E.164 - Start Last Call ??? Cc: enum@ietf.org In-Reply-To: <5.1.1.2.2.20020605084828.03327c48@jay.songbird.com> References: <5.1.0.14.2.20020603125252.024e35b0@popd.ix.netcom.com> <1C1EEC765F843E44996971A80682118B014B1427@opwinex02.corp.il luminet.com> 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 08:49 AM 6/5/2002 -0700, Dave Crocker wrote: >At 11:32 AM 6/3/2002 -0400, Richard Shockey wrote: >>I'd like to re-note this message sent to the list earlier and poll the >>list for any objections to taking this to Last Call as a Informational >>document ASAP. > >EPP is IETF standards track. > >ENUM is IETF standards track. > >Why should not the use of ENUM for EPP also be standards track? Well my thinking was its just the data object without any real presentation of transport ..but your point is well taken .. >I believe it has sufficient utility and that it was developed and reviewed >in the appropriate IETF manner. > >d/ > > >---------- >Dave Crocker >TribalWise, Inc. >tel +1.408.246.8253; fax +1.408.850.1850 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Jun 5 13:42:29 2002 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 NAA08718 for ; Wed, 5 Jun 2002 13:42:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21559 for enum-archive@odin.ietf.org; Wed, 5 Jun 2002 13:42: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 NAA21053; Wed, 5 Jun 2002 13:33:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21022 for ; Wed, 5 Jun 2002 13:33:17 -0400 (EDT) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08380 for ; Wed, 5 Jun 2002 13:32:47 -0400 (EDT) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g55H46rl012524 for ; Wed, 5 Jun 2002 12:32:45 -0500 (CDT) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3CE519BE0096E707; Wed, 5 Jun 2002 13:32:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: [Enum] EPP for E.164 - Start Last Call ??? Date: Wed, 5 Jun 2002 13:32:44 -0400 Message-ID: <62DA45D4963FA747BA1B253E266760F902AB7AD3@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Enum] EPP for E.164 - Start Last Call ??? Thread-Index: AcILJBjNEooHWJFIQtC68l87UmHuEABkcOJA From: "Pfautz, Penn L, ALVAP" To: "Richard Shockey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA21023 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: While I'm generally supportive of the work to make use of EPP in ENUM provisioning, I have a couple of potential concerns about the context in which it is used. These may prove insubstantial (I hope so) but I'd like to offer them up anyway: 1. It's not entirely clear from the document what, if any, assumptions are being made about which information flows in the ENUM provisioning process would make use of EPP. The Registry (Tier 1) - Registrar interface seems the most likely candidate, but at least in the domestic USA ENUM Forum plan, this would not require the NAPTR record objects, so I infer that Registrar - Tier 2 use is also contemplated. Can Scott or someone elese elaborate? 2. In the US ENUM Forum there has been some debate about what contact information the Tier 1 Registry would actually have. EPP seems to assume a thick Registry and I'm not sure there is agreement on this for ENUM. I'd at least like to see some statements about contact objects being optional in the document. Penn Pfautz AT&T -----Original Message----- From: Richard Shockey [mailto:rich.shockey@neustar.com] Sent: Monday, June 03, 2002 1:32 PM To: enum@ietf.org Subject: Re: [Enum] EPP for E.164 - Start Last Call ??? At 09:14 AM 5/23/2002 -0700, you wrote: >We want to bring to everyone's attention to the draft for provisioning >E.164 numbers using EPP in a registry >environment. >http://search.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-00.txt. >This draft was accepted as an ENUM working group item at the 53rd >IETF. We would like to solicit comments for this draft so we can make >changes, if necessary, to the draft before the June 24th cut off date for >the 54th IETF in Japan. We would like to move forward, as expediently as >possible, because the ENUM forum is very interested in having this draft >move to RFC before they adopt it into their provisioning process. I'd like to re-note this message sent to the list earlier and poll the list for any objections to taking this to Last Call as a Informational document ASAP. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Jun 5 14:05:14 2002 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 OAA09829 for ; Wed, 5 Jun 2002 14:05:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22953 for enum-archive@odin.ietf.org; Wed, 5 Jun 2002 14:05: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 NAA21975; Wed, 5 Jun 2002 13:56: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 NAA21943 for ; Wed, 5 Jun 2002 13:56:17 -0400 (EDT) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09286 for ; Wed, 5 Jun 2002 13:55:47 -0400 (EDT) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA22010; Wed, 5 Jun 2002 13:56:17 -0400 (EDT) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 13:55:45 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189BAF8@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Pfautz, Penn L, ALVAP'" , enum@ietf.org Subject: RE: [Enum] EPP for E.164 - Start Last Call ??? Date: Wed, 5 Jun 2002 13:55:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Pfautz, Penn L, ALVAP [mailto:ppfautz@att.com] > Sent: Wednesday, June 05, 2002 1:33 PM > To: Richard Shockey; enum@ietf.org > Subject: RE: [Enum] EPP for E.164 - Start Last Call ??? > > > Richard: > While I'm generally supportive of the work to make use of EPP > in ENUM provisioning, I have a couple of potential concerns > about the context in which it is used. These may prove > insubstantial (I hope so) but I'd like to offer them up anyway: > > 1. It's not entirely clear from the document what, if any, > assumptions are being made about which information flows in > the ENUM provisioning process would make use of EPP. The > Registry (Tier 1) - Registrar interface seems the most likely > candidate, but at least in the domestic USA ENUM Forum plan, > this would not require the NAPTR record objects, so I infer > that Registrar - Tier 2 use is also contemplated. Can Scott > or someone elese elaborate? I'd suggest that the scope is for any registry-registrar interface that requires the provisioning of NAPTR information. Maybe it's not needed for the anticipated tier-1 situation in the US, but it's hardly safe to assume that the same operating model holds world-wide. > 2. In the US ENUM Forum there has been some debate about what > contact information the Tier 1 Registry would actually have. > EPP seems to assume a thick Registry and I'm not sure there > is agreement on this for ENUM. I'd at least like to see some > statements about contact objects being optional in the document. EPP assumes nothing about the registry being thick or thin; mappings are defined to support both models. If the domain examples used in the document appear to imply a requirement for a thick registry, I don't have a problem with adding text to make it clear that there is no such requirement. -Scott- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Jun 5 15:59:16 2002 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 PAA15661 for ; Wed, 5 Jun 2002 15:59:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27766 for enum-archive@odin.ietf.org; Wed, 5 Jun 2002 15:59: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 PAA27343; Wed, 5 Jun 2002 15:49: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 PAA27312 for ; Wed, 5 Jun 2002 15:49:35 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15034 for ; Wed, 5 Jun 2002 15:49:04 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g55Jn1B14968; Wed, 5 Jun 2002 15:49:01 -0400 Message-Id: <5.1.0.14.2.20020605145237.02477738@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Jun 2002 15:00:16 -0400 To: "Pfautz, Penn L, ALVAP" , From: Richard Shockey Subject: RE: [Enum] EPP for E.164 - Start Last Call ??? In-Reply-To: <62DA45D4963FA747BA1B253E266760F902AB7AD3@OCCLUST04EVS1.ugd .att.com> 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 01:32 PM 6/5/2002 -0400, Pfautz, Penn L, ALVAP wrote: >Richard: >While I'm generally supportive of the work to make use of EPP in ENUM >provisioning, I have a couple of potential concerns about the context in >which it is used. These may prove insubstantial (I hope so) but I'd like >to offer them up anyway: I'm wondering if we should even be hinting at a transport here ...EPP is a transport mechanism I wondering how we can abstract this whole mechanism to things like SOAP etc. Just a thought not a monkey wrench... its just that I see opportunities for provisioning using variety of mechanisms. >1. It's not entirely clear from the document what, if any, assumptions are >being made about which information flows in the ENUM provisioning process >would make use of EPP. The Registry (Tier 1) - Registrar interface seems >the most likely candidate, but at least in the domestic USA ENUM Forum >plan, this would not require the NAPTR record objects, so I infer that >Registrar - Tier 2 use is also contemplated. Can Scott or someone elese >elaborate? Well my thought is that this document outlines a possible mechanism for T1 - T2 data interchange using this data object ..but by no means the only one or the eventual dominant one we have markets for that ..which was one other reason I thought this might be better as Informational ..Penn ..what are your thoughts? >2. In the US ENUM Forum there has been some debate about what contact >information the Tier 1 Registry would actually have. EPP seems to assume a >thick Registry and I'm not sure there is agreement on this for ENUM. I'd >at least like to see some statements about contact objects being optional >in the document. good point... >Penn Pfautz >AT&T Thanks for your comments... >-----Original Message----- >From: Richard Shockey [mailto:rich.shockey@neustar.com] >Sent: Monday, June 03, 2002 1:32 PM >To: enum@ietf.org >Subject: Re: [Enum] EPP for E.164 - Start Last Call ??? > > >At 09:14 AM 5/23/2002 -0700, you wrote: > >We want to bring to everyone's attention to the draft for provisioning > >E.164 numbers using EPP in a registry > >environment. > >h > ttp://search.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-00.txt. > >This draft was accepted as an ENUM working group item at the 53rd > >IETF. We would like to solicit comments for this draft so we can make > >changes, if necessary, to the draft before the June 24th cut off date for > >the 54th IETF in Japan. We would like to move forward, as expediently as > >possible, because the ENUM forum is very interested in having this draft > >move to RFC before they adopt it into their provisioning process. > > >I'd like to re-note this message sent to the list earlier and poll the list >for any objections to taking this to Last Call as a Informational document >ASAP. > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Senior Manager, Strategic Technology Initiatives >NeuStar Inc. >45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 >1120 Vermont Ave NW Suite 400 Washington DC 20005 >Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > > > ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Jun 5 17:45:58 2002 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 RAA21717 for ; Wed, 5 Jun 2002 17:45:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04367 for enum-archive@odin.ietf.org; Wed, 5 Jun 2002 17:46: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 RAA03834; Wed, 5 Jun 2002 17:34: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 RAA03802 for ; Wed, 5 Jun 2002 17:34:09 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21095 for ; Wed, 5 Jun 2002 17:33:39 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g55LWurw000181; Wed, 5 Jun 2002 23:32:56 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Wed, 5 Jun 2002 23:33:35 +0200 Received: from [10.0.1.100] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 5 Jun 2002 23:33:34 +0200 Date: Wed, 05 Jun 2002 23:15:27 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Richard Shockey , "Pfautz, Penn L, ALVAP" , enum@ietf.org Subject: RE: [Enum] EPP for E.164 - Start Last Call ??? Message-ID: <1598412.1023318927@localhost> In-Reply-To: <5.1.0.14.2.20020605145237.02477738@popd.ix.netcom.com> References: <5.1.0.14.2.20020605145237.02477738@popd.ix.netcom.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 05 Jun 2002 21:33:35.0289 (UTC) FILETIME=[A5BCFA90:01C20CD8] 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 --On 2002-06-05 15.00 -0400 Richard Shockey wrote: > I'm wondering if we should even be hinting at a transport here ...EPP is > a transport mechanism I wondering how we can abstract this whole > mechanism to things like SOAP etc. SOAP, I hate when getting it into my eyes ;-) Joke aside, as wg co-chair I have heard from several parties they want to be able to create registry/registrar systems passing "whatever" information needed when creating thick or thin registries holding ENUM information. No, I don't know if they mean with registry the party holding the NAPTR record or the one delegating NS records for E.164 numbers. What the goal is should be clear enough when reading the document, and if it is not, that is not a general question, but issue which should be addressed by the document editor(s). paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 7 09:27:34 2002 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 JAA25780 for ; Fri, 7 Jun 2002 09:27:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26482 for enum-archive@odin.ietf.org; Fri, 7 Jun 2002 09:28: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 JAA26101; Fri, 7 Jun 2002 09:17:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26071 for ; Fri, 7 Jun 2002 09:17:11 -0400 (EDT) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25586 for ; Fri, 7 Jun 2002 09:16:39 -0400 (EDT) Received: from attrh1i.attrh.att.com ([135.71.62.10]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g57DBDol028523 for ; Fri, 7 Jun 2002 09:16:39 -0400 (EDT) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029) id 3CBB49730027B08D for enum@ietf.org; Fri, 7 Jun 2002 09:16:34 -0400 content-class: urn:content-classes:message Subject: RE: [Enum] EPP for E.164 - Start Last Call ??? Date: Fri, 7 Jun 2002 09:16:34 -0400 Message-ID: <62DA45D4963FA747BA1B253E266760F902B242AC@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Enum] EPP for E.164 - Start Last Call ??? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcIMyhvk2+OGIsI1RLOfxVmxqHvD6gBWRivQ From: "Pfautz, Penn L, ALVAP" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA26072 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 Looking over the draft-ietf-enum-epp-e164-00.txt and the other EPP I-Ds I've come to the following conclusions which I'd like test others' agreement to since I'm not protocol wizard: 1. draft-ietf-enum-epp-e164-00.txt is just about provisioning of NAPTR records. So from the perspective of the US ENUM Forum, UKENUM, (and probably the ITU supplement )it has nothing to do with the Registrar-Tier 1 Registry interface, but speaks more to a Registrar - Tier 2, Registrant - Tier 2, or ASP - Tier 2 interface. 2. The functions defined in are sufficient to handle Registrar-Tier 1 Registry for ENUM as have been generally discussed e.g. in the some earlier I-Ds and in the US ENUM Forum. 3. The hosts provisioned in Tier 1 will be external hosts (with a TLD different from that used for ENUM domain names) and thus managed on a per-client (per Registrar) basis so there will be no issues with two different Registrars registering differernt ENUM domain names that point to the same Tier 2 name server. 4. EPP allows a domain name to be registered without any name servers specified (although in this case it can't get DNS service) Penn Pfautz _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 7 09:44:30 2002 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 JAA26146 for ; Fri, 7 Jun 2002 09:44:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27794 for enum-archive@odin.ietf.org; Fri, 7 Jun 2002 09:45: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 JAA27238; Fri, 7 Jun 2002 09:36: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 JAA27180 for ; Fri, 7 Jun 2002 09:36:00 -0400 (EDT) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25924 for ; Fri, 7 Jun 2002 09:35:28 -0400 (EDT) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA05222; Fri, 7 Jun 2002 09:36:01 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 09:35:28 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189BB11@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Pfautz, Penn L, ALVAP'" , enum@ietf.org Subject: RE: [Enum] EPP for E.164 - Start Last Call ??? Date: Fri, 7 Jun 2002 09:35:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Pfautz, Penn L, ALVAP [mailto:ppfautz@att.com] > Sent: Friday, June 07, 2002 9:17 AM > To: enum@ietf.org > Subject: RE: [Enum] EPP for E.164 - Start Last Call ??? > > > Looking over the draft-ietf-enum-epp-e164-00.txt and the > other EPP I-Ds I've come to the following conclusions which > I'd like test others' agreement to since I'm not protocol wizard: > > 1. draft-ietf-enum-epp-e164-00.txt is just about provisioning > of NAPTR records. > So from the perspective of the US ENUM Forum, UKENUM, (and > probably the ITU supplement )it has nothing to do with the > Registrar-Tier 1 Registry interface, but speaks more to a > Registrar - Tier 2, Registrant - Tier 2, or ASP - Tier 2 interface. Currently true. In the absence of any known (by me) requirements to provision anything other than NAPTR details, that's all that's in there right now. > 2. The functions defined in > are sufficient to > handle Registrar-Tier 1 Registry for ENUM as have been > generally discussed e.g. in the some earlier I-Ds and in the > US ENUM Forum. Also true. > 3. The hosts provisioned in Tier 1 will be external hosts > (with a TLD different from that used for ENUM domain names) > and thus managed on a per-client (per Registrar) basis so > there will be no issues with two different Registrars > registering differernt ENUM domain names that point to the > same Tier 2 name server. Also true. > 4. EPP allows a domain name to be registered without any name > servers specified (although in this case it can't get DNS service) True again. -Scott- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 7 23:37:47 2002 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 XAA21680 for ; Fri, 7 Jun 2002 23:37:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA25482 for enum-archive@odin.ietf.org; Fri, 7 Jun 2002 23:38: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 XAA24788; Fri, 7 Jun 2002 23:29: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 XAA24757 for ; Fri, 7 Jun 2002 23:29:09 -0400 (EDT) Received: from smtp.huawei.com ([61.144.161.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21581 for ; Fri, 7 Jun 2002 23:28:35 -0400 (EDT) Received: from x16187 ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GXDAWP01.D61; Sat, 8 Jun 2002 11:26:49 +0800 Message-ID: <002101c20e9c$990f50c0$e2290b0a@huawei.com.cn> From: "ripple" To: Cc: Subject: Re: [Enum] Triggering ENUM Queries Date: Sat, 8 Jun 2002 11:28:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id XAA24758 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 have two questions about your opinion: >Camp A has a broader view and see in addition the user who just wants to >communicate with another user and has not decided yet, how he will do this. >So the user is querying ENUM, retrieving all NAPTR records e.g. by a >stand-alone application, and gets the result displayed in a user meaningful >format, e.g. URLs sorted by tel, fax, sms, mail, like on a business card. >The user is now selecting the proper appclication by clicking on the URL. >This also explains, that this camp has no problem with peeking ahead beyond >the enumservices field. >To summarize, we really have three principle ways to trigger an ENUM query, >and we want to use the trials to find out the user preferences (maybe all >tree variants are needed anyway): >1. Stand-alone ENUM Client: >The stand-alone ENUM client is given an E.164 Number in the format +431..., >retrieving all NAPTRs (and ev. other records) from the given domain and >displaying them in a human readable and grouped form, eg. sure, the user get all NAPTR records, and then he can make a dicision. But the callee maybe wouldn't rather his private information known by everyone, especially for the telemarketing. >3. ENUM query triggered by URL >I also see a third possibility to launch an ENUM query: by clicking on an >URL on a webpage or in a document. This is a bit different from the usage of >URL in the stand-alone client, because then I use the URL AFTER the ENUM >query. The problem here is, that this requires some additions to the >existing URI schemes, eg: >mailto:+431... or sip:+431... or http://+431... >If there is an ambiguity, whether ENUM should be queried or not, a ;svc=enum >parameter could be used. >If such an URL is used, the corresponding application should be launched >and, provided there is an ENUM add-on, ENUM should be queried, and the >number should be replaced with the retrieved URI as in 2. >Proposal of a new URI scheme enum:+431... >This leads to another requirement: If a user has an ENUM entry, it does not >make sense to list all the different URLs e.g. on his e-mail signature, >pointing to the same ENUM entry. >He may just want to say, hey guys, I am in ENUM, you can get all information >there. Therefore a new URI scheme is required: >enum:+431... >This URL would launch the standalone client from 1. and I can also imagine, >that a bubble with the information pops up, if you hoover with the mouse >over the URL ;-) >The new URI scheme ENUM may also come in handy to forward the complete E.164 >domain to another number, including all services. >If I enter in my office number domain +4317978032 >NAPTR blabla "E2U+enum" blabla enum:+436644204100 >I can forward now ALL services to my mobile number, having all records in >one place. This is proposed as alternative to the use of CNAME for End >Users. First, I can't sure if the 'NAPTR blabla "E2U+enum" blabla enum:+436644204100' is the output of the ENUM query. Second, if the end user is a telephone subscriber, how does he use the URL ? Hope this helps, ripple _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Jun 10 07:27:05 2002 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 HAA28890 for ; Mon, 10 Jun 2002 07:27:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25234 for enum-archive@odin.ietf.org; Mon, 10 Jun 2002 07:27: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 HAA24395; Mon, 10 Jun 2002 07:17: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 HAA24366 for ; Mon, 10 Jun 2002 07:17:34 -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 HAA28238; Mon, 10 Jun 2002 07:16:46 -0400 (EDT) Message-Id: <200206101116.HAA28238@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org, iptel@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 10 Jun 2002 07:16:46 -0400 Subject: [Enum] I-D ACTION:draft-brandner-tel-svc-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 : 'The 'tel:' URI 'svc' Parameter' Author(s) : R. Brandner, L. Conroy, R. Stastny Filename : draft-brandner-tel-svc-00.txt Pages : 9 Date : 07-Jun-02 This document describes the 'svc' parameter for use within a 'tel:' URI. This is intended to indicate the uses to which a resource identified via the 'tel:' URI can be put. It is an optional parameter, and if not understood can be ignored. It allows the user to 'hint' at the features supported at the resource. There are guidelines for how this parameter might be used, and for expected behaviour on detection of this parameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-tel-svc-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-brandner-tel-svc-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-brandner-tel-svc-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: <20020607133104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brandner-tel-svc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brandner-tel-svc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607133104.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Jun 10 13:01:03 2002 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 NAA13161 for ; Mon, 10 Jun 2002 13:01:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16055 for enum-archive@odin.ietf.org; Mon, 10 Jun 2002 13:01: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 MAA15057; Mon, 10 Jun 2002 12:51: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 MAA15021 for ; Mon, 10 Jun 2002 12:51:08 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12711 for ; Mon, 10 Jun 2002 12:50:33 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA02098; Mon, 10 Jun 2002 18:51:03 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA00874; Mon, 10 Jun 2002 18:51:05 +0200 (MET DST) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 18:50:54 +0200 Message-ID: From: Brandner Rudolf To: "'ripple'" Cc: richard.stastny@oefeg.at, CONROY LAWRENCE , enum@ietf.org Subject: AW: [Enum] Triggering ENUM Queries Date: Mon, 10 Jun 2002 18:50:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA15022 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 Comments inline. Sorry for being lazy. > -----Urspr¨¹ngliche Nachricht----- > Von: ripple [mailto:swanbo@huawei.com] > Gesendet: Samstag, 8. Juni 2002 05:29 > An: richard.stastny@oefeg.at > Cc: enum@ietf.org > Betreff: Re: [Enum] Triggering ENUM Queries > > -----[snipp]----- > > sure, the user get all NAPTR records, and then he can make a > dicision. But the callee maybe wouldn't rather his private > information known by everyone, especially for the telemarketing. > A user who has an ENUM domain controls what NAPTRs are listed in that domain. So it is the user's responsability and choice, what the NAPTRs reveal. And the user has the option of not opt-in. This is similar to an entry in a phone book. You have the choice of not being listed, or if listed, what's in there. > -----[snipp]----- > > First, I can't sure if the 'NAPTR blabla "E2U+enum" blabla > enum:+436644204100' is the output of the ENUM query. I am not quite sure what you mean here. If it comes down to the question: how can I be sure that this response to my ENUM request is the correct one, then it is not specific to an enum: URI. > Second, if the end user is a telephone subscriber, how does > he use the URL ? > Not sure what you mean here. If my end system or terminal can query ENUM and gets an enum: URI, the end systems just queries ENUM with that phone number of the enum: URI. > Hope this helps, > ripple > If the answers do not cover your questions, please let me know. Rudi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Jun 10 13:29:25 2002 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 NAA15042 for ; Mon, 10 Jun 2002 13:29:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17450 for enum-archive@odin.ietf.org; Mon, 10 Jun 2002 13:29: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 NAA16960; Mon, 10 Jun 2002 13:18: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 NAA16931 for ; Mon, 10 Jun 2002 13:18:29 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14293 for ; Mon, 10 Jun 2002 13:17:54 -0400 (EDT) Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090435; Mon, 10 Jun 2002 18:18:25 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Mon, 10 Jun 2002 18:17:56 +0100 To: enum@ietf.org From: Lawrence Conroy Cc: Rudi , Richard Stastny Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] 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 Hi Folks, It occurs to me that this hasn't been mentioned on the list, but some responses assume its existence. Hence - Heads up, folks! Our intention is to define a URI-scheme 'enum:' to indicate explicitly that an ENUM search is required rather than using a telephone number directly. The syntax is going to follow the 2806bis update, but with a parameter ('es=') that will hold the enumservices that should be checked. The reason you haven't seen this draft yet is that we've been waiting until there's some clarity over the enumservices. (That's why I'm a little anxious to get that sorted :). This 'es' parameter will use the 'any' value to indicate that there is no explicit (or publicly stated) limitation for enumservices. This also suggests an alternative to CNAME - the URI inside a NAPTR could be an 'enum:' URI, and such a URI could specify that "re-submission is required". That way, we can exclude re-submission for a 'tel:' URI retrieved from ENUM (and shorten the tel/talk enumservice draft :). all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Jun 11 03:48:25 2002 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 DAA15534 for ; Tue, 11 Jun 2002 03:48:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA06848 for enum-archive@odin.ietf.org; Tue, 11 Jun 2002 03:49:01 -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 DAA06587; Tue, 11 Jun 2002 03:39: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 DAA06554 for ; Tue, 11 Jun 2002 03:39:12 -0400 (EDT) Received: from smtp.huawei.com ([61.144.161.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15432 for ; Tue, 11 Jun 2002 03:38:34 -0400 (EDT) Received: from x16187 ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GXJ68700.1DN; Tue, 11 Jun 2002 15:31:19 +0800 Message-ID: <009201c2111a$43604640$e2290b0a@huawei.com.cn> From: "ripple" To: "Brandner Rudolf" Cc: References: Subject: Re: [Enum] Triggering ENUM Queries Date: Tue, 11 Jun 2002 15:33:21 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id DAA06555 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 Hi, thanks for your comments, mine are inline... >----- Original Message ----- >From: "Brandner Rudolf" >To: "'ripple'" >Cc: ; "CONROY LAWRENCE" ; >Sent: Tuesday, June 11, 2002 12:50 AM >Subject: AW: [Enum] Triggering ENUM Queries >-----[snipp]----- >> >> First, I can't sure if the 'NAPTR blabla "E2U+enum" blabla >> enum:+436644204100' is the output of the ENUM query. >I am not quite sure what you mean here. >If it comes down to the question: how can I be sure that this response to my ENUM request is the correct one, >then it is not specific to an enum: URI. I just want to confirm that when I have sent a ENUM query whether 'NAPTR blabla "E2U+enum" blabla enum:+436644204100 ' is a response for the query. >> Second, if the end user is a telephone subscriber, how does >> he use the URL ? >> >Not sure what you mean here. >If my end system or terminal can query ENUM and gets an enum: URI, the end systems just queries ENUM with that >phone number of the enum: URI. I mean that when I use the telephone, How do I click the URL ? So the 3# approach "ENUM query triggered by URL" is not available. Thanks again, rippple _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Jun 11 04:52:30 2002 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 EAA16334 for ; Tue, 11 Jun 2002 04:52:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09636 for enum-archive@odin.ietf.org; Tue, 11 Jun 2002 04:52: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 EAA09395; Tue, 11 Jun 2002 04:43: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 EAA09364 for ; Tue, 11 Jun 2002 04:43:23 -0400 (EDT) Received: from oefeg-tmp.oefeg.loc ([62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16179 for ; Tue, 11 Jun 2002 04:42:49 -0400 (EDT) content-class: urn:content-classes:message Subject: AW: [Enum] Triggering ENUM Queries MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Tue, 11 Jun 2002 10:45:01 +0200 Message-ID: <35B3051023BFA24CA5505982EBD7974C088EDB@oefeg-tmp.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Enum] Triggering ENUM Queries Thread-Index: AcIRHXaBMMW+Qph0R9yFfO2HibhuTAAAjBPk From: "Stastny Richard" To: "ripple" , "Brandner Rudolf" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id EAA09365 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 Hi, comments inline: -----Ursprüngliche Nachricht----- Von: ripple [mailto:swanbo@huawei.com] Gesendet: Di 11.06.2002 09:33 An: Brandner Rudolf Cc: enum@ietf.org Betreff: Re: [Enum] Triggering ENUM Queries Hi, thanks for your comments, mine are inline... >----- Original Message ----- >From: "Brandner Rudolf" >To: "'ripple'" >Cc: ; "CONROY LAWRENCE" ; >Sent: Tuesday, June 11, 2002 12:50 AM >Subject: AW: [Enum] Triggering ENUM Queries >-----[snipp]----- >> >> First, I can't sure if the 'NAPTR blabla "E2U+enum" blabla >> enum:+436644204100' is the output of the ENUM query. >I am not quite sure what you mean here. >If it comes down to the question: how can I be sure that this response to my ENUM request is the correct one, >then it is not specific to an enum: URI. I just want to confirm that when I have sent a ENUM query whether 'NAPTR blabla "E2U+enum" blabla enum:+436644204100 ' is a response for the query. To which I reply. Yes, and it will in most cases the only NAPTR record in the domain, just pointing you to the E.164 number domain where the "real" NAPTRs are. It is really up to the client, if the user is recocgnizing the fact he is diverted , and how this is displayed. The client could also just select the NAPTRs from the new number and process them. >> Second, if the end user is a telephone subscriber, how does >> he use the URL ? >> >Not sure what you mean here. >If my end system or terminal can query ENUM and gets an enum: URI, the end systems just queries ENUM with that >phone number of the enum: URI. I mean that when I use the telephone, How do I click the URL ? So the 3# approach "ENUM query triggered by URL" is not available. To which I reply: We are talking two things here: 1. The enum: URI is in the NAPTR, indicating that a new query should be made, so the question here is, how did you do the query from the phone in the first place. If you dialled up a GW with an access number, the GW (or MGC) is querying ENUM, looking e.g. for a 'talk' enumservice, and getting only e.g.'any' with enum URI. So he is querying ENUM again and now finding a 'talk' enumservice with a SIP URI. Fine. Done 2. The enum: URI is e.g in an e-mail signatur, so you see it in a PDA od PC, click on it, a stand-alone client opens and shows you all entries. I agree. its hard with a steam-phone to receice an e-mail and click on a link ;-) regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Jun 11 07:17:04 2002 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 HAA18428 for ; Tue, 11 Jun 2002 07:17:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16387 for enum-archive@odin.ietf.org; Tue, 11 Jun 2002 07:17: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 HAA16022; Tue, 11 Jun 2002 07:08:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15889 for ; Tue, 11 Jun 2002 07:08:10 -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 HAA18108; Tue, 11 Jun 2002 07:07:33 -0400 (EDT) Message-Id: <200206111107.HAA18108@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, 11 Jun 2002 07:07:33 -0400 Subject: [Enum] I-D ACTION:draft-ietf-enum-usage-scenarios-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. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Usage Scenarios Author(s) : S. Lind Filename : draft-ietf-enum-usage-scenarios-00.txt Pages : 17 Date : 10-Jun-02 This document provides illustrations of the use of ENUM [2] functionality within the larger context of service-level call flows for Voice over IP communication where interworking between the PSTN and IP-based networks are necessary to complete a call. Details are presented for simple calls made on a 'direct dial' basis. Some details are also provided for calls made using the ITU-defined 'Global Services' [3,4,5]. The impact of number portability within the call scenarios is discussed. The objective of this document is to identify areas where gaps exist in the provision of services and suggest where protocol extensions for ENUM, SIP, TRIP, etc. are needed. The document does not propose that the examples represent the only or best approach for interworking between the PSTN and IP-based networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-usage-scenarios-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-usage-scenarios-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-ietf-enum-usage-scenarios-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: <20020610143315.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-usage-scenarios-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-usage-scenarios-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020610143315.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Jun 12 06:41:10 2002 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 GAA22004 for ; Wed, 12 Jun 2002 06:41:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA17476 for enum-archive@odin.ietf.org; Wed, 12 Jun 2002 06:41:45 -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 GAA16970; Wed, 12 Jun 2002 06:31: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 GAA16931 for ; Wed, 12 Jun 2002 06:31:10 -0400 (EDT) Received: from oefeg-tmp.oefeg.loc (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21792 for ; Wed, 12 Jun 2002 06:30:33 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Wed, 12 Jun 2002 12:32:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <35B3051023BFA24CA5505982EBD7974C088EE4@oefeg-tmp.oefeg.loc> Thread-Topic: Public Keys in ENUM Thread-Index: AcIR/HtbQFkI6zVSQoyMkCU5LnyWBw== From: "Stastny Richard" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id GAA16932 Subject: [Enum] Public Keys in 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: 8bit Hi folks, Patrik, In my recently submitted draft-stastny-enum-services-analysis-00.txt (not yet officially announced, but already available in the directories) I propose in sections 4.3 and 4.4 also enumservices related to public keys (e.g. "ldapkey" and "cert"), assuming that e.g. an ldap: URI is pointing to the public key of the holder of the ENUM domain. I also raise the question, if there is an URI scheme or another possibility to store the public key directly in an ENUM domain and what would be the preferred method? IMHO this could be a nice (killer?) application for ENUM and also for a global PKI. best regards Richard Stastny mailto:richard.stastny@oefeg.at tel:+436644204100 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Jun 12 17:35:07 2002 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 RAA13883 for ; Wed, 12 Jun 2002 17:35:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA28138 for enum-archive@odin.ietf.org; Wed, 12 Jun 2002 17:35: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 RAA27081; Wed, 12 Jun 2002 17:26: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 RAA27013 for ; Wed, 12 Jun 2002 17:26:16 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13584 for ; Wed, 12 Jun 2002 17:25:40 -0400 (EDT) Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5CLOMPl003321; Wed, 12 Jun 2002 23:25:03 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 12 Jun 2002 23:25:31 +0200 Received: from [10.0.1.100] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 12 Jun 2002 23:25:09 +0200 Date: Wed, 12 Jun 2002 23:05:56 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Stastny Richard , enum@ietf.org Message-ID: <25122967.1023923156@localhost> In-Reply-To: <35B3051023BFA24CA5505982EBD7974C088EE4@oefeg-tmp.oefeg.loc> References: <35B3051023BFA24CA5505982EBD7974C088EE4@oefeg-tmp.oefeg.loc> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 12 Jun 2002 21:25:09.0673 (UTC) FILETIME=[A1425990:01C21257] Content-Transfer-Encoding: 7bit Subject: [Enum] Re: Public Keys in 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 --On 2002-06-12 12.32 +0200 Stastny Richard wrote: > In my recently submitted draft-stastny-enum-services-analysis-00.txt (not > yet officially announced, but already available in the directories) I > propose in sections 4.3 and 4.4 also enumservices related to public keys > (e.g. "ldapkey" and "cert"), assuming that e.g. an ldap: URI is pointing > to the public key of the holder of the ENUM domain. > I also raise the question, if there is an URI scheme or another > possibility to store the public key directly in an ENUM domain and what > would be the preferred method? The view by DNS people in IETF in general, and the DNS Directorate (of which I am a member) is that DNS is not to be a kitchen-sink for storage of data. That should be done in various suitable directory services. DNS MIGHT though contain pointers to where the data is. So, I would like to say that storing the keys/certificates directly in DNS will get a "no no" answer from DNS people, while having a specific LDAP URI in an NAPTR record and that LDAP URI is what you use to fetch the cert/key is ok. Of course, something else than LDAP can be used as access protocol, but the key point is that the key itself is not stored in DNS. Just my $0.02. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Jun 12 17:54:38 2002 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 RAA14749 for ; Wed, 12 Jun 2002 17:54:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA29810 for enum-archive@odin.ietf.org; Wed, 12 Jun 2002 17:55: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 RAA28344; Wed, 12 Jun 2002 17:39: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 RAA28313 for ; Wed, 12 Jun 2002 17:39:45 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14045 for ; Wed, 12 Jun 2002 17:39:09 -0400 (EDT) Received: from [128.177.195.171] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 878253190C; Wed, 12 Jun 2002 14:39:13 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 12 Jun 2002 14:39:29 -0700 Subject: Re: [Enum] Re: Public Keys in ENUM From: David Conrad To: Patrik F=?ISO-8859-1?B?5Gx0c3Ry9g==?=m , Stastny Richard , enum wg Message-ID: In-Reply-To: <25122967.1023923156@localhost> Mime-version: 1.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 RAA28314 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 6/12/02 2:05 PM, "Patrik Fältström" wrote: > So, I would like to say that storing the keys/certificates directly in DNS > will get a "no no" answer from DNS people, I guess I'm not a DNS person then. Rgds, -drc _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Jun 12 18:06:55 2002 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 SAA15005 for ; Wed, 12 Jun 2002 18:06:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA00679 for enum-archive@odin.ietf.org; Wed, 12 Jun 2002 18:07: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 RAA29956; Wed, 12 Jun 2002 17:58: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 RAA29929 for ; Wed, 12 Jun 2002 17:58:32 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14864 for ; Wed, 12 Jun 2002 17:57:56 -0400 (EDT) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 699AF31914; Wed, 12 Jun 2002 14:58:00 -0700 (PDT) To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Stastny Richard , enum@ietf.org Subject: Re: [Enum] Re: Public Keys in ENUM In-Reply-To: Message from =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= of "Wed, 12 Jun 2002 23:05:56 +0200." <25122967.1023923156@localhost> Date: Wed, 12 Jun 2002 14:58:00 -0700 Message-ID: <82504.1023919080@shell.nominum.com> From: Jim Reid 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 >>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes: paf> The view by DNS people in IETF in general, and the DNS paf> Directorate (of which I am a member) is that DNS is not to be paf> a kitchen-sink for storage of data. Isn't acting as a kitchen sink for data the sole purpose of the DNS... :-) paf> So, I would like to say that storing the keys/certificates paf> directly in DNS will get a "no no" answer from DNS people, Including the DNS people who invented the CERT record? :-) I would have thought that it would be cleaner and more elegant to just do a DNS lookup and retrieve a PGP or SSH key (say) instead of getting back the name of some server to then query with some other protocol to get that data. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Jun 12 18:21:06 2002 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 SAA15318 for ; Wed, 12 Jun 2002 18:21:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA01197 for enum-archive@odin.ietf.org; Wed, 12 Jun 2002 18:21:37 -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 SAA00901; Wed, 12 Jun 2002 18:12: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 SAA00870 for ; Wed, 12 Jun 2002 18:12:41 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15139 for ; Wed, 12 Jun 2002 18:12:04 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5CMAtRP002078; Wed, 12 Jun 2002 18:10:55 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5CMAsLx002077; Wed, 12 Jun 2002 18:10:54 -0400 (EDT) Date: Wed, 12 Jun 2002 18:10:54 -0400 From: Michael Mealling To: Jim Reid Cc: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , Stastny Richard , enum@ietf.org Subject: Re: [Enum] Re: Public Keys in ENUM Message-ID: <20020612181054.B1751@bailey.dscga.com> Reply-To: Michael Mealling References: <25122967.1023923156@localhost> <82504.1023919080@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82504.1023919080@shell.nominum.com> User-Agent: Mutt/1.3.22.1i 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, Jun 12, 2002 at 02:58:00PM -0700, Jim Reid wrote: > >>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes: > paf> The view by DNS people in IETF in general, and the DNS > paf> Directorate (of which I am a member) is that DNS is not to be > paf> a kitchen-sink for storage of data. > > Isn't acting as a kitchen sink for data the sole purpose of the DNS... :-) > > paf> So, I would like to say that storing the keys/certificates > paf> directly in DNS will get a "no no" answer from DNS people, > > Including the DNS people who invented the CERT record? :-) > > I would have thought that it would be cleaner and more elegant to just > do a DNS lookup and retrieve a PGP or SSH key (say) instead of getting > back the name of some server to then query with some other protocol to > get that data. It might be cleaner for that particular application if it were the only one but it isn't. The rule of thumb I've heard used and which I particular adhere to is this: the DNS is used for pointing to where the information you are after can be found, not containing it. For ENUM this means that we put the URIs in there, not the information in the resources they point too. In the URI Resolution application we made sure that the granularity of what was in DNS was still at the host or node level, not the content level. I.e. there should never be a 1:1 correlation between the number of URIs for a site and the number of DNS records in its zone. For certificates this means that while it may be fine to contain a CERT for a given host, its not OK to put all of the CERTS for the users that may inhabit that host.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Jun 12 18:44:01 2002 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 SAA15823 for ; Wed, 12 Jun 2002 18:44:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA02381 for enum-archive@odin.ietf.org; Wed, 12 Jun 2002 18:44: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 SAA02108; Wed, 12 Jun 2002 18:35: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 SAA02077 for ; Wed, 12 Jun 2002 18:35:28 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15618 for ; Wed, 12 Jun 2002 18:34:50 -0400 (EDT) Received: from [128.177.195.171] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id C7BB03190C; Wed, 12 Jun 2002 15:34:54 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 12 Jun 2002 15:35:10 -0700 Subject: Re: [Enum] Re: Public Keys in ENUM From: David Conrad To: Michael Mealling , Jim Reid Cc: Patrik F=?ISO-8859-1?B?5Gx0c3Ry9g==?=m , Stastny Richard , enum wg Message-ID: In-Reply-To: <20020612181054.B1751@bailey.dscga.com> Mime-version: 1.0 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 Needless to say, this is a controversial topic. It also isn't particularly relevant to ENUM. For those interested in this sort of thing, there is a mailing list, keydist@cafax.se, where discussions related to putting keying information in the DNS occur. I'd strongly recommend continuing the discussion there. Rgds, -drc On 6/12/02 3:10 PM, "Michael Mealling" wrote: > On Wed, Jun 12, 2002 at 02:58:00PM -0700, Jim Reid wrote: >>>>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes: >> paf> The view by DNS people in IETF in general, and the DNS >> paf> Directorate (of which I am a member) is that DNS is not to be >> paf> a kitchen-sink for storage of data. >> >> Isn't acting as a kitchen sink for data the sole purpose of the DNS... :-) >> >> paf> So, I would like to say that storing the keys/certificates >> paf> directly in DNS will get a "no no" answer from DNS people, >> >> Including the DNS people who invented the CERT record? :-) >> >> I would have thought that it would be cleaner and more elegant to just >> do a DNS lookup and retrieve a PGP or SSH key (say) instead of getting >> back the name of some server to then query with some other protocol to >> get that data. > > It might be cleaner for that particular application if it were the only > one but it isn't. The rule of thumb I've heard used and which I particular > adhere to is this: the DNS is used for pointing to where the information > you are after can be found, not containing it. For ENUM this means that we > put the URIs in there, not the information in the resources they point too. > > In the URI Resolution application we made sure that the granularity of > what was in DNS was still at the host or node level, not the content level. > I.e. there should never be a 1:1 correlation between the number of URIs > for a site and the number of DNS records in its zone. > > For certificates this means that while it may be fine to contain a CERT > for a given host, its not OK to put all of the CERTS for the users > that may inhabit that host.... > > -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Jun 13 03:20:15 2002 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 DAA03378 for ; Thu, 13 Jun 2002 03:20:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA00421 for enum-archive@odin.ietf.org; Thu, 13 Jun 2002 03:20: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 DAA29979; Thu, 13 Jun 2002 03:11: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 DAA29823 for ; Thu, 13 Jun 2002 03:11:36 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02968 for ; Thu, 13 Jun 2002 03:10:59 -0400 (EDT) Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5D7AF8R028388; Thu, 13 Jun 2002 09:10:20 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 13 Jun 2002 09:10:58 +0200 Received: from [10.0.1.100] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 13 Jun 2002 09:10:49 +0200 Date: Thu, 13 Jun 2002 08:59:27 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: David Conrad , Stastny Richard , enum wg Subject: Re: [Enum] Re: Public Keys in ENUM Message-ID: <25439683.1023958767@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 13 Jun 2002 07:10:49.0534 (UTC) FILETIME=[723F9DE0:01C212A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA29827 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 2002-06-12 14.39 -0700 David Conrad wrote: > On 6/12/02 2:05 PM, "Patrik Fältström" wrote: >> So, I would like to say that storing the keys/certificates directly in >> DNS will get a "no no" answer from DNS people, > > I guess I'm not a DNS person then. You are David Conrad, and yes, I count you as a DNS person. Yes, I know you have a different view, but, I must still say this is the message I get from for example chairs of DNSEXT and DNSOPS and other people in the DNS Directorate. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Jun 13 04:07:21 2002 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 DAA03379 for ; Thu, 13 Jun 2002 03:20:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA00420 for enum-archive@odin.ietf.org; Thu, 13 Jun 2002 03:20: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 DAA29981; Thu, 13 Jun 2002 03:11: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 DAA29825 for ; Thu, 13 Jun 2002 03:11:36 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02969 for ; Thu, 13 Jun 2002 03:10:59 -0400 (EDT) Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5D7AIwK028392; Thu, 13 Jun 2002 09:10:20 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 13 Jun 2002 09:10:59 +0200 Received: from [10.0.1.100] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 13 Jun 2002 09:10:50 +0200 Date: Thu, 13 Jun 2002 09:02:33 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Jim Reid cc: Stastny Richard , enum@ietf.org Subject: Re: [Enum] Re: Public Keys in ENUM Message-ID: <25450832.1023958953@localhost> In-Reply-To: <82504.1023919080@shell.nominum.com> References: <82504.1023919080@shell.nominum.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 13 Jun 2002 07:10:50.0753 (UTC) FILETIME=[72F99F10:01C212A9] 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 --On 2002-06-12 14.58 -0700 Jim Reid wrote: > Including the DNS people who invented the CERT record? :-) > > I would have thought that it would be cleaner and more elegant to just > do a DNS lookup and retrieve a PGP or SSH key (say) instead of getting > back the name of some server to then query with some other protocol to > get that data. As you DNS persons (yes, David included ;-) there are several very "unpleasant" discussions about keys, certificates in DNS at the moment. Appkey being one. CERT record being another. (Re-)use of KEY record for non-DNSSEC issues etc. I suggest ENUM should follow the result/outcome in that discussion, and throw yet another log into the fire. Part from this, I think ENUM as a mechanism for storing pointers to "things". The pointers are in the form of URI's. So, one can with ENUM have in DNS a pointer (URI) to the cert one want to expose. This I think is perfectly alright. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Jun 13 05:09:20 2002 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 FAA05194 for ; Thu, 13 Jun 2002 05:09:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA05672 for enum-archive@odin.ietf.org; Thu, 13 Jun 2002 05:09: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 FAA05268; Thu, 13 Jun 2002 05:00: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 FAA05221 for ; Thu, 13 Jun 2002 05:00:39 -0400 (EDT) Received: from oefeg-tmp.oefeg.loc ([62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05116 for ; Thu, 13 Jun 2002 05:00:00 -0400 (EDT) content-class: urn:content-classes:message Subject: AW: [Enum] Re: Public Keys in ENUM MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Thu, 13 Jun 2002 11:02:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <35B3051023BFA24CA5505982EBD7974C088EE6@oefeg-tmp.oefeg.loc> Thread-Topic: [Enum] Re: Public Keys in ENUM Thread-Index: AcISqd8uH5dbVNrjQ0W4eZ4fHPuvGwACr9jY From: "Stastny Richard" To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , "David Conrad" , "enum wg" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id FAA05222 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 Hi folks, nice to see, that some work is done overnight (at least from a European point of view) and not everybody is watching soccer only ;-) What bothers me a bit is that everytime I ask a question, I do not get an answer, but either 10 more questions are raised or I get the hint, that the issues are treated already somewhere else and I should look there ;-) I think we have again the two or three camps here: Camp A is the minimalistic camp, saying that you finally need only one pointer in ENUM DNS to a service resolution services (srs) and this service is doing the rest. Can it be that this is also the sip camp? Camp B in the middle (Patrik) is saying, you do not want to put all eggs in a basket and you should use ENUM DNS to POINT to other services, thats what ENUM and DNS is intented for. Camp C is saying that I already have a service subscribed (ENUM) and have to pay for it, so I do not want to subscribe another service (e.g. a public key storage services) for things I can do in DNS as well. Jim and David, can it be that this is the DNS service providers camp also? Some additional comments: 1. If it can be done technically, it will be done. And having finally a common global repository for a PKI will drive the usage of public keys AND ENUM, to the benefit of both. 2. What about UDP package lenght with storing keys in DNS? This could be a problem. But on the other side, if I look at the current requirements for ENUM done by the national groups, everybody seems to insist on using DNSSEC for ENUM. If I understood Jims presentation in Geneva correctly, if you use DNSSEC you increase the data in DNS four times at least, so you blow UDP out of the water anyway. Is this correct? best regards Richard Stastny PS to Patrik: Danmark vs Sweden in the final, Danmark world champion? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 13 11:04:32 2002 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 LAA16480 for ; Thu, 13 Jun 2002 11:04:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28692 for enum-archive@odin.ietf.org; Thu, 13 Jun 2002 11:05: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 KAA27680; Thu, 13 Jun 2002 10:54:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27651 for ; Thu, 13 Jun 2002 10:54:56 -0400 (EDT) Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net [38.202.36.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15938 for ; Thu, 13 Jun 2002 10:54:16 -0400 (EDT) Received: from RWALTER ([65.203.166.26]) by hvmta02-stg.us.psimail.psi.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020613145420.HDAX1795.hvmta02-stg.us.psimail.psi.net@RWALTER>; Thu, 13 Jun 2002 10:54:20 -0400 Reply-To: From: "Robert H. Walter" To: "Stastny Richard" Cc: "enum wg" Subject: RE: [Enum] Re: Public Keys in ENUM Date: Thu, 13 Jun 2002 10:54:19 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <35B3051023BFA24CA5505982EBD7974C088EE6@oefeg-tmp.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA27652 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, > 2. What about UDP package lenght with storing keys in DNS? This could be a > problem. But on the other side, if I look at the current requirements for > ENUM done by the national groups, everybody seems to insist on using DNSSEC > for ENUM. If I understood Jims presentation in Geneva correctly, if you > use DNSSEC you increase the data in DNS four times at least, so you blow > UDP out of the water anyway. Is this correct? RFC 1035 defines the UDP packet size to be 512 bytes. RFC 2671 defines a standard mechanism for extending the UDP packet size using the OPT record. The basic idea is for a client to issue a DNS request containing an OPT record that specifies the size of the UDP datagram that the server should reply with... Of course this only works with DNS clients and servers that are OPT aware. So, returning CERT records that are ~2048 bytes in size is not really an issue. Regards, Bob Walter _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 13 11:39:02 2002 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 LAA17940 for ; Thu, 13 Jun 2002 11:38:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00269 for enum-archive@odin.ietf.org; Thu, 13 Jun 2002 11:39:30 -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 LAA29667; Thu, 13 Jun 2002 11:30: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 LAA29628 for ; Thu, 13 Jun 2002 11:30:34 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17709 for ; Thu, 13 Jun 2002 11:29:58 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5DFTRB12011; Thu, 13 Jun 2002 11:29:27 -0400 Message-Id: <5.1.0.14.2.20020613112247.04446e50@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Jun 2002 11:33:46 -0400 To: "Stastny Richard" , =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , "David Conrad" , "enum wg" From: Richard Shockey Subject: Re: AW: [Enum] Re: Public Keys in ENUM In-Reply-To: <35B3051023BFA24CA5505982EBD7974C088EE6@oefeg-tmp.oefeg.loc > 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 11:02 AM 6/13/2002 +0200, Stastny Richard wrote: >Hi folks, >nice to see, that some work is done overnight (at least from a European >point of view) and not everybody is watching soccer only ;-) >What bothers me a bit is that everytime I ask a question, I do not get an >answer, but either 10 more questions are raised or I get the hint, that >the issues are treated already somewhere else and I should look there ;-) Old joke in US. Harry Truman once commented about economists that could apply to us.." All these people do is say 'on the one hand its like this and on the other hand its like that' ...will some one please show me a one handed economist?" Are you looking for one handed Internet Engineers? :-) >I think we have again the two or three camps here: > >Camp A is the minimalistic camp, saying that you finally need only one >pointer in ENUM DNS to a service resolution services (srs) and this >service is doing the rest. Can it be that this is also the sip camp? I'd certainly say so... >Camp B in the middle (Patrik) is saying, you do not want to put all eggs >in a basket and you should use ENUM DNS to POINT to other services, thats >what ENUM and DNS is intented for. Count me in that camp as well. >Camp C is saying that I already have a service subscribed (ENUM) and have >to pay for it, so I do not want to subscribe another service (e.g. a >public key storage services) for things I can do in DNS as well. Jim and >David, can it be that this is the DNS service providers camp also? Not so ..it just that for any number of perfectly good reasons you do not want to store application oriented PKI in the DNS directly ... this was the subject of much debate in Minneapolis at the BOF there and it has re-erupted on the IETF General Discussion list. I clearly count myself as one who supports the use of NAPTR records for this kind of thing. Its exactly what NAPTR was designed for. >Some additional comments: > >1. If it can be done technically, it will be done. And having finally a >common global repository for a PKI will drive the usage of public keys AND >ENUM, to the benefit of both. Agreed ..but do not store them directly in the DNS ...point to them using NAPTR records. This also may permit Authentication and Authorization mechanisms to be utilized if necessary. >2. What about UDP package lenght with storing keys in DNS? This could be a >problem. But on the other side, if I look at the current requirements for >ENUM done by the national groups, everybody seems to insist on using >DNSSEC for ENUM. If I understood Jims presentation in Geneva correctly, >if you use DNSSEC you increase the data in DNS four times at least, so you >blow UDP out of the water anyway. Is this correct? Yes but again let's not drag ourselves into a side discussion of DNSSEC for the moment .. there are serious technical issues there that have not been resolved and deployment is not a "done deal" yet. >best regards > >Richard Stastny > >PS to Patrik: Danmark vs Sweden in the final, Danmark world champion? > > > > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 13 12:35:12 2002 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 MAA21060 for ; Thu, 13 Jun 2002 12:35:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06092 for enum-archive@odin.ietf.org; Thu, 13 Jun 2002 12: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 MAA04907; Thu, 13 Jun 2002 12:26: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 MAA04878 for ; Thu, 13 Jun 2002 12:26:16 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20556 for ; Thu, 13 Jun 2002 12:25:40 -0400 (EDT) Received: from [128.177.195.171] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 25BAE3190C; Thu, 13 Jun 2002 09:25:44 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Thu, 13 Jun 2002 09:26:00 -0700 Subject: Re: AW: [Enum] Re: Public Keys in ENUM From: David Conrad To: Stastny Richard , Patrik F=?ISO-8859-1?B?5Gx0c3Ry9g==?=m , enum wg Message-ID: In-Reply-To: <35B3051023BFA24CA5505982EBD7974C088EE6@oefeg-tmp.oefeg.loc> Mime-version: 1.0 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, This isn't really related to ENUM. I was commenting on the generic statement 'putting keys in the DNS is a no no' which I disagree with for various reasons that aren't really relevant here. However... On 6/13/02 2:02 AM, "Stastny Richard" wrote: > Camp C is saying that I already have a service subscribed (ENUM) and have to > pay for it, so I do not want to subscribe another service (e.g. a public key > storage services) for things I can do in DNS as well. Jim and David, can it be > that this is the DNS service providers camp also? I have no idea what DNS service providers think on this (not even Nominum). My view is that the DNS was originally designed (according to the guy who sits 2 doors down from me) to support arbitrary key/value lookups of relatively small amounts of relatively static data. Looking up security related keys in the DNS easily fits within the original design goals of the DNS, thus attempting to outlaw the use of the DNS for this purpose has always struck me as strange. > 1. If it can be done technically, it will be done. And having finally a common > global repository for a PKI will drive the usage of public keys AND ENUM, to > the benefit of both. I personally believe that one of the primary reasons PKI hasn't gained more public acceptance is the insistence of the various security-related protocol developers to attempt to handwave the key distribution problem away. To date, no globally scalable system for key distribution has been deployed. However, if you look at the problem of scalable key distribution, you'll see that many of the attributes of such a system replicate exactly what the DNS does (caching, scalability, redundancy, reliability, resiliency, integrity assurance, etc). Since I'm lazy by nature, I prefer not to reinvent the wheel. Further, the DNS infrastructure is already deployed -- there are millions of libraries out there that require no modification to enable fetching of data out of the DNS. Seems a waste not to make use of it. > 2. What about UDP package lenght with storing keys in DNS? EDNS0 was created to address this concern (among others). Rgds, -drc _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 13 14:55:34 2002 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 OAA26026 for ; Thu, 13 Jun 2002 14:55:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13758 for enum-archive@odin.ietf.org; Thu, 13 Jun 2002 14:56: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 OAA13452; Thu, 13 Jun 2002 14:45: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 OAA13419 for ; Thu, 13 Jun 2002 14:45:37 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25672 for ; Thu, 13 Jun 2002 14:44:59 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5DIj4B15768 for ; Thu, 13 Jun 2002 14:45:04 -0400 Message-Id: <5.1.0.14.2.20020613145044.02367ac8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Jun 2002 14:50:52 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: Protocol Action: Assignment Procedures for the URI Resolution using DNS to BCP 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 >To: IETF-Announce: ; >Cc: RFC Editor , IANA , > Internet Architecture Board , > urn-ietf@lists.internic.net.cnri.reston.va >From: The IESG >Subject: Protocol Action: Assignment Procedures for the URI Resolution > using DNS to BCP >Date: Thu, 13 Jun 2002 13:06:47 -0400 >Sender: scoya@cnri.reston.va.us > > > >The IESG has approved the Internet-Draft 'Assignment Procedures for the >URI Resolution using DNS' as a >BCP. This document is the product of the Uniform Resource Names >Working Group. The IESG contact persons are Ned Freed and Patrik >Faltstrom. > > > >Technical Summary > >draft-ietf-urn-uri-res-ddds-07.txt defines a how DNS is used as a >DDDS database that contains URI delegation rules. That document >specifies that the first step in that algorithm is to append >'URI.ARPA' to the URI scheme and retrieve the NAPTR record for that >domain-name. URN resolution also follows a similar procedure but uses >the 'URN.ARPA' zone as its root. This document describes the >procedures for inserting a new rule into the 'URI.ARPA' and >'URN.ARPA' zones by requesting the addition at IANA. It doesn't talk >about registrations of URI schemes or URN namespaces, only how the >entries are added to the DNS. > >Working Group Summary > >There was consensus around the proposal in the working group, aswell >as agreements with IANA about how the registration is to be done. > >Protocol Quality > >Patrik Faltstrom reviewed the document for the IESG. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 13 14:55:37 2002 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 OAA26024 for ; Thu, 13 Jun 2002 14:55:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13744 for enum-archive@odin.ietf.org; Thu, 13 Jun 2002 14:56: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 OAA13411; Thu, 13 Jun 2002 14:45: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 OAA13382 for ; Thu, 13 Jun 2002 14:45:34 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25670 for ; Thu, 13 Jun 2002 14:44:58 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5DIj3B15763 for ; Thu, 13 Jun 2002 14:45:03 -0400 Message-Id: <5.1.0.14.2.20020613145015.02368b70@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Jun 2002 14:50:26 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: Protocol Action: Dynamic Delegation Discovery System (DDDS) 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 >To: IETF-Announce: ; >Cc: RFC Editor , IANA , > Internet Architecture Board , urn-ietf@lists.netsol.com >From: The IESG >Subject: Protocol Action: Dynamic Delegation Discovery System (DDDS) to > Proposed Standard >Date: Thu, 13 Jun 2002 10:48:32 -0400 >Sender: scoya@cnri.reston.va.us > > > >The IESG has approved the following Internet-Drafts for publication as >Proposed Standards > > o Dynamic Delegation Discovery System (DDDS) > > > o A DDDS Database Using The Domain Name System > > > o URI Resolution using the Dynamic Delegation Discovery System > > >The IESG aslo approved publication of Dynamic Delegation Discovery >System (DDDS) Part One: The Comprehensive DDDS Standard > as an Informational RFC. > >Publication of these documents obsoletes RFC2915 and RFC2168. > > >These documents are the product of the Uniform Resource Names Working >Group. The IESG contact persons are Ned Freed and Patrik Faltstrom. > > >Technical Summary > >The DDDS defines an abstract algorithm for applying dynamically >retrieved string transformation rules to an application-unique >string. This means in reality that given some specific input string, >one can fetch transformation rules from a DDDS database, and by >applying them get the desired result. The key is that the DDDS >algorithm is abstract, and not dependent on any specific database or >protocol technology. > >The second document specifies how DDDS can be implemented using the >domain name system, and the third how one DDDS database (for example >one using DNS) can be used for resolution of URI schemes. > >Working Group Summary > >The URN working group have been using NAPTR resource records >according to specifications in RFC 2915 and 2168. Experience from the >last couple of years have shown that the description needed to be >split and abstracted in the three parts we see here. The wg had >consensus for this solution. > >Protocol Quality > >The protocol was reviewed by Patrik Faltstrom. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 13 16:15:05 2002 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 QAA28966 for ; Thu, 13 Jun 2002 16:15:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA18267 for enum-archive@odin.ietf.org; Thu, 13 Jun 2002 16:15:41 -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 QAA17846; Thu, 13 Jun 2002 16:06: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 QAA17814 for ; Thu, 13 Jun 2002 16:06:23 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28686 for ; Thu, 13 Jun 2002 16:05:46 -0400 (EDT) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id A87DF31914; Thu, 13 Jun 2002 13:05:51 -0700 (PDT) To: "Stastny Richard" Cc: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , "David Conrad" , "enum wg" Subject: Re: AW: [Enum] Re: Public Keys in ENUM In-Reply-To: Message from "Stastny Richard" of "Thu, 13 Jun 2002 11:02:16 +0200." <35B3051023BFA24CA5505982EBD7974C088EE6@oefeg-tmp.oefeg.loc> Date: Thu, 13 Jun 2002 13:05:51 -0700 Message-ID: <19721.1023998751@shell.nominum.com> From: Jim Reid 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 >>>>> "Richard" == Stastny Richard writes: Richard> If I understood Jims presentation in Richard> Geneva correctly, if you use DNSSEC you increase the data Richard> in DNS four times at least, so you blow UDP out of the Richard> water anyway. Is this correct? Zone files will increase by at least a factor of 4 (roughly) if they are using RFC2535-style DNSSEC. Every resource record (RR) will get a SIG record. Each RR -- actually each RRset -- will also get a NXT record and that NXT record also gets a SIG record. The actual multiplier will probably be more than 4 even though there are 4 times as many resource records in the signed zone. SIG records are not small. Signed answers typically exceed the 512 byte payload limit for a standard UDP DNS response because of the crypto gunk they have to include. This should not be an issue. EDNS0 allows for bigger DNS datagrams and most (all?) DNSSEC-aware servers and resolvers support this. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Jun 17 07:43:30 2002 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 HAA27221 for ; Mon, 17 Jun 2002 07:43:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA08081 for enum-archive@odin.ietf.org; Mon, 17 Jun 2002 07:44: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 HAA07695; Mon, 17 Jun 2002 07:33:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07670 for ; Mon, 17 Jun 2002 07:33:08 -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 HAA26705; Mon, 17 Jun 2002 07:32:26 -0400 (EDT) Message-Id: <200206171132.HAA26705@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: Mon, 17 Jun 2002 07:32:26 -0400 Subject: [Enum] I-D ACTION:draft-brandner-enum-uri-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 : The 'enum:' URI scheme Author(s) : R. Brandner, L. Conroy, R. Stastny Filename : draft-brandner-enum-uri-00.txt Pages : 6 Date : 14-Jun-02 This document specifies the 'enum:' URI scheme. This URI is intended for use where a resource can be returned by evaluating the URI value using the ENUM DDDS application. It also includes a definition of an optional URI parameter to indicate a list of enumservices that should be considered in the returned response to the ENUM query. Syntactically, it uses a subset of the format defined for the 'tel:' URI scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-brandner-enum-uri-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-brandner-enum-uri-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: <20020614131350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brandner-enum-uri-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brandner-enum-uri-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020614131350.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Jun 17 11:49:51 2002 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 LAA08402 for ; Mon, 17 Jun 2002 11:49:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23419 for enum-archive@odin.ietf.org; Mon, 17 Jun 2002 11: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 LAA22853; Mon, 17 Jun 2002 11:39: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 LAA22821 for ; Mon, 17 Jun 2002 11:39:34 -0400 (EDT) Received: from oefeg-tmp.oefeg.loc ([62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08028 for ; Mon, 17 Jun 2002 11:38:56 -0400 (EDT) Date: Mon, 17 Jun 2002 17:41:12 +0200 Message-ID: <35B3051023BFA24CA5505982EBD7974C088EF4@oefeg-tmp.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: I-D ACTION:draft-stastny-enum-services-analysis-00.txt Thread-Index: AcIWFRONISHSVdj7SNG8p4FKDwxGeg== From: "Stastny Richard" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA22822 Subject: [Enum] I-D ACTION:draft-stastny-enum-services-analysis-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 Content-Transfer-Encoding: 8bit FYI To: IETF-Announce: ; Subject: I-D ACTION:draft-stastny-enum-services-analysis-00.txt From: Internet-Drafts@ietf.org Date: Mon, 10 Jun 2002 07:17:01 -0400 Reply-to: Internet-Drafts@ietf.org Sender: nsyracus@cnri.reston.va.us A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of the Usage of ENUM and ENUM Services Author(s) : R. Stastny, R. Brandner, L. Conroy Filename : draft-stastny-enum-services-analysis-00.txt Pages : 11 Date : 07-Jun-02 This document analyzes the usage of the URI-schemes, services and 'enumservices' under discussion for the ENUM System. It tries to combine the existing proposals for 'enumservices' and proposes examples of a compatible approach as a way forward for the definition of the 'enumservices' to be used in the ENUM trials planned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stastny-enum-services-analysis -00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-stastny-enum-services-analysis-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-stastny-enum-services-analysis-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. Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Jun 18 07:37:18 2002 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 HAA13288 for ; Tue, 18 Jun 2002 07:37:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA06231 for enum-archive@odin.ietf.org; Tue, 18 Jun 2002 07:37: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 HAA05104; Tue, 18 Jun 2002 07:28: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 HAA05073 for ; Tue, 18 Jun 2002 07:28:00 -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 HAA12992; Tue, 18 Jun 2002 07:27:18 -0400 (EDT) Message-Id: <200206181127.HAA12992@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, 18 Jun 2002 07:27:18 -0400 Subject: [Enum] I-D ACTION:draft-ietf-enum-e164-gstn-np-04.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 : Number Portability in the GSTN: An Overview Author(s) : M. Foster, T. McGarry, J. Yu Filename : draft-ietf-enum-e164-gstn-np-04.txt Pages : 27 Date : 17-Jun-02 This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony work-in-progress at IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn-np-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-gstn-np-04.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-gstn-np-04.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: <20020617142738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-e164-gstn-np-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-e164-gstn-np-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020617142738.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 21 03:59:01 2002 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 DAA04019 for ; Fri, 21 Jun 2002 03:59:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26858 for enum-archive@odin.ietf.org; Fri, 21 Jun 2002 03:59:41 -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 DAA26590; Fri, 21 Jun 2002 03:49: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 DAA26559 for ; Fri, 21 Jun 2002 03:49:41 -0400 (EDT) Received: from oefeg-tmp.oefeg.loc (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03747 for ; Fri, 21 Jun 2002 03:48:59 -0400 (EDT) Subject: WG: [Enum] I-D ACTION:draft-ietf-enum-e164-gstn-np-04.txt Date: Fri, 21 Jun 2002 09:51:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-ID: <35B3051023BFA24CA5505982EBD7974C088F0D@oefeg-tmp.oefeg.loc> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-e164-gstn-np-04.txt Thread-Index: AcIWvUOrJ77S5ZzwTaKWSmEDRrr8aACOUpFNAABqL5k= From: "Stastny Richard" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id DAA26560 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 Hi James, congratulations to the new version of draft-ietf-enum-e164-gstn-np-04.txt. Its an excellent overview on NP issues. Although I had not the time to check everything, a quick first remark: Regarding Austria in the table Section 7, the sentence should read: Austria : Uses onward routing at the donor network. Routing prefix is "86xx" where "xx" identifies the recipient network (instead of switch). best regards Richard -----Ursprüngliche Nachricht----- Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Gesendet: Di 18.06.2002 13:27 An: Cc: enum@ietf.org Betreff: [Enum] I-D ACTION:draft-ietf-enum-e164-gstn-np-04.txt 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 : Number Portability in the GSTN: An Overview Author(s) : M. Foster, T. McGarry, J. Yu Filename : draft-ietf-enum-e164-gstn-np-04.txt Pages : 27 Date : 17-Jun-02 This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony work-in-progress at IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn-np-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-gstn-np-04.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-gstn-np-04.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. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 21 06:40:40 2002 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 GAA06722 for ; Fri, 21 Jun 2002 06:40:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA03792 for enum-archive@odin.ietf.org; Fri, 21 Jun 2002 06:41: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 GAA03297; Fri, 21 Jun 2002 06:31:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03262 for ; Fri, 21 Jun 2002 06:31:56 -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 GAA06413 for ; Fri, 21 Jun 2002 06:31:14 -0400 (EDT) Received: from gbcwcwarmsw3.isops.cwcom.co.uk ([148.185.176.7]) by relay.cwplc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5LAVls10287 for ; Fri, 21 Jun 2002 11:31:47 +0100 (BST) Received: from gbcwcbrti002.isops.cwcom.co.uk (unverified) by gbcwcwarmsw3.isops.cwcom.co.uk (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Fri, 21 Jun 2002 11:31:22 +0100 Received: by gbcwcbrti002.isops.cwcom.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jun 2002 11:30:10 +0100 Message-ID: From: "Rosbotham, Paul" To: enum@ietf.org Cc: james.yu@neustar.biz Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-e164-gstn-np-04.txt Date: Fri, 21 Jun 2002 11:31:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 GAA03263 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 James I'd echo Richard's praise - well done. The text as relates to the UK is correct, but note that Oftel launched a consultation last week to further move the goalposts (sorry, after this morning's football result that's a bad choice of words). The consultation can be found at http://www.oftel.gov.uk/publications/numbering/2002/nupo0602.htm Cheers Paul > -----Original Message----- > From: Stastny Richard [SMTP:Richard.Stastny@oefeg.at] > Sent: 21 June 2002 08:51 > To: enum@ietf.org > Cc: james.yu@neustar.biz > Subject: WG: [Enum] I-D ACTION:draft-ietf-enum-e164-gstn-np-04.txt > > Hi James, > > congratulations to the new version of draft-ietf-enum-e164-gstn-np-04.txt. Its an excellent overview on NP issues. > > Although I had not the time to check everything, a quick first remark: > > Regarding Austria in the table Section 7, the sentence should read: > > Austria : Uses onward routing at the donor network. Routing prefix is "86xx" where "xx" identifies the recipient network (instead of switch). > > best regards > Richard > > > -----Ursprüngliche Nachricht----- > Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Gesendet: Di 18.06.2002 13:27 > An: > Cc: enum@ietf.org > Betreff: [Enum] I-D ACTION:draft-ietf-enum-e164-gstn-np-04.txt > > > > 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 : Number Portability in the GSTN: An Overview > Author(s) : M. Foster, T. McGarry, J. Yu > Filename : draft-ietf-enum-e164-gstn-np-04.txt > Pages : 27 > Date : 17-Jun-02 > > This document provides an overview of E.164 telephone number > portability (NP) in the Global Switched Telephone Network (GSTN). > NP is a regulatory imperative seeking to liberalize local telephony > service competition, by enabling end-users to retain telephone > numbers while changing service providers. NP changes the > fundamental nature of a dialed E.164 number from a hierarchical > physical routing address to a virtual address, thereby requiring the > transparent translation of the later to the former. In addition, > there are various regulatory constraints that establish relevant > parameters for NP implementation, most of which are not network > technology specific. Consequently, the implementation of NP > behavior consistent with applicable regulatory constraints, as well > as the need for interoperation with the existing GSTN NP > implementations, are relevant topics for numerous areas of IP > telephony work-in-progress at IETF. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn-np-04.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > 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-gstn-np-04.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-gstn-np-04.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. > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://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 https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Jun 21 10:09:32 2002 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 KAA13702 for ; Fri, 21 Jun 2002 10:09:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13237 for enum-archive@odin.ietf.org; Fri, 21 Jun 2002 10:10: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 JAA12360; Fri, 21 Jun 2002 09:57:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10929 for ; Fri, 21 Jun 2002 09:17:51 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11338 for ; Fri, 21 Jun 2002 09:17:07 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5LDH1B32542; Fri, 21 Jun 2002 09:17:02 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jun 2002 08:16:56 -0500 Message-ID: <5E42C1C85C5D064A947CF92FADE6D82EBD24@STNTEXCH1> From: "Yu, James" To: "'Stastny Richard'" Cc: enum@ietf.org Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-e164-gstn-np-04.txt Date: Fri, 21 Jun 2002 08:16:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA10930 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, Thanks. Will incorporate. James > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, June 21, 2002 3:51 AM > To: enum@ietf.org > Cc: james.yu@neustar.biz > Subject: WG: [Enum] I-D ACTION:draft-ietf-enum-e164-gstn-np-04.txt > > > Hi James, > > congratulations to the new version of > draft-ietf-enum-e164-gstn-np-04.txt. Its an excellent > overview on NP issues. > > Although I had not the time to check everything, a > quick first remark: > > Regarding Austria in the table Section 7, the sentence > should read: > > Austria : Uses onward routing at the donor network. > Routing prefix is "86xx" where "xx" identifies the recipient > network (instead of switch). > > best regards > Richard > > > -----Ursprüngliche Nachricht----- > Von: Internet-Drafts@ietf.org > [mailto:Internet-Drafts@ietf.org] > Gesendet: Di 18.06.2002 13:27 > An: > Cc: enum@ietf.org > Betreff: [Enum] I-D > ACTION:draft-ietf-enum-e164-gstn-np-04.txt > > > > 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 : Number Portability in > the GSTN: An Overview > Author(s) : M. Foster, T. McGarry, J. Yu > Filename : > draft-ietf-enum-e164-gstn-np-04.txt > Pages : 27 > Date : 17-Jun-02 > > This document provides an overview of E.164 > telephone number > portability (NP) in the Global Switched > Telephone Network (GSTN). > NP is a regulatory imperative seeking to > liberalize local telephony > service competition, by enabling end-users to > retain telephone > numbers while changing service providers. NP > changes the > fundamental nature of a dialed E.164 number > from a hierarchical > physical routing address to a virtual address, > thereby requiring the > transparent translation of the later to the > former. In addition, > there are various regulatory constraints that > establish relevant > parameters for NP implementation, most of which > are not network > technology specific. Consequently, the > implementation of NP > behavior consistent with applicable regulatory > constraints, as well > as the need for interoperation with the existing GSTN NP > implementations, are relevant topics for > numerous areas of IP > telephony work-in-progress at IETF. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn- np-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-gstn-np-04.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-gstn-np-04.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. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Jun 21 10:50:12 2002 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 KAA15418 for ; Fri, 21 Jun 2002 10:50:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15264 for enum-archive@odin.ietf.org; Fri, 21 Jun 2002 10:50: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 KAA14858; Fri, 21 Jun 2002 10:41: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 KAA14816 for ; Fri, 21 Jun 2002 10:41:53 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15108 for ; Fri, 21 Jun 2002 10:41:10 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5LEfAB01737; Fri, 21 Jun 2002 10:41:11 -0400 Message-Id: <5.1.0.14.2.20020621103516.024327a8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Jun 2002 10:47:21 -0400 To: Brandner Rudolf From: Richard Shockey Cc: richard.stastny@oefeg.at, CONROY LAWRENCE , enum@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] PRIVATE Triggering ENUM Queries w/ URI 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 was wondering for a while what might be the possible use for the ENUM URI scheme until I started talking to several carriers (who shall remain nameless). Over the last several weeks I've had talks with senior SS7 (C7) types who are clearly thinking about the impact of VoIP in their markets etc. What they are trying to wrestle with is the following scenario...which is how can they dump a call destined for a IP endpoint immediately at point of origination to a Media Gateway which then does the ENUM query and routes the call as appropriate. This was the first time I've heard a carrier really start to think hard and long about convergence signalling. 1. A POTS call enters the C5 switch 2. How does the switch know that the call has a alternative routing mechanism (IP)? 3. In the US case the idea was to do a LNP dip immediately at origination instead of N-1 but there would be a trigger field in the LRN data field that would signal the C5 that ...AH HA .. you can transport this call via IP. Now I started thinking ...what if that trigger was a enum URI? 4. Now of course this could be accomplished by having the C5 do a DNS query immediately but I doubt we will see switches build in that capability any time soon. Rudolf ..what I'm suggesting is some usage examples here to focus attention on how the ENUM URI might be useful in a converged routing architecture. Thoughts ... could this be a useful C7/SS7 signalling data point? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Jun 21 11:05:52 2002 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 LAA16113 for ; Fri, 21 Jun 2002 11:05:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16386 for enum-archive@odin.ietf.org; Fri, 21 Jun 2002 11:06: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 KAA15554; Fri, 21 Jun 2002 10:57:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15522 for ; Fri, 21 Jun 2002 10:57:39 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15662 for ; Fri, 21 Jun 2002 10:56:57 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5LEv6B02011 for ; Fri, 21 Jun 2002 10:57:06 -0400 Message-Id: <5.1.0.14.2.20020621105116.04131558@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Jun 2002 11:03:21 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Agenda Items for Yokohama.... 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 believe Patrik will have the revision of 2916bis ready to meet the cut off date. It looks like we are scheduled for Monday ... I know that is difficult for some but in order to not conflict with the numerous groups we are associated with it may be the best we can do. So... I'd like to start compiling proposals as soon as possible. A reminder ..we are only going to discuss topics that have been reviewed and discussed on the list. ######################### ONDAY, July 15, 2002 0800-1930 IETF Registration - 0800-0900 Continental Breakfast 0900-1130 Morning Sessions APP apparea Applications Open Area Meeting INT ipoib IP over InfiniBand WG OPS bmwg Benchmarking Methodology WG TSV nsis Next Steps in Signaling WG TSV pwe3 Pseudo Wire Emulation Edge to Edge WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP trade Internet Open Trading Protocol WG SEC smime S/MIME Mail Security WG SUB ccamp Common Control and Measurement Plane WG TSV enum Telephone Number Mapping WG TSV ippm IP Performance Metrics WG >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Jun 21 15:04:01 2002 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 PAA27452 for ; Fri, 21 Jun 2002 15:04:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03166 for enum-archive@odin.ietf.org; Fri, 21 Jun 2002 15:04: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 OAA02194; Fri, 21 Jun 2002 14:53: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 OAA02164 for ; Fri, 21 Jun 2002 14:53:30 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26967 for ; Fri, 21 Jun 2002 14:52:47 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5LIqwB06403 for ; Fri, 21 Jun 2002 14:52:58 -0400 Message-Id: <5.1.0.14.2.20020621145638.023ddc20@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Jun 2002 14:59:14 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Excellent Introductory Article on ENUM in the latest Internet Protocol Journal 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 Hot off the web! Very very useful for folks that are new to the subject. My personal thanks to Ole Jacobson and Geoff Huston for this ... http://www.cisco.com/warp/public/759/ipj_issues.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Jun 22 03:50:26 2002 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 DAA21355 for ; Sat, 22 Jun 2002 03:50:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA07494 for enum-archive@odin.ietf.org; Sat, 22 Jun 2002 03:51: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 DAA07124; Sat, 22 Jun 2002 03:34: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 DAA07094 for ; Sat, 22 Jun 2002 03:34:01 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21138 for ; Sat, 22 Jun 2002 03:33:17 -0400 (EDT) Received: from xbe-ams-303.cisco.com (xbe-ams-303.cisco.com [144.254.75.93]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5M7VcKD005045; Sat, 22 Jun 2002 00:33:25 -0700 (PDT) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sat, 22 Jun 2002 09:31:59 +0200 Received: from [10.0.1.100] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sat, 22 Jun 2002 09:31:59 +0200 Date: Fri, 21 Jun 2002 22:15:23 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Richard Shockey , enum@ietf.org Subject: Re: [Enum] Agenda Items for Yokohama.... Message-ID: <3981239.1024697723@localhost> In-Reply-To: <5.1.0.14.2.20020621105116.04131558@popd.ix.netcom.com> References: <5.1.0.14.2.20020621105116.04131558@popd.ix.netcom.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 22 Jun 2002 07:31:59.0642 (UTC) FILETIME=[E50277A0:01C219BE] 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 --On 2002-06-21 11.03 -0400 Richard Shockey wrote: > I believe Patrik will have the revision of 2916bis ready to meet the cut > off date. Yes, that is the plan. I moved two weeks ago, and was at INET in Washington last week...but, the next couple of days I will produce one. Now, if you have things you have pointed out which you really want as changes from 00 to 01, please resend the issues _just_in_case_. I have the whole mailing list archive to go through, and might of course as all humans miss some issues... I don't mind getting told twice, or trice, what issues you have which should be updated. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Jun 26 10:47:41 2002 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 KAA21251 for ; Wed, 26 Jun 2002 10:47:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA03799 for enum-archive@odin.ietf.org; Wed, 26 Jun 2002 10:48: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 KAA03039; Wed, 26 Jun 2002 10:34:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03008 for ; Wed, 26 Jun 2002 10:34:05 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20719 for ; Wed, 26 Jun 2002 10:33:21 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5QEXZB07892 for ; Wed, 26 Jun 2002 10:33:35 -0400 Message-Id: <5.1.0.14.2.20020626103606.02386db0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Jun 2002 10:39:42 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] We're still looking for agenda items here... and comments on 2916bis 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 Hello folks... the list is rather silent on these issues ..... ######################## Just a reminder on presentations: This comes from Scott Bradner and Loa Anderson which sums up the consensus on policy very well.... It is not the purpose of a WG session to have presentation of the content of a document. It is assumed that all attendees will have read the drafts in advance of the meeting. For documents that are work-in-progress, the presentation should cover issues resolved since the last draft followed by open issues and controversial topics with the intent to reach a resolution of said issues and topics. For new work items, the presentation should focus on what the problem is and why it is necessary for the work group to address it. Further it should be either shown how it falls within the existing charter or why and how the charter should be extended to encompass it. The solution should only be sketched. The appropriate way of bringing new work to the working group is to send a draft to the mailing list and promoting discussion on the list. Slots on the agenda should be used to discuss outstanding topics that has not be solved on the mailing list. For new proposals addressing issues where work-in-progess the presentation should focus on the (perceived) short-fallings of the existing work and why those issues need to be addressed both in terms of why they are required and why they cannot be addressed in the existing work. the new work must be related to existing work (i.e. compatible, mutually exclusive, outright replacement). Finally, the new solution should be skechted, explaining how the solution overcomes those issues. The primary purpose of this last part is to allow commentary from the floor, it should not be orientented toward selling the idea. In all cases only a limited number of slides should be used. Speakers should budget their at least 25% of their time to allow for questions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Jun 26 15:17:41 2002 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 PAA06483 for ; Wed, 26 Jun 2002 15:17:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24490 for enum-archive@odin.ietf.org; Wed, 26 Jun 2002 15:18:26 -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 PAA24058; Wed, 26 Jun 2002 15:08:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24027 for ; Wed, 26 Jun 2002 15:08:57 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06040 for ; Wed, 26 Jun 2002 15:08:12 -0400 (EDT) Received: from xbe-lon-303.cisco.com (xbe-lon-303.cisco.com [64.103.98.22]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5QJ7gVc025953 for ; Wed, 26 Jun 2002 21:07:42 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 26 Jun 2002 20:08:26 +0100 Received: from [10.0.1.100] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 26 Jun 2002 21:08:25 +0200 Date: Wed, 26 Jun 2002 20:59:32 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum@ietf.org Message-ID: <7235289.1025125172@localhost> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 26 Jun 2002 19:08:25.0783 (UTC) FILETIME=[D9249470:01C21D44] Content-Transfer-Encoding: 7bit Subject: [Enum] enumservices in new version of 2916bis 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 I have been discussing how to define enumservice with Michael Mealling outside of the list, and he and myself have different opinion, so I really want/need to know what the consensus of the wg is. I ask Richard to be the wg chair which sort things out. The format of the service field in the NAPTR is to be: E2U+enumservice1+enumservice2+... My personal view is that enumservice1 (etc) is to be defined in a way so the client know exactly what he needs to know before selecting the record. Or rather, if the client get two NAPTR records, and those are like this: E2U+enumservice1 E2U+enumservice2 ...then the client must know which one of the two "makes sense" to him. Regarding "makes sense" both Michael and I see two different axis along which one have to do a selection: - Protocol (basically, URI scheme and/or final protocol to use) - Function (talk, fax, chat,...) Michael suggested that one should have the following _two_ attributes: E2U+function+protocol This is one after defining an enumservice (as a function), one can say explicitly if the function (such as "talk") is to be on sip/rtp or h323 or whatever. Once again, my view is that IF the client need to know more than "talk", for example what URI scheme which will be the result, then that have to be clear in the registration of the enumservice itself. For example, from my point of view, voice call with the help of SIP might not be enough for a client. One might want to know also what resulting protocol is to be used after negotiations inside the SIP protocol. Is then the protocol according to Michaels idea "sip" or "rtp" or "sip+rtp"? Should "talk" define what protocols are to be used, or do one need two defnitions, the function and the protocol? A registration of a protocol, should that be the URI scheme or a separate registration for ENUM? Or, should we go down the path I suggest? Where the enumservice is to define whatever is needed? I need advice. What is the consensus of the group? I think we should discuss this in Yokohama, but, I want to write something in the draft which is no too far away... paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Jun 26 15:51:04 2002 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 PAA08267 for ; Wed, 26 Jun 2002 15:51:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26622 for enum-archive@odin.ietf.org; Wed, 26 Jun 2002 15:51: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 PAA26045; Wed, 26 Jun 2002 15:42: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 PAA26008 for ; Wed, 26 Jun 2002 15:42:26 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07880 for ; Wed, 26 Jun 2002 15:41:41 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5QJfeB13840; Wed, 26 Jun 2002 15:41:40 -0400 Message-Id: <5.1.0.14.2.20020626153351.023ad8c8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Jun 2002 15:47:52 -0400 To: Patrik =?iso-8859-1?Q?Fältström?= , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] enumservices in new version of 2916bis In-Reply-To: <7235289.1025125172@localhost> 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 PAA26009 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 08:59 PM 6/26/2002 +0200, Patrik Fältström wrote: >I have been discussing how to define enumservice with Michael Mealling >outside of the list, and he and myself have different opinion, so I really >want/need to know what the consensus of the wg is. I ask Richard to be the >wg chair which sort things out. O I have to be neutral now right? :-) >The format of the service field in the NAPTR is to be: > > E2U+enumservice1+enumservice2+... Naming clarification here .... I have usually associated ' enumservice' with all data included in the record. maybe it would be better to define things as E2U+data1+data2+.. where dataX is defined as elements that could represent Protocol or Function or now add Transport...see below >My personal view is that enumservice1 (etc) is to be defined in a way so >the client know exactly what he needs to know before selecting the record. >Or rather, if the client get two NAPTR records, and those are like this: > > E2U+enumservice1 > E2U+enumservice2 > >...then the client must know which one of the two "makes sense" to him. > >Regarding "makes sense" both Michael and I see two different axis along >which one have to do a selection: > > - Protocol (basically, URI scheme and/or final protocol to use) > - Function (talk, fax, chat,...) > >Michael suggested that one should have the following _two_ attributes: > > E2U+function+protocol There seemed to be some consensus on this ... I certainly thought that things like E2U+FAX+SMTP or E2U+FAX+tel to be reasonable. >This is one after defining an enumservice (as a function), one can say >explicitly if the function (such as "talk") is to be on sip/rtp or h323 or >whatever. > >Once again, my view is that IF the client need to know more than "talk", >for example what URI scheme which will be the result, then that have to be >clear in the registration of the enumservice itself. > >For example, from my point of view, voice call with the help of SIP might >not be enough for a client. One might want to know also what resulting >protocol is to be used after negotiations inside the SIP protocol. Is then >the protocol according to Michaels idea "sip" or "rtp" or "sip+rtp"? Well my views on the E2U+function+SIP issue is well known but you have brought up something new ... SIP can be transported over different protocols RTP and RTSP is this where the hint is given? I really hope the SIP people will make their views known. >Should "talk" define what protocols are to be used, or do one need two >defnitions, the function and the protocol? A registration of a protocol, >should that be the URI scheme or a separate registration for ENUM? I'm assuming that 2916bis tests for IANA enumservice field registration are what we discussed in the past ... applicability statement .. security considerations, privacy considerations etc.?? >Or, should we go down the path I suggest? Where the enumservice is to >define whatever is needed? > >I need advice. What is the consensus of the group? > >I think we should discuss this in Yokohama, but, I want to write something >in the draft which is no too far away... I think its topic A. :-) > paf > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Jun 26 16:21:24 2002 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 QAA09306 for ; Wed, 26 Jun 2002 16:21:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28012 for enum-archive@odin.ietf.org; Wed, 26 Jun 2002 16:22: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 QAA27679; Wed, 26 Jun 2002 16:13: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 QAA27651 for ; Wed, 26 Jun 2002 16:13:01 -0400 (EDT) Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net [38.202.36.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09044 for ; Wed, 26 Jun 2002 16:12:15 -0400 (EDT) Received: from dranalli ([65.203.166.57]) by hvmta02-stg.us.psimail.psi.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020626201257.JBMF1886.hvmta02-stg.us.psimail.psi.net@dranalli>; Wed, 26 Jun 2002 16:12:57 -0400 Message-ID: <011701c21d4d$dcda3350$39a6cb41@netnumber.com> Reply-To: "Douglas Ranalli" From: "Douglas Ranalli" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , References: <7235289.1025125172@localhost> Subject: Re: [Enum] enumservices in new version of 2916bis Date: Wed, 26 Jun 2002 16:12:56 -0400 Organization: NetNumber.com, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, In response to your question: > Michael suggested that one should have the following _two_ attributes: > > E2U+function+protocol I support Michael's proposal. Both approaches are perfectly reasonable but in working to implement ENUM based solutions we've found value in the flexibility that comes from being able to sort ENUM records along two different criteria: "Function" answers the question: "What does this particular service do?" "Protocol" answer the question: "How do I talk to this particular service?" Thank you for your efforts in trying to bring this issue to consensus. DJR Douglas Ranalli NetNumber, Inc. dranalli@netnumber.com ----- Original Message ----- From: "Patrik Fältström" To: Sent: Wednesday, June 26, 2002 2:59 PM Subject: [Enum] enumservices in new version of 2916bis > I have been discussing how to define enumservice with Michael Mealling > outside of the list, and he and myself have different opinion, so I really > want/need to know what the consensus of the wg is. I ask Richard to be the > wg chair which sort things out. > > The format of the service field in the NAPTR is to be: > > E2U+enumservice1+enumservice2+... > > My personal view is that enumservice1 (etc) is to be defined in a way so > the client know exactly what he needs to know before selecting the record. > Or rather, if the client get two NAPTR records, and those are like this: > > E2U+enumservice1 > E2U+enumservice2 > > ...then the client must know which one of the two "makes sense" to him. > > Regarding "makes sense" both Michael and I see two different axis along > which one have to do a selection: > > - Protocol (basically, URI scheme and/or final protocol to use) > - Function (talk, fax, chat,...) > > Michael suggested that one should have the following _two_ attributes: > > E2U+function+protocol > > This is one after defining an enumservice (as a function), one can say > explicitly if the function (such as "talk") is to be on sip/rtp or h323 or > whatever. > > Once again, my view is that IF the client need to know more than "talk", > for example what URI scheme which will be the result, then that have to be > clear in the registration of the enumservice itself. > > For example, from my point of view, voice call with the help of SIP might > not be enough for a client. One might want to know also what resulting > protocol is to be used after negotiations inside the SIP protocol. Is then > the protocol according to Michaels idea "sip" or "rtp" or "sip+rtp"? > > Should "talk" define what protocols are to be used, or do one need two > defnitions, the function and the protocol? A registration of a protocol, > should that be the URI scheme or a separate registration for ENUM? > > Or, should we go down the path I suggest? Where the enumservice is to > define whatever is needed? > > I need advice. What is the consensus of the group? > > I think we should discuss this in Yokohama, but, I want to write something > in the draft which is no too far away... > > paf > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Jun 26 18:17:48 2002 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 SAA13639 for ; Wed, 26 Jun 2002 18:17:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04597 for enum-archive@odin.ietf.org; Wed, 26 Jun 2002 18:18:30 -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 SAA04110; Wed, 26 Jun 2002 18:09: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 SAA04083 for ; Wed, 26 Jun 2002 18:09:04 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13335 for ; Wed, 26 Jun 2002 18:08:19 -0400 (EDT) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 23:09:04 +0100 Received: from [192.168.0.3] (greeneye.roke.co.uk [193.118.195.83]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N4S7DHL2; Wed, 26 Jun 2002 23:08:57 +0100 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Cc: Patrik , Rudi , Richard , Rich Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Wed, 26 Jun 2002 23:08:49 +0100 Subject: RE: [Enum] enumservices in new version of 2916bis Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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 multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="us-ascii" ; format="flowed" Hi Folks, whilst on the topic of issues for the agenda... I am glad that someone has been discussing the format for enumservices - it seemed quiet on the list. BTW, Rudi, Richard, and I have three drafts that are germane here: The "enum scenarios" draft . The "enumservice analysis" draft The "enumservice categories" draft From the above it's pretty obvious that I/we agree with the protocol/function matrix. (Note though that for protocol, we have URI-scheme). Whether or not the URI-scheme is needed within the service field is a question that has been raised in the draft (and on the list), and will be raised in the meeting, I'm sure. I believe that it's just a regexp away, so isn't needed in the service field - the NAPTRs will have been filtered on function (a.k.a. enumservice category) already so there won't be a lot. (Further comments on "function" in a separate mail :). Also, some nasty people have pointed out that one could download URI-scheme handlers :( In that situation, it's not easy to tell what URIs are appropriate. Thus I *think* I'm with Patrik on this one - we don't NEED the URI-scheme to be copied into the services field, and it complicates parsing with a non-terminal NAPTR (where there IS no URI-scheme). The idea that we should specify the eventual session/protocol that will result from the Service Resolution Service (i.e. SIP) is interesting. However, I have a question and a nightmare:: If I fire up a browser window for the 7cent.com site where in this URL does it specify the embedded sound that plays as a result of opening this URL (no - it won't make your ears bleed)? Seems that there ARE precedents for not indicating the mess one will get into when following a URL; plus this is a nightmare to validate and synchronize (between DNS and a SIP registrar/proxy). Re. a possible "shape" for the category definitions: - see the enumservice category draft - this includes the URI-schemes that will "fit" within each category. I'm not sure this fits exactly with Patrik's "give the client everything he needs" - as that would include the URI-scheme that is found after regexp replacement. ------- Regarding Rich's comments: * Whoa - In each NAPTR there is (potentially) a list of enumservices. That's in both RFC2916 and draft-2916bis. All right, Rich - I'll buy you a beer if I don't have to re-write all of the drafts that have used this term. If one beer's not enough, I'm sure that Rudi and Richard will as well :) -Please- choose another term for the sub-field you called enumservice1/enumservice2. * Hmm....Just when you thought URI-scheme was bad, we bring in protocols. Should SMTP read mailto? (As for rtp - is there an rtp: URI-scheme?) * Transport....SIP has its own negotiation mechanism for selecting between UDP, TCP, and TLS. (As well as the protocol that will be used for the resulting session to be initiated) * (I think it's topic A and B and C :)) Just my 7 cents for this one. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Jun 26 18:46:27 2002 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 SAA14297 for ; Wed, 26 Jun 2002 18:46:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA06282 for enum-archive@odin.ietf.org; Wed, 26 Jun 2002 18:47: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 SAA05827; Wed, 26 Jun 2002 18:38: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 SAA05796 for ; Wed, 26 Jun 2002 18:38:04 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14068 for ; Wed, 26 Jun 2002 18:37:21 -0400 (EDT) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 23:38:04 +0100 Received: from [192.168.0.3] (greeneye.roke.co.uk [193.118.195.83]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N4S7DHLP; Wed, 26 Jun 2002 23:37:55 +0100 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Cc: Rudi , Richard Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Wed, 26 Jun 2002 23:37:52 +0100 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Enum] high and low level function mixing 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 multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="us-ascii" ; format="flowed" Hi again folks, Note that one issue is "what is the 'level' of the matrix 'function' axis"? This is covered extensively in the enumservice-analysis draft, but there seem to be two discrete possibilities. We have "high level functions" - also known as categories - and/or we have "low level" functions like voice, video, fax, sms, (basically the ones listed in the tel-svc draft plus possibly one or two more, like mailto). Now...in the analysis draft, there's the possibility of mixing these; thus +talk+voice, or msg+sms. This raises an interesting detail that's covered only briefly in the "category" draft and I'd like to flag here. If the querying user is interested in a high level category like "talk", and the registrant has specified a low level function like "voice", a simple string match is not going to work. In the category draft we've tried to cover the low level functions that are contained in each of the categories, so if the querying end user (or the User Interface with which they're interacting) specifies "talk" then this can be converted into a list with the strings "talk" plus all of the more specific services that comprise this category ("voice", "video"). All of the strings in this list can be matched against the incoming NAPTR, and it works fine. However.... What if the querying user specifies a low level service like "video", but the registrant has specified only a category like "talk"? There seem to be two choices here - either the D3S client application engine doesn't match the string (in which case we may have a false negative) or the "containing" category string is added, in which case we MAY have a false positive. The querying user may have no way to know whether or not this *is* a false positive without trying the URI (certainly if it's a tel:). Personally, I think that the D3S client application engine should return the URI in this situation. The registrant may have their own (privacy ?) reasons for not being more specific, and for "normal" protocols like SIP there will be a second negotiation phase outside ENUM anyway. However, I'd appreciate any comments on this, please. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Jun 27 05:10:45 2002 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 FAA06976 for ; Thu, 27 Jun 2002 05:10:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA14576 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 05:11:30 -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 EAA13599; Thu, 27 Jun 2002 04:59: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 EAA13568 for ; Thu, 27 Jun 2002 04:59:56 -0400 (EDT) Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06779 for ; Thu, 27 Jun 2002 04:59:11 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] enumservices in new version of 2916bis MIME-Version: 1.0 Date: Thu, 27 Jun 2002 11:01:39 +0200 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <06CF906FE3998C4E944213062009F1620246F7@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Enum] enumservices in new version of 2916bis Thread-Index: AcIdS58CSscnicsDS5u2asLDEqLmHgAaFc0w From: "Stastny Richard" To: "Richard Shockey" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA13569 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 Hi folks, E2U+function+protocol+...? So we are back to G.711 again? I really have a problem with this discussion, especially with SIP and TEL. On one side I hear from SIP people, that SIP is enough, because it is "srs" and everything can be negotiated anyway, and now I hear that we have to include rtp as well? Since we have multiple (6) dimensions here, we have IMHO two (three?) options. The dimensions are: E2U (which is the only stable item) category (e.g. talk or msg as proposed in draft-brandner-enum-categorical-enumservices-00) service (e.g. voice, video, fax, ..) protocol or better URI-scheme (e.g. sip, h323, tel, mailto, ...) subprotocol etc. (e.g. rtp, G711, ...?) additional info (e.g. home, office, mobile, ...) In draft-stastny-enum-services-analysis I proposed to combine service and protocol, but this is not the issue, they also may be separate. The two options are: 1) Put everything in the enumservice field: E.g. "E2U+category+service+URIscheme+subprotocol+addinfo", eventually defining default values if there is no entry. This also raises some questions: is mailto the default of msg, or msg the default of mailto ;-) 2) Put only information in the enumservice field which is NOT in the URI, assuming the the regexp(s) are evaluated before the NAPTR is selected (which I would prefer, because I do not really see the problem doing this) E.g. "E2U+category+addinfo" ... URIscheme;svc=service For version 1 it should be kept in mind also, that especially the tel URI may allow multiple categories and/or services: E.g. "E2U+talk+msg+voice+fax+sms There should also be a clear definition if this is allowed or if separate NAPTRs have to be used in this case. BTW, the third option would be, to cancel the whole discussion on enumservices and just use only E2U and define the URIs in such a way, that everything may be expressed with the URI. I think, that has to be done anyway, since an URI may also be used without ENUM (e.g. as a link on a webpage or in an email signature, so a client should be able to do the same it is doing with a NAPTR + URIscheme with the URI alone. Or put it the other way round, the URI in the NAPTR may contain enough information to be selected by the client, if it is only allowed to look at it. If not, we end up duplicating any possible information in the URI-scheme in the enumservice field (as proposed in option one). Best regards Richard Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at > -----Original Message----- > From: Richard Shockey [mailto:rich.shockey@NeuStar.com] > Sent: Wednesday, June 26, 2002 9:48 PM > To: Patrik Fältström; enum@ietf.org > Subject: Re: [Enum] enumservices in new version of 2916bis > > > At 08:59 PM 6/26/2002 +0200, Patrik Fältström wrote: > >I have been discussing how to define enumservice with > Michael Mealling > >outside of the list, and he and myself have different opinion, so I > >really want/need to know what the consensus of the wg is. I > ask Richard > >to be the wg chair which sort things out. > > O I have to be neutral now right? :-) > > > >The format of the service field in the NAPTR is to be: > > > > E2U+enumservice1+enumservice2+... > > Naming clarification here .... I have usually associated ' > enumservice' > with all data included in the record. > > maybe it would be better to define things as > > E2U+data1+data2+.. > > where dataX is defined as elements that could represent Protocol or > Function or now add Transport...see below > > > >My personal view is that enumservice1 (etc) is to be defined > in a way > >so the client know exactly what he needs to know before > selecting the > >record. Or rather, if the client get two NAPTR records, and > those are > >like this: > > > > E2U+enumservice1 > > E2U+enumservice2 > > > >...then the client must know which one of the two "makes > sense" to him. > > > >Regarding "makes sense" both Michael and I see two different > axis along > >which one have to do a selection: > > > > - Protocol (basically, URI scheme and/or final protocol to use) > > - Function (talk, fax, chat,...) > > > >Michael suggested that one should have the following _two_ > attributes: > > > > E2U+function+protocol > > There seemed to be some consensus on this ... I certainly > thought that > things like > > E2U+FAX+SMTP or > E2U+FAX+tel > > to be reasonable. > > > > >This is one after defining an enumservice (as a function), > one can say > >explicitly if the function (such as "talk") is to be on > sip/rtp or h323 > >or whatever. > > > >Once again, my view is that IF the client need to know more than > >"talk", for example what URI scheme which will be the > result, then that > >have to be clear in the registration of the enumservice itself. > > > >For example, from my point of view, voice call with the help of SIP > >might not be enough for a client. One might want to know also what > >resulting protocol is to be used after negotiations inside the SIP > >protocol. Is then the protocol according to Michaels idea "sip" or > >"rtp" or "sip+rtp"? > > Well my views on the E2U+function+SIP issue is well known > but you have > brought up something new ... SIP can be transported over different > protocols RTP and RTSP is this where the hint is given? > > I really hope the SIP people will make their views known. > > > >Should "talk" define what protocols are to be used, or do > one need two > >defnitions, the function and the protocol? A registration of a > >protocol, should that be the URI scheme or a separate > registration for > >ENUM? > > > I'm assuming that 2916bis tests for IANA enumservice field > registration > are what we discussed in the past ... applicability statement > .. security > considerations, privacy considerations etc.?? > > > >Or, should we go down the path I suggest? Where the > enumservice is to > >define whatever is needed? > > > >I need advice. What is the consensus of the group? > > > >I think we should discuss this in Yokohama, but, I want to write > >something in the draft which is no too far away... > > I think its topic A. :-) > > > > paf > > > > > >_______________________________________________ > >enum mailing list > >enum@ietf.org > >https://www1.ietf.org/mailman/listinfo/enum > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology > Initiatives NeuStar Inc. > 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 > 1120 Vermont Ave NW Suite 400 Washington DC 20005 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Jun 27 06:46:52 2002 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 GAA10142 for ; Thu, 27 Jun 2002 06:46:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA21449 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 06:47: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 GAA19729; Thu, 27 Jun 2002 06:38: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 GAA19698 for ; Thu, 27 Jun 2002 06:38:37 -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 GAA08781; Thu, 27 Jun 2002 06:37:51 -0400 (EDT) Message-Id: <200206271037.GAA08781@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: Thu, 27 Jun 2002 06:37:51 -0400 Subject: [Enum] I-D ACTION:draft-brandner-enum-categorical-enumservices-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 : 'Categorical enumservices' Author(s) : R. Brandner, L. Conroy, R. Stastny Filename : draft-brandner-enum-categorical-enumservices-00.txt Pages : 14 Date : 26-Jun-02 This document defines the set of enumservices describing 'high level' communications categories. These are used as elements within the services field of NAPTR resource records within ENUM domain space. Each category identifies a kind of communications service in which an end user might want to engage using the associated resource. It includes the expected 'low level' service that comes under each category, together with a list of the URI schemes that are appropriate for use with each categorical enumservice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enum-categorical-enumservices-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-brandner-enum-categorical-enumservices-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-brandner-enum-categorical-enumservices-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: <20020626134444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brandner-enum-categorical-enumservices-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brandner-enum-categorical-enumservices-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020626134444.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Jun 27 11:19:10 2002 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 LAA23384 for ; Thu, 27 Jun 2002 11:19:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16002 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 11:19:54 -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 LAA14411; Thu, 27 Jun 2002 11:09: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 LAA14326 for ; Thu, 27 Jun 2002 11:09:40 -0400 (EDT) Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net [38.202.36.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22580 for ; Thu, 27 Jun 2002 11:08:54 -0400 (EDT) Received: from RWALTER ([65.203.166.26]) by hvmta02-stg.us.psimail.psi.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020627150937.QUFE1886.hvmta02-stg.us.psimail.psi.net@RWALTER>; Thu, 27 Jun 2002 11:09:37 -0400 Reply-To: From: "Robert H. Walter" To: "Stastny Richard" , Subject: RE: [Enum] enumservices in new version of 2916bis Date: Thu, 27 Jun 2002 11:09:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <06CF906FE3998C4E944213062009F1620246F7@oefeg-s02.oefeg.loc> 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 > E2U+function+protocol+...? So the extreme boundaries of the problem have been identified... minimum: E2U maximum: E2U+category+service+URIscheme+subprotocol+addinfo Einstein once said: "Everything should be made as simple as possible, but not simpler" The answer lies somewhere in between... The service field should be used to enable a client application to rapidly select the NAPTR records it is interested in, Consequently... 1. The DDDS indicator (E2U) is required because the NAPTR record can be overloaded for many purposes and NAPTRs must be distinguishable between applications. 2. The FUNCTION is required because a client application needs to be able to distinguish between NAPTRs that share the same URI scheme or protocol. For example, assume the following two NAPTRs are associated with a telephone number: NAPTR 0 0 "U" "E2U" "!^.*$!mailto:user@vmail.domain1!" . NAPTR 0 0 "U" "E2U" "!^.*$!mailto:user@email.domain2!" . The first identifies an voice messaging system that supports and SMTP interface, the second identifies a conventional electronic mail system. Assume the client application wants to send a recorded voice message to the voice messaging server. How does the application differentiate between the two NAPTRs? The answer is simple, by service... NAPTR 0 0 "U" "E2U+vmail" "!^.*$!mailto:user@vmail.domain1!" . NAPTR 0 0 "U" "E2U+email" "!^.*$!mailto:user@email.domain2!" . 3. The PROTOCOL should not be required but deserves serious consideration. Processing of the regular expression dominates the overall processing time of the ENUM response. By including the protocol the application can rapidly select all NAPTR records that are of interest. The alternative is to LESS rapidly select interesing NAPTR records. I am having difficulty distinguishing between CATEGORY and SERVICE, i.e. TALK and VOICE, feel redundant. As for SUBPROTOCOL, this is the purpose of Session Description Protocol and is undoubtably over-kill. Finally, ADDINFO is an extension mechanism, which violates Einstonian wisdom... I propose the following EBNF for the ENUM service field: enum-service : "E2U" ( function )+ function : "+" service [ ":" protocol ] service : "voice" | "video" | "email" | "vmail" | other protocol : "smtp" | "sip" | "h323" | "mms" | other other : For those that don't read EBNF, the enum-service field starts with the string "E2U" and is followed by one or more functions. Each function starts with a "+" and consists of a service string and optional protocol string that starts with a ":". Several examples are: "E2U+email" "E2U+email:smtp" "E2U+vmail:smtp" "E2U+email+vmail" "E2U+voice:h323" "E2U+voice" The service and protocol strings should be registered with IANA, while other extensions should be ignored. Regards, Bob Walter NetNumber, Inc. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Jun 27 12:01:05 2002 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 MAA26949 for ; Thu, 27 Jun 2002 12:01:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21932 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 12:01: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 LAA19956; Thu, 27 Jun 2002 11:51: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 LAA19924 for ; Thu, 27 Jun 2002 11:51:28 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25918 for ; Thu, 27 Jun 2002 11:50:42 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5RFosB31955; Thu, 27 Jun 2002 11:50:55 -0400 Message-Id: <5.1.0.14.2.20020627113632.043f3bc0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Jun 2002 11:57:16 -0400 To: , From: Richard Shockey Subject: RE: [Enum] enumservices in new version of 2916bis In-Reply-To: References: <06CF906FE3998C4E944213062009F1620246F7@oefeg-s02.oefeg.loc> 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 11:09 AM 6/27/2002 -0400, Robert H. Walter wrote: > > E2U+function+protocol+...? > >So the extreme boundaries of the problem have been identified... > >minimum: E2U >maximum: E2U+category+service+URIscheme+subprotocol+addinfo > >Einstein once said: > > "Everything should be made as simple as possible, but not simpler" Well said .... that should be a guiding rule as we attempt to come to some rough consensus ... >The answer lies somewhere in between... The service field should >be used to enable a client application to rapidly select the NAPTR >records it is interested in, Consequently... > >1. The DDDS indicator (E2U) is required because the NAPTR record can > be overloaded for many purposes and NAPTRs must be distinguishable > between applications. > >2. The FUNCTION is required because a client application needs to be able > to distinguish between NAPTRs that share the same URI scheme or protocol. > > For example, assume the following two NAPTRs are associated with a > telephone number: > > NAPTR 0 0 "U" "E2U" "!^.*$!mailto:user@vmail.domain1!" . > NAPTR 0 0 "U" "E2U" "!^.*$!mailto:user@email.domain2!" . > > The first identifies an voice messaging system that supports and SMTP > interface, the second identifies a conventional electronic mail system. > Assume the client application wants to send a recorded voice message > to the voice messaging server. How does the application differentiate > between the two NAPTRs? The answer is simple, by service... > > NAPTR 0 0 "U" "E2U+vmail" "!^.*$!mailto:user@vmail.domain1!" . > NAPTR 0 0 "U" "E2U+email" "!^.*$!mailto:user@email.domain2!" . yes thank you ... from a Client User Agent perspective the first parse is against ALL enumservice fields for ALL NAPTR records to select which is the most appropriate at that point discard all other NAPTR records.. If 2 or more enumservice fields are identical then use the preference field to sort.... we we are on the same track >3. The PROTOCOL should not be required but deserves serious consideration. > Processing of the regular expression dominates the overall processing > time of the ENUM response. By including the protocol the application > can rapidly select all NAPTR records that are of interest. The > alternative is to LESS rapidly select interesing NAPTR records. > >I am having difficulty distinguishing between CATEGORY and SERVICE, i.e. >TALK and VOICE, feel redundant. As for SUBPROTOCOL, this is the purpose >of Session Description Protocol and is undoubtably over-kill. Finally, >ADDINFO is an extension mechanism, which violates Einstonian wisdom... > >I propose the following EBNF for the ENUM service field: > > enum-service : "E2U" ( function )+ > function : "+" service [ ":" protocol ] > service : "voice" | "video" | "email" | "vmail" | other > protocol : "smtp" | "sip" | "h323" | "mms" | other > other : EXCELLENT start ! transport or port as options seem reasonable .. ... what about reversing the order ... protocol > service > other ..... I'm asking what is the C/UA looking for first? >For those that don't read EBNF, the enum-service field starts with the >string "E2U" and is followed by one or more functions. Each function >starts with a "+" and consists of a service string and optional protocol >string that starts with a ":". Several examples are: > > "E2U+email" > "E2U+email:smtp" > "E2U+vmail:smtp" > "E2U+email+vmail" > "E2U+voice:h323" > "E2U+voice" But I also personally argue that SIP in and of itself is a service...but I'm not going to beat a dead horse here. >The service and protocol strings should be registered with IANA, while >other extensions should be ignored. should or could be ignored ??? Bob ...this is a most useful contribution to the discussion ... what is your thinking about the protocol field being mandatory and all others optional or are you thinking the service should be mandatory etc? There is a reason for this ... I'm sorry if I continue to harp on the issue but there are privacy considerations here that I continue to worry about. Exposing too much personal preference data _could_ create problems with various national governments that are properly looking into this issue and understand that the DNS is global and globally accessible. Without necessarily trying to restrict the clear preference by some to move in this direction ..how can the two requirements be balanced? Thanks again.... >Regards, > >Bob Walter >NetNumber, Inc. > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Jun 27 12:52:34 2002 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 MAA00932 for ; Thu, 27 Jun 2002 12:52:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25527 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 12:53: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 MAA25042; Thu, 27 Jun 2002 12:44: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 MAA25011 for ; Thu, 27 Jun 2002 12:44:02 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00310 for ; Thu, 27 Jun 2002 12:43:18 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5RGhTB00723; Thu, 27 Jun 2002 12:43:29 -0400 Message-Id: <5.1.0.14.2.20020627122623.04044710@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Jun 2002 12:49:52 -0400 To: Jim Reid , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] enumservices in new version of 2916bis In-Reply-To: <8929.1025194511@shell.nominum.com> References: 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 09:15 AM 6/27/2002 -0700, Jim Reid wrote: > >>>>> "Richard" == Richard Shockey writes: > > Richard> There is a reason for this ... I'm sorry if I continue to > Richard> harp on the issue but there are privacy considerations > Richard> here that I continue to worry about. Exposing too much > Richard> personal preference data _could_ create problems with > Richard> various national governments that are properly looking > Richard> into this issue and understand that the DNS is global and > Richard> globally accessible. > >If my limited understanding of EU data protection law is correct, >there won't be a problem provided the data subject -- ie the owner of >the phone number/domain name -- knows what's been entered for them in >the DNS and what that data gets used for. They get to determine how >little or how much they reveal about that number. And change that as >they see fit. Since ENUM will have to be opt-in within the EU because >of data protection/privacy law -- that pretty much means users will >get full control over their ENUM data anyway. AFAIK the EU has the >toughest rules on data protection/privacy. Do you know of anywhere >with even stricter laws? Well Ok ..... but I suppose what I'm suggesting is that its worth exploring the concept of _choice_ in how much granularity and preference data is actually exposed in the DNS. So to add to Bob Walters statement ... Id like to suggest some principals we need to guide ourselves by here. First order priorities is to get a grip on the real problem statement here which is ...What is the proper and reasonable syntax to describe the N squared options in the enumservice field? What are the guiding principals we should use in coming to rough consensus ...I suggest for a start A. Simplicity .. the solution for the enumservice field must be as simple as practically possible since it will have to be implemented by C/UA and adding complexity to the logic a NAPTR parser must use to determine a solution may or may not be "good thing". What is absolutely required here ...is it the protocol SIP H323 or it is the service voice..fax video IM etc. Of the two which is the most essential? What is the proper order? Can one be mandatory and the other optional ? B. Choice ... What is the minimum data necessary to successfully describe an enumservice or conversely the maximum. Can I have the option of saying [E2U+SIP] only but optionally [E2U+SIP:voice] [ E2U+SIP:video] yes you could write this [E2U+voice:SIP] [ E2U+voice:SIP] depending on your preference for ordering any other thoughts? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Jun 27 12:57:49 2002 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 MAA01227 for ; Thu, 27 Jun 2002 12:57:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25682 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 12:58: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 MAA25308; Thu, 27 Jun 2002 12:49: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 MAA25275 for ; Thu, 27 Jun 2002 12:49:35 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00669 for ; Thu, 27 Jun 2002 12:48:50 -0400 (EDT) Received: from xbe-lon-303.cisco.com (xbe-lon-303.cisco.com [64.103.98.22]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5RGlgVq021731; Thu, 27 Jun 2002 18:47:56 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 27 Jun 2002 17:47:30 +0100 Received: from [10.0.1.100] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 27 Jun 2002 18:47:30 +0200 Date: Thu, 27 Jun 2002 18:34:17 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: rwalter@netnumber.com, Stastny Richard , enum@ietf.org Subject: RE: [Enum] enumservices in new version of 2916bis Message-ID: <11867334.1025202857@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 27 Jun 2002 16:47:30.0523 (UTC) FILETIME=[53D40AB0:01C21DFA] 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 --On 2002-06-27 11.09 -0400 "Robert H. Walter" wrote: > I propose the following EBNF for the ENUM service field: > > enum-service : "E2U" ( function )+ > function : "+" service [ ":" protocol ] > service : "voice" | "video" | "email" | "vmail" | other > protocol : "smtp" | "sip" | "h323" | "mms" | other > other : > > For those that don't read EBNF, the enum-service field starts with the > string "E2U" and is followed by one or more functions. Each function > starts with a "+" and consists of a service string and optional protocol > string that starts with a ":". Several examples are: > > "E2U+email" > "E2U+email:smtp" > "E2U+vmail:smtp" > "E2U+email+vmail" > "E2U+voice:h323" > "E2U+voice" > > The service and protocol strings should be registered with IANA, while > other extensions should be ignored. I like this. I would like to rephrase the requirement, and that is that the _combination_ of service and protocol string needs to be registered with IANA, and registration is via the IETF RFC publication process. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Jun 27 13:09:00 2002 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 NAA01806 for ; Thu, 27 Jun 2002 13:09:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26551 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 13:09: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 NAA25958; Thu, 27 Jun 2002 13:00: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 NAA25928 for ; Thu, 27 Jun 2002 13:00:47 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01381 for ; Thu, 27 Jun 2002 13:00:03 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5RGx6uK004710; Thu, 27 Jun 2002 12:59:06 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5RGx5i0004705; Thu, 27 Jun 2002 12:59:05 -0400 (EDT) Date: Thu, 27 Jun 2002 12:59:04 -0400 From: Michael Mealling To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: rwalter@netnumber.com, Stastny Richard , enum@ietf.org Subject: Re: [Enum] enumservices in new version of 2916bis Message-ID: <20020627125904.K24592@bailey.dscga.com> Reply-To: Michael Mealling References: <11867334.1025202857@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <11867334.1025202857@localhost> User-Agent: Mutt/1.3.22.1i 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, Jun 27, 2002 at 06:34:17PM +0200, Patrik Fältström wrote: > --On 2002-06-27 11.09 -0400 "Robert H. Walter" > wrote: > > I propose the following EBNF for the ENUM service field: > > > > enum-service : "E2U" ( function )+ > > function : "+" service [ ":" protocol ] > > service : "voice" | "video" | "email" | "vmail" | other > > protocol : "smtp" | "sip" | "h323" | "mms" | other > > other : > > > > For those that don't read EBNF, the enum-service field starts with the > > string "E2U" and is followed by one or more functions. Each function > > starts with a "+" and consists of a service string and optional protocol > > string that starts with a ":". Several examples are: > > > > "E2U+email" > > "E2U+email:smtp" > > "E2U+vmail:smtp" > > "E2U+email+vmail" > > "E2U+voice:h323" > > "E2U+voice" > > > > The service and protocol strings should be registered with IANA, while > > other extensions should be ignored. > > I like this. > > I would like to rephrase the requirement, and that is that the > _combination_ of service and protocol string needs to be registered with > IANA, and registration is via the IETF RFC publication process. Yep! That sounds perfect to me! -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Jun 27 13:59:42 2002 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 NAA04955 for ; Thu, 27 Jun 2002 13:59:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00478 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 14:00:26 -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 NAA29618; Thu, 27 Jun 2002 13:51: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 NAA29589 for ; Thu, 27 Jun 2002 13:51:26 -0400 (EDT) Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net [38.202.36.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04399 for ; Thu, 27 Jun 2002 13:50:41 -0400 (EDT) Received: from RWALTER ([65.203.166.26]) by hvmta02-stg.us.psimail.psi.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020627175123.SCUJ1886.hvmta02-stg.us.psimail.psi.net@RWALTER>; Thu, 27 Jun 2002 13:51:23 -0400 Reply-To: From: "Robert H. Walter" To: "Richard Shockey" , Subject: RE: [Enum] enumservices in new version of 2916bis Date: Thu, 27 Jun 2002 13:51:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <5.1.0.14.2.20020627113632.043f3bc0@popd.ix.netcom.com> 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, > Well said .... that should be a guiding rule as we attempt to come to some > rough consensus ... Thanks, I wish I could take credit for the statement! > > EXCELLENT start ! transport or port as options seem reasonable .. ... > > what about reversing the order ... protocol > service > other ..... I'm > asking what is the C/UA looking for first? > > Bob ...this is a most useful contribution to the discussion ... what is > your thinking about the protocol field being mandatory and all others > optional or are you thinking the service should be mandatory etc? ENUM provides an excellent mechanism for discovering and locating communications services using a telephone number. The key word is here is services. Real-time voice, video-conferencing, voice messaging, electronic mail are all types of communications services that can be associated with a telephone number. IMHO, the ability to differentiate between communications services is core, hence the service should be mandatory. The protocol should be optional. It is possible to infer the protocol via the URI scheme, though this may be inefficient. The proposed approach is much like how a port is optional when used with a host in a http URL (e.g. http://www.domain.com is equivalent to http://www.domain.com:80). I suggest we follow this widely understood idiom and place the optional protocol string after the mandatory service string. Regards, Bob NetNumber, Inc. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 27 14:18:29 2002 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 OAA06281 for ; Thu, 27 Jun 2002 14:18:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02391 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 14:19: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 OAA01710; Thu, 27 Jun 2002 14:09: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 OAA01679 for ; Thu, 27 Jun 2002 14:09:53 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05702 for ; Thu, 27 Jun 2002 14:09:07 -0400 (EDT) Received: from [193.118.205.14] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090684; Thu, 27 Jun 2002 19:10:05 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <20020627125904.K24592@bailey.dscga.com> References: <11867334.1025202857@localhost> <20020627125904.K24592@bailey.dscga.com> Date: Thu, 27 Jun 2002 19:09:12 +0100 To: enum@ietf.org From: Lawrence Conroy Subject: Re: [Enum] enumservices in new version of 2916bis Cc: rwalter@netnumber.com, Michael , Patrik , Richard , Rich 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 OAA01680 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 12:59 pm -0400 27/6/02, Michael Mealling wrote: >On Thu, Jun 27, 2002 at 06:34:17PM +0200, Patrik Fältström wrote: >> --On 2002-06-27 11.09 -0400 "Robert H. Walter" >> wrote: >> > I propose the following EBNF for the ENUM service field: >> > >> > enum-service : "E2U" ( function )+ >> > function : "+" service [ ":" protocol ] >> > service : "voice" | "video" | "email" | "vmail" | other >> > protocol : "smtp" | "sip" | "h323" | "mms" | other >> > other : >> > >> > For those that don't read EBNF, the enum-service field starts with the >> > string "E2U" and is followed by one or more functions. Each function >> > starts with a "+" and consists of a service string and optional protocol >> > string that starts with a ":". Several examples are: >> > >> > "E2U+email" >> > "E2U+email:smtp" >> > "E2U+vmail:smtp" >> > "E2U+email+vmail" >> > "E2U+voice:h323" >> > "E2U+voice" >> > >> > The service and protocol strings should be registered with IANA, while >> > other extensions should be ignored. >> >> I like this. >> >> I would like to rephrase the requirement, and that is that the >> _combination_ of service and protocol string needs to be registered with >> IANA, and registration is via the IETF RFC publication process. > >Yep! That sounds perfect to me! > To which I reply: In the words of Mandy Rice-Davis, "Well, he would say that, wouldn't he". Conversely, I would say No, as described. * The naming of names I am confused (even within some of the posts) on function as opposed to service as opposed to category. I am also confused over protocol as opposed to sub-protocol as opposed to URI-scheme. For a start, what is the "vmail" protocol? This looks like a low level service to me. Similarly, "mms" is not a protocol, it's a service (Strictly, if you really want to look into the 3GPP documents, there *is* a protocol for a GSM mobile sending and receiving SMS or MMS, but I sure hope you don't mean this). Further, when did the service field get re-named? We appear to have the enum-service field now. Yet more changes to the documentation. Sigh... -------- * What's in a service/function/category? We now have "service" as the only option, on the grounds that category is redundant. Have folks checked with the end users? I'm not sure what the correct options should be - that's why we're developing trials ->right now<-. Once they're done we'll have some data on what the customers want. Until that time, I'm not willing to restrict this. Personally, I'd be surprised if end users were interested both in category AND in low level service (I'd be surprised if the first user interface they're provided with allows this anyway :). However, I can't dictate in what terms they think. -------- * There's more to this BNF than meets the eye Now, I *had* assumed that the URI-scheme was what people meant when they said protocol. Thus, for "smtp" read "mailto". However, the continued use of the term protocol makes me unsure. If you all DO mean protocol, then why? We have URI-scheme - either it's copied in the service field or it's just a regexp away. Thus, as written, I can't accept the BNF; there are already definitions in RFCs for each URI-scheme, and so these tokens SHOULD NOT be copied here. If you choose to use the protocols specified in the URI-scheme RFCs, then these should also be included only by reference. Following on from this, is not enough - the existing 2916bis defines a mechanism for specifying enumservices in RFCs; this MUST be nailed down rather than just using the BNF primitive. What does "other extensions MUST be ignored" mean? I also can't accept it as it's badly structured - there's ONE URI within a NAPTR. Its URI-scheme is associated with ONE protocol. There are a number of services for which the URI can be used, so the services part is (potentially) a multi-valued set. If the URI-scheme is to be duplicated within wht was called the services field, then it should be a discrete sub-field - there's no earthly point in duplicating it in more than one enumservice as it will be the same each time. (Implementation hat on here); The BNF makes parsing the field a pain in the parts - it's a game of hunt the URI-scheme copy. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 27 15:28:15 2002 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 PAA10847 for ; Thu, 27 Jun 2002 15:28:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15211 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 15:28: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 PAA14808; Thu, 27 Jun 2002 15:18: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 PAA14779 for ; Thu, 27 Jun 2002 15:18:48 -0400 (EDT) Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10388 for ; Thu, 27 Jun 2002 15:18:02 -0400 (EDT) content-class: urn:content-classes:message Subject: AW: [Enum] enumservices in new version of 2916bis Date: Thu, 27 Jun 2002 21:20:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-ID: <06CF906FE3998C4E944213062009F1620246F9@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Enum] enumservices in new version of 2916bis Thread-Index: AcIeBhOSPmxQjvTXR1WOeP+bhBN+QwABOh/f From: "Stastny Richard" To: "Lawrence Conroy" , Cc: , "Michael" , "Patrik" , "Rich" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id PAA14780 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 Hi folks, I have to agree with Lawrence that the EBNF is badly structured, because it confuses different levels of services. Once again: We have basically URI-schemes (and I also have to agree with Lawrence, we do not have protocols), and services, which may be defined with the svc parameter (e.g sms or mms are services, not protocols or URIs). To not confuse things to much, we should use other "names" for other things, e.g. categories. Since the URIscheme and the services are somewhere in the NAPTR anyway, they may be left out or be optional. This leaves ónly the categories like talk, msg, info, etc. One word to Robert: talk and voice are not redundant, because voice is a service, like video, but talk (or rtc - real time communication) is a category, which may include voice and video services. And it was selected on purpose to be different. And we should not forget, there is a hierachy, as can be seen in the related drafts: It is well defined which URIschemes are within which categories, and it is also well defined (with the URI definition), which services are possible within an URIscheme (either explicit or implicit) E.g msg > tel > sms So may proposal is still: "E2U+category" --- URIscheme;svc "E2U+category+URIscheme+services" --- URIscheme;svc where there are distinct "names" for category, service and URIscheme to keep things easy for the clients. regards Richard -----Ursprüngliche Nachricht----- Von: Lawrence Conroy [mailto:lwc@roke.co.uk] Gesendet: Do 27.06.2002 20:09 An: enum@ietf.org Cc: rwalter@netnumber.com; Michael; Patrik; Stastny Richard; Rich Betreff: Re: [Enum] enumservices in new version of 2916bis At 12:59 pm -0400 27/6/02, Michael Mealling wrote: >On Thu, Jun 27, 2002 at 06:34:17PM +0200, Patrik Fältström wrote: >> --On 2002-06-27 11.09 -0400 "Robert H. Walter" >> wrote: >> > I propose the following EBNF for the ENUM service field: >> > >> > enum-service : "E2U" ( function )+ >> > function : "+" service [ ":" protocol ] >> > service : "voice" | "video" | "email" | "vmail" | other >> > protocol : "smtp" | "sip" | "h323" | "mms" | other >> > other : >> > >> > For those that don't read EBNF, the enum-service field starts with the >> > string "E2U" and is followed by one or more functions. Each function >> > starts with a "+" and consists of a service string and optional protocol >> > string that starts with a ":". Several examples are: >> > >> > "E2U+email" >> > "E2U+email:smtp" >> > "E2U+vmail:smtp" >> > "E2U+email+vmail" >> > "E2U+voice:h323" >> > "E2U+voice" >> > >> > The service and protocol strings should be registered with IANA, while >> > other extensions should be ignored. >> >> I like this. >> >> I would like to rephrase the requirement, and that is that the >> _combination_ of service and protocol string needs to be registered with >> IANA, and registration is via the IETF RFC publication process. > >Yep! That sounds perfect to me! > To which I reply: In the words of Mandy Rice-Davis, "Well, he would say that, wouldn't he". Conversely, I would say No, as described. * The naming of names I am confused (even within some of the posts) on function as opposed to service as opposed to category. I am also confused over protocol as opposed to sub-protocol as opposed to URI-scheme. For a start, what is the "vmail" protocol? This looks like a low level service to me. Similarly, "mms" is not a protocol, it's a service (Strictly, if you really want to look into the 3GPP documents, there *is* a protocol for a GSM mobile sending and receiving SMS or MMS, but I sure hope you don't mean this). Further, when did the service field get re-named? We appear to have the enum-service field now. Yet more changes to the documentation. Sigh... -------- * What's in a service/function/category? We now have "service" as the only option, on the grounds that category is redundant. Have folks checked with the end users? I'm not sure what the correct options should be - that's why we're developing trials ->right now<-. Once they're done we'll have some data on what the customers want. Until that time, I'm not willing to restrict this. Personally, I'd be surprised if end users were interested both in category AND in low level service (I'd be surprised if the first user interface they're provided with allows this anyway :). However, I can't dictate in what terms they think. -------- * There's more to this BNF than meets the eye Now, I *had* assumed that the URI-scheme was what people meant when they said protocol. Thus, for "smtp" read "mailto". However, the continued use of the term protocol makes me unsure. If you all DO mean protocol, then why? We have URI-scheme - either it's copied in the service field or it's just a regexp away. Thus, as written, I can't accept the BNF; there are already definitions in RFCs for each URI-scheme, and so these tokens SHOULD NOT be copied here. If you choose to use the protocols specified in the URI-scheme RFCs, then these should also be included only by reference. Following on from this, is not enough - the existing 2916bis defines a mechanism for specifying enumservices in RFCs; this MUST be nailed down rather than just using the BNF primitive. What does "other extensions MUST be ignored" mean? I also can't accept it as it's badly structured - there's ONE URI within a NAPTR. Its URI-scheme is associated with ONE protocol. There are a number of services for which the URI can be used, so the services part is (potentially) a multi-valued set. If the URI-scheme is to be duplicated within wht was called the services field, then it should be a discrete sub-field - there's no earthly point in duplicating it in more than one enumservice as it will be the same each time. (Implementation hat on here); The BNF makes parsing the field a pain in the parts - it's a game of hunt the URI-scheme copy. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 27 15:56:14 2002 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 PAA12661 for ; Thu, 27 Jun 2002 15:56:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17447 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 15:56: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 PAA16685; Thu, 27 Jun 2002 15:47: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 OAA04918 for ; Thu, 27 Jun 2002 14:45:50 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08258 for ; Thu, 27 Jun 2002 14:45:04 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g5RIjGt23323; Thu, 27 Jun 2002 13:45:16 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 13:45:11 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA810A02BC@STNTEXCH2> From: "Peterson, Jon" To: "Shockey, Richard" , rwalter@netnumber.com, enum@ietf.org Subject: RE: [Enum] enumservices in new version of 2916bis Date: Thu, 27 Jun 2002 13:45:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 I would like to register some (no doubt predictable) support for Mr. Shockey's suggestion that protocol come before service in the enumservice field, and that ideally protocol be mandatory and other fields optional. As we discussed in Minneapolis, and as has been raised in this thread already, many of the SIP people feel that forcing a characterization of one or more services (such as 'voice' or 'rtp' something) in ENUM actually materially impedes the functioning of a SIP address-of-record URI, and limits the utility of ENUM for SIP. If a 'service' subfield in the enumservice field is to be mandatory, we SIP folk would appreciate the specification of a 'service' identifier that signifies that the protocol in question has its own capability negotiation - such capability negotiation is, after all, the whole point of the SDP offer-answer model in SIP. I personally would like to see an identifier to this effect (with 'negotiate' something as the token) in the revision of rfc2916bis, so that we could cite in the SIPPING ENUM draft. Jon Peterson NeuStar, inc. > -----Original Message----- > From: Richard Shockey [mailto:rich.shockey@NeuStar.com] > Sent: Thursday, June 27, 2002 8:57 AM > To: rwalter@netnumber.com; enum@ietf.org > Subject: RE: [Enum] enumservices in new version of 2916bis > > > At 11:09 AM 6/27/2002 -0400, Robert H. Walter wrote: > > > E2U+function+protocol+...? > > > >So the extreme boundaries of the problem have been identified... > > > >minimum: E2U > >maximum: E2U+category+service+URIscheme+subprotocol+addinfo > > > >Einstein once said: > > > > "Everything should be made as simple as possible, but not simpler" > > Well said .... that should be a guiding rule as we attempt to > come to some > rough consensus ... > > > > >The answer lies somewhere in between... The service field should > >be used to enable a client application to rapidly select the NAPTR > >records it is interested in, Consequently... > > > >1. The DDDS indicator (E2U) is required because the NAPTR record can > > be overloaded for many purposes and NAPTRs must be > distinguishable > > between applications. > > > >2. The FUNCTION is required because a client application > needs to be able > > to distinguish between NAPTRs that share the same URI > scheme or protocol. > > > > For example, assume the following two NAPTRs are > associated with a > > telephone number: > > > > NAPTR 0 0 "U" "E2U" "!^.*$!mailto:user@vmail.domain1!" . > > NAPTR 0 0 "U" "E2U" "!^.*$!mailto:user@email.domain2!" . > > > > The first identifies an voice messaging system that > supports and SMTP > > interface, the second identifies a conventional > electronic mail system. > > Assume the client application wants to send a recorded > voice message > > to the voice messaging server. How does the application > differentiate > > between the two NAPTRs? The answer is simple, by service... > > > > NAPTR 0 0 "U" "E2U+vmail" "!^.*$!mailto:user@vmail.domain1!" . > > NAPTR 0 0 "U" "E2U+email" "!^.*$!mailto:user@email.domain2!" . > > yes thank you ... from a Client User Agent perspective the > first parse is > against ALL enumservice fields for ALL NAPTR records to > select which is the > most appropriate at that point discard all other NAPTR > records.. If 2 or > more enumservice fields are identical then use the preference > field to > sort.... we we are on the same track > > > >3. The PROTOCOL should not be required but deserves serious > consideration. > > Processing of the regular expression dominates the > overall processing > > time of the ENUM response. By including the protocol > the application > > can rapidly select all NAPTR records that are of interest. The > > alternative is to LESS rapidly select interesing NAPTR records. > > > >I am having difficulty distinguishing between CATEGORY and > SERVICE, i.e. > >TALK and VOICE, feel redundant. As for SUBPROTOCOL, this is > the purpose > >of Session Description Protocol and is undoubtably > over-kill. Finally, > >ADDINFO is an extension mechanism, which violates Einstonian > wisdom... > > > >I propose the following EBNF for the ENUM service field: > > > > enum-service : "E2U" ( function )+ > > function : "+" service [ ":" protocol ] > > service : "voice" | "video" | "email" | "vmail" | other > > protocol : "smtp" | "sip" | "h323" | "mms" | other > > other : > > EXCELLENT start ! transport or port as options seem > reasonable .. ... > > what about reversing the order ... protocol > service > other > ..... I'm > asking what is the C/UA looking for first? > > > >For those that don't read EBNF, the enum-service field > starts with the > >string "E2U" and is followed by one or more functions. Each function > >starts with a "+" and consists of a service string and > optional protocol > >string that starts with a ":". Several examples are: > > > > "E2U+email" > > "E2U+email:smtp" > > "E2U+vmail:smtp" > > "E2U+email+vmail" > > "E2U+voice:h323" > > "E2U+voice" > > But I also personally argue that SIP in and of itself is a > service...but > I'm not going to beat a dead horse here. > > > >The service and protocol strings should be registered with > IANA, while > >other extensions should be ignored. > > should or could be ignored ??? > > > Bob ...this is a most useful contribution to the discussion > ... what is > your thinking about the protocol field being mandatory and all others > optional or are you thinking the service should be mandatory etc? > > There is a reason for this ... I'm sorry if I continue to > harp on the issue > but there are privacy considerations here that I continue to worry > about. Exposing too much personal preference data _could_ > create problems > with various national governments that are properly looking > into this issue > and understand that the DNS is global and globally accessible. > > Without necessarily trying to restrict the clear preference > by some to move > in this direction ..how can the two requirements be balanced? > > Thanks again.... > > > > >Regards, > > > >Bob Walter > >NetNumber, Inc. > > > > > >_______________________________________________ > >enum mailing list > >enum@ietf.org > >https://www1.ietf.org/mailman/listinfo/enum > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 > 1120 Vermont Ave NW Suite 400 Washington DC 20005 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 27 16:02:10 2002 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 QAA13004 for ; Thu, 27 Jun 2002 16:02:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA18398 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 16:02: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 PAA17171; Thu, 27 Jun 2002 15:53:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17082 for ; Thu, 27 Jun 2002 15:53:52 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12411 for ; Thu, 27 Jun 2002 15:53:06 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5RJrEB04382; Thu, 27 Jun 2002 15:53:14 -0400 Message-Id: <5.1.0.14.2.20020627154111.0241d7d8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Jun 2002 15:59:36 -0400 To: "Stastny Richard" , "Lawrence Conroy" , From: Richard Shockey Subject: Re: AW: [Enum] enumservices in new version of 2916bis Cc: , "Michael" , "Patrik" In-Reply-To: <06CF906FE3998C4E944213062009F1620246F9@oefeg-s02.oefeg.loc > 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 PAA17083 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 09:20 PM 6/27/2002 +0200, Stastny Richard wrote: >Hi folks, >I have to agree with Lawrence that the EBNF is badly structured, because >it confuses different levels of services. > >Once again: >We have basically URI-schemes (and I also have to agree with Lawrence, we >do not have protocols), and services, which may be defined with the svc >parameter (e.g sms or mms are services, not protocols or URIs). To not >confuse things to much, we should use other "names" for other things, e.g. >categories. There seems to be a serious disconnect here between definition of terms... I dont see a real difference between what you describe as a 'category' and what Bob and others describe as a "service" these are things like voice, video, text, vmail, now I see some confusion between the concepts of protocol and URIscheme... this looks like to me SIP, mailto, ldap, h323, tel etc Then is your concept of the services ...... The EBNF concept is the right one its just how is it structured. > >Since the URIscheme and the services are somewhere in the NAPTR anyway, >they may be left out or be optional. No you cant do that since the first order processing of all the NAPTR records is on the enumservice field itself and you clearly see some of us want the URIscheme (aka protocol) there to be processed, unless you will permit the SIP community to call SIP a "category" in and of itself. so in your scheme it would looks like E2U+SIP+SIP+N for negotiate.. which strikes me as a violation of the simplicity principal here What I continue to suggest is that there is a body of evidence ( the SIP community) that _may not_ want to expose things like categories in the enumservice field and I think that can be accomodiated if the protocol/URI portion is A. mandatory B first we seem to differ on which field is more criticial. > >This leaves ónly the categories like talk, msg, info, etc. > >One word to Robert: talk and voice are not redundant, because voice is a >service, like video, but talk (or rtc - real time communication) is a >category, which may include voice and video services. And it was selected >on purpose to be different. > >And we should not forget, there is a hierachy, as can be seen in the >related drafts: > >It is well defined which URIschemes are within which categories, and it is >also well defined (with the URI definition), which services are possible >within an URIscheme (either explicit or implicit) > >E.g msg > tel > sms > >So may proposal is still: >"E2U+category" --- URIscheme;svc >"E2U+category+URIscheme+services" --- URIscheme;svc >where there are distinct "names" for category, service and URIscheme to >keep things easy for the clients. Its just prefer ..for well known reasons that the URIscheme (aka protocol) is ordered first so that concepts like catagory and services could be made optional. > >regards >Richard > > > -----Ursprüngliche Nachricht----- > Von: Lawrence Conroy [mailto:lwc@roke.co.uk] > Gesendet: Do 27.06.2002 20:09 > An: enum@ietf.org > Cc: rwalter@netnumber.com; Michael; Patrik; Stastny Richard; Rich > Betreff: Re: [Enum] enumservices in new version of 2916bis > > > > At 12:59 pm -0400 27/6/02, Michael Mealling wrote: > >On Thu, Jun 27, 2002 at 06:34:17PM +0200, Patrik Fältström wrote: > >> --On 2002-06-27 11.09 -0400 "Robert H. Walter" > > >> wrote: > >> > I propose the following EBNF for the ENUM service field: > >> > > >> > enum-service : "E2U" ( function )+ > >> > function : "+" service [ ":" protocol ] > >> > service : "voice" | "video" | "email" | "vmail" | other > >> > protocol : "smtp" | "sip" | "h323" | "mms" | other > >> > other : > >> > > >> > For those that don't read EBNF, the enum-service field > starts with the > >> > string "E2U" and is followed by one or more > functions. Each function > >> > starts with a "+" and consists of a service string and > optional protocol > >> > string that starts with a ":". Several examples are: > >> > > >> > "E2U+email" > >> > "E2U+email:smtp" > >> > "E2U+vmail:smtp" > >> > "E2U+email+vmail" > >> > "E2U+voice:h323" > >> > "E2U+voice" > >> > > >> > The service and protocol strings should be registered with > IANA, while > >> > other extensions should be ignored. > >> > >> I like this. > >> > >> I would like to rephrase the requirement, and that is that the > >> _combination_ of service and protocol string needs to be > registered with > >> IANA, and registration is via the IETF RFC publication process. > > > >Yep! That sounds perfect to me! > > > To which I reply: > In the words of Mandy Rice-Davis, "Well, he would say that, > wouldn't he". > > Conversely, I would say No, as described. > > * The naming of names > > I am confused (even within some of the posts) on function as > opposed to service > as opposed to category. > > I am also confused over protocol as opposed to sub-protocol as > opposed to URI-scheme. > > For a start, what is the "vmail" protocol? This looks like a low > level service to me. > > Similarly, "mms" is not a protocol, it's a service (Strictly, if you > really want to > look into the 3GPP documents, there *is* a protocol for a GSM mobile > sending and > receiving SMS or MMS, but I sure hope you don't mean this). > > Further, when did the service field get re-named? We appear to have > the enum-service > field now. Yet more changes to the documentation. Sigh... > > -------- > > * What's in a service/function/category? > > We now have "service" as the only option, on the grounds that > category is redundant. > > Have folks checked with the end users? I'm not sure what the correct > options should be > - that's why we're developing trials ->right now<-. Once they're done > we'll have some > data on what the customers want. Until that time, I'm not willing to > restrict this. > > Personally, I'd be surprised if end users were interested both in > category AND in > low level service (I'd be surprised if the first user interface > they're provided > with allows this anyway :). However, I can't dictate in what > terms they think. > > -------- > * There's more to this BNF than meets the eye > > Now, I *had* assumed that the URI-scheme was what people meant when > they said protocol. > Thus, for "smtp" read "mailto". > > However, the continued use of the term protocol makes me unsure. If > you all DO mean > protocol, then why? We have URI-scheme - either it's copied in the > service field or > it's just a regexp away. > > Thus, as written, I can't accept the BNF; there are already > definitions in RFCs > for each URI-scheme, and so these tokens SHOULD NOT be copied here. > If you choose > to use the protocols specified in the URI-scheme RFCs, then these > should also > be included only by reference. > > Following on from this, is not enough - the existing > 2916bis defines > a mechanism for specifying enumservices in RFCs; this MUST be nailed > down rather > than just using the BNF primitive. > > What does "other extensions MUST be ignored" mean? > > I also can't accept it as it's badly structured - there's ONE URI > within a NAPTR. > Its URI-scheme is associated with ONE protocol. There are a number of > services for > which the URI can be used, so the services part is (potentially) a > multi-valued set. > If the URI-scheme is to be duplicated within wht was called the > services field, > then it should be a discrete sub-field - there's no earthly point in > duplicating > it in more than one enumservice as it will be the same each time. > > (Implementation hat on here); The BNF makes parsing the field a pain > in the parts > - it's a game of hunt the URI-scheme copy. > > all the best, > Lawrence > -- > lwc@roke.co.uk: +44 1794 833666::: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 27 16:37:58 2002 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 QAA14587 for ; Thu, 27 Jun 2002 16:37:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21059 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 16:38: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 QAA20004; Thu, 27 Jun 2002 16:29: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 QAA19973 for ; Thu, 27 Jun 2002 16:29:43 -0400 (EDT) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14233 for ; Thu, 27 Jun 2002 16:28:57 -0400 (EDT) Received: from RWALTER ([65.203.166.26]) by hvmta01-stg.us.psimail.psi.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020627202932.DWLB18522.hvmta01-stg.us.psimail.psi.net@RWALTER>; Thu, 27 Jun 2002 16:29:32 -0400 Reply-To: From: "Robert H. Walter" To: =?us-ascii?Q?Patrik_Faltstrom?= , Subject: RE: [Enum] enumservices in new version of 2916bis Date: Thu, 27 Jun 2002 16:29:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <11867334.1025202857@localhost> 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 > I would like to rephrase the requirement, and that is that the > _combination_ of service and protocol string needs to be registered with > IANA, and registration is via the IETF RFC publication process. Much better... Bob Walter NetNumber, Inc. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 27 16:38:09 2002 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 QAA14603 for ; Thu, 27 Jun 2002 16:38:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21071 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 16:38: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 QAA19845; Thu, 27 Jun 2002 16:28: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 QAA19815 for ; Thu, 27 Jun 2002 16:28:00 -0400 (EDT) Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net [38.202.36.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14170 for ; Thu, 27 Jun 2002 16:27:14 -0400 (EDT) Received: from RWALTER ([65.203.166.26]) by hvmta02-stg.us.psimail.psi.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020627202751.TJXV1886.hvmta02-stg.us.psimail.psi.net@RWALTER>; Thu, 27 Jun 2002 16:27:51 -0400 Reply-To: From: "Robert H. Walter" To: "Lawrence Conroy" , Subject: RE: [Enum] enumservices in new version of 2916bis Date: Thu, 27 Jun 2002 16:27:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: 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 Hello Mr. Conroy... > For a start, what is the "vmail" protocol? This looks like a low > level service to me. The mnemonic "vmail" represents a voice-mail or voice-messaging service, not a protocol. > Similarly, "mms" is not a protocol, it's a service You are correct, it is a service not a protocol. The updated EBNF is: enum-service : "E2U" ( function )+ function : "+" service [ ":" protocol ] service : "voice" | "video" | "email" | "vmail" | other protocol : "smtp" | "sip" | "h323" | other other : and if you don't like the "function" production... enum-service : "E2U" ( "+" service [ ":" protocol ] )+ service : "voice" | "video" | "email" | "vmail" | other protocol : "smtp" | "sip" | "h323" | other other : > What does "other extensions MUST be ignored" mean? Actually I wrote "... other extensions should be ignored". As with many protocols, it is often desirable to provide a mechanism for supporting parameter extensions without breaking the parsing engine. It is typically recommended that unrecoginized extensions be successfully parsed, but simply ignored by the application/UA. If you don't want to allow support for a service/protocol extension mechnaism the EBNF gets even simpler... enum-service : "E2U" ( "+" service [ ":" protocol ] )+ service : "voice" | "video" | "email" | "vmail" protocol : "smtp" | "sip" | "h323" > (Implementation hat on here); The BNF makes parsing the field a pain > in the parts Hmmm... That's a different perspective. Regards, Bob Walter NetNumber, Inc. > -----Original Message----- > From: Lawrence Conroy [mailto:lwc@roke.co.uk] > Sent: Thursday, June 27, 2002 2:09 PM > To: enum@ietf.org > Cc: rwalter@netnumber.com; Michael; Patrik; Richard; Rich > Subject: Re: [Enum] enumservices in new version of 2916bis > > > At 12:59 pm -0400 27/6/02, Michael Mealling wrote: > >On Thu, Jun 27, 2002 at 06:34:17PM +0200, Patrik Fältström wrote: > >> --On 2002-06-27 11.09 -0400 "Robert H. Walter" > >> wrote: > >> > I propose the following EBNF for the ENUM service field: > >> > > >> > enum-service : "E2U" ( function )+ > >> > function : "+" service [ ":" protocol ] > >> > service : "voice" | "video" | "email" | "vmail" | other > >> > protocol : "smtp" | "sip" | "h323" | "mms" | other > >> > other : > >> > > >> > For those that don't read EBNF, the enum-service field starts with the > >> > string "E2U" and is followed by one or more functions. Each function > >> > starts with a "+" and consists of a service string and optional protocol > >> > string that starts with a ":". Several examples are: > >> > > >> > "E2U+email" > >> > "E2U+email:smtp" > >> > "E2U+vmail:smtp" > >> > "E2U+email+vmail" > >> > "E2U+voice:h323" > >> > "E2U+voice" > >> > > >> > The service and protocol strings should be registered with IANA, while > >> > other extensions should be ignored. > >> > >> I like this. > >> > >> I would like to rephrase the requirement, and that is that the > >> _combination_ of service and protocol string needs to be registered with > >> IANA, and registration is via the IETF RFC publication process. > > > >Yep! That sounds perfect to me! > > > To which I reply: > In the words of Mandy Rice-Davis, "Well, he would say that, wouldn't he". > > Conversely, I would say No, as described. > > * The naming of names > > I am confused (even within some of the posts) on function as opposed to service > as opposed to category. > > I am also confused over protocol as opposed to sub-protocol as > opposed to URI-scheme. > (Strictly, if you > really want to > look into the 3GPP documents, there *is* a protocol for a GSM mobile > sending and > receiving SMS or MMS, but I sure hope you don't mean this). > > Further, when did the service field get re-named? We appear to have > the enum-service > field now. Yet more changes to the documentation. Sigh... > > -------- > > * What's in a service/function/category? > > We now have "service" as the only option, on the grounds that > category is redundant. > > Have folks checked with the end users? I'm not sure what the correct > options should be > - that's why we're developing trials ->right now<-. Once they're done > we'll have some > data on what the customers want. Until that time, I'm not willing to > restrict this. > > Personally, I'd be surprised if end users were interested both in > category AND in > low level service (I'd be surprised if the first user interface > they're provided > with allows this anyway :). However, I can't dictate in what terms they think. > > -------- > * There's more to this BNF than meets the eye > > Now, I *had* assumed that the URI-scheme was what people meant when > they said protocol. > Thus, for "smtp" read "mailto". > > However, the continued use of the term protocol makes me unsure. If > you all DO mean > protocol, then why? We have URI-scheme - either it's copied in the > service field or > it's just a regexp away. > > Thus, as written, I can't accept the BNF; there are already definitions in RFCs > for each URI-scheme, and so these tokens SHOULD NOT be copied here. > If you choose > to use the protocols specified in the URI-scheme RFCs, then these should also > be included only by reference. > > Following on from this, is not enough - the existing 2916bis defines > a mechanism for specifying enumservices in RFCs; this MUST be nailed > down rather > than just using the BNF primitive. > > What does "other extensions MUST be ignored" mean? > > I also can't accept it as it's badly structured - there's ONE URI > within a NAPTR. > Its URI-scheme is associated with ONE protocol. There are a number of > services for > which the URI can be used, so the services part is (potentially) a > multi-valued set. > If the URI-scheme is to be duplicated within wht was called the services field, > then it should be a discrete sub-field - there's no earthly point in > duplicating > it in more than one enumservice as it will be the same each time. > > (Implementation hat on here); The BNF makes parsing the field a pain > in the parts > - it's a game of hunt the URI-scheme copy. > > all the best, > Lawrence > -- > lwc@roke.co.uk: +44 1794 833666::: > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 27 16:39:15 2002 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 QAA14678 for ; Thu, 27 Jun 2002 16:39:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21309 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 16:40:01 -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 QAA20466; Thu, 27 Jun 2002 16:31: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 QAA20428 for ; Thu, 27 Jun 2002 16:31:03 -0400 (EDT) Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14322 for ; Thu, 27 Jun 2002 16:30:17 -0400 (EDT) content-class: urn:content-classes:message Subject: AW: [Enum] enumservices in new version of 2916bis MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Thu, 27 Jun 2002 22:32:45 +0200 Message-ID: <06CF906FE3998C4E944213062009F1620246FA@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Enum] enumservices in new version of 2916bis Thread-Index: AcIeFWvTr64402GERVKUr1wD4LV1QwAATHjL From: "Stastny Richard" To: "Peterson, Jon" , "Shockey, Richard" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id QAA20435 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 To the .biz people;-) I see the point of your argument, in direction sip and also in direction privacy. I also talked to a lot of people recently and there are really two groups: Group A does not mind to put as much information in ENUM, and Group B would like to have only one NAPTR with a "srs", eventually even with a meaningless URI (and this need not only be sip., it may also be h323. or later UCI.), to be able to negotiate and filter. This is BTW also one issue we want to find out with trials, what people prefer, but as I said, there are two groups and we have to serve both. Of course, there is also group C, which tell me that there would never think of giving any information in ENUM, but there are not causing any problems with the enumservices anyway;-) Rich states: >Its just prefer ..for well known reasons that the URIscheme (aka protocol) >is ordered first so that concepts like catagory and services could be made >optional. The order of the "tokens" is not so important, if we keep the "names distinct, but so I have no problem to follow your suggestion: "E2U+URIscheme(mandatory)+category(optional)+service(optional)" It is up to the ENUM End User entering the information in ENUM if he gives category and/or service information. The trials may show what the users prefer, but the clients can be designed to work with all options. Jons request could the be fullfilled either with "E2U+sip", where negotiation is the default, or "E2U+sip+srs", where srs is indicating the "negotiate". regards Richard -----Ursprüngliche Nachricht----- Von: Peterson, Jon [mailto:jon.peterson@neustar.biz] Gesendet: Do 27.06.2002 20:45 An: Shockey, Richard; rwalter@netnumber.com; enum@ietf.org Cc: Betreff: RE: [Enum] enumservices in new version of 2916bis I would like to register some (no doubt predictable) support for Mr. Shockey's suggestion that protocol come before service in the enumservice field, and that ideally protocol be mandatory and other fields optional. As we discussed in Minneapolis, and as has been raised in this thread already, many of the SIP people feel that forcing a characterization of one or more services (such as 'voice' or 'rtp' something) in ENUM actually materially impedes the functioning of a SIP address-of-record URI, and limits the utility of ENUM for SIP. If a 'service' subfield in the enumservice field is to be mandatory, we SIP folk would appreciate the specification of a 'service' identifier that signifies that the protocol in question has its own capability negotiation - such capability negotiation is, after all, the whole point of the SDP offer-answer model in SIP. I personally would like to see an identifier to this effect (with 'negotiate' something as the token) in the revision of rfc2916bis, so that we could cite in the SIPPING ENUM draft. Jon Peterson NeuStar, inc. > -----Original Message----- > From: Richard Shockey [mailto:rich.shockey@NeuStar.com] > Sent: Thursday, June 27, 2002 8:57 AM > To: rwalter@netnumber.com; enum@ietf.org > Subject: RE: [Enum] enumservices in new version of 2916bis > > > At 11:09 AM 6/27/2002 -0400, Robert H. Walter wrote: > > > E2U+function+protocol+...? > > > >So the extreme boundaries of the problem have been identified... > > > >minimum: E2U > >maximum: E2U+category+service+URIscheme+subprotocol+addinfo > > > >Einstein once said: > > > > "Everything should be made as simple as possible, but not simpler" > > Well said .... that should be a guiding rule as we attempt to > come to some > rough consensus ... > > > > >The answer lies somewhere in between... The service field should > >be used to enable a client application to rapidly select the NAPTR > >records it is interested in, Consequently... > > > >1. The DDDS indicator (E2U) is required because the NAPTR record can > > be overloaded for many purposes and NAPTRs must be > distinguishable > > between applications. > > > >2. The FUNCTION is required because a client application > needs to be able > > to distinguish between NAPTRs that share the same URI > scheme or protocol. > > > > For example, assume the following two NAPTRs are > associated with a > > telephone number: > > > > NAPTR 0 0 "U" "E2U" "!^.*$!mailto:user@vmail.domain1!" . > > NAPTR 0 0 "U" "E2U" "!^.*$!mailto:user@email.domain2!" . > > > > The first identifies an voice messaging system that > supports and SMTP > > interface, the second identifies a conventional > electronic mail system. > > Assume the client application wants to send a recorded > voice message > > to the voice messaging server. How does the application > differentiate > > between the two NAPTRs? The answer is simple, by service... > > > > NAPTR 0 0 "U" "E2U+vmail" "!^.*$!mailto:user@vmail.domain1!" . > > NAPTR 0 0 "U" "E2U+email" "!^.*$!mailto:user@email.domain2!" . > > yes thank you ... from a Client User Agent perspective the > first parse is > against ALL enumservice fields for ALL NAPTR records to > select which is the > most appropriate at that point discard all other NAPTR > records.. If 2 or > more enumservice fields are identical then use the preference > field to > sort.... we we are on the same track > > > >3. The PROTOCOL should not be required but deserves serious > consideration. > > Processing of the regular expression dominates the > overall processing > > time of the ENUM response. By including the protocol > the application > > can rapidly select all NAPTR records that are of interest. The > > alternative is to LESS rapidly select interesing NAPTR records. > > > >I am having difficulty distinguishing between CATEGORY and > SERVICE, i.e. > >TALK and VOICE, feel redundant. As for SUBPROTOCOL, this is > the purpose > >of Session Description Protocol and is undoubtably > over-kill. Finally, > >ADDINFO is an extension mechanism, which violates Einstonian > wisdom... > > > >I propose the following EBNF for the ENUM service field: > > > > enum-service : "E2U" ( function )+ > > function : "+" service [ ":" protocol ] > > service : "voice" | "video" | "email" | "vmail" | other > > protocol : "smtp" | "sip" | "h323" | "mms" | other > > other : > > EXCELLENT start ! transport or port as options seem > reasonable .. ... > > what about reversing the order ... protocol > service > other > ..... I'm > asking what is the C/UA looking for first? > > > >For those that don't read EBNF, the enum-service field > starts with the > >string "E2U" and is followed by one or more functions. Each function > >starts with a "+" and consists of a service string and > optional protocol > >string that starts with a ":". Several examples are: > > > > "E2U+email" > > "E2U+email:smtp" > > "E2U+vmail:smtp" > > "E2U+email+vmail" > > "E2U+voice:h323" > > "E2U+voice" > > But I also personally argue that SIP in and of itself is a > service...but > I'm not going to beat a dead horse here. > > > >The service and protocol strings should be registered with > IANA, while > >other extensions should be ignored. > > should or could be ignored ??? > > > Bob ...this is a most useful contribution to the discussion > ... what is > your thinking about the protocol field being mandatory and all others > optional or are you thinking the service should be mandatory etc? > > There is a reason for this ... I'm sorry if I continue to > harp on the issue > but there are privacy considerations here that I continue to worry > about. Exposing too much personal preference data _could_ > create problems > with various national governments that are properly looking > into this issue > and understand that the DNS is global and globally accessible. > > Without necessarily trying to restrict the clear preference > by some to move > in this direction ..how can the two requirements be balanced? > > Thanks again.... > > > > >Regards, > > > >Bob Walter > >NetNumber, Inc. > > > > > >_______________________________________________ > >enum mailing list > >enum@ietf.org > >https://www1.ietf.org/mailman/listinfo/enum > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 > 1120 Vermont Ave NW Suite 400 Washington DC 20005 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Jun 27 22:49:09 2002 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 WAA27882 for ; Thu, 27 Jun 2002 22:49:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA11511 for enum-archive@odin.ietf.org; Thu, 27 Jun 2002 22:49:54 -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 WAA11173; Thu, 27 Jun 2002 22:40:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11144 for ; Thu, 27 Jun 2002 22:40:44 -0400 (EDT) Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27633 for ; Thu, 27 Jun 2002 22:39:58 -0400 (EDT) Received: from user-2ivek03.dialup.mindspring.com ([165.247.80.3] helo=dick.ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17NlgH-0007B8-00; Thu, 27 Jun 2002 22:40:18 -0400 Message-Id: <5.1.0.14.2.20020627223111.01f37ec0@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Jun 2002 22:42:23 -0400 To: "Stastny Richard" , "Peterson, Jon" , , From: Richard Shockey Subject: Re: AW: [Enum] enumservices in new version of 2916bis In-Reply-To: <06CF906FE3998C4E944213062009F1620246FA@oefeg-s02.oefeg.loc > 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 WAA11145 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 10:32 PM 6/27/2002 +0200, Stastny Richard wrote: >To the .biz people;-) and .us too ! > >I see the point of your argument, in direction sip and also in direction >privacy. I also talked to a lot of people recently and there are really >two groups: > >Group A does not mind to put as much information in ENUM, and >Group B would like to have only one NAPTR with a "srs", eventually even >with a meaningless URI (and this need not only be sip., it may also be >h323. or later UCI.), to be able to negotiate and filter. > >This is BTW also one issue we want to find out with trials, what people >prefer, but as I said, there are two groups and we have to serve both. Of >course, there is also group C, which tell me that there would never think >of giving any information in ENUM, but there are not causing any problems >with the enumservices anyway;-) > >Rich states: > >Its just prefer ..for well known reasons that the URIscheme (aka protocol) > >is ordered first so that concepts like catagory and services could be made > >optional. > >The order of the "tokens" is not so important, if we keep the "names >distinct, but so I have no problem to follow your suggestion: > >"E2U+URIscheme(mandatory)+category(optional)+service(optional)" Thank you very much ...this is substantial movement to rough consensus ... now I think its reasonable to set the definition of terms and URI vs protocol catagory vs service service vs other and revisit the list of options and consider a minimal subset suitable for testing. > >It is up to the ENUM End User entering the information in ENUM if he gives >category and/or service information. The trials may show what the users >prefer, but the clients can be designed to work with all options. I think this is precisely where we want to be ... end user choice is a "good thing" tm. Jons request could the be fullfilled either with "E2U+sip", where negotiation is the default, or "E2U+sip+srs", or in the Walter convention ..."E2U+sip:srs" ?? IMHO there is much to recommend in his approach.... Rudolf? Larry? are we close here? >where srs is indicating the "negotiate". > >regards >Richard Bob ..what do you think? Patrik ...Mike ... thoughts? This will help with agenda planning immensely.... > > > -----Ursprüngliche Nachricht----- > Von: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Gesendet: Do 27.06.2002 20:45 > An: Shockey, Richard; rwalter@netnumber.com; enum@ietf.org > Cc: > Betreff: RE: [Enum] enumservices in new version of 2916bis > > > > I would like to register some (no doubt predictable) support for Mr. > Shockey's suggestion that protocol come before service in the > enumservice > field, and that ideally protocol be mandatory and other fields > optional. > > As we discussed in Minneapolis, and as has been raised in this thread > already, many of the SIP people feel that forcing a > characterization of one > or more services (such as 'voice' or 'rtp' something) in ENUM > actually > materially impedes the functioning of a SIP address-of-record > URI, and > limits the utility of ENUM for SIP. If a 'service' subfield in the > enumservice field is to be mandatory, we SIP folk would > appreciate the > specification of a 'service' identifier that signifies that the > protocol in > question has its own capability negotiation - such capability > negotiation > is, after all, the whole point of the SDP offer-answer model in > SIP. I > personally would like to see an identifier to this effect (with > 'negotiate' > something as the token) in the revision of rfc2916bis, so that we > could cite > in the SIPPING ENUM draft. > > Jon Peterson > NeuStar, inc. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 05:34:27 2002 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 FAA15760 for ; Fri, 28 Jun 2002 05:34:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA08637 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 05:35: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 FAA07614; Fri, 28 Jun 2002 05:26: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 FAA07588 for ; Fri, 28 Jun 2002 05:26:00 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15527 for ; Fri, 28 Jun 2002 05:25:13 -0400 (EDT) Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090699 for ; Fri, 28 Jun 2002 10:26:16 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: Date: Fri, 28 Jun 2002 10:25:19 +0100 To: enum@ietf.org From: Lawrence Conroy Subject: Re: [ENUM] enumservices in new version of 2916bis 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 Hi Folks, Quick points here: - The URI-scheme *is* available "within the NAPTR" - strictly, once the regexp-replacement has been done. - For historical reasons we have non-terminal NAPTRs - whether or not they are used is another question, but they are a valid part of ENUM D3S. It's hard to have a mandatory element (the URI-scheme) within the service field when in some NAPTRs there IS no URI-scheme. I appear to have walked into ETSI/ITU - a conditionally mandatory information element, no less :). all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 06:49:26 2002 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 GAA18765 for ; Fri, 28 Jun 2002 06:49:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13975 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 06:50: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 GAA12874; Fri, 28 Jun 2002 06:40: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 GAA12820 for ; Fri, 28 Jun 2002 06:40:46 -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 GAA18287; Fri, 28 Jun 2002 06:39:58 -0400 (EDT) Message-Id: <200206281039.GAA18287@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: Fri, 28 Jun 2002 06:39:58 -0400 Subject: [Enum] I-D ACTION:draft-ietf-enum-e164-gstn-np-05.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 : Number Portability in the GSTN: An Overview Author(s) : M. Foster, T. McGarry, J. Yu Filename : draft-ietf-enum-e164-gstn-np-05.txt Pages : 27 Date : 27-Jun-02 This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony work-in-progress at IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn-np-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-gstn-np-05.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-gstn-np-05.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: <20020627133558.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-e164-gstn-np-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-e164-gstn-np-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020627133558.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 07:05:39 2002 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 HAA19544 for ; Fri, 28 Jun 2002 07:05:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA15850 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 07:06:23 -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 GAA14788; Fri, 28 Jun 2002 06:57: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 GAA14688 for ; Fri, 28 Jun 2002 06:57:25 -0400 (EDT) Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19139 for ; Fri, 28 Jun 2002 06:56:40 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: AW: [Enum] enumservices in new version of 2916bis MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 28 Jun 2002 12:59:08 +0200 Message-ID: <06CF906FE3998C4E944213062009F1620246FC@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: AW: [Enum] enumservices in new version of 2916bis Thread-Index: AcIeTX+SoMlu77ffSPWRjBag5SoVZgANlFHQ From: "Stastny Richard" To: "Richard Shockey" , "Peterson, Jon" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA14696 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 Comments inline: > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > Sent: Friday, June 28, 2002 4:42 AM > To: Stastny Richard; Peterson, Jon; rwalter@netnumber.com; > enum@ietf.org > Subject: Re: AW: [Enum] enumservices in new version of 2916bis > Jons request could the be fullfilled either with "E2U+sip", where > negotiation is the default, or "E2U+sip+srs", > > or in the Walter convention ..."E2U+sip:srs" ?? IMHO there > is much to > recommend in his approach.... Rudolf? Larry? are we close here? > If used in this order, I have to admit, that I cannot reject this proposal, because it is in principle the combination of the "3.1 Simple URI Scheme" and "3.2 Combined URI Schemes and Services" from my draft-stastny-enum-services-analysis-00.txt The difference is that I proposed to use +telvoice, +telfax, +sipvoice, etc., but this is obviously the same as +tel:voice, +tel:fax, +sip:voice. I only have the following requirements for the definition of "E2U+URI:svc+addinfo": 1. The "svc" SHALL be the same as defined with the URI Scheme used, and SHALL be defined with the URI Scheme. Only defined svc shall be used. The idea behind this is that it shall be possible (and shall be the same for the application-SW) to use a URI equivalent to the one used in the NAPTR also stand-alone on a webpage. 2. An "svc" SHALL be defined (used) consistently over all URI Schemes, if used in more than one URI Scheme. So e.g. svc=voice has the same meaning in tel:, sip:, etc. 3. A NAPTR containing "E2U+tel:voice+tel:fax" "...tel:+431xxx;svc=voice,fax!" is equivalent to "E2U+tel:voice+tel:fax" "...tel:+431...!" or should two NAPTRs be used in that case? 4. Only the URI Scheme is mandatory, but only if there is a "u" flag, to keep Lawrence happy;-) 5. There is a definition necessary, what it means, if only the URI scheme is used: A. Define a default (e.g. mailto defaults to email) (BTW: is vmail defined?) B. void svc means either "all", "any" or "negotiate" (or is "neg" an svc on ist own?) The "all" now leads to the question how to deal with the categories proposed in draft-brandner-enum-categorical-enumservices-00.txt? "all" may come in handy with the enum: URI and also others, for a detailed discussion see section 7.1 of the above mentioned draft. The other categories may go to the "+addinfo", provided at courtesy of the ENUM End User. So he may provide additional info, e.g. this is the preferred NAPTR for talk, msg, etc, but also "home", "office", "mobile", etc may be convinient. An open issue is categories like presence, location, certificate, etc. If we use it together with the URI Scheme as "svc" (e.g. ldap:cert), they need to be defined in the URI Scheme. My proposal here is to agree on the principal format as stated above, of course correctly defined and to include this in RFC2916bis. This together with a rough consensus could also serve as a basis for the format used at the trials (we will start with the simple and obvious URIs and services anyway). The details could be worked out in a separate draft (e.g. along the lines of my draft-stastny-enum-services-analysis), also resolving the above mentioned open issues on the list between Yokohama and Atlanta. There could also be some first feedback from the trials. Best regards Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 07:24:02 2002 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 HAA20157 for ; Fri, 28 Jun 2002 07:24:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16771 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 07:24: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 HAA16212; Fri, 28 Jun 2002 07:15: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 HAA16182 for ; Fri, 28 Jun 2002 07:15:44 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19836 for ; Fri, 28 Jun 2002 07:14:58 -0400 (EDT) Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090706 for ; Fri, 28 Jun 2002 12:16:00 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Fri, 28 Jun 2002 12:15:07 +0100 To: enum@ietf.org From: Lawrence Conroy Subject: Re: [ENUM] service field in rfc2916bis 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 Hi Folks, In answer to Rich's question - "are we close"? I think so, but using the earlier BNF roughtly like this: servicefield = "E2U" ("-" ) [*("+" )] is a URI scheme label registered in an RFC as defined according to RFC2717 section 4. In the case of a non-terminal NAPTR only, is empty. is an enumservice label registered in an RFC as defined according to 2916 section 3. Note that in this BNF the URI-scheme is a separate sub-field. As mentioned earlier, I do not like having the URI-scheme duplicated, and the other proposed option *( [(":" )]) will either result in the being duplicated in each enumservice or included only in one (or not at all), in which case I have to play "hunt the URI-scheme". I do not want to do this and do not see a benefit in this formulation over the first. BTW: the effect of the optional enumservice list means that it is possible either for a querying end user or a registrant to include no enumservices (no categories or low level services) in their NAPTR listing. I understand that these are used as filters on returned NAPTRs ....so... Question:: Should an empty list be considered as meaning "all" or as "any"? This is an important end user behaviour issue. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 08:45:43 2002 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 IAA23684 for ; Fri, 28 Jun 2002 08:45:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22763 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 08:46: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 IAA22205; Fri, 28 Jun 2002 08:37:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22174 for ; Fri, 28 Jun 2002 08:37:17 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23243 for ; Fri, 28 Jun 2002 08:36:31 -0400 (EDT) Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090707 for ; Fri, 28 Jun 2002 13:37:30 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Fri, 28 Jun 2002 13:36:38 +0100 To: enum@ietf.org From: Lawrence Conroy Subject: Re: [ENUM] service 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 Hi Folks, gleaning more from the postings, I think that (category and/or "low level" service) occupy the same sub-field. Category and low level service are part of the same name space; these are not two separate lists, but one. Thus when folks say service, I include the "categorical enumservices" as well as the low level ones in this space. As mentioned in earlier post, there may be some querying end user/client behaviour specified, to deal with a mixture of categories and services in a list, but as each service belongs to a single category, this is not too complex. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 12:19:40 2002 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 MAA04555 for ; Fri, 28 Jun 2002 12:19:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10778 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 12:20:26 -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 MAA09841; Fri, 28 Jun 2002 12: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 MAA09784 for ; Fri, 28 Jun 2002 12:10:41 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03812 for ; Fri, 28 Jun 2002 12:09:54 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA08453; Fri, 28 Jun 2002 18:10:36 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA18151; Fri, 28 Jun 2002 18:10:36 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 18:10:07 +0200 Message-ID: From: Brandner Rudolf To: "'Richard Shockey'" , Stastny Richard , "Peterson, Jon" , rwalter@netnumber.com, CONROY LAWRENCE Cc: enum@ietf.org Subject: AW: AW: [Enum] enumservices in new version of 2916bis Date: Fri, 28 Jun 2002 18:09:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 MAA09786 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 Hi all, > -----Ursprüngliche Nachricht----- > Von: Richard Shockey [mailto:rshockey@ix.netcom.com] > Gesendet: Freitag, 28. Juni 2002 04:42 > An: Stastny Richard; Peterson, Jon; rwalter@netnumber.com; > enum@ietf.org > Betreff: Re: AW: [Enum] enumservices in new version of 2916bis > -----[snipp]----- > > or in the Walter convention ..."E2U+sip:srs" ?? IMHO there > is much to > recommend in his approach.... Rudolf? Larry? are we close here? > So the discussion led to the following regarding the enumservice field: E2U That's a given and not controversial. URIscheme .. as a neccessity and being requested being mandatory. service .. being optional. Lawrence proposed servicefield = "E2U" ("-" ) [*("+" )] for parsing reasons, which I support. If regexp is considered expensive, parsing is also. Thus having distinct delimiters is an advantage. Along the lines that a CATEGORY is a group of SERVICEs and therefore within the same space (but not redundant), I'd like to be able to put in the service field a category. So the might be voice or fax or email or talk or msg. In addition, Richard Stastny proposed an optional addinfo, which I'd think would be best delimited by a '*' (see cost of parsing). Usage of addinfo needs to be defined, yet. So we would have: servicefield = "E2U" ("-" ) [*("+" )] ["*" addinfo] Some examples: A non-terminal with no optional fields: "E2U-" There's a sip URI coming with no more information revealed (as requested) "E2U-sip" A tel: URI for a phone with a lot of features and an addinfo "E2U-tel+voice+msg*do not call me at night" which is equivalent to (well, vmail not defined yet) "E2U-tel+voice+fax+sms+mms+vmail*do not call me at night" OK, I can live with this and I accept servicefield = "E2U" ("-" ) [*("+" )] ["*" addinfo] I think we are there. The SIP community requirements are met, end systems requirements are met, regexp and parsing cost considered, gateways can deal with this. Anything more? Rudi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 12:31:44 2002 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 MAA05335 for ; Fri, 28 Jun 2002 12:31:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12088 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 12:32:30 -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 MAA10956; Fri, 28 Jun 2002 12:23: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 MAA10926 for ; Fri, 28 Jun 2002 12:23:24 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04723 for ; Fri, 28 Jun 2002 12:22:38 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5SGLfuK008463; Fri, 28 Jun 2002 12:21:41 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5SGLd1Q008462; Fri, 28 Jun 2002 12:21:39 -0400 (EDT) Date: Fri, 28 Jun 2002 12:21:39 -0400 From: Michael Mealling To: Brandner Rudolf Cc: "'Richard Shockey'" , Stastny Richard , "Peterson, Jon" , rwalter@netnumber.com, CONROY LAWRENCE , enum@ietf.org Subject: Re: AW: [Enum] enumservices in new version of 2916bis Message-ID: <20020628122139.Z24592@bailey.dscga.com> Reply-To: Michael Mealling References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.3.22.1i 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, Jun 28, 2002 at 06:09:37PM +0200, Brandner Rudolf wrote: > > -----Ursprüngliche Nachricht----- > > Von: Richard Shockey [mailto:rshockey@ix.netcom.com] > > Gesendet: Freitag, 28. Juni 2002 04:42 > > An: Stastny Richard; Peterson, Jon; rwalter@netnumber.com; > > enum@ietf.org > > Betreff: Re: AW: [Enum] enumservices in new version of 2916bis > > > -----[snipp]----- > > > > or in the Walter convention ..."E2U+sip:srs" ?? IMHO there > > is much to > > recommend in his approach.... Rudolf? Larry? are we close here? > > > > So the discussion led to the following regarding the enumservice field: > > E2U > That's a given and not controversial. > > URIscheme > .. as a neccessity and being requested being mandatory. > > service > .. being optional. > > > Lawrence proposed > servicefield = "E2U" ("-" ) [*("+" )] > for parsing reasons, which I support. If regexp is considered > expensive, parsing is also. Thus having distinct delimiters is an > advantage. Along the lines that a CATEGORY is a group of SERVICEs and > therefore within the same space (but not redundant), I'd like to be > able to put in the service field a category. So the might > be voice or fax or email or talk or msg. > In addition, Richard Stastny proposed an optional addinfo, which I'd > think would be best delimited by a '*' (see cost of parsing). Usage of > addinfo needs to be defined, yet. > > So we would have: > servicefield = "E2U" ("-" ) [*("+" )] ["*" addinfo] Umm... I'd really like to change that from uri-scheme to protocol. It is _very_ common for protocols to be able to handle more than one URI scheme. URI scheme does _not_ equate to an actual protocol and vice versa. In the above grammar it is impossible to specify that a mailto URI can be used for something that isn't using SMTP. > Some examples: > > A non-terminal with no optional fields: > "E2U-" > There's a sip URI coming with no more information revealed (as requested) > "E2U-sip" > A tel: URI for a phone with a lot of features and an addinfo > "E2U-tel+voice+msg*do not call me at night" > which is equivalent to (well, vmail not defined yet) > "E2U-tel+voice+fax+sms+mms+vmail*do not call me at night" > > OK, I can live with this and I accept > servicefield = "E2U" ("-" ) [*("+" )] ["*" addinfo] > I think we are there. The SIP community requirements are met, end > systems requirements are met, regexp and parsing cost considered, > gateways can deal with this. Anything more? I think the SIP community has communicated that they're happy with something more than just 'SIP' as long as they can gaurantee that they can make the decision to only ever deal with SIP. So I think you may be intepreting their requirements more tightly than they are. I think it is _very_ important to seperate the URI scheme from the protocol found in the Service field. You can specify valid mappings in the definition of the protocol value in the Service field but don't actually _put_ the URI scheme there as though it were the only thing needed. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 13:04:21 2002 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 NAA07147 for ; Fri, 28 Jun 2002 13:04:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14543 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 13:05: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 MAA13490; Fri, 28 Jun 2002 12:56: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 MAA13458 for ; Fri, 28 Jun 2002 12:56:06 -0400 (EDT) Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06631 for ; Fri, 28 Jun 2002 12:55:19 -0400 (EDT) content-class: urn:content-classes:message Subject: AW: AW: [Enum] enumservices in new version of 2916bis MIME-Version: 1.0 Date: Fri, 28 Jun 2002 18:57:49 +0200 Content-Type: text/plain; charset="utf-8" Message-ID: <06CF906FE3998C4E944213062009F1620246FE@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: AW: [Enum] enumservices in new version of 2916bis Thread-Index: AcIewF14n2QwYaAtSBywuoqTZKsqhAAAy++S From: "Stastny Richard" To: "Michael Mealling" , "Brandner Rudolf" Cc: "Richard Shockey" , "Peterson, Jon" , , "CONROY LAWRENCE" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id MAA13460 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 Comments inline: -----Ursprüngliche Nachricht----- Von: Michael Mealling [mailto:michael@neonym.net] Gesendet: Fr 28.06.2002 18:21 An: Brandner Rudolf Cc: 'Richard Shockey'; Stastny Richard; Peterson, Jon; rwalter@netnumber.com; CONROY LAWRENCE; enum@ietf.org Betreff: Re: AW: [Enum] enumservices in new version of 2916bis On Fri, Jun 28, 2002 at 06:09:37PM +0200, Brandner Rudolf wrote: > > -----Ursprüngliche Nachricht----- > > Von: Richard Shockey [mailto:rshockey@ix.netcom.com] > > Gesendet: Freitag, 28. Juni 2002 04:42 > > An: Stastny Richard; Peterson, Jon; rwalter@netnumber.com; > > enum@ietf.org > > Betreff: Re: AW: [Enum] enumservices in new version of 2916bis > > > -----[snipp]----- > So we would have: > servicefield = "E2U" ("-" ) [*("+" )] ["*" addinfo] Umm... I'd really like to change that from uri-scheme to protocol. It is _very_ common for protocols to be able to handle more than one URI scheme. URI scheme does _not_ equate to an actual protocol and vice versa. In the above grammar it is impossible to specify that a mailto URI can be used for something that isn't using SMTP. Richard Stastny replies: NO, now I am totally confused. Maybe I missed something or I do not properly understand ENUM, but I have been told (and thats also what I told then everybody who wanted to listen), that ENUM is an E.164 to URI mapping. If I see an mailto:hugo@neustar.biz on a webpage, I do not need an additional information to send an e-mail to Hugo, or do I? So I personally considered it redundant to even use the URI-Scheme in the NAPTR, because anybody or any-SW can see it, I they just look a bit to the left, but if this is considered helpfull, ok, shall it be. Then I may add some service definitions to the URI, e.g. if this tel URI may be used for sms and/or fax. But I definetly see nor reason to add a protocol information. best regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 13:06:24 2002 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 NAA07272 for ; Fri, 28 Jun 2002 13:06:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14657 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 13:07: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 MAA13639; Fri, 28 Jun 2002 12:57:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13608 for ; Fri, 28 Jun 2002 12:57:38 -0400 (EDT) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06720 for ; Fri, 28 Jun 2002 12:56:52 -0400 (EDT) Received: from RWALTER ([65.203.166.26]) by hvmta01-stg.us.psimail.psi.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020628165733.CDQW223.hvmta01-stg.us.psimail.psi.net@RWALTER>; Fri, 28 Jun 2002 12:57:34 -0400 Reply-To: From: "Robert H. Walter" To: , "Stastny Richard" , "Peterson, Jon" , Cc: Date: Fri, 28 Jun 2002 12:57:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Enum] enumservices in new version of 2916bis 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 R. Stastny and R. Shocky, I think we are very close to concensus... BTW, I like the spirit of the draft-brandner-tel-svc-00.txt I-D and also believe that a tight correlation between the TEL URI svc parameters and the ENUM service specification is a good thing. I reiterate that the purpose of the service field is to allow an application to rapidly select NAPTR records that are meaningful to its purpose and/or function. Consider the following examples: An application wants to send a voice message to a voice messaging system that supports an SMTP interface and it only knows a telephone number. This can be handled with EITHER of the following NAPTRs: NAPTR 0 0 "U" "E2U+vmail" "!^.*$!mailto:user@domain!" . NAPTR 0 0 "U" "E2U+vmail:mailto" "!^.*$!mailto:user@domain!" A SIP UAC wants to initiate a voice session with another SIP UAC and it only knows a telephone number. Since SIP supports some degree of service negotiation this can be handled with EITHER of the following NAPTRs: NAPTR 0 0 "U" "E2U+srs" "!^.*$!sip:domain!" . NAPTR 0 0 "U" "E2U+srs:sip" "!^.*$!sip:domain!" In each example above, I assert that both NAPTR records are equivalent and placing the URI Scheme in the service field is merely a performance optimization. If we decide that the performance optimization is so important that it becomes a MUST, then so be it, otherwise I recommend it SHOULD be used, however specified as optional. The core issue I am addressing is that service discovery, applicability and location are different but related things... Applications need to discover if a particular communication service is available, i.e. Real- time voice, Voice Messaging, etc. The service or "svc" parameter addresses the discovery issue. The URI scheme or service protocol addresses the applicability issue or what protocol to use to communicate with the service. Once the application determines that a service exists and that it can communicate with, it leverages the URI to locate it. Based on the requirements R. Stastny defined I suggest the following: Using R. Stastny's short-hand schema: "E2U+service:uri-scheme". The complete ABNF is as follows: enum-service = "E2U" 1*( "+" service [ ":" uri-scheme ] ) service = "voice" / "video" / "email" / "vmail" / "mms" / "sms" / "tdd" / "srs" / "fax" / extension uri-scheme = "mailto" | "sip" | "h323" | other extension = ALPHA *( ALPHA / DIGIT ) DIGIT = %x30-39 ; 0-9 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z The addinfo is addressed through the extension production on the service and uri-scheme productions. R. Shockey, J. Peterson: I'm cool with "srs" as a service, thus SIP can do its negotiation thing without impedding AOR... Finally, the definition of the service and uri-schemes in the ABNF above are illustrative and should follow Patrik's recommendation from yesterday. Thanks To All, Bob ====================================================================== Robert H. Walter - CTO, VP Engineering tel:+19788482831 NetNumber, Inc. fax:+19784545044 650 Suffolk Street mailto:rwalter@netnumber.com Lowell, MA 01854 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 13:24:03 2002 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 NAA08350 for ; Fri, 28 Jun 2002 13:24:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15716 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 13:24: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 NAA15039; Fri, 28 Jun 2002 13:13: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 NAA15008 for ; Fri, 28 Jun 2002 13:13:29 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07679 for ; Fri, 28 Jun 2002 13:12:28 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5SHA9uK008649; Fri, 28 Jun 2002 13:10:14 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5SH9MKa008643; Fri, 28 Jun 2002 13:09:22 -0400 (EDT) Date: Fri, 28 Jun 2002 13:09:22 -0400 From: Michael Mealling To: Stastny Richard Cc: Michael Mealling , Brandner Rudolf , Richard Shockey , "Peterson, Jon" , rwalter@netnumber.com, CONROY LAWRENCE , enum@ietf.org Subject: Re: AW: [Enum] enumservices in new version of 2916bis Message-ID: <20020628130921.A24592@bailey.dscga.com> Reply-To: Michael Mealling References: <06CF906FE3998C4E944213062009F1620246FE@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CF906FE3998C4E944213062009F1620246FE@oefeg-s02.oefeg.loc> User-Agent: Mutt/1.3.22.1i 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 Fri, Jun 28, 2002 at 06:57:49PM +0200, Stastny Richard wrote: >> > An: Stastny Richard; Peterson, Jon; rwalter@netnumber.com; >> > enum@ietf.org >> > Betreff: Re: AW: [Enum] enumservices in new version of 2916bis >> > >> -----[snipp]----- >> So we would have: >> servicefield = "E2U" ("-" ) [*("+" )] ["*" addinfo] > > Umm... I'd really like to change that from uri-scheme to protocol. It is > _very_ common for protocols to be able to handle more than one URI scheme. > URI scheme does _not_ equate to an actual protocol and vice versa. > In the above grammar it is impossible to specify that a mailto URI can be > used for something that isn't using SMTP. > > Richard Stastny replies: > > NO, now I am totally confused. Maybe I missed something or I do > not properly understand ENUM, but I have been told (and thats also what > I told then everybody who wanted to listen), that ENUM is an E.164 to > URI mapping. Correct. E.164 to URI mapping. But a URI denotes a network endpoint (node) within the WorldWideWeb. Some URIs suggest what transport you use to get to that endpoint but not all of them. There are _many_ URI schems that have no transport defined for them at all. > If I see an mailto:hugo@neustar.biz on a webpage, I do not need an > additional information to send an e-mail to Hugo, or do I? From RFC 2368: The mailto URL scheme is used to designate the Internet mailing address of an individual or service. In its simplest form, a mailto URL contains an Internet mail address. It does not define the _reason_ why you are doing it and what protocols you are using to do what is is you are attempting to do. Its simply saying "hey, the thing after the colon is an Internet email address". What you _do_ with that address and _how_ you do it isn't defined or restricted. In many Instant Messaging schemes the 'mailto' URI generates an Instant Message sent via some IM network. > So I personally considered it redundant to even use the URI-Scheme in > the NAPTR, because anybody or any-SW can see it, I they just look a bit > to the left, but if this is considered helpfull, ok, shall it be. Then > I may add some service definitions to the URI, e.g. if this tel URI may > be used for sms and/or fax. > > But I definetly see nor reason to add a protocol information. You need it because URI does _not_ equate with how you are expected to access it that particular endpoint. You can use _any_ URI scheme within the HTTP protocol. 'urn', 'mailto', 'data', 'news', etc are all examples of URIs that do not and never will define a protocl by which you access the resource identified by that URI. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 13:26:29 2002 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 NAA08537 for ; Fri, 28 Jun 2002 13:26:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15792 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 13:27: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 NAA15384; Fri, 28 Jun 2002 13:17: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 NAA15333 for ; Fri, 28 Jun 2002 13:17:47 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07933 for ; Fri, 28 Jun 2002 13:17:02 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5SHH6B26319; Fri, 28 Jun 2002 13:17:06 -0400 Message-Id: <5.1.0.14.2.20020628105200.02386120@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 28 Jun 2002 13:23:29 -0400 To: "Stastny Richard" , "Peterson, Jon" , , From: Richard Shockey Subject: RE: AW: [Enum] enumservices in new version of 2916bis Cc: dranalli@netnumber.com In-Reply-To: <06CF906FE3998C4E944213062009F1620246FC@oefeg-s02.oefeg.loc > 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 > > >If used in this order, I have to admit, that I cannot reject this >proposal, because it is in principle the combination of the "3.1 Simple >URI Scheme" and "3.2 Combined URI Schemes and Services" from my >draft-stastny-enum-services-analysis-00.txt > >The difference is that I proposed to use +telvoice, +telfax, +sipvoice, >etc., but this is obviously the same as +tel:voice, +tel:fax, >+sip:voice. > >I only have the following requirements for the definition of >"E2U+URI:svc+addinfo": Speaking for myself I don't see a problem with this and that could be added to the EBNF syntax proposed by Bob enum-service : "E2U" ( "+" URI/protocol [ ":" service] )+ URI/protocol [mandatory] : | "tel" |"mailto" | "H323" | "sip" | other service [optional] : "voice" | "video" | "email" | "im" | "sms" |other info [optional] : In a private note Mike Mealling remarked to me his definition of terms: "IMHO, a service is an action that can be expressed via multiple protocols. A protocol is profile of some set of semantics and an on the wire protocol that is used to accomplish the task expressed by the service... A protocol is seperate from a URI scheme because URI identify endpoints and many protocols can handle multiple URI schemes..." What I'm trying to resolve here is the definition of terms ......... >1. The "svc" SHALL be the same as defined with the URI Scheme used, and >SHALL be defined with the URI Scheme. Only defined svc shall be used. >The idea behind this is that it shall be possible (and shall be the same >for the application-SW) to use a URI equivalent to the one used in the >NAPTR also stand-alone on a webpage. > >2. An "svc" SHALL be defined (used) consistently over all URI Schemes, >if used in more than one URI Scheme. So e.g. svc=voice has the same >meaning in tel:, sip:, etc. can we just call it "service" ? its verbose and easily understandable >3. A NAPTR containing "E2U+tel:voice+tel:fax" >"...tel:+431xxx;svc=voice,fax!" is equivalent to >"E2U+tel:voice+tel:fax" "...tel:+431...!" or should two NAPTRs be used >in that case? Ok now I'm getting confused again... I'm assuming that if you are assuming a T.30 capable fax terminal device that is PSTN addressable that "E2U+tel:fax" IMHO is sufficient with a tel URL. >4. Only the URI Scheme is mandatory, but only if there is a "u" flag, to >keep Lawrence happy;-) > >5. There is a definition necessary, what it means, if only the URI >scheme is used: >A. Define a default (e.g. mailto defaults to email) (BTW: is vmail >defined?) It will be .... I'm very wary of defining things like this at this time since I'm assuming the VPIM WG will want to address those issues separately in their own drafts. I've personally briefed both the VPIM and FAX WG on the progress of the ENUM WG at several IETF meetings and I'm assuming they will use our guidance to construct appropriate ENUM service fields for their respective protocols. >B. void svc means either "all", "any" or "negotiate" (or is "neg" an svc >on ist own?) > >The "all" now leads to the question how to deal with the categories >proposed in draft-brandner-enum-categorical-enumservices-00.txt? > >"all" may come in handy with the enum: URI and also others, for a >detailed discussion see section 7.1 of the above mentioned draft. > >The other categories may go to the "+addinfo", provided at courtesy of >the ENUM End User. So he may provide additional info, e.g. this is the >preferred NAPTR for talk, msg, etc, but also "home", "office", "mobile", >etc may be convinient. I think its best all around if we look at this info field as being ambiguous .. your examples make my nervous since it defines a lot more information than I think some folks want to disclose in the DNS as you correctly point out . If we start to suggest things like this in 2916bis the assumption will be made that its "official" and that will trigger some serious misconceptions on the part of the privacy community. I don't dbout there may be users that want to do this ..its just that we will have to be very careful in the language to point out that uses like this are purely optional at the discretion of the End User. >An open issue is categories like presence, location, certificate, etc. >If we use it together with the URI Scheme as "svc" (e.g. ldap:cert), >they need to be defined in the URI Scheme. Sure ..but the ENUM WG itself may not be the appropriate WG to create those drafts. I think we need to have a bit more outreach to other communities of interest here. >My proposal here is to agree on the principal format as stated above, of >course correctly defined and to include this in RFC2916bis. This >together with a rough consensus could also serve as a basis for the >format used at the trials (we will start with the simple and obvious >URIs and services anyway). Yes and I think we know what those are the question is what is the document instrument we use to define those initial trial fields. We have a process issue to deal with ... first we need to see 2916bis and the IANA registration procedures associated with it. >The details could be worked out in a separate draft (e.g. along the >lines of my draft-stastny-enum-services-analysis), also resolving the >above mentioned open issues on the list between Yokohama and Atlanta. >There could also be some first feedback from the trials. I think this is a very very good idea. A specific ID on a limited series of enumservice constructs for the purposes of global trials. ..we can create a simple matrix with verbose explanations along the lines of your "Catagoricial enumservices" document and Bob Walters syntax. enum-service : "E2U" ( "+" URI/protocol [ ":" service] )+ URI/protocol [mandatory] : | "tel" |"mailto" | "H323" | "sip" | other service [optional] : "voice" | "video" | "email" | "im" | "sms" |other info [optional] : The purpose of the document would be to explain the current state of ENUM development perhaps highlight the agreement made with SG2 etc and note that several nation-states have committed to developing trials etc. This new ID is offered to "facilitate" these trials under way blah blah etc. Now in addition, putting my WG chair hat on, I think it would be a good idea for both you , Rudolf, and Larry to collaborate with Bob Walter and Doug Ranalli on this. Bob and Doug have put a lot of thought into this and their original draft suggested many of the concepts here so it only seems reasonable to combine efforts. You all could have something ready shortly after Yokohama and put it on track to "Experimental" in conjunction with 2916bis itself. Is this a plan? >Best regards > >Richard STASTNY >OeFEG/Telekom Austria >Box 147, A-1103 Vienna, Austria >tel:+43 664 420 4100 >fax:+43 1 797 80 13 >mailto:richard.stastny@oefeg.at >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 13:38:56 2002 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 NAA09279 for ; Fri, 28 Jun 2002 13:38:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16834 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 13:39: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 NAA16090; Fri, 28 Jun 2002 13:30:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16054 for ; Fri, 28 Jun 2002 13:30:41 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08718 for ; Fri, 28 Jun 2002 13:29:56 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5SHTfB26567; Fri, 28 Jun 2002 13:29:41 -0400 Message-Id: <5.1.0.14.2.20020628132714.0245bb28@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 28 Jun 2002 13:36:03 -0400 To: , , "Stastny Richard" , "Peterson, Jon" , From: Richard Shockey Subject: Re: [Enum] enumservices in new version of 2916bis Cc: In-Reply-To: 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 12:57 PM 6/28/2002 -0400, Robert H. Walter wrote: >R. Stastny and R. Shocky, > >I think we are very close to concensus... BTW, I like the spirit of >the draft-brandner-tel-svc-00.txt I-D and also believe that a tight >correlation between the TEL URI svc parameters and the ENUM service >specification is a good thing. > >I reiterate that the purpose of the service field is to allow an >application to rapidly select NAPTR records that are meaningful >to its purpose and/or function. Consider the following examples: Which is also why some of us argue the URI/protocol is first >An application wants to send a voice message to a voice messaging >system that supports an SMTP interface and it only knows a telephone >number. This can be handled with EITHER of the following NAPTRs: > > NAPTR 0 0 "U" "E2U+vmail" "!^.*$!mailto:user@domain!" . > NAPTR 0 0 "U" "E2U+vmail:mailto" "!^.*$!mailto:user@domain!" I'd like these reversed ... NAPTR 0 0 "U" "E2U+vmail" "!^.*$!mailto:user@domain!" . This in my view this construct is not good since vmail is not a URI/protocol ..that needs to always be there. Therefore the proper expression proper would be NAPTR 0 0 "U" "E2U+mailto:vmail" "!^.*$!mailto:user@domain!" or simply NAPTR 0 0 "U" "E2U+mailto" "!^.*$!mailto:user@domain!" . The transaction result is the same ..but it has the advantage of not exposing that this is really a vmail box.... but again as I noted in previous messages I'd like to see the input from the VPIM group first on these issues. >A SIP UAC wants to initiate a voice session with another SIP UAC >and it only knows a telephone number. Since SIP supports some >degree of service negotiation this can be handled with EITHER of >the following NAPTRs: > > NAPTR 0 0 "U" "E2U+srs" "!^.*$!sip:domain!" . > NAPTR 0 0 "U" "E2U+srs:sip" "!^.*$!sip:domain!" reverse again ... >In each example above, I assert that both NAPTR records are >equivalent and placing the URI Scheme in the service field is merely >a performance optimization. If we decide that the performance >optimization is so important that it becomes a MUST, then so >be it, otherwise I recommend it SHOULD be used, however specified >as optional. IMHO MUST ... >The core issue I am addressing is that service discovery, applicability >and location are different but related things... Applications need to >discover if a particular communication service is available, i.e. Real- >time voice, Voice Messaging, etc. The service or "svc" parameter >addresses the discovery issue. The URI scheme or service protocol >addresses the applicability issue or what protocol to use to communicate >with the service. Once the application determines that a service exists >and that it can communicate with, it leverages the URI to locate it. > >Based on the requirements R. Stastny defined I suggest the following: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 14:32:26 2002 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 OAA12754 for ; Fri, 28 Jun 2002 14:32:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20165 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 14:33: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 OAA19028; Fri, 28 Jun 2002 14:22:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18941 for ; Fri, 28 Jun 2002 14:22:29 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12102 for ; Fri, 28 Jun 2002 14:21:43 -0400 (EDT) Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090709 for ; Fri, 28 Jun 2002 19:22:45 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Fri, 28 Jun 2002 19:21:55 +0100 To: enum@ietf.org From: Lawrence Conroy Subject: [Enum] service field 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 Hi Folks, - protocol # URI-scheme. Initial reaction - are you kidding? Subsequent reaction - obviously not, as it's repeated. If you want to specify the protocol to be used (or sub-protocol), then write up a draft to put this as a URI parameter. Yes, Rich, you could put this into the service field instead of the URI-scheme, IF someone writes the RFCs to define the label for each protocol that can be used (and ensures that this fits with the URI-scheme generated from the NAPTR), and opens a new protocol-label tree with IANA. However, I WANT the the NAPTR service field to be restricted to including URI-scheme, at least for now. Basically, protocol in the services field over my dead and smoking body. Put it in the URI if someone needs it. Get it through the IETF; convince the OS/Application companies to change their URL handler APIs, and then I might look at it, but now? I understand that urn: does not tell me how to access the resource. This probably explains why it's such a stellar success; considering all of the "select your nearest mirror to download" pages I traverse, there is a definite need out there, and yet... As for mailto: using either IM or SMTP, so? I have a handler that works quite well with such URLs. I don't have a problem putting a mailto: URL on a web page, or on clicking on the link and it firing up a local handler. Judging from the volume of junk emails I get, handling a mailto: URL on my web page works for at least some folks. Forgive the sting, but I have the rare joy of focusing on making this stuff work in real end systems, using real (existing) URL handlers, and with real DNS entries, set up by real people using web pages to make it all look half intelligible. My last good choice was tracking SIP for the PINT work, when that changed syntax every two weeks (around the time of mmusic-sip-06). Now it looks like I have the same problem here. Finally, given that Rich (and others) think that the URI-scheme is a MUST, PLEASE let's not put the URI-scheme as an addendum on every enumservice - it really SHOULD be a separate sub-field on its own in the NAPTR service field. Also, can folks please use examples with more than one service/function/category? The syntax choices are more obvious in that case, IMHO. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 14:41:22 2002 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 OAA13527 for ; Fri, 28 Jun 2002 14:41:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21173 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 14:42: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 OAA20162; Fri, 28 Jun 2002 14:33: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 OAA20131 for ; Fri, 28 Jun 2002 14:33:08 -0400 (EDT) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12748 for ; Fri, 28 Jun 2002 14:32:23 -0400 (EDT) Received: from RWALTER ([65.203.166.26]) by hvmta01-stg.us.psimail.psi.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020628183304.COWF223.hvmta01-stg.us.psimail.psi.net@RWALTER>; Fri, 28 Jun 2002 14:33:04 -0400 Reply-To: From: "Robert H. Walter" To: "Richard Shockey" Cc: Subject: RE: [Enum] enumservices in new version of 2916bis Date: Fri, 28 Jun 2002 14:33:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.0.14.2.20020628132714.0245bb28@popd.ix.netcom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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 Richard, > I'd like these reversed ... > > NAPTR 0 0 "U" "E2U+vmail" "!^.*$!mailto:user@domain!" . > > This in my view this construct is not good since vmail is not a > URI/protocol ..that needs to always be there. > > Therefore the proper expression proper would be > > NAPTR 0 0 "U" "E2U+mailto:vmail" "!^.*$!mailto:user@domain!" > > or simply > > NAPTR 0 0 "U" "E2U+mailto" "!^.*$!mailto:user@domain!" > > The transaction result is the same ..but it has the advantage of not > exposing that this is really a vmail box.... but again as I noted in > previous messages I'd like to see the input from the VPIM group first > on these issues. Respectfully, the transaction result is not the same. Without the service the application has no idea what type of communication service this NAPTR represents. The application only knows that it can communicate with it using SMTP. IMHO, the NAPTR is at best ambiguous. Now, if the service field is defined as "E2U+srs:mailto" The expectation is that the application will somehow negotiate with the service using SMTP to decide on what the service will be... If both service and protocol are a MUST, then we have reached concensus and I have no opinion on the order. The following ABNF reflects this thinking: enum-service = "E2U" 1*( "+" uri-scheme ":" service ) service = "voice" / "video" / "email" / "vmail" / "mms" / "sms" / "tdd" / "srs" / "fax" / extension uri-scheme = "mailto" | "sip" | "h323" | extension extension = ALPHA *( ALPHA / DIGIT ) DIGIT = %x30-39 ; 0-9 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z Regards, Bob Walter NetNumber, Inc. > -----Original Message----- > From: Richard Shockey [mailto:rich.shockey@NeuStar.com] > Sent: Friday, June 28, 2002 1:36 PM > To: rwalter@netnumber.com; rich.shockey@neustar.com; Stastny Richard; > Peterson, Jon; paf@cisco.com > Cc: enum@ietf.org > Subject: Re: [Enum] enumservices in new version of 2916bis > > > At 12:57 PM 6/28/2002 -0400, Robert H. Walter wrote: > >R. Stastny and R. Shocky, > > > >I think we are very close to concensus... BTW, I like the spirit of > >the draft-brandner-tel-svc-00.txt I-D and also believe that a tight > >correlation between the TEL URI svc parameters and the ENUM service > >specification is a good thing. > > > >I reiterate that the purpose of the service field is to allow an > >application to rapidly select NAPTR records that are meaningful > >to its purpose and/or function. Consider the following examples: > > Which is also why some of us argue the URI/protocol is first > > > >An application wants to send a voice message to a voice messaging > >system that supports an SMTP interface and it only knows a telephone > >number. This can be handled with EITHER of the following NAPTRs: > > > > NAPTR 0 0 "U" "E2U+vmail" "!^.*$!mailto:user@domain!" . > > NAPTR 0 0 "U" "E2U+vmail:mailto" "!^.*$!mailto:user@domain!" > > I'd like these reversed ... > > NAPTR 0 0 "U" "E2U+vmail" "!^.*$!mailto:user@domain!" . > > This in my view this construct is not good since vmail is not a > URI/protocol ..that needs to always be there. > > Therefore the proper expression proper would be > > NAPTR 0 0 "U" "E2U+mailto:vmail" > "!^.*$!mailto:user@domain!" > > or simply > > NAPTR 0 0 "U" "E2U+mailto" > "!^.*$!mailto:user@domain!" . The transaction result is the same ..but it > has the advantage of not exposing that this is really a vmail box.... but > again as I noted in previous messages I'd like to see the input from the > VPIM group first on these issues. > > > > > >A SIP UAC wants to initiate a voice session with another SIP UAC > >and it only knows a telephone number. Since SIP supports some > >degree of service negotiation this can be handled with EITHER of > >the following NAPTRs: > > > > NAPTR 0 0 "U" "E2U+srs" "!^.*$!sip:domain!" . > > NAPTR 0 0 "U" "E2U+srs:sip" "!^.*$!sip:domain!" > > reverse again ... > > > >In each example above, I assert that both NAPTR records are > >equivalent and placing the URI Scheme in the service field is merely > >a performance optimization. If we decide that the performance > >optimization is so important that it becomes a MUST, then so > >be it, otherwise I recommend it SHOULD be used, however specified > >as optional. > > IMHO MUST ... > > > >The core issue I am addressing is that service discovery, applicability > >and location are different but related things... Applications need to > >discover if a particular communication service is available, i.e. Real- > >time voice, Voice Messaging, etc. The service or "svc" parameter > >addresses the discovery issue. The URI scheme or service protocol > >addresses the applicability issue or what protocol to use to communicate > >with the service. Once the application determines that a service exists > >and that it can communicate with, it leverages the URI to locate it. > > > >Based on the requirements R. Stastny defined I suggest the following: > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 > 1120 Vermont Ave NW Suite 400 Washington DC 20005 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 14:54:00 2002 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 OAA14427 for ; Fri, 28 Jun 2002 14:54:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22027 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 14:54:45 -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 OAA21461; Fri, 28 Jun 2002 14:45: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 OAA21430 for ; Fri, 28 Jun 2002 14:45:43 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13724 for ; Fri, 28 Jun 2002 14:44:53 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5SIhxuK009054; Fri, 28 Jun 2002 14:43:59 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5SIhxMP009053; Fri, 28 Jun 2002 14:43:59 -0400 (EDT) Date: Fri, 28 Jun 2002 14:43:58 -0400 From: Michael Mealling To: Lawrence Conroy Cc: enum@ietf.org Subject: Re: [Enum] service field Message-ID: <20020628144358.C24592@bailey.dscga.com> Reply-To: Michael Mealling References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i 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 Fri, Jun 28, 2002 at 07:21:55PM +0100, Lawrence Conroy wrote: > Hi Folks, > - protocol # URI-scheme. Initial reaction - are you kidding? > Subsequent reaction - obviously not, as it's repeated. > If you want to specify the protocol to be used (or sub-protocol), > then write up a draft to put this as a URI parameter. URI parameter? Are you seriously suggesting we tell the existing URI schemes to change their definitions when the explicitly _don't_ want something like that in there? > Yes, Rich, you could put this into the service field instead of the > URI-scheme, IF someone writes the RFCs to define the label for each > protocol that can be used (and ensures that this fits with the > URI-scheme generated from the NAPTR), and opens a new protocol-label > tree with IANA. You don't define an RFC for each one unless that's what you want to do. Most already define that. HTTP says "hey, use whatever URI you want here, that's what its for". > However, I WANT the the NAPTR service field to be restricted to > including URI-scheme, at least for now. So the working group has to limit the standard to what you're willing to implement right now? > Basically, protocol in the services field over my dead and smoking > body. Put it in the URI if someone needs it. Ok, here's the typical question we have to ask when a statement like this comes up: what part of your implementation _breaks_ if it is in there? > Get it through the IETF; convince the OS/Application companies to > change their URL handler APIs, and then I might look at it, but now? Huh? I really don't follow that statement. You do realize that most (all?) URI specifications make a very distinct seperation between what they identify and what protocol you can use to talk about them. That's at the entire core of what URIs are and why they're used. That's the entire basis of how things like web caching, middle boxes, etc work. > I understand that urn: does not tell me how to access the resource. > This probably explains why it's such a stellar success; considering > all of the "select your nearest mirror to download" pages I traverse, > there is a definite need out there, and yet... > As for mailto: using either IM or SMTP, so? I have a handler that > works quite well with such URLs. I don't have a problem putting a > mailto: URL on a web page, or on clicking on the link and it firing > up a local handler. Judging from the volume of junk emails I get, > handling a mailto: URL on my web page works for at least some folks. The job here is to define protocols that work _in the future_ given what we know now. Just about everyone here realizes the need for a protocol and understands why URIs explicitly divorce themselves from a given transport. I think you are confusing what you happen to use in a web browser with web architecure and why things are the way they are. The web is _not_ constrianed to what you see in your browser. > Forgive the sting, but I have the rare joy of focusing on making this > stuff work in real end systems, using real (existing) URL handlers, Ever written a URL handler? I have.... > and with real DNS entries, set up by real people using web pages to > make it all look half intelligible. My last good choice was tracking > SIP for the PINT work, when that changed syntax every two weeks > (around the time of mmusic-sip-06). Now it looks like I have the same > problem here. I actually don't think we have that problem. So far I think you're voice is the only one being this adament about 'protocol' vs 'URI scheme' and it really sounds like its from a misunderstanding of web architecture and the role of URIs in it. Unless you're suggesting we just through out the architecture? > Finally, given that Rich (and others) think that the URI-scheme is a > MUST, PLEASE let's not put the URI-scheme as an addendum on every > enumservice - it really SHOULD be a separate sub-field on its own in > the NAPTR service field. What I keep wondering is why you need to know the URI scheme when the protocol defines what set of URI schemes it can handle. I.e. the protocol 'foo' can handle 'bar:' and 'baz:' URI schemes. Why does it matter which one is actually in the REGEXP field? > Also, can folks please use examples with more than one > service/function/category? The syntax choices are more obvious in > that case, IMHO. I personally can only see service+protocol. I don't see any differences between 'service', 'function' or 'category'.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 15:02:14 2002 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 PAA14832 for ; Fri, 28 Jun 2002 15:02:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA22910 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 15:02: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 OAA21936; Fri, 28 Jun 2002 14:53: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 OAA21909 for ; Fri, 28 Jun 2002 14:53:47 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14343 for ; Fri, 28 Jun 2002 14:53:00 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5SIpxuK009078; Fri, 28 Jun 2002 14:52:00 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5SIpw6s009077; Fri, 28 Jun 2002 14:51:58 -0400 (EDT) Date: Fri, 28 Jun 2002 14:51:57 -0400 From: Michael Mealling To: "Robert H. Walter" Cc: Richard Shockey , enum@ietf.org Subject: Re: [Enum] enumservices in new version of 2916bis Message-ID: <20020628145157.D24592@bailey.dscga.com> Reply-To: Michael Mealling References: <5.1.0.14.2.20020628132714.0245bb28@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i 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 Fri, Jun 28, 2002 at 02:33:03PM -0400, Robert H. Walter wrote: > > I'd like these reversed ... > > > > NAPTR 0 0 "U" "E2U+vmail" "!^.*$!mailto:user@domain!" . > > > > This in my view this construct is not good since vmail is not a > > URI/protocol ..that needs to always be there. > > > > Therefore the proper expression proper would be > > > > NAPTR 0 0 "U" "E2U+mailto:vmail" "!^.*$!mailto:user@domain!" > > > > or simply > > > > NAPTR 0 0 "U" "E2U+mailto" "!^.*$!mailto:user@domain!" > > > > The transaction result is the same ..but it has the advantage of not > > exposing that this is really a vmail box.... but again as I noted in > > previous messages I'd like to see the input from the VPIM group first > > on these issues. > > Respectfully, the transaction result is not the same. Without the service > the application has no idea what type of communication service this NAPTR > represents. The application only knows that it can communicate with it > using SMTP. IMHO, the NAPTR is at best ambiguous. Now, if the service > field is defined as > > "E2U+srs:mailto" > > The expectation is that the application will somehow negotiate with the > service using SMTP to decide on what the service will be... If both > service and protocol are a MUST, then we have reached concensus > and I have no opinion on the order. Umm.... I'm not sure in what context you're using the string 'mailto' here but just in case: mailto is a URI scheme defined in RFC 2368 which only mentioned SMTP _once_ in a caveat about making sure the SMTP 'From' address is set correctly in the message. RFC 2368 does not define any transport system to be used. Period. 'mailto:' identifies RFC 822 addresses and messages. How you get to an address or send a message is not defined. Everyone: Please be _very_ careful how you use 'mailto:'. It _does NOT_ mean what you think it means simply from your usage on a web page. Please read RFC 2368 and RFC 2396 if this is confusing.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 15:14:03 2002 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 PAA15556 for ; Fri, 28 Jun 2002 15:14:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24104 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 15:14: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 PAA23209; Fri, 28 Jun 2002 15:05: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 PAA23182 for ; Fri, 28 Jun 2002 15:05:08 -0400 (EDT) Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net [38.202.36.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14971 for ; Fri, 28 Jun 2002 15:04:22 -0400 (EDT) Received: from RWALTER ([65.203.166.26]) by hvmta03-stg.us.psimail.psi.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020628190501.UXWY15093.hvmta03-stg.us.psimail.psi.net@RWALTER>; Fri, 28 Jun 2002 15:05:01 -0400 Reply-To: From: "Robert H. Walter" To: "Michael Mealling" Cc: Subject: RE: [Enum] enumservices in new version of 2916bis Date: Fri, 28 Jun 2002 15:05:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020628145157.D24592@bailey.dscga.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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 > Umm.... I'm not sure in what context you're using the string 'mailto' > here but just in case: > > mailto is a URI scheme defined in RFC 2368 which only mentioned SMTP _once_ > in a caveat about making sure the SMTP 'From' address is set correctly in the > message. RFC 2368 does not define any transport system to be used. Period. > 'mailto:' identifies RFC 822 addresses and messages. How you get to an > address or send a message is not defined. > > Everyone: Please be _very_ careful how you use 'mailto:'. It _does NOT_ > mean what you think it means simply from your usage on a web page. Please > read RFC 2368 and RFC 2396 if this is confusing.... Agreed, the uri-scheme and protocol are different things and should not be used interchangeably... Bob Walter NetNumber, Inc. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 15:49:00 2002 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 PAA17740 for ; Fri, 28 Jun 2002 15:49:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26668 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 15:49:45 -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 PAA26050; Fri, 28 Jun 2002 15:38: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 PAA26019 for ; Fri, 28 Jun 2002 15:38:19 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16995 for ; Fri, 28 Jun 2002 15:37:30 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5SJbXB29475; Fri, 28 Jun 2002 15:37:34 -0400 Message-Id: <5.1.0.14.2.20020628152346.0256ed70@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 28 Jun 2002 15:42:57 -0400 To: Michael Mealling , "Robert H. Walter" From: Richard Shockey Subject: Re: [Enum] enumservices in new version of 2916bis Cc: enum@ietf.org In-Reply-To: <20020628145157.D24592@bailey.dscga.com> References: <5.1.0.14.2.20020628132714.0245bb28@popd.ix.netcom.com> 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 A > > > Therefore the proper expression proper would be > > > > > > NAPTR 0 0 "U" "E2U+mailto:vmail" "!^.*$!mailto:user@domain!" > > > > > > or simply > > > > > > NAPTR 0 0 "U" "E2U+mailto" "!^.*$!mailto:user@domain!" > > > > > > The transaction result is the same ..but it has the advantage of not > > > exposing that this is really a vmail box.... but again as I noted in > > > previous messages I'd like to see the input from the VPIM group first > > > on these issues. > > > > Respectfully, the transaction result is not the same. Without the service > > the application has no idea what type of communication service this NAPTR > > represents. The application only knows that it can communicate with it > > using SMTP. IMHO, the NAPTR is at best ambiguous. Now, if the service > > field is defined as > > > > "E2U+srs:mailto" (Prospective Consumer hat on) " Well tough I really don't care if your application has a problem here thats your problem not mine." ... Believe me I understand your technicial concern but I submit there are other issues involved. What this discussion about now is consumer choice and providing the option NOT to reveal underling service attributes if that is the choice of the consumer. Which argues for protocol first everything else optional. The consumer _has the option_ to reveal only the minimum subset of data necessary to complete a connection. Ambiguity here that is EXACTLY what I want ...the ability to choose. Consumer Protection ... plus it will pass the smell test with the privacy community. I know I harp on this but I really believe in this case Privacy Considerations are just as essential to the function and applicability of the protocol as Security Considerations. > > > > The expectation is that the application will somehow negotiate with the > > service using SMTP to decide on what the service will be... If both > > service and protocol are a MUST, then we have reached concensus > > and I have no opinion on the order. No I have chosen this is the way I will be communicated with and I have made a conscious decision NOT to reveal the underlying service. The service logic beneath this construct basically states ..."Here..use SMTP or dont." I will not reveal the underlying capabilities of this endpoint. You want perfect 1:1 matching between Client Applicaiton and Service End Point .. I just dont think thats possible here. >Umm.... I'm not sure in what context you're using the string 'mailto' >here but just in case: > >mailto is a URI scheme defined in RFC 2368 which only mentioned SMTP _once_ >in a caveat about making sure the SMTP 'From' address is set correctly in the >message. RFC 2368 does not define any transport system to be used. Period. >'mailto:' identifies RFC 822 addresses and messages. How you get to an >address or send a message is not defined. >Everyone: Please be _very_ careful how you use 'mailto:'. It _does NOT_ >mean what you think it means simply from your usage on a web page. Please >read RFC 2368 and RFC 2396 if this is confusing.... I apologize Ive gotten sucked into the problem myself ... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 15:58:45 2002 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 PAA18350 for ; Fri, 28 Jun 2002 15:58:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27124 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 15:59:30 -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 PAA26738; Fri, 28 Jun 2002 15:50: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 PAA26695 for ; Fri, 28 Jun 2002 15:50:23 -0400 (EDT) Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17795 for ; Fri, 28 Jun 2002 15:49:36 -0400 (EDT) content-class: urn:content-classes:message Subject: AW: [Enum] enumservices in new version of 2916bis MIME-Version: 1.0 Date: Fri, 28 Jun 2002 21:52:02 +0200 Content-Type: text/plain; charset="utf-8" Message-ID: <06CF906FE3998C4E944213062009F1620246FF@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Enum] enumservices in new version of 2916bis Thread-Index: AcIe2JA32UhQQhKGQXqIjSn/5Oc56wAAaGH4 From: "Stastny Richard" To: , "Michael Mealling" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id PAA26700 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 Comments inline: -----Ursprüngliche Nachricht----- Von: Robert H. Walter [mailto:rwalter@netnumber.com] Gesendet: Fr 28.06.2002 21:05 An: Michael Mealling Cc: enum@ietf.org Betreff: RE: [Enum] enumservices in new version of 2916bis > Umm.... I'm not sure in what context you're using the string 'mailto' > here but just in case: > > mailto is a URI scheme defined in RFC 2368 which only mentioned SMTP _once_ > in a caveat about making sure the SMTP 'From' address is set correctly in the > message. RFC 2368 does not define any transport system to be used. Period. > 'mailto:' identifies RFC 822 addresses and messages. How you get to an > address or send a message is not defined. > > Everyone: Please be _very_ careful how you use 'mailto:'. It _does NOT_ > mean what you think it means simply from your usage on a web page. Please > read RFC 2368 and RFC 2396 if this is confusing.... Agreed, the uri-scheme and protocol are different things and should not be used interchangeably... Bob Walter NetNumber, Inc. Richard Stastny replies: Ok. I have learned a lot today. For years there were given examples on how to use ENUM, especially mailto+E2U and E2U+mailto. Every dummy out there, including myself and ITU-T SG2 thought you can send an e-mail with this. Today I have heard, we all are stupid, mailto does not mean what everbody think it means and you need to add a protocol information to get this working. As a dummy MS operating system user you may click on mailto: link, MS Outlook starts, you write an e-mail and it is also received by the recipient, but this is just pure luck. I have also learned today, that a couple of very sophisticated and wise guys have defined an RFC2916 and even a 2919bis, which has been discussed for 2 years in all necessary and unnecessary standard bodies, but which cannot implemented at least in is simplest version, because at the moment not even ONE bl... ENUM service is defined. I have also learned (not only today, but since some months), that what is proposed does not work, why it does not work, Nah, you cannot do this and you cannot do that, it should be done in another way, etc. Can anybody who defined ENUM please explain to me what I shall use in a trial. What I want is at least a simple basic workable solution, for mail, tel, fax, sms and http: and I want this after Yokohama. Since I am on vacation for 2 weeks in Spain (I really need this now), I promise not to interfere (to much) any more, maybe this helps. So you have two weeks to get this sorted out. best regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 16:30:52 2002 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 QAA20178 for ; Fri, 28 Jun 2002 16:30:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA00037 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 16:31: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 QAA29066; Fri, 28 Jun 2002 16:22: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 QAA29034 for ; Fri, 28 Jun 2002 16:22:23 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19663 for ; Fri, 28 Jun 2002 16:21:35 -0400 (EDT) Received: from [193.118.205.14] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090710; Fri, 28 Jun 2002 21:22:38 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 28 Jun 2002 21:21:47 +0100 To: enum@ietf.org From: Lawrence Conroy Subject: RE: [Enum] enumservices in new version of 2916bis Cc: Michael Mealling , richard.stastny@oefeg.at 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 3:05 pm -0400 28/6/02, Robert H. Walter wrote: > > Umm.... I'm not sure in what context you're using the string 'mailto' >> here but just in case: >> >> mailto is a URI scheme defined in RFC 2368 which only mentioned SMTP _once_ >> in a caveat about making sure the SMTP 'From' address is set >>correctly in the >> message. RFC 2368 does not define any transport system to be used. Period. >> 'mailto:' identifies RFC 822 addresses and messages. How you get to an >> address or send a message is not defined. >> >> Everyone: Please be _very_ careful how you use 'mailto:'. It _does NOT_ >> mean what you think it means simply from your usage on a web page. Please >> read RFC 2368 and RFC 2396 if this is confusing.... > >Agreed, the uri-scheme and protocol are different things and should not >be used interchangeably... To which I reply: Amen to that. (In answer to Michael's question regarding implementing URL handlers ...me too !) I guess that the problem is that I'd rather like to have something implemented by the end of the summer that doesn't just have SRS as the service and sip: as the URL. I believe that I and everyone else here understands the difference between the architecture and the implementation - at least the old fogeys around here [and I still have hopes for Xanadu]. We seem to be getting to the nub here - how an end user gets to the resource with which they want to communicate is not specified in the URL. At what point did instructing the querying end user/client exactly how to connect to their intended correspondent become a core part of ENUM? In answer to the "what will it break"? question, my answer is "nothing, if ignored". Those fine OS manufacturers have provided an easy API to fire up a URL handler for "mailto:". I also have an easy API to fire up a URL handler for "tel:" (strictly, this one's via TAPI), and for "http:", and (shortly) for "sip:". The querying end user (or the defaults of a certain Redmond company) configure what protocols and programs these URLs trigger. No great pain, and we'll get something out soon. If ENUM implementors are expected to find a way to override these configurations and control the programs to run whatever protocol the registrant specifies, we might have the trials sometime before the end of 2003. My gripe is that, until this week's wheeze, there was none of this - it's all new. New and "by September 2002" don't mix. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 17:12:58 2002 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 RAA22449 for ; Fri, 28 Jun 2002 17:12:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03380 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 17:13: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 RAA02802; Fri, 28 Jun 2002 17:03: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 RAA02717 for ; Fri, 28 Jun 2002 17:03:01 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21737 for ; Fri, 28 Jun 2002 17:02:14 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5SL1LuK009542; Fri, 28 Jun 2002 17:01:21 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5SL1KfR009541; Fri, 28 Jun 2002 17:01:20 -0400 (EDT) Date: Fri, 28 Jun 2002 17:01:20 -0400 From: Michael Mealling To: Lawrence Conroy Cc: enum@ietf.org, Michael Mealling , richard.stastny@oefeg.at Subject: Re: [Enum] enumservices in new version of 2916bis Message-ID: <20020628170120.G24592@bailey.dscga.com> Reply-To: Michael Mealling References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i 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 Fri, Jun 28, 2002 at 09:21:47PM +0100, Lawrence Conroy wrote: > At 3:05 pm -0400 28/6/02, Robert H. Walter wrote: > > > Umm.... I'm not sure in what context you're using the string 'mailto' > >> here but just in case: > >> > >> mailto is a URI scheme defined in RFC 2368 which only mentioned SMTP > >> _once_ > >> in a caveat about making sure the SMTP 'From' address is set > >>correctly in the > >> message. RFC 2368 does not define any transport system to be used. > >> Period. > >> 'mailto:' identifies RFC 822 addresses and messages. How you get to an > >> address or send a message is not defined. > >> > >> Everyone: Please be _very_ careful how you use 'mailto:'. It _does NOT_ > >> mean what you think it means simply from your usage on a web page. Please > >> read RFC 2368 and RFC 2396 if this is confusing.... > > > >Agreed, the uri-scheme and protocol are different things and should not > >be used interchangeably... > > To which I reply: > Amen to that. > > (In answer to Michael's question regarding implementing URL handlers > ...me too !) > I guess that the problem is that I'd rather like to have something > implemented by the end of the summer that doesn't just have SRS as the > service and sip: as the URL. Can you describe that something? > I believe that I and everyone else here understands the difference between > the architecture and the implementation - at least the old fogeys around here > [and I still have hopes for Xanadu]. > > We seem to be getting to the nub here - how an end user gets to the > resource with which they want to communicate is not specified in the URL. Correct. It just specifies what that resource is. We still need a way to specify what method is used to talk to it. > At what point did instructing the querying end user/client exactly > how to connect to their intended correspondent become a core part of ENUM? When it became clear that simply identifying the endpoint wasn't sufficient for knowing how to interact with that resource since the protocol you use to do has a large amount of impact on what services you can express for that endpoint. > In answer to the "what will it break"? question, my answer is > "nothing, if ignored". Depending on your implementation schedule and feature list that might be sufficient for now. I assume you'll be coming out with updates? > Those fine OS manufacturers have provided an easy API to fire up a URL > handler for "mailto:". Sure. But on a very popular OS platform all that does is bring up the Outlook with a few header fields filled in. You can't really use that as a voice mail interface. I.e. if the _service_ you want is voice mail then bringing up Outlook is probably _not_ what you wanted to happen, regardless of whether or not there's a built in handler for the 'mailto' scheme on that platform. > I also have an easy API to fire up a URL handler for "tel:" > (strictly, this one's via TAPI), and for "http:", and (shortly) for "sip:". Sure. But do those APIs know what it is you're trying to _do_ with those endpoints? > The querying end user (or the defaults of a certain Redmond company) > configure what protocols and programs these URLs trigger. > No great pain, and we'll get something out soon. The Asynchronous Pluggable Protocol (bad terminology!) APIs found in urlmon and friends are great. But they're only half of the story. Before your call ever goes the actual scheme handler it goes through a security and caching policy filter that can determine whether or not your 'ftp:' URL request actually gets sent to your proxy via the HTTP protocol. If you're client has this specified then your 'sip:' url is going to get sent to the the 'http:' handler as a proxy proccess. So it isn't as clear cut as "Microsoft just gives me nifty APIs and that's all I need". There are nasy side effects when you use it if you aren't clear why your using it. > If ENUM implementors are expected to find a way to override these > configurations and control the programs to run whatever protocol the > registrant specifies, we might have the trials sometime before the > end of 2003. I'm not so sure. I think we're actually converging very quickly. We've only been having this particular discussion for 2 days. A couple of more and I think we'll have it... > My gripe is that, until this week's wheeze, there was none of this - it's > all new. New and "by September 2002" don't mix. Well, its a discussion that's been going on in fits and starts since Minneapolis. IMHO, we'll get there soon. I'll do my best to get this settled by Yokohama... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jun 28 22:28:00 2002 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 WAA03018 for ; Fri, 28 Jun 2002 22:28:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA21207 for enum-archive@odin.ietf.org; Fri, 28 Jun 2002 22:28: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 WAA21032; Fri, 28 Jun 2002 22:19: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 WAA21001 for ; Fri, 28 Jun 2002 22:19:26 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02881 for ; Fri, 28 Jun 2002 22:18:40 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id EAA14814; Sat, 29 Jun 2002 04:19:16 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id EAA19605; Sat, 29 Jun 2002 04:19:18 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Sat, 29 Jun 2002 04:18:48 +0200 Message-ID: From: Brandner Rudolf To: "'Michael Mealling'" , CONROY LAWRENCE Cc: enum@ietf.org, richard.stastny@oefeg.at Subject: AW: [Enum] enumservices in new version of 2916bis Date: Sat, 29 Jun 2002 04:18:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 WAA21002 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 Hi all, I'd like to come back to the very pressing issue: enumservice field structure. I'm with Richard Stastny on this: we really need to sort this out. Thus I'd like to ask whether we do have a (rough) consensus on servicefield = "E2U" ("-" ) [*("+" )] ["*" ] or not. [note: I think I've got the addinfo right now. If not, please let me know.] And yes, I agree that we will have to be very clear about addinfo being optional. Now on to the thread of protocols and APIs: > -----Ursprüngliche Nachricht----- > Von: Michael Mealling [mailto:michael@neonym.net] > Gesendet: Freitag, 28. Juni 2002 23:01 > An: Lawrence Conroy > Cc: enum@ietf.org; Michael Mealling; richard.stastny@oefeg.at > Betreff: Re: [Enum] enumservices in new version of 2916bis > > > On Fri, Jun 28, 2002 at 09:21:47PM +0100, Lawrence Conroy wrote: > > At 3:05 pm -0400 28/6/02, Robert H. Walter wrote: > > > > Umm.... I'm not sure in what context you're using the > string 'mailto' > > >> here but just in case: > > >> > > >> mailto is a URI scheme defined in RFC 2368 which only > mentioned SMTP > > >> _once_ > > >> in a caveat about making sure the SMTP 'From' address is set > > >>correctly in the > > >> message. RFC 2368 does not define any transport system > to be used. > > >> Period. > > >> 'mailto:' identifies RFC 822 addresses and messages. How > you get to an > > >> address or send a message is not defined. > > >> > > >> Everyone: Please be _very_ careful how you use > 'mailto:'. It _does NOT_ > > >> mean what you think it means simply from your usage on a > web page. Please > > >> read RFC 2368 and RFC 2396 if this is confusing.... > > > > > >Agreed, the uri-scheme and protocol are different things > and should not > > >be used interchangeably... > > > > To which I reply: > > Amen to that. > > > > (In answer to Michael's question regarding implementing URL > handlers > > ...me too !) > > I guess that the problem is that I'd rather like to have something > > implemented by the end of the summer that doesn't just have > SRS as the > > service and sip: as the URL. > > Can you describe that something? > Hmmm, I'm not sure, whether this discussion is helpful on our main issue: enumservice field structure. > > I believe that I and everyone else here understands the > difference between > > the architecture and the implementation - at least the old > fogeys around here > > [and I still have hopes for Xanadu]. > > > > We seem to be getting to the nub here - how an end user gets to the > > resource with which they want to communicate is not > specified in the URL. > > Correct. It just specifies what that resource is. We still need a way > to specify what method is used to talk to it. > Sorry, but I think no, we don't as far as protocols are concerned. Today, I can send an SMS to an e-mail address. My mobile phone might not get a very popular e-mail client any time soon, but it might get ENUM-enabled. If my mobile phone gets a mailto: it might fire up the SMS UI to enter the message, prepends the e-mail address and sends it to a gateway of choice, which forwards it as an e-mail to the reciepient. If you are going to specify protocols here you are opening a whole new can of worms. The only thing I need to know is how the receiving end can be reached. How the communication is started with is a complete different story. For instance, if you are specifying SMTP as the protocol of choice, I won't be able to send a message to an e-mail address from my mobile phone any more until it get's STMP or at least an e-mail client. > > At what point did instructing the querying end user/client exactly > > how to connect to their intended correspondent become a > core part of ENUM? > > When it became clear that simply identifying the endpoint > wasn't sufficient > for knowing how to interact with that resource since the > protocol you use > to do has a large amount of impact on what services you can > express for > that endpoint. > Define a default behaviour of the client for a default protocol. However, the protocol used at the recieving side does not necessarily be the same as on the sender side. ENUM is about how a recieving side can be contacted. > > In answer to the "what will it break"? question, my answer is > > "nothing, if ignored". > > Depending on your implementation schedule and feature list that might > be sufficient for now. I assume you'll be coming out with updates? > You're not? (sorry, couldn't resist ;^) > > Those fine OS manufacturers have provided an easy API to > fire up a URL > > handler for "mailto:". > > Sure. But on a very popular OS platform all that does is bring up the > Outlook with a few header fields filled in. You can't really > use that as > a voice mail interface. I.e. if the _service_ you want is voice mail > then bringing up Outlook is probably _not_ what you wanted to happen, > regardless of whether or not there's a built in handler for > the 'mailto' > scheme on that platform. > As for that very popular OS platform: is it ENUM enabled? If you are looking for a vmail service and start an application which is not capable of dealing with voice.... er... what's wrong here? Maybe there need to be some application to glue together. In this particular case, looking for a vmail it might be of help first start some voice recording software and then send it using that very popular mailer until that very popular software company gets its very popular mailer ENUM-enabled. > > I also have an easy API to fire up a URL handler for "tel:" > > (strictly, this one's via TAPI), and for "http:", and > (shortly) for "sip:". > > Sure. But do those APIs know what it is you're trying to _do_ with > those endpoints? > Maybe I am off some miles here, but I think that the APIs do not need to know. An ENUM client software should know about the features ENUM enables and start the appropriate pieces of software already being there. > > The querying end user (or the defaults of a certain Redmond company) > > configure what protocols and programs these URLs trigger. > > No great pain, and we'll get something out soon. > > The Asynchronous Pluggable Protocol (bad terminology!) APIs found in > urlmon and friends are great. But they're only half of the > story. Before > your call ever goes the actual scheme handler it goes through a > security and caching policy filter that can determine whether or not > your 'ftp:' URL request actually gets sent to your proxy via the HTTP > protocol. If you're client has this specified then your 'sip:' > url is going to get sent to the the 'http:' handler as a > proxy proccess. > So it isn't as clear cut as "Microsoft just gives me nifty > APIs and that's > all I need". There are nasy side effects when you use it if you aren't > clear why your using it. > Is Microsoft's software ENUM enabled already? If not, maybe they just up the ante in changing APIs and their semantics a little bit....... Sorry for being somehow sarcastic here. I see that there are problems with actual APIs. However, I do not see any immediate link to the enumservice field. The trials will show how easy or complicated it is to implement useful ENUM clients. APIs might change after getting some experice. > > If ENUM implementors are expected to find a way to override these > > configurations and control the programs to run whatever > protocol the > > registrant specifies, we might have the trials sometime before the > > end of 2003. > > I'm not so sure. I think we're actually converging very quickly. > We've only been having this particular discussion for 2 days. A couple > of more and I think we'll have it... > > > My gripe is that, until this week's wheeze, there was none > of this - it's > > all new. New and "by September 2002" don't mix. > > Well, its a discussion that's been going on in fits and starts since > Minneapolis. IMHO, we'll get there soon. I'll do my best to get this > settled by Yokohama... > I'm with you here. .... and if not, I suggest that we discuss this in Yokohama over a beer or two..... Rudi ------[snipp]----- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Jun 29 03:13:11 2002 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 DAA18827 for ; Sat, 29 Jun 2002 03:13:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA10496 for enum-archive@odin.ietf.org; Sat, 29 Jun 2002 03:13: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 DAA10168; Sat, 29 Jun 2002 03:04: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 DAA10140 for ; Sat, 29 Jun 2002 03:04:33 -0400 (EDT) Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18674 for ; Sat, 29 Jun 2002 03:03:46 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Sat, 29 Jun 2002 09:06:14 +0200 Message-ID: <06CF906FE3998C4E944213062009F162024700@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: ENUM broken? Thread-Index: AcIfO3TQPthcCAR3Q5iD7A7ZSJ4kvg== From: "Stastny Richard" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id DAA10141 Subject: [Enum] ENUM broken? 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 Hi folks, before I start: of course (I think) I know the difference between an URI and a protocol (maybe I even know the difference between a phone number, a name and an address ;-) If it is necessary to include the protocol how the endpoint can be reached in the NAPTR, then first, all examples sofar in RFC2916 and also 2916bis have been totally misleading, and secondly, and more seriously: ENUM cannot be implemented as intended, because most administrative models discussed in the last 2 years may not work! ENUM is an End User Service, so the data (at least the URI) has to come from the user. I cannot expect the ENUM End User to provision the NAPTR and especially the protocol correctly. So the Tier 2 Nameserver provider has to to do it. The tier 2 nameserver provider can only do it, if he is also the application service provider (ASP), and he may do this for all NAPTRs only, of he is the ASP of all services provided, and since we have may have phone services also, the T2 Nameserver provider and ASP has to be the TSP. This is not exceptable (except maybe in France;-). This would imply that the most commonly agreed upon (in US and Europe) administrative model would not work. This model stated that it must be possible that the T2 Name server provider, the ASP and the TSP are separate entities. So ENUM cannot work in this way and I fully agree with Rudi, that the protocol used by the reciepient is meaningless for the originator and therefore also has no value in ENUM. The originator either by himself or by a service provider will use HIS means to reach the URI. The best example is the tel: URI: In the same way I do not need to know the protocol of the other end if I make a phone call, I do not need to know a protocol if a tel URI is present (I may need to know the services). It is up to the originating user in which way and how he is establishing communication to the destination (he may use sip or h323 or a dialler or whatever). He may even look at the URI and make a phone call with his mobile phone. Maybe we have a serious misunderstanding of the useability of ENUM here, but if am am wrong, I mayself and also a lot of other people in ITU-T, ETSI and other bodies have wasted a lot of their time with a badly designed or explained system from the IETF. It is urgently necessary to get the discussion back on track again. best regards Richard PS: an e-mail address is a name, and a phone number may be a name or an address;-) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum