From mailnull@www1.ietf.org Tue Oct 1 07:37:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09446 for ; Tue, 1 Oct 2002 07:37:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91BcYW21493 for enum-archive@odin.ietf.org; Tue, 1 Oct 2002 07:38:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91BcWv21488; Tue, 1 Oct 2002 07:38:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Bbav21034 for ; Tue, 1 Oct 2002 07:37:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09128; Tue, 1 Oct 2002 07:35:35 -0400 (EDT) Message-Id: <200210011135.HAA09128@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, 01 Oct 2002 07:35:35 -0400 Subject: [Enum] I-D ACTION:draft-nyckelgard-uri-lookup-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNS look-up for services related to a URI Author(s) : S. Nyckelgard Filename : draft-nyckelgard-uri-lookup-00.txt Pages : 3 Date : 2002-9-30 This memo is an extension to ENUM RFC 2916 [3]. RFC 2916 describes how to utilize DNS as a look-up mechanism for services related to a telephone number. This memo describes how to utilize the same look- up mechanism for personal URIs (user@domain). Specifically, it defines how to translate personal URIs to DNS names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nyckelgard-uri-lookup-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-nyckelgard-uri-lookup-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-nyckelgard-uri-lookup-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: <2002-9-30144528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nyckelgard-uri-lookup-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nyckelgard-uri-lookup-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-30144528.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Oct 1 09:40:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16037 for ; Tue, 1 Oct 2002 09:40:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91Dfxg21647 for enum-archive@odin.ietf.org; Tue, 1 Oct 2002 09:41:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Dfvv21642; Tue, 1 Oct 2002 09:41:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Depv21244 for ; Tue, 1 Oct 2002 09:40:51 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15873 for ; Tue, 1 Oct 2002 09:38:46 -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 g91DcfTj006978 for ; Tue, 1 Oct 2002 09:38:47 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g91DcZC7006977 for enum@ietf.org; Tue, 1 Oct 2002 09:38:35 -0400 (EDT) Date: Tue, 1 Oct 2002 09:38:34 -0400 From: Michael Mealling To: enum@ietf.org Subject: Re: [Enum] I-D ACTION:draft-nyckelgard-uri-lookup-00.txt Message-ID: <20021001093834.F3017@bailey.dscga.com> Reply-To: Michael Mealling References: <200210011135.HAA09128@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210011135.HAA09128@ietf.org> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This draft covers a service that is already covered in draft-ietf-urn-uri-res-ddds-07.txt which is a product of the URN working group. Could the authors please let us know how this suggestion is better than the one discussed in draft-ietf-urn-uri-res-ddds-07.txt which is generalized for all URI schemes (of which the mailto:user@domain is a trivial case of). -MM On Tue, Oct 01, 2002 at 07:35:35AM -0400, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : DNS look-up for services related to a URI > Author(s) : S. Nyckelgard > Filename : draft-nyckelgard-uri-lookup-00.txt > Pages : 3 > Date : 2002-9-30 > > This memo is an extension to ENUM RFC 2916 [3]. RFC 2916 describes > how to utilize DNS as a look-up mechanism for services related to a > telephone number. This memo describes how to utilize the same look- > up mechanism for personal URIs (user@domain). Specifically, it > defines how to translate personal URIs to DNS names. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nyckelgard-uri-lookup-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-nyckelgard-uri-lookup-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-nyckelgard-uri-lookup-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. -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Oct 8 14:10:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24575 for ; Tue, 8 Oct 2002 14:10:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g98ICFt20925 for enum-archive@odin.ietf.org; Tue, 8 Oct 2002 14:12:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98IBvv20910; Tue, 8 Oct 2002 14:11:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98GWZv15046 for ; Tue, 8 Oct 2002 12:32:35 -0400 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20726 for ; Tue, 8 Oct 2002 12:30:26 -0400 (EDT) Received: from dick.shockey.us (external.lecstar.net [65.243.117.2] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA20301 for ; Tue, 8 Oct 2002 09:32:30 -0700 Message-Id: <5.1.0.14.2.20021008122929.03ee8e28@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 08 Oct 2002 12:32:28 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Agenda for ENUM WG at IETF 55 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Well its that time again folks ..we have already had some submissions and I'm assuming we should see 2916bis shortly I'd to start start blocking time ASAP. If you have a new draft coming remember the cut off date is October 28 Monday 1130-1300 Break 1300-1500 Afternoon Sessions I APP opes Open Pluggable Edge Services WG APP trade Internet Open Trading Protocol WG INT pana Protocol for carrying Authentication for Network Access WG OPS mboned MBONE Deployment WG OPS rmonmib Remote Network Monitoring WG TSV enum Telephone Number Mapping WG TSV seamoby Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting WG >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 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 mailnull@www1.ietf.org Tue Oct 8 14:27:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25200 for ; Tue, 8 Oct 2002 14:27:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g98IT6M21714 for enum-archive@odin.ietf.org; Tue, 8 Oct 2002 14:29:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98IT5v21709; Tue, 8 Oct 2002 14:29:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98ISmv21662 for ; Tue, 8 Oct 2002 14:28:48 -0400 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25162 for ; Tue, 8 Oct 2002 14:26:37 -0400 (EDT) Received: from dick.shockey.us (external.lecstar.net [65.243.119.158] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA25515 for ; Tue, 8 Oct 2002 11:28:42 -0700 Message-Id: <5.1.0.14.2.20021008122929.03ee8e28@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 08 Oct 2002 14:28:17 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Agenda for ENUM WG at IETF 55 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Well its that time again folks ..we have already had some submissions and I'm assuming we should see 2916bis shortly I'd to start start blocking time ASAP. If you have a new draft coming remember the cut off date is October 28 Monday 1130-1300 Break 1300-1500 Afternoon Sessions I APP opes Open Pluggable Edge Services WG APP trade Internet Open Trading Protocol WG INT pana Protocol for carrying Authentication for Network Access WG OPS mboned MBONE Deployment WG OPS rmonmib Remote Network Monitoring WG TSV enum Telephone Number Mapping WG TSV seamoby Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting WG >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 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 mailnull@www1.ietf.org Wed Oct 16 10:36:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01098 for ; Wed, 16 Oct 2002 10:36:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GEcS806426 for enum-archive@odin.ietf.org; Wed, 16 Oct 2002 10:38:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GEcGv06416; Wed, 16 Oct 2002 10:38:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GEL3v04595 for ; Wed, 16 Oct 2002 10:21:03 -0400 Received: from almso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00145 for ; Wed, 16 Oct 2002 10:18:48 -0400 (EDT) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g9GDwhXK015031 for ; Wed, 16 Oct 2002 10:20:56 -0400 (EDT) Received: from OCCLUST03EVS1.ugd.att.com (135.71.164.10) by attrh3i.attrh.att.com (6.5.019) id 3D8B5605007406EC; Wed, 16 Oct 2002 10:20:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 16 Oct 2002 10:20:55 -0400 Message-ID: Thread-Topic: Draft IETF ENUM usage scenarios Thread-Index: AcJ09RAhJFr3vLSWSPO6pO/VorblSwAKDuDg From: "Lind, Steven D, ALASO" To: "Keats, Evan" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9GEL3v04596 Subject: [Enum] RE: Draft IETF ENUM usage scenarios Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Evan, No, tht's not a scenario I/we have considered. It sounds like an interesting scenario and I'd like to think about it some. The ENUM WG is starting out with the premise that one only knows an E.164 telephone number instead of an email address. One could imagine that instead of a number, you could use a unique FQDN, e.g., steven.d.lind.name, that could point to the various NAPTR records. That would require the application software to behave differently than looking up a telephone number. And the problem with uniqueness of the names would not guarantee that you've reached the right steven.d.lind (I know of several Steven Linds, not sure about those with same middle initial). Steve -------------------------------------------------------------------------------- Steven D. Lind Tel: 973-236-6787 180 Park Avenue, Bldg. 2 Fax: 973-236-6453 Room 2G25 sdlind@att.com Florham Park, NJ 07932 -------------------------------------------------------------------------------- -----Original Message----- From: Keats, Evan [mailto:evan.keats@nz.unisys.com] Sent: Wednesday, October 16, 2002 5:17 AM To: Lind, Steven D, ALASO Subject: Draft IETF ENUM usage scenarios I have just read your draft document with great interest. I am interested in the following IP origination - PSTN termination scenario Jenny Jones with her SIP client wants to call Evan Keats. Knowing that my email address is evan.keats@nz.unisys.com, she tries sip:evan.keats@nz.unisys.com. However, rather than answering the call with a SIP client, I would like to take the call on my landline [one phone on my desk is quite enough :) ] I have been trying to fathom out how we could use ENUM to allow me translate sip:evan.keats@nz.unisys.com to 6.4.4.4.6.2.2.0.5.5.e164.arpa, but have not made tangible progress. Is this a scenario you have considered, or would consider for you document ? Or am I missing something ridiculously obvious ? Thanks. Regards, Evan Keats Unisys Unisys New Zealand Ph: 64-4-462 2055 Fax: 64-4-462 2127 Net2: 848 2055 evan.keats@nz.unisys.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Oct 16 13:20:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06559 for ; Wed, 16 Oct 2002 13:20:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GHMhk16483 for enum-archive@odin.ietf.org; Wed, 16 Oct 2002 13:22:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GHMdv16474; Wed, 16 Oct 2002 13:22:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GGecv14007 for ; Wed, 16 Oct 2002 12:40:38 -0400 Received: from ierw.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05137 for ; Wed, 16 Oct 2002 12:38:23 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03063 for ; Wed, 16 Oct 2002 12:38:22 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03053 for ; Wed, 16 Oct 2002 12:38:22 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Enum] RE: Draft IETF ENUM usage scenarios Date: Wed, 16 Oct 2002 10:40:32 -0600 Message-ID: Thread-Topic: Draft IETF ENUM usage scenarios Thread-Index: AcJ09RAhJFr3vLSWSPO6pO/VorblSwAKDuDgAATikYA= From: "Zmolek, Andrew (Andy)" To: "Lind, Steven D, ALASO" , "Keats, Evan" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9GGecv14008 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit There are several possible methods of going to a PSTN/E.164 number from a SIP address, but in general ENUM has nothing to do with this: - Your home SIP redirect server could provide a tel: URI to the SIP originator and effectively force it to find a PSTN gateway to complete the call (not sure if this is "legal" in SIP, though) - Your home SIP proxy/gateway could complete the SIP session by transparently gatewaying the call over the PSTN (Or PBX system, which is how my SIP address rings my regular desk phone) - You could create a registry similar to enum that maps a SIP URI to an E.164 address The latter requires a lot of agreement among many parties (vendors, developers, end-users, etc.) and would not happen very soon. But gatewaying SIP calls back to the PSTN or private PBX or POTS lines is easy enough to do today. --Andy Zmolek Senior Security Consultant Network Consulting Services Avaya Inc. zmolek@avaya.com +1 720 444 4001 sip:zmolek@avaya.com > -----Original Message----- > From: Lind, Steven D, ALASO [mailto:sdlind@att.com] > Sent: Wednesday, October 16, 2002 8:21 AM > To: Keats, Evan > Cc: enum@ietf.org > Subject: [Enum] RE: Draft IETF ENUM usage scenarios > > > Evan, > > No, tht's not a scenario I/we have considered. It sounds like > an interesting scenario and I'd like to think about it some. > > The ENUM WG is starting out with the premise that one only > knows an E.164 telephone number instead of an email address. > One could imagine that instead of a number, you could use a > unique FQDN, e.g., steven.d.lind.name, that could point to > the various NAPTR records. That would require the application > software to behave differently than looking up a telephone > number. And the problem with uniqueness of the names would > not guarantee that you've reached the right steven.d.lind (I > know of several Steven Linds, not sure about those with same > middle initial). > > Steve > > -------------------------------------------------------------- > ------------------ > Steven D. Lind Tel: 973-236-6787 > 180 Park Avenue, Bldg. 2 Fax: 973-236-6453 > Room 2G25 sdlind@att.com > Florham Park, NJ 07932 > -------------------------------------------------------------- > ------------------ > > > -----Original Message----- > From: Keats, Evan [mailto:evan.keats@nz.unisys.com] > Sent: Wednesday, October 16, 2002 5:17 AM > To: Lind, Steven D, ALASO > Subject: Draft IETF ENUM usage scenarios > > > > I have just read your draft document with great interest. > > I am interested in the following IP origination - PSTN > termination scenario > > Jenny Jones with her SIP client wants to call Evan Keats. > Knowing that my > email address is evan.keats@nz.unisys.com, she tries > sip:evan.keats@nz.unisys.com. > > However, rather than answering the call with a SIP client, I > would like to > take the call on my landline [one phone on my desk is quite > enough :) ] > > I have been trying to fathom out how we could use ENUM to > allow me translate > sip:evan.keats@nz.unisys.com to > 6.4.4.4.6.2.2.0.5.5.e164.arpa, but have not > made tangible progress. > > Is this a scenario you have considered, or would consider for > you document ? > > Or am I missing something ridiculously obvious ? > > Thanks. > > Regards, > Evan Keats > > Unisys > Unisys New Zealand > Ph: 64-4-462 2055 > Fax: 64-4-462 2127 > Net2: 848 2055 > evan.keats@nz.unisys.com > > > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Oct 16 14:08:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07804 for ; Wed, 16 Oct 2002 14:08:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GIAZ119945 for enum-archive@odin.ietf.org; Wed, 16 Oct 2002 14:10:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GIAXv19935; Wed, 16 Oct 2002 14:10:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GI9Zv19811 for ; Wed, 16 Oct 2002 14:09:35 -0400 Received: from bab5.dscga.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07715 for ; Wed, 16 Oct 2002 14:07:20 -0400 (EDT) Received: from mmealling (usrppp4.dscga.com [207.120.28.133]) by bab5.dscga.com (8.11.0/8.11.0) with SMTP id g9GI7xQ16429; Wed, 16 Oct 2002 14:07:59 -0400 Message-ID: <013801c2753e$65d33d80$850b4ec6@netsol.com> From: "Michael Mealling" To: "Zmolek, Andrew \(Andy\)" , "Lind, Steven D, ALASO" , "Keats, Evan" Cc: References: Subject: Re: [Enum] RE: Draft IETF ENUM usage scenarios Date: Wed, 16 Oct 2002 14:03:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Andrew Zmolek said this: > There are several possible methods of going to a PSTN/E.164 number from a SIP address, > but in general ENUM has nothing to do with this: But the DDDS and the URI Resolution application in RFC 3404 (yes the DDDS documents now have RFC #s!) does.... > - Your home SIP redirect server could provide a tel: URI to the SIP originator and effectively > force it to find a PSTN gateway to complete the call (not sure if this is "legal" in SIP, though) > > - Your home SIP proxy/gateway could complete the SIP session by transparently gatewaying > the call over the PSTN (Or PBX system, which is how my SIP address rings my regular desk > phone) Both of these assume that a SIP server will answer for the given SIP address. What happens when I have a SIP address and no server responds? It would be nice is there was a service that could turn a SIP address into a tel: URL without a SIP server even being involved. > - You could create a registry similar to enum that maps a SIP URI to an E.164 address This is what RFC 3404 does. It takes _any_ URI and looks up the deconstruction rules for how to find an authoritative server for it. I.e. the NAPTR record for sip.uri.arpa would look like this: sip.uri.arpa IN NAPTR 0 0 "" "" "!^sip:(.*)@(.*)$!/2!" . Which says, "go ask the domain-name in that address for a NAPTR record that can tell me if a server can answer questions about this URI". One of the obvious questions would be: "since a SIP server isn't responding, what should I do to contact that user?" and the result would be a tel: URL, or an error message sayign what happened, or a redirect to another sip address, etc. > The latter requires a lot of agreement among many parties (vendors, developers, > end-users, etc.) and would not happen very soon. But gatewaying SIP calls back to the > PSTN or private PBX or POTS lines is easy enough to do today. All that needs to be done is register the NAPTR record for the 'sip' URI scheme in the uri.arpa zone.... -MM > > -----Original Message----- > > From: Lind, Steven D, ALASO [mailto:sdlind@att.com] > > Sent: Wednesday, October 16, 2002 8:21 AM > > To: Keats, Evan > > Cc: enum@ietf.org > > Subject: [Enum] RE: Draft IETF ENUM usage scenarios > > > > > > Evan, > > > > No, tht's not a scenario I/we have considered. It sounds like > > an interesting scenario and I'd like to think about it some. > > > > The ENUM WG is starting out with the premise that one only > > knows an E.164 telephone number instead of an email address. > > One could imagine that instead of a number, you could use a > > unique FQDN, e.g., steven.d.lind.name, that could point to > > the various NAPTR records. That would require the application > > software to behave differently than looking up a telephone > > number. And the problem with uniqueness of the names would > > not guarantee that you've reached the right steven.d.lind (I > > know of several Steven Linds, not sure about those with same > > middle initial). > > > > Steve > > > > -------------------------------------------------------------- > > ------------------ > > Steven D. Lind Tel: 973-236-6787 > > 180 Park Avenue, Bldg. 2 Fax: 973-236-6453 > > Room 2G25 sdlind@att.com > > Florham Park, NJ 07932 > > -------------------------------------------------------------- > > ------------------ > > > > > > -----Original Message----- > > From: Keats, Evan [mailto:evan.keats@nz.unisys.com] > > Sent: Wednesday, October 16, 2002 5:17 AM > > To: Lind, Steven D, ALASO > > Subject: Draft IETF ENUM usage scenarios > > > > > > > > I have just read your draft document with great interest. > > > > I am interested in the following IP origination - PSTN > > termination scenario > > > > Jenny Jones with her SIP client wants to call Evan Keats. > > Knowing that my > > email address is evan.keats@nz.unisys.com, she tries > > sip:evan.keats@nz.unisys.com. > > > > However, rather than answering the call with a SIP client, I > > would like to > > take the call on my landline [one phone on my desk is quite > > enough :) ] > > > > I have been trying to fathom out how we could use ENUM to > > allow me translate > > sip:evan.keats@nz.unisys.com to > > 6.4.4.4.6.2.2.0.5.5.e164.arpa, but have not > > made tangible progress. > > > > Is this a scenario you have considered, or would consider for > > you document ? > > > > Or am I missing something ridiculously obvious ? > > > > Thanks. > > > > Regards, > > Evan Keats > > > > Unisys > > Unisys New Zealand > > Ph: 64-4-462 2055 > > Fax: 64-4-462 2127 > > Net2: 848 2055 > > evan.keats@nz.unisys.com > > > > > > _______________________________________________ > > 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 mailnull@www1.ietf.org Wed Oct 16 16:21:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11121 for ; Wed, 16 Oct 2002 16:21:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GKN1527445 for enum-archive@odin.ietf.org; Wed, 16 Oct 2002 16:23:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GKMrv27437; Wed, 16 Oct 2002 16:22:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GKLbv27367 for ; Wed, 16 Oct 2002 16:21:37 -0400 Received: from padda.telia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11039 for ; Wed, 16 Oct 2002 16:19:19 -0400 (EDT) Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g9GKLI442235; Wed, 16 Oct 2002 22:21:18 +0200 (CEST) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Wed, 16 Oct 2002 22:21:18 +0200 (CEST) From: Mats Dufberg To: Michael Mealling cc: Subject: Re: [Enum] RE: Draft IETF ENUM usage scenarios In-Reply-To: <013801c2753e$65d33d80$850b4ec6@netsol.com> Message-ID: <20021016221708.B35220-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8BIT On Oct 16, 2002, 14:03 (-0400) Michael Mealling wrote: > But the DDDS and the URI Resolution application in RFC 3404 (yes the > DDDS documents now have RFC #s!) does.... That RFC does not exist according to the IETF RFC repository. Could you check the data? Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/Nwi +46 8 71 354 38 Mårbackagatan 11, hus L +46 70 258 2588 SE-123 86 Farsta ---------------------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Oct 16 16:57:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12144 for ; Wed, 16 Oct 2002 16:57:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GKxhM29296 for enum-archive@odin.ietf.org; Wed, 16 Oct 2002 16:59:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GKxfv29291; Wed, 16 Oct 2002 16:59:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GKwZv29266 for ; Wed, 16 Oct 2002 16:58:35 -0400 Received: from bab5.dscga.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12011 for ; Wed, 16 Oct 2002 16:56:18 -0400 (EDT) Received: from mmealling (usrppp4.dscga.com [207.120.28.133]) by bab5.dscga.com (8.11.0/8.11.0) with SMTP id g9GKv0Q32644; Wed, 16 Oct 2002 16:57:00 -0400 Message-ID: <019c01c27556$023cee20$850b4ec6@netsol.com> From: "Michael Mealling" To: "Mats Dufberg" Cc: References: <20021016221708.B35220-100000@padda.telia.net> Subject: Re: [Enum] RE: Draft IETF ENUM usage scenarios Date: Wed, 16 Oct 2002 16:52:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mats Dufberg said this: > On Oct 16, 2002, 14:03 (-0400) Michael Mealling wrote: > > > But the DDDS and the URI Resolution application in RFC 3404 (yes the > > DDDS documents now have RFC #s!) does.... > > That RFC does not exist according to the IETF RFC repository. Could you > check the data? I was a little premature. ;-) They should be appearing shortly. In the meantime the draft version is here: http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-07.txt -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Oct 16 17:30:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12705 for ; Wed, 16 Oct 2002 17:30:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GLVpX31457 for enum-archive@odin.ietf.org; Wed, 16 Oct 2002 17:31:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GLVmv31452; Wed, 16 Oct 2002 17:31:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GLUCv31375 for ; Wed, 16 Oct 2002 17:30:12 -0400 Received: from padda.telia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12681 for ; Wed, 16 Oct 2002 17:27:53 -0400 (EDT) Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g9GLU2o42332; Wed, 16 Oct 2002 23:30:02 +0200 (CEST) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Wed, 16 Oct 2002 23:30:02 +0200 (CEST) From: Mats Dufberg To: "Lind, Steven D, ALASO" cc: Subject: Re: [Enum] RE: Draft IETF ENUM usage scenarios In-Reply-To: Message-ID: <20021016232135.B35220-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8BIT On Oct 16, 2002, 10:20 (-0400) Lind, Steven D, ALASO wrote: > The ENUM WG is starting out with the premise that one only knows an > E.164 telephone number instead of an email address. One could imagine > that instead of a number, you could use a unique FQDN, e.g., > steven.d.lind.name, that could point to the various NAPTR records. > That would require the application software to behave differently than > looking up a telephone number. And the problem with uniqueness of the > names would not guarantee that you've reached the right steven.d.lind > (I know of several Steven Linds, not sure about those with same middle > initial). I don't think that we should try to force everything into DNS. There is already a service responsible for mail addresses -- mail service. To me it seems simpler to update the SMTP protocol by adding a new command, say, INFO, to the nameserver in charge of the maildomain telia.net according to the MX record. INFO dufberg@telia.net which would or could return a list of URL:s for that address, or maybe a referal to another SMTP server holding the data. Mailservers know about mail addresses. In order to force mailaddresses into DNS we would have to invent a conversion from mailaddress into domain. The allowed characters in the mailbox part is different from the characters that can normally be used in DNS. The mailbox part is case sensitive. Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/Nwi +46 8 71 354 38 Mårbackagatan 11, hus L +46 70 258 2588 SE-123 86 Farsta ---------------------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Oct 17 04:32:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03688 for ; Thu, 17 Oct 2002 04:32:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9H8Y3706484 for enum-archive@odin.ietf.org; Thu, 17 Oct 2002 04:34:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H8Xuv06473; Thu, 17 Oct 2002 04:33:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H8Wvv06408 for ; Thu, 17 Oct 2002 04:32:57 -0400 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03618 for ; Thu, 17 Oct 2002 04:30:34 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Oct 2002 10:35:35 +0200 Message-ID: <06CF906FE3998C4E944213062009F162024841@oefeg-s02.oefeg.loc> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Reverse ENUM Thread-Index: AcJ1QD7Ov2vuHFUwTeuUUu9OvXVvJgAdDvVg From: "Stastny Richard" To: "Michael Mealling" , "Zmolek, Andrew (Andy)" , "Lind, Steven D, ALASO" , "Keats, Evan" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9H8Wwv06409 Subject: [Enum] Reverse ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi MM, Michael Mealling wrote: > > This is what RFC 3404 does. It takes _any_ URI and looks up > the deconstruction rules for how to find an authoritative > server for it. I.e. the NAPTR record for sip.uri.arpa would > look like this: > > sip.uri.arpa IN NAPTR 0 0 "" "" > "!^sip:(.*)@(.*)$!/2!" . > > Which says, "go ask the domain-name in that address for a > NAPTR record that can tell me if a server can answer > questions about this URI". One of the obvious questions would > be: "since a SIP server isn't responding, what should I do to > contact that user?" and the result would be a tel: URL, or an > error message sayign what happened, or a redirect to another > sip address, etc. > At the last Pulver Conference in Atlanta VON Fall2002 the idea of "Reverse ENUM" was discussed at various places. Even Vint Cerf mentioned it in his speech. BTW, Vint Cerf talked about 10 min about the importance of ENUM and Rich nearly got a heart-attack because he had no voice-recorder on ;-) The principle of "Reverse ENUM" should be, that in the same way you use a client querying for an E.164 Number in the format +1234xxx you may use the same client entering user@foo.bar. The idea is, that in the domain foo.bar somewhere a NAPTR? is stored pointing to the ENUM entry for the phone number (e.g. with a tel: or enum: URI). The user would always get the same information regardless if he is entering either the +431xxx or the user@foo.bar. One simple approach was (as proposed by Rich et.al) to store the NAPTRs? by convention in subdomains user.at.foo.bar of the domain foo.bar. A more sophisticated approach may retrieve the "user" part with a ldap pointer from the mail or sip server. Michael, since I do not fully understand your example and also your (soon to come) RFC3404, (I tried, but it gave me a headache) could you please elaborate more on your proposal, to enlighten me ;-) Best regards Richard Stastny _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Oct 17 09:25:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10140 for ; Thu, 17 Oct 2002 09:25:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HDQqI22953 for enum-archive@odin.ietf.org; Thu, 17 Oct 2002 09:26:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HDQnv22948; Thu, 17 Oct 2002 09:26:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HDPrv22881 for ; Thu, 17 Oct 2002 09:25:53 -0400 Received: from bab5.dscga.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10043 for ; Thu, 17 Oct 2002 09:23:38 -0400 (EDT) Received: from mmealling (usrppp0a.dscga.com [207.120.28.175]) by bab5.dscga.com (8.11.0/8.11.0) with SMTP id g9HDNbQ20961; Thu, 17 Oct 2002 09:23:37 -0400 Message-ID: <006b01c275e0$83b33880$850b4ec6@netsol.com> From: "Michael Mealling" To: "Stastny Richard" , "Zmolek, Andrew \(Andy\)" , "Lind, Steven D, ALASO" , "Keats, Evan" Cc: References: <06CF906FE3998C4E944213062009F162024841@oefeg-s02.oefeg.loc> Subject: Re: [Enum] Reverse ENUM Date: Thu, 17 Oct 2002 09:24:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit (loooong....) Richard Stastny said this: > Michael Mealling wrote: > > This is what RFC 3404 does. It takes _any_ URI and looks up > > the deconstruction rules for how to find an authoritative > > server for it. I.e. the NAPTR record for sip.uri.arpa would > > look like this: > > > > sip.uri.arpa IN NAPTR 0 0 "" "" > > "!^sip:(.*)@(.*)$!/2!" . > > > > Which says, "go ask the domain-name in that address for a > > NAPTR record that can tell me if a server can answer > > questions about this URI". One of the obvious questions would > > be: "since a SIP server isn't responding, what should I do to > > contact that user?" and the result would be a tel: URL, or an > > error message sayign what happened, or a redirect to another > > sip address, etc. > > The principle of "Reverse ENUM" should be, that in the same way > you use a client querying for an E.164 Number in the format +1234xxx > you may use the same client entering user@foo.bar. The idea is, > that in the domain foo.bar somewhere a NAPTR? is stored pointing > to the ENUM entry for the phone number (e.g. with a tel: or enum: URI). Correct. > The user would always get the same information regardless if he > is entering either the +431xxx or the user@foo.bar. One simple > approach was (as proposed by Rich et.al) to store the NAPTRs? > by convention in subdomains user.at.foo.bar of the domain foo.bar. > A more sophisticated approach may retrieve the "user" part with a > ldap pointer from the mail or sip server. That is what RFC 3404 (will) say: that there is a NAPTR or series of NAPTRs for the right hand side of the sip/email address. Those NAPTR records will point you to one or more services that can answer questions about the left hand side of the address. Some have suggested LDAP as you have. I prefer something like what the RESCAP working group was trying to do. The trick of turning the @ into an 'at' domain causes the number of NAPTR records in the zone to equal the number of users which causes there to be a huge number of unneeded DNS records (i.e. _Everyone_ in your company would have a NAPTR record instead of every phone). > Michael, since I do not fully understand your example and also your > (soon to come) RFC3404, (I tried, but it gave me a headache) > could you please elaborate more on your proposal, to enlighten me ;-) I'll run through a more typical RFC 3404 example and then do a SIP example: Let's say you want to send me a document but you don't know whether or not I prefer postscript or PDF. You have my email address so you turn that email address into a URI by just sticking 'mailto:' in the front (e.g. mailto:michael@neonym.net). Now, your uber-DDDS tool does a NAPTR query for 'mailto.uri.arpa' (uri.arpa == e164.arpa but for URIs). One NAPTR record comes back that has a rewrite rule that essentially says to take the domain-name portion of the email address and use that to go find more NAPTR records (remember the "non-terminal NAPTR" discussion we had a month or so ago?). So, the client goes off and requests NAPTR records for "neonym.net". It recieves a couple of them but one in particular looks like this: 0 0 "u" "ldap+I2C" "!^mailto:.*$!ldap://ldap.neonym.net/ldapstuff!" . Which says that for mailto URIs you should talk to my LDAP server. Your uber-DDDS client then runs some little LDAP tool that connects to ldap.neonym.net and asks it "What email attachment formats does the user 'michael' prefer?". You get the answer and send me the attachment as a PDF instead of postscript (also getting my public key in the process so that you can encrypt it). Ok, so back to SIP and ENUM. As with the example above you have one of my three SIP addresses (one for home, one for work sip:mmealling@verisign.com and one that I got free with my Voicestream phone). But the odd thing is that the one for work isn't responding, so you take the SIP address and hand it to your uber-DDDS client and it requests NAPTR records for 'sip.uri.arpa' and gets back a record that says "take the domain-name on the right hand side of the @ and look up more NAPTRs for that domain-name". Your client does that and gets this: 0 0 "u" "ldap+I2C" "!^sip:(.*)@(.*)$!ldap://ldap.verisign.com/user=\1!" . Which says, take the first part of the sip address and use it in the LDAP URL to ask questions about that SIP user. You connect and ask that LDAP server "What is the E.164 reverse lookup for this SIP address?" and then you get back "+1-779-555-1212". That's one way of doing it. You could also do this: 0 0 "u" "tel+I2R" "^sip:mmealling@verisign.com$!tel:+1-779-555-1212" . But I personally prefer the one that redirects to some intermediary directory service so you can insert policy 'n stuff.... Does that make sense? -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Oct 17 13:38:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19187 for ; Thu, 17 Oct 2002 13:38:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HHf6N07665 for enum-archive@odin.ietf.org; Thu, 17 Oct 2002 13:41:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HHewv07658; Thu, 17 Oct 2002 13:40:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HHbiv07535 for ; Thu, 17 Oct 2002 13:37:44 -0400 Received: from smtp23.singnet.com.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19070 for ; Thu, 17 Oct 2002 13:35:23 -0400 (EDT) Received: from JSENGTOSHIBA (bb-203-125-80-6.singnet.com.sg [203.125.80.6]) by smtp23.singnet.com.sg (8.12.6/8.12.6) with SMTP id g9HHbWn7011825 for ; Fri, 18 Oct 2002 01:37:32 +0800 Message-ID: <023b01c27603$8a9debe0$ad00a8c0@JSENGTOSHIBA> From: "James Seng" To: Subject: [Enum] Reverse ENUM Date: Fri, 18 Oct 2002 01:35:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I hate to be the one pouring cold water on this stuff but...I probably should inform the group that there was a patent filed in Oct 2001 by my previous employee on a titled 'Phone Name'. The broad claim involve using the DNS to resolve a name into a tel: or fax: URL via NAPTR records. In a couple of months, it should appear on the USPTO website. Regardless of the merits of the patent filing, the group should take note of this IPR. -James Seng > At the last Pulver Conference in Atlanta VON Fall2002 the idea > of "Reverse ENUM" was discussed at various places. Even Vint Cerf > mentioned it in his speech. BTW, Vint Cerf talked about 10 min about > the importance of ENUM and Rich nearly got a heart-attack because > he had no voice-recorder on ;-) > > The principle of "Reverse ENUM" should be, that in the same way > you use a client querying for an E.164 Number in the format +1234xxx > you may use the same client entering user@foo.bar. The idea is, > that in the domain foo.bar somewhere a NAPTR? is stored pointing > to the ENUM entry for the phone number (e.g. with a tel: or enum: URI). > > The user would always get the same information regardless if he > is entering either the +431xxx or the user@foo.bar. One simple > approach was (as proposed by Rich et.al) to store the NAPTRs? > by convention in subdomains user.at.foo.bar of the domain foo.bar. > A more sophisticated approach may retrieve the "user" part with a > ldap pointer from the mail or sip server. > > Michael, since I do not fully understand your example and also your > (soon to come) RFC3404, (I tried, but it gave me a headache) > could you please elaborate more on your proposal, to enlighten me ;-) > > Best regards > Richard Stastny > > > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Oct 17 13:47:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19588 for ; Thu, 17 Oct 2002 13:47:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HHo6008151 for enum-archive@odin.ietf.org; Thu, 17 Oct 2002 13:50:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HHo6v08146; Thu, 17 Oct 2002 13:50:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HHlIv08018 for ; Thu, 17 Oct 2002 13:47:18 -0400 Received: from smtp24.singnet.com.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19471 for ; Thu, 17 Oct 2002 13:45:02 -0400 (EDT) Received: from JSENGTOSHIBA (bb-203-125-80-6.singnet.com.sg [203.125.80.6]) by smtp24.singnet.com.sg (8.12.6/8.12.6) with SMTP id g9HHlBMc029328; Fri, 18 Oct 2002 01:47:11 +0800 Message-ID: <026901c27604$e005abd0$ad00a8c0@JSENGTOSHIBA> From: "James Seng" To: "James Seng" , References: <023b01c27603$8a9debe0$ad00a8c0@JSENGTOSHIBA> Subject: Re: [Enum] Reverse ENUM Date: Fri, 18 Oct 2002 01:44:42 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "James Seng" To: Sent: Friday, October 18, 2002 1:35 AM Subject: [Enum] Reverse ENUM > I hate to be the one pouring cold water on this stuff but...I probably > should inform the group that there was a patent filed in Oct 2001 by my > previous employee on a titled 'Phone Name'. The broad claim involve using s/employee/employer/ > the DNS to resolve a name into a tel: or fax: URL via NAPTR records. > > In a couple of months, it should appear on the USPTO website. > > Regardless of the merits of the patent filing, the group should take note of > this IPR. > > -James Seng > > > At the last Pulver Conference in Atlanta VON Fall2002 the idea > > of "Reverse ENUM" was discussed at various places. Even Vint Cerf > > mentioned it in his speech. BTW, Vint Cerf talked about 10 min about > > the importance of ENUM and Rich nearly got a heart-attack because > > he had no voice-recorder on ;-) > > > > The principle of "Reverse ENUM" should be, that in the same way > > you use a client querying for an E.164 Number in the format +1234xxx > > you may use the same client entering user@foo.bar. The idea is, > > that in the domain foo.bar somewhere a NAPTR? is stored pointing > > to the ENUM entry for the phone number (e.g. with a tel: or enum: URI). > > > > The user would always get the same information regardless if he > > is entering either the +431xxx or the user@foo.bar. One simple > > approach was (as proposed by Rich et.al) to store the NAPTRs? > > by convention in subdomains user.at.foo.bar of the domain foo.bar. > > A more sophisticated approach may retrieve the "user" part with a > > ldap pointer from the mail or sip server. > > > > Michael, since I do not fully understand your example and also your > > (soon to come) RFC3404, (I tried, but it gave me a headache) > > could you please elaborate more on your proposal, to enlighten me ;-) > > > > Best regards > > Richard Stastny > > > > > > _______________________________________________ > > 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 mailnull@www1.ietf.org Thu Oct 17 13:50:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19700 for ; Thu, 17 Oct 2002 13:50:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HHr7V08328 for enum-archive@odin.ietf.org; Thu, 17 Oct 2002 13:53:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HHr4v08323; Thu, 17 Oct 2002 13:53:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HHahv06953 for ; Thu, 17 Oct 2002 13:36:43 -0400 Received: from sentosa.post1.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19035 for ; Thu, 17 Oct 2002 13:34:26 -0400 (EDT) Received: (qmail 72634 invoked from network); 17 Oct 2002 17:38:23 -0000 Received: from bb-203-125-80-6.singnet.com.sg (HELO JSENGTOSHIBA) (203.125.80.6) by sentosa.post1.com with SMTP; 17 Oct 2002 17:38:23 -0000 Message-ID: <022901c27603$68ed5940$ad00a8c0@JSENGTOSHIBA> From: "James Seng" To: References: <06CF906FE3998C4E944213062009F162024841@oefeg-s02.oefeg.loc> Subject: Re: [Enum] Reverse ENUM Date: Fri, 18 Oct 2002 01:34:13 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I hate to be the one pouring cold water on this stuff but...I probably should inform the group that there was a patent filed in Oct 2001 by my previous employee on a titled 'Phone Name'. The broad claim involve using the DNS to resolve a name into a tel: or fax: URL via NAPTR records. In a couple of months, it should appear on the USPTO website. Regardless of the merits of the patent filing, the group should take note of this IPR. -James Seng > At the last Pulver Conference in Atlanta VON Fall2002 the idea > of "Reverse ENUM" was discussed at various places. Even Vint Cerf > mentioned it in his speech. BTW, Vint Cerf talked about 10 min about > the importance of ENUM and Rich nearly got a heart-attack because > he had no voice-recorder on ;-) > > The principle of "Reverse ENUM" should be, that in the same way > you use a client querying for an E.164 Number in the format +1234xxx > you may use the same client entering user@foo.bar. The idea is, > that in the domain foo.bar somewhere a NAPTR? is stored pointing > to the ENUM entry for the phone number (e.g. with a tel: or enum: URI). > > The user would always get the same information regardless if he > is entering either the +431xxx or the user@foo.bar. One simple > approach was (as proposed by Rich et.al) to store the NAPTRs? > by convention in subdomains user.at.foo.bar of the domain foo.bar. > A more sophisticated approach may retrieve the "user" part with a > ldap pointer from the mail or sip server. > > Michael, since I do not fully understand your example and also your > (soon to come) RFC3404, (I tried, but it gave me a headache) > could you please elaborate more on your proposal, to enlighten me ;-) > > Best regards > Richard Stastny > > > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Oct 17 20:29:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00863 for ; Thu, 17 Oct 2002 20:29:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I0Uq030800 for enum-archive@odin.ietf.org; Thu, 17 Oct 2002 20:30:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I0Uiv30792; Thu, 17 Oct 2002 20:30:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I0R1v30687 for ; Thu, 17 Oct 2002 20:27:01 -0400 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00725 for ; Thu, 17 Oct 2002 20:24:42 -0400 (EDT) Received: from dick.shockey.us (65-84-233-204.client.dsl.net [65.84.233.204]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id RAA10857; Thu, 17 Oct 2002 17:26:46 -0700 Message-Id: <5.1.0.14.2.20021017202425.01592df8@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 17 Oct 2002 20:26:50 -0400 To: "James Seng" , From: Richard Shockey Subject: Re: [Enum] Reverse ENUM In-Reply-To: <023b01c27603$8a9debe0$ad00a8c0@JSENGTOSHIBA> 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-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 01:35 AM 10/18/2002 +0800, James Seng wrote: >I hate to be the one pouring cold water on this stuff but...I probably >should inform the group that there was a patent filed in Oct 2001 by my >previous employee on a titled 'Phone Name'. The broad claim involve using >the DNS to resolve a name into a tel: or fax: URL via NAPTR records. > >In a couple of months, it should appear on the USPTO website. > >Regardless of the merits of the patent filing, the group should take note of >this IPR. Have you heard of TPC.INT? circa 1990? Marshall Rose?? Read the RFC's because there may be a claim of prior art here in the public domain. >-James Seng > > > At the last Pulver Conference in Atlanta VON Fall2002 the idea > > of "Reverse ENUM" was discussed at various places. Even Vint Cerf > > mentioned it in his speech. BTW, Vint Cerf talked about 10 min about > > the importance of ENUM and Rich nearly got a heart-attack because > > he had no voice-recorder on ;-) > > > > The principle of "Reverse ENUM" should be, that in the same way > > you use a client querying for an E.164 Number in the format +1234xxx > > you may use the same client entering user@foo.bar. The idea is, > > that in the domain foo.bar somewhere a NAPTR? is stored pointing > > to the ENUM entry for the phone number (e.g. with a tel: or enum: URI). > > > > The user would always get the same information regardless if he > > is entering either the +431xxx or the user@foo.bar. One simple > > approach was (as proposed by Rich et.al) to store the NAPTRs? > > by convention in subdomains user.at.foo.bar of the domain foo.bar. > > A more sophisticated approach may retrieve the "user" part with a > > ldap pointer from the mail or sip server. > > > > Michael, since I do not fully understand your example and also your > > (soon to come) RFC3404, (I tried, but it gave me a headache) > > could you please elaborate more on your proposal, to enlighten me ;-) > > > > Best regards > > Richard Stastny > > > > > > _______________________________________________ > > 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. 46000 Center Oak Plaza - Sterling, VA 20166 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 mailnull@www1.ietf.org Thu Oct 17 22:10:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03161 for ; Thu, 17 Oct 2002 22:10:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I2BrQ03811 for enum-archive@odin.ietf.org; Thu, 17 Oct 2002 22:11:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I2Bov03806; Thu, 17 Oct 2002 22:11:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I288v03663 for ; Thu, 17 Oct 2002 22:08:08 -0400 Received: from smtp25.singnet.com.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03074 for ; Thu, 17 Oct 2002 22:05:47 -0400 (EDT) Received: from JSENGTOSHIBA (bb-203-125-86-117.singnet.com.sg [203.125.86.117]) by smtp25.singnet.com.sg (8.12.6/8.12.6) with SMTP id g9I27uUh000478; Fri, 18 Oct 2002 10:07:57 +0800 Message-ID: <02a101c2764a$e2e85690$ad00a8c0@JSENGTOSHIBA> From: "James Seng" To: , "Richard Shockey" References: <5.1.0.14.2.20021017202425.01592df8@popd.ix.netcom.com> Subject: Re: [Enum] Reverse ENUM Date: Fri, 18 Oct 2002 10:05:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Have you heard of TPC.INT? circa 1990? Marshall Rose?? > > Read the RFC's because there may be a claim of prior art here in the public > domain. Maybe there is a prior art. In fact, I would be surprise if there arent any. But if the experience in IDN is any indication, existence of prior art in public domain does not mean USPTO will not grant the patent. So lets continue the discussion (on the concept of reverse ENUM) but lets not brush it off as irrelevent. Personally, I like the idea to map names (or maybe more correctly identifiers) into telephone numbers. It means we could build a global phone directory with easy to remember names for end-users. But should the DNS be the global phone directory or is there something else we could use? NAPTR provides a direct solution allow tel: URI to be encoded right now int he DNS. Mats suggested using the INFO command in SMTP to do that which is also a possibility answer. -James Seng _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Oct 17 22:46:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04082 for ; Thu, 17 Oct 2002 22:46:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I2mTm05537 for enum-archive@odin.ietf.org; Thu, 17 Oct 2002 22:48:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I2mRv05532; Thu, 17 Oct 2002 22:48:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I2k0v05460 for ; Thu, 17 Oct 2002 22:46:00 -0400 Received: from bab5.dscga.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04029 for ; Thu, 17 Oct 2002 22:43:39 -0400 (EDT) Received: from mmealling (usrpppg.dscga.com [207.120.28.146]) by bab5.dscga.com (8.11.0/8.11.0) with SMTP id g9I2iNQ18647 for ; Thu, 17 Oct 2002 22:44:23 -0400 Message-ID: <007d01c27650$6146db10$921c78cf@netsol.com> From: "Michael Mealling" To: Date: Thu, 17 Oct 2002 22:45:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Enum] DDDS and other documents published Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi everyone, Just to keep everyone up to date and referencing the correct documents, the following have been recently published. In particular, the ENUM WG should reference RFC 3403 as the most up to date definition for the NAPTR record. RFC 3401 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS RFC 3402 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm RFC 3403 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database RFC 3404 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application RFC 3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures RFC 3406 Uniform Resource Names (URN) Namespace Definition Mechanisms _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Oct 18 04:06:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18409 for ; Fri, 18 Oct 2002 04:06:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I88SI30359 for enum-archive@odin.ietf.org; Fri, 18 Oct 2002 04:08:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I88Ov30354; Fri, 18 Oct 2002 04:08:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I87sv30328 for ; Fri, 18 Oct 2002 04:07:54 -0400 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18391 for ; Fri, 18 Oct 2002 04:05:29 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] Reverse ENUM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Oct 2002 10:10:31 +0200 Message-ID: <06CF906FE3998C4E944213062009F16202484B@oefeg-s02.oefeg.loc> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Reverse ENUM Thread-Index: AcJ14QM3fs6a1t0zSZ2KQD4qCnYewAAluGkQ From: "Stastny Richard" To: "Michael Mealling" , "Zmolek, Andrew (Andy)" , "Lind, Steven D, ALASO" , "Keats, Evan" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9I87sv30329 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi MM, Thank you for the (loooong...) explanation, it helped ;-) Anyway, the explanation raised some other questions, mainly what is already defined and what needs still to be standardized. 1.Regarding the uri.arpa: Do I understand it correctly, that you may have normally one entry per URI e.g. in sip.uri.arpa for the decomposting (ups) deconstruction rules for sip or may you have more than one? What is required to get the rules into uri.arpa, a RFC? If there is only one rule possible, would not be a RFC for IANA registration stating the deconstruction rules sufficient? Furthermore, I do not see much sense having one additional query on each DNS lookup to get the deconstruction rules. 2.Regarding the nice chat with the ldap servers etc.: > that connects to ldap.neonym.net and asks it "What email > attachment formats does the user 'michael' prefer?" or > connect and ask that LDAP server "What is the E.164 reverse > lookup for this SIP address?" and then you get back Is this somewhere standardized already, or is there still work to be done? 3.Regarding your two examples > 0 0 "u" "ldap+I2C" > "!^sip:(.*)@(.*)$!ldap://ldap.verisign.com/user=\1!" . > > 0 0 "u" "tel+I2R" > "^sip:mmealling@verisign.com$!tel:+1-779-555-1212" . > > But I personally prefer the one that redirects to some > intermediary directory service so you can insert policy 'n stuff.... Of course I would also prefer the first example, because the second would not scale with more than 10 records (users) in a domain. Imagine you get back 1000 NAPTRs in one query. I still would prefer the more simplistic version with the at. Domain. This would be in your example either IN NAPTR 0 0 "u" "tel+I2R" "^sip:mmealling@verisign.com$!tel:+1-779-555-1212" in mmmealling.at.verisign.com which scales better for few users or If you have many records, you may use * IN NAPTR 0 0 "u" "ldap+I2C" "!^sip:(.*)@(.*)$!ldap://ldap.verisign.com/user=\1!" in at.verisign.com 4.And finally, to my favorite, the enum: URI The first example is IMHO another reason why we need an enum: URI, because if a tel URI is returned here, this means you should make a phone call directly, if you want to indicate an ENUM query should be done, the enum: URI should be used. IN NAPTR 0 0 "u" "tel+I2R" "^sip:mmealling@verisign.com$!enum:+1-779-555-1212" Regards Richard > -----Original Message----- > From: Michael Mealling [mailto:michael@neonym.net] > Sent: Thursday, October 17, 2002 3:24 PM > To: Stastny Richard; Zmolek, Andrew (Andy); Lind, Steven D, > ALASO; Keats, Evan > Cc: enum@ietf.org > Subject: Re: [Enum] Reverse ENUM > > > (loooong....) > > Richard Stastny said this: > > Michael Mealling wrote: > > > This is what RFC 3404 does. It takes _any_ URI and looks up the > > > deconstruction rules for how to find an authoritative > server for it. > > > I.e. the NAPTR record for sip.uri.arpa would look like this: > > > > > > sip.uri.arpa IN NAPTR 0 0 "" "" > > > "!^sip:(.*)@(.*)$!/2!" . > > > > > > Which says, "go ask the domain-name in that address for a NAPTR > > > record that can tell me if a server can answer questions > about this > > > URI". One of the obvious questions would > > > be: "since a SIP server isn't responding, what should I do to > > > contact that user?" and the result would be a tel: URL, > or an error > > > message sayign what happened, or a redirect to another > sip address, > > > etc. > > > > The principle of "Reverse ENUM" should be, that in the same way you > > use a client querying for an E.164 Number in the format > +1234xxx you > > may use the same client entering user@foo.bar. The idea is, that in > > the domain foo.bar somewhere a NAPTR? is stored pointing to > the ENUM > > entry for the phone number (e.g. with a tel: or enum: URI). > > Correct. > > > The user would always get the same information regardless if he is > > entering either the +431xxx or the user@foo.bar. One simple > approach > > was (as proposed by Rich et.al) to store the NAPTRs? by > convention in > > subdomains user.at.foo.bar of the domain foo.bar. A more > sophisticated > > approach may retrieve the "user" part with a ldap pointer from the > > mail or sip server. > > That is what RFC 3404 (will) say: that there is a NAPTR or > series of NAPTRs for the right hand side of the sip/email > address. Those NAPTR records will point you to one or more > services that can answer questions about the left hand side > of the address. Some have suggested LDAP as you have. I > prefer something like what the RESCAP working group was > trying to do. The trick of turning the @ into an 'at' domain > causes the number of NAPTR records in the zone to equal the > number of users which causes there to be a huge number of > unneeded DNS records (i.e. _Everyone_ in your company would > have a NAPTR record instead of every phone). > > > Michael, since I do not fully understand your example and also your > > (soon to come) RFC3404, (I tried, but it gave me a > headache) could you > > please elaborate more on your proposal, to enlighten me ;-) > > I'll run through a more typical RFC 3404 example and then do a SIP > example: > > Let's say you want to send me a document but you don't know > whether or not I prefer postscript or PDF. You have my email > address so you turn that email address into a URI by just > sticking 'mailto:' in the front (e.g. > mailto:michael@neonym.net). Now, your uber-DDDS tool does a > NAPTR query for 'mailto.uri.arpa' (uri.arpa == e164.arpa but > for URIs). One NAPTR record comes back that has a rewrite > rule that essentially says to take the domain-name portion of > the email address and use that to go find more NAPTR records > (remember the "non-terminal NAPTR" discussion we had a month > or so ago?). So, the client goes off and requests NAPTR > records for "neonym.net". It recieves a couple of them but > one in particular looks like this: > > 0 0 "u" "ldap+I2C" > "!^mailto:.*$!ldap://ldap.neonym.net/ldapstuff!" . > > Which says that for mailto URIs you should talk to my LDAP > server. Your uber-DDDS client then runs some little LDAP tool > that connects to ldap.neonym.net and asks it "What email > attachment formats does the user 'michael' prefer?". You get > the answer and send me the attachment as a PDF instead of > postscript (also getting my public key in the process so that > you can encrypt it). > > Ok, so back to SIP and ENUM. As with the example above you > have one of my three SIP addresses (one for home, one for > work sip:mmealling@verisign.com and one that I got free with > my Voicestream phone). But the odd thing is that the one for > work isn't responding, so you take the SIP address and hand > it to your uber-DDDS client and it requests NAPTR records for > 'sip.uri.arpa' and gets back a record that says "take the > domain-name on the right hand side of the @ and look up more > NAPTRs for that domain-name". Your client does that and gets > this: > > 0 0 "u" "ldap+I2C" > "!^sip:(.*)@(.*)$!ldap://ldap.verisign.com/user=\1!" . > > Which says, take the first part of the sip address and use it > in the LDAP URL to ask questions about that SIP user. You > connect and ask that LDAP server "What is the E.164 reverse > lookup for this SIP address?" and then you get back > "+1-779-555-1212". That's one way of doing it. You could also do this: > > 0 0 "u" "tel+I2R" > "^sip:mmealling@verisign.com$!tel:+1-779-555-1212" . > > But I personally prefer the one that redirects to some > intermediary directory service so you can insert policy 'n stuff.... > > Does that make sense? > > -MM > > > > > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Oct 18 09:33:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25628 for ; Fri, 18 Oct 2002 09:33:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IDZFu15416 for enum-archive@odin.ietf.org; Fri, 18 Oct 2002 09:35:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IDZ6v15407; Fri, 18 Oct 2002 09:35:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IDXAv15333 for ; Fri, 18 Oct 2002 09:33:10 -0400 Received: from bab5.dscga.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25514 for ; Fri, 18 Oct 2002 09:30:54 -0400 (EDT) Received: from mmealling (usrpppn.dscga.com [207.120.28.153]) by bab5.dscga.com (8.11.0/8.11.0) with SMTP id g9IDUfQ17504; Fri, 18 Oct 2002 09:30:41 -0400 Message-ID: <004301c276aa$a9bd2b60$991c78cf@netsol.com> From: "Michael Mealling" To: "Stastny Richard" , "Zmolek, Andrew \(Andy\)" , "Lind, Steven D, ALASO" , "Keats, Evan" Cc: References: <06CF906FE3998C4E944213062009F16202484B@oefeg-s02.oefeg.loc> Subject: Re: [Enum] Reverse ENUM Date: Fri, 18 Oct 2002 09:31:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Richard Stastny said this: > Hi MM, > Thank you for the (loooong...) explanation, it helped ;-) Great! > Anyway, the explanation raised some other questions, > mainly what is already defined and what needs still > to be standardized. IMHO, the one to reckon with now is James' previous employers IP claims..... > 1.Regarding the uri.arpa: > > Do I understand it correctly, that you may have normally > one entry per URI e.g. in sip.uri.arpa for the decomposting (ups) > deconstruction rules for sip or may you have more than one? You would have one per URI scheme and it would have an insanely long TTL. Essentially you want caches to keep this record for as long as possible because it should never really change. > What is required to get the rules into uri.arpa, a RFC? > If there is only one rule possible, would not be a RFC for > IANA registration stating the deconstruction rules sufficient? An RFC isn't necessary for the registration of the NAPTR record but an RFC is required that documents the actual URI scheme itself. Since 'sip' has been registered in RFC 2543 its just a matter of getting the appropriate people to review the registration and send it to 'register@uri.arpa'. The members of the list will approve it, it will get reviewed by the IESG and it goes in the nameserver. > Furthermore, I do not see much sense having one additional query > on each DNS lookup to get the deconstruction rules. Hence the really long TTL for that record. Its there for two reasons: 1) you can delegate that record directly out to a zone that has a shorter TTL if there is a need for this particular scheme's NAPTR record to change (feature additions, services, etc). 2) For systems that do not understand the actual scheme but do understand the DDDS they can find gateways that can proxy that scheme for them, thus allowing bootstrapping of new URI schemes without having to upgrade very client in the world. > 2.Regarding the nice chat with the ldap servers etc.: > > > that connects to ldap.neonym.net and asks it "What email > > attachment formats does the user 'michael' prefer?" > > or > > connect and ask that LDAP server "What is the E.164 reverse > > lookup for this SIP address?" and then you get back > > Is this somewhere standardized already, or is there still work > to be done? Still work to be done... Seems like it would be easy, fun work since you can start getting into all sorts of AAA and policy stuff as well as interesting call routing questions. I.e. ENUM is kind of limited in order to be interoperable. By using something like LDAP/RESCAP/etc you get to have schemas which lets you interoperate a diferent way. Thus, this is where you can go crazy and do all the fun stuff. > 3.Regarding your two examples > > > 0 0 "u" "ldap+I2C" > > "!^sip:(.*)@(.*)$!ldap://ldap.verisign.com/user=\1!" . > > > > 0 0 "u" "tel+I2R" > > "^sip:mmealling@verisign.com$!tel:+1-779-555-1212" . > > > > But I personally prefer the one that redirects to some > > intermediary directory service so you can insert policy 'n stuff.... > > > Of course I would also prefer the first example, because > the second would not scale with more than 10 records (users) > in a domain. Imagine you get back 1000 NAPTRs in one query. Exactly... > I still would prefer the more simplistic version with the > at. Domain. This would be in your example > > either > > IN NAPTR 0 0 "u" "tel+I2R" > "^sip:mmealling@verisign.com$!tel:+1-779-555-1212" > in mmmealling.at.verisign.com > > which scales better for few users > or > > If you have many records, you may use > * IN NAPTR 0 0 "u" "ldap+I2C" > "!^sip:(.*)@(.*)$!ldap://ldap.verisign.com/user=\1!" > in at.verisign.com But why the 'at.versign.com'? Putting it in 'verisign.com' does the exact same thing..... > 4.And finally, to my favorite, the enum: URI > > The first example is IMHO another reason why we need an > enum: URI, because if a tel URI is returned here, this means you > should make a phone call directly, > if you want to indicate an ENUM query should be done, > the enum: URI should be used. > > IN NAPTR 0 0 "u" "tel+I2R" > "^sip:mmealling@verisign.com$!enum:+1-779-555-1212" Yep. But you could do both since the protocol profile is in the Services field... It looks like you grokked it all to me! -MM > > -----Original Message----- > > From: Michael Mealling [mailto:michael@neonym.net] > > Sent: Thursday, October 17, 2002 3:24 PM > > To: Stastny Richard; Zmolek, Andrew (Andy); Lind, Steven D, > > ALASO; Keats, Evan > > Cc: enum@ietf.org > > Subject: Re: [Enum] Reverse ENUM > > > > > > (loooong....) > > > > Richard Stastny said this: > > > Michael Mealling wrote: > > > > This is what RFC 3404 does. It takes _any_ URI and looks up the > > > > deconstruction rules for how to find an authoritative > > server for it. > > > > I.e. the NAPTR record for sip.uri.arpa would look like this: > > > > > > > > sip.uri.arpa IN NAPTR 0 0 "" "" > > > > "!^sip:(.*)@(.*)$!/2!" . > > > > > > > > Which says, "go ask the domain-name in that address for a NAPTR > > > > record that can tell me if a server can answer questions > > about this > > > > URI". One of the obvious questions would > > > > be: "since a SIP server isn't responding, what should I do to > > > > contact that user?" and the result would be a tel: URL, > > or an error > > > > message sayign what happened, or a redirect to another > > sip address, > > > > etc. > > > > > > The principle of "Reverse ENUM" should be, that in the same way you > > > use a client querying for an E.164 Number in the format > > +1234xxx you > > > may use the same client entering user@foo.bar. The idea is, that in > > > the domain foo.bar somewhere a NAPTR? is stored pointing to > > the ENUM > > > entry for the phone number (e.g. with a tel: or enum: URI). > > > > Correct. > > > > > The user would always get the same information regardless if he is > > > entering either the +431xxx or the user@foo.bar. One simple > > approach > > > was (as proposed by Rich et.al) to store the NAPTRs? by > > convention in > > > subdomains user.at.foo.bar of the domain foo.bar. A more > > sophisticated > > > approach may retrieve the "user" part with a ldap pointer from the > > > mail or sip server. > > > > That is what RFC 3404 (will) say: that there is a NAPTR or > > series of NAPTRs for the right hand side of the sip/email > > address. Those NAPTR records will point you to one or more > > services that can answer questions about the left hand side > > of the address. Some have suggested LDAP as you have. I > > prefer something like what the RESCAP working group was > > trying to do. The trick of turning the @ into an 'at' domain > > causes the number of NAPTR records in the zone to equal the > > number of users which causes there to be a huge number of > > unneeded DNS records (i.e. _Everyone_ in your company would > > have a NAPTR record instead of every phone). > > > > > Michael, since I do not fully understand your example and also your > > > (soon to come) RFC3404, (I tried, but it gave me a > > headache) could you > > > please elaborate more on your proposal, to enlighten me ;-) > > > > I'll run through a more typical RFC 3404 example and then do a SIP > > example: > > > > Let's say you want to send me a document but you don't know > > whether or not I prefer postscript or PDF. You have my email > > address so you turn that email address into a URI by just > > sticking 'mailto:' in the front (e.g. > > mailto:michael@neonym.net). Now, your uber-DDDS tool does a > > NAPTR query for 'mailto.uri.arpa' (uri.arpa == e164.arpa but > > for URIs). One NAPTR record comes back that has a rewrite > > rule that essentially says to take the domain-name portion of > > the email address and use that to go find more NAPTR records > > (remember the "non-terminal NAPTR" discussion we had a month > > or so ago?). So, the client goes off and requests NAPTR > > records for "neonym.net". It recieves a couple of them but > > one in particular looks like this: > > > > 0 0 "u" "ldap+I2C" > > "!^mailto:.*$!ldap://ldap.neonym.net/ldapstuff!" . > > > > Which says that for mailto URIs you should talk to my LDAP > > server. Your uber-DDDS client then runs some little LDAP tool > > that connects to ldap.neonym.net and asks it "What email > > attachment formats does the user 'michael' prefer?". You get > > the answer and send me the attachment as a PDF instead of > > postscript (also getting my public key in the process so that > > you can encrypt it). > > > > Ok, so back to SIP and ENUM. As with the example above you > > have one of my three SIP addresses (one for home, one for > > work sip:mmealling@verisign.com and one that I got free with > > my Voicestream phone). But the odd thing is that the one for > > work isn't responding, so you take the SIP address and hand > > it to your uber-DDDS client and it requests NAPTR records for > > 'sip.uri.arpa' and gets back a record that says "take the > > domain-name on the right hand side of the @ and look up more > > NAPTRs for that domain-name". Your client does that and gets > > this: > > > > 0 0 "u" "ldap+I2C" > > "!^sip:(.*)@(.*)$!ldap://ldap.verisign.com/user=\1!" . > > > > Which says, take the first part of the sip address and use it > > in the LDAP URL to ask questions about that SIP user. You > > connect and ask that LDAP server "What is the E.164 reverse > > lookup for this SIP address?" and then you get back > > "+1-779-555-1212". That's one way of doing it. You could also do this: > > > > 0 0 "u" "tel+I2R" > > "^sip:mmealling@verisign.com$!tel:+1-779-555-1212" . > > > > But I personally prefer the one that redirects to some > > intermediary directory service so you can insert policy 'n stuff.... > > > > Does that make sense? > > > > -MM > > > > > > > > > > > > > > > _______________________________________________ > 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 mailnull@www1.ietf.org Fri Oct 18 10:41:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28504 for ; Fri, 18 Oct 2002 10:41:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IEh4G20351 for enum-archive@odin.ietf.org; Fri, 18 Oct 2002 10:43:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IEh0v20346; Fri, 18 Oct 2002 10:43:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IEeCv20211 for ; Fri, 18 Oct 2002 10:40:12 -0400 Received: from babelfish.srmr.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28336 for ; Fri, 18 Oct 2002 10:37:56 -0400 (EDT) Received: from percy.roke.co.uk ([193.118.205.20] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 10635u via TCP with SMTP; Fri, 18 Oct 2002 15:39:30 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <06CF906FE3998C4E944213062009F16202484B@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F16202484B@oefeg-s02.oefeg.loc> Date: Fri, 18 Oct 2002 15:39:33 +0100 To: Stastny Richard , Michael Mealling , "Zmolek, Andrew (Andy)" , "Lind, Steven D, ALASO" , "Keats, Evan" From: Lawrence Conroy Subject: RE: [Enum] Reverse ENUM Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 10:10 am +0200 18/10/02, Stastny Richard wrote: >Hi MM, >Thank you for the (loooong...) explanation, it helped ;-) >I still would prefer the more simplistic version with the >at. Domain. Hi Folks, Forgive the question, but... As the goal was to map from email address to "e-number", then IFF we have an "enum:" URI, then why not just have: $ORIGIN lwc.at.roke.co.uk. . IN NAPTR 0 0 "u" "X2U" "!^.*$!enum:+441794833666!" . Now, this means a constructed lookup based on my email address should submit an ENUM query based on the E.164 number to find my contact information. I'm only looking up one email address at a time, so this seems to work for me. I may be missing something, but why would I need ANYTHING more complex? ---- If every email address within a group mapped to a single "e-number" then I guess we'd use a * entry with the same data. In D3S application terms I guess that X2U accepts an email address, converts the '@' to '.at.', and submits the result. The AUS is (maybe) an email address, the 1st well known rule is either null/identity or "replace the '@' with ".at.'", the database is DNS, and the result is a URI. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Oct 18 11:06:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29387 for ; Fri, 18 Oct 2002 11:06:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IF88k21901 for enum-archive@odin.ietf.org; Fri, 18 Oct 2002 11:08:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IF86v21896; Fri, 18 Oct 2002 11:08:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IF7Ov21855 for ; Fri, 18 Oct 2002 11:07:24 -0400 Received: from bab5.dscga.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29335 for ; Fri, 18 Oct 2002 11:05:08 -0400 (EDT) Received: from mmealling (usrpppn.dscga.com [207.120.28.153]) by bab5.dscga.com (8.11.0/8.11.0) with SMTP id g9IF5iQ31059; Fri, 18 Oct 2002 11:05:45 -0400 Message-ID: <00bc01c276b7$f11e1b10$991c78cf@netsol.com> From: "Michael Mealling" To: "Stastny Richard" , "Zmolek, Andrew \(Andy\)" , "Lind, Steven D, ALASO" , "Keats, Evan" , "Lawrence Conroy" Cc: References: <06CF906FE3998C4E944213062009F16202484B@oefeg-s02.oefeg.loc> Subject: Re: [Enum] Reverse ENUM Date: Fri, 18 Oct 2002 11:06:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Lawrence Conroy said this: > At 10:10 am +0200 18/10/02, Stastny Richard wrote: > Forgive the question, but... > > As the goal was to map from email address to "e-number", > then IFF we have an "enum:" URI, then why not just have: > > $ORIGIN lwc.at.roke.co.uk. > . IN NAPTR 0 0 "u" "X2U" "!^.*$!enum:+441794833666!" . > > Now, this means a constructed lookup based on my email address > should submit an ENUM query based on the E.164 number to find my > contact information. > > I'm only looking up one email address at a time, so this seems > to work for me. I may be missing something, but why would I need > ANYTHING more complex? 1) It means having a DNS entry for each email address. For a small domain like VeriSign this would be fine. But for something like hotmail, AOL, MSN, etc it would mean a huge increase in the number of subdomains for the given zone. 2) There is a direct correlation between an email address and a user. As a rule of thumb the DNS shouldn't be used to store information about users or documents directly. Instead it should be used to denote devices in domains in order for aggregation to allow the caching mechanisms to work. I.e. zones like '.com' shouldn't be encouraged to happen. 3) Users expect to be able to exert policy restrictions surrounding their email address. Putting mappings directly from email to telephone number in a public space will cause a lot of headaches. > If every email address within a group mapped to a single "e-number" > then I guess we'd use a * entry with the same data. But DNS doesn't allow you to do that on a subset basis. I.e. everything below at.example.com has the same record or everything under at.example.com must have its own record. You can't do the in between without using the DDDS regular expression method. > In D3S application terms I guess that X2U accepts an email address, > converts the '@' to '.at.', and submits the result. > The AUS is (maybe) an email address, the 1st well known rule is either > null/identity or "replace the '@' with ".at.'", the database is DNS, > and the result is a URI. But by doing that you're creating an unneeded rewrite. Also remember, the mailto URI scheme will have other services associated with it. You want to delegate down to the authority for that domain and then ask _that_ nameserver whether or not it has any idea what E.164 number mapping service exists for that domain. Hard examples: mailto:foo@example.com mailto.uri.arpa IN NAPTR 0 0 "" "" "!^mailto:(.*)@(.*)$!\2!" . example.com IN NAPTR 0 0 "" "enum+X2U" "!^mailto:(.*)@example.com!\2.at.example.com" . foo.at.example.com IN NAPTR 0 0 "u" "enum+X2U" "!^.*$!+1-679-555-1212!" . That method creates an additional subdomain when none is necessary. Either the bloat occurs in the 'at.example.com' domain or it occurs in the 'example.com' domain, it doesn't really buy you anything other being able to set a zone level TTL. Here's one really important issue: is this really "ENUM reverse lookups" or is it "find an e.164 number given a sip address" because ENUM can point you to any URI so this won't work for all of ENUM. If its "I want to find a telephone number given an email address" then you're talking about suggesting putting information in DNS for email when the email guys will tell you it had better be in some kind of redirected server (LDAP). I think we're discussing several diferrent services depending on what the starting identifier is. If its a SIP address then its pretty simple. If its an email address then you're part of a much larger application that the RESCAP WG is looking at. If its _any_ URI (which is what ENUM does) then you're talking about a specific global Service level definition that would need to be available for any URI scheme that's resolveable by the DDDS. -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Oct 18 12:30:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02750 for ; Fri, 18 Oct 2002 12:30:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IGWIc27782 for enum-archive@odin.ietf.org; Fri, 18 Oct 2002 12:32:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IGWFv27777; Fri, 18 Oct 2002 12:32:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I3V1v07498 for ; Thu, 17 Oct 2002 23:31:01 -0400 Received: from polaris.dazza.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04735 for ; Thu, 17 Oct 2002 23:28:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by polaris.dazza.org (Postfix) with ESMTP id E3EB6254005; Thu, 17 Oct 2002 20:30:51 -0700 (PDT) Received: by polaris.dazza.org (Postfix, from userid 79) id 608FF254010; Thu, 17 Oct 2002 20:30:51 -0700 (PDT) Received: from dazzawinxp (209-166-32-61.client.dsl.net [209.166.32.61]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by polaris.dazza.org (Postfix) with ESMTP id C0DCF254005; Thu, 17 Oct 2002 20:30:48 -0700 (PDT) Message-ID: <190701c27656$dcfbf500$3d20a6d1@dazzawinxp> From: "Darren Nickerson" To: "James Seng" , , "Richard Shockey" References: <5.1.0.14.2.20021017202425.01592df8@popd.ix.netcom.com> Subject: Re: [Enum] Reverse ENUM Date: Thu, 17 Oct 2002 23:31:34 -0400 Organization: The Phone Company MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_OE version=2.42 X-Virus-Scanned: by AMaViS snapshot-20020300 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Have you heard of TPC.INT? circa 1990? Marshall Rose?? > > Read the RFC's because there may be a claim of prior art here in the public > domain. Indeed ;-) -dpn _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Oct 18 12:47:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03108 for ; Fri, 18 Oct 2002 12:47:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IGnYG28826 for enum-archive@odin.ietf.org; Fri, 18 Oct 2002 12:49:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IGnRv28820; Fri, 18 Oct 2002 12:49:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IGmVv28745 for ; Fri, 18 Oct 2002 12:48:31 -0400 Received: from babelfish.srmr.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03053 for ; Fri, 18 Oct 2002 12:46:12 -0400 (EDT) Received: from percy.roke.co.uk ([193.118.205.20] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 10672u via TCP with SMTP; Fri, 18 Oct 2002 17:48:13 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <00bc01c276b7$f11e1b10$991c78cf@netsol.com> References: <06CF906FE3998C4E944213062009F16202484B@oefeg-s02.oefeg.loc> <00bc01c276b7$f11e1b10$991c78cf@netsol.com> Date: Fri, 18 Oct 2002 17:48:14 +0100 To: Michael Mealling , Stastny Richard , "Zmolek, Andrew (Andy)" , "Lind, Steven D, ALASO" , "Keats, Evan" From: Lawrence Conroy Subject: Re: [Enum] Reverse ENUM Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 11:06 am -0400 18/10/02, Michael Mealling wrote: >Lawrence Conroy said this: >> At 10:10 am +0200 18/10/02, Stastny Richard wrote: >> Forgive the question, but... >> >> As the goal was to map from email address to "e-number", >> then IFF we have an "enum:" URI, then why not just have: >> >> $ORIGIN lwc.at.roke.co.uk. >> . IN NAPTR 0 0 "u" "X2U" "!^.*$!enum:+441794833666!" . >> >> Now, this means a constructed lookup based on my email address >> should submit an ENUM query based on the E.164 number to find my >> contact information. >> >> I'm only looking up one email address at a time, so this seems >> to work for me. I may be missing something, but why would I need >> ANYTHING more complex? > >1) It means having a DNS entry for each email address. For a small domain >like VeriSign this would be fine. But for something like hotmail, AOL, MSN, >etc it would mean a huge increase in the number of subdomains for the given >zone. This is indeed a lot of work for AOL's DNS admin folk. And this means it does not work for me because...? > >2) There is a direct correlation between an email address and a user. As a >rule of thumb the DNS shouldn't be used to store information about users or >documents directly. Instead it should be used to denote devices in domains >in order for aggregation to allow the caching mechanisms to work. I.e. zones >like '.com' shouldn't be encouraged to happen. Correlated person for email address 'all@ietf.org' is...? For the rest, that is a valid opinion. > >3) Users expect to be able to exert policy restrictions surrounding their >email address. Putting mappings directly from email to telephone number in a >public space will cause a lot of headaches. That is also an opinion. However, technically, the "direct mapping" works? > >> If every email address within a group mapped to a single "e-number" >> then I guess we'd use a * entry with the same data. c/group/zone/ oops... >But DNS doesn't allow you to do that on a subset basis. I.e. everything >below at.example.com has the same record or everything under at.example.com >must have its own record. You can't do the in between without using the DDDS >regular expression method. Works for me, as per Section 4.3.3 of RFC1034. > >> In D3S application terms I guess that X2U accepts an email address, >> converts the '@' to '.at.', and submits the result. >> The AUS is (maybe) an email address, the 1st well known rule is either >> null/identity or "replace the '@' with ".at.'", the database is DNS, > > and the result is a URI. >But by doing that you're creating an unneeded rewrite. Also remember, the >mailto URI scheme will have other services associated with it. You want to >delegate down to the authority for that domain and then ask _that_ >nameserver whether or not it has any idea what E.164 number mapping service >exists for that domain. Hard examples: > >mailto:foo@example.com > >mailto.uri.arpa IN NAPTR 0 0 "" "" "!^mailto:(.*)@(.*)$!\2!" >. > >example.com IN NAPTR 0 0 "" "enum+X2U" >"!^mailto:(.*)@example.com!\2.at.example.com" . > >foo.at.example.com IN NAPTR 0 0 "u" "enum+X2U" >"!^.*$!+1-679-555-1212!" . > >That method creates an additional subdomain when none is necessary. Either >the bloat occurs in the 'at.example.com' domain or it occurs in the >'example.com' domain, it doesn't really buy you anything other being able to >set a zone level TTL. Hmmm....I don't understand the "un-needed rewrite" statement. I have an email address - I want the associated ENUM number. The examples do not help to explain why I cannot place a NAPTR within the foo.at.exaple.com zone. I'm not clear on why I care whether or not the "mailto scheme having other services associated with it". The first example seems to be the .uri.arpa RR. The second example seems to be a redundant step. I have an application that is passed an email address and converts it as described in my earlier email. This is part of the first well known rule, or the database key step (akin to "reverse digits, interpose bullets, and append .e164.arpa" in RFC2916bis). This is done by the program on the querying client machine. => I cannot understand why this extra NAPTR is required or useful. The third example is incorrect. There is no URI output from this NAPTR. >Here's one really important issue: is this really "ENUM reverse lookups" or >is it "find an e.164 >number given a sip address" because ENUM can point you to any URI so this >won't work for all of ENUM. If its "I want to find a telephone number given >an email address" then you're talking about suggesting putting information >in DNS for email when the email guys will tell you it had better be in some >kind of redirected server (LDAP). SIP can already return (has always returned) a URI in a 3xx redirect; It'll return whatever URI you have registered. This is a non-problem, IMHO. I'm interested solely in Reverse ENUM. I cannot see from these comments why the scheme I mentioned doesn't suffice. I'll agree that it's a lot of work for AOL, and my heart bleeds for them. However, how is it illegal? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Oct 20 11:48:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29380 for ; Sun, 20 Oct 2002 11:48:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9KFoBe31558 for enum-archive@odin.ietf.org; Sun, 20 Oct 2002 11:50:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9KFnxv31543; Sun, 20 Oct 2002 11:49:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9KFlFv31522 for ; Sun, 20 Oct 2002 11:47:15 -0400 Received: from babelfish.srmr.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29348 for ; Sun, 20 Oct 2002 11:44:56 -0400 (EDT) Received: from percy.roke.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 10734u via TCP with SMTP; Sun, 20 Oct 2002 16:46:58 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Sun, 20 Oct 2002 16:47:03 +0100 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] compendium? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Folks, ...on another topic... Has anyone found any errors in the compendium document? see I believe that these are being used in a trial, but if we've mangled the text please holler and I'll try to correct it. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Oct 20 13:36:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00655 for ; Sun, 20 Oct 2002 13:36:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9KHchh03202 for enum-archive@odin.ietf.org; Sun, 20 Oct 2002 13:38:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9KHcZv03192; Sun, 20 Oct 2002 13:38:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9KHbHv03012 for ; Sun, 20 Oct 2002 13:37:17 -0400 Received: from babelfish.srmr.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00638 for ; Sun, 20 Oct 2002 13:34:58 -0400 (EDT) Received: from percy.roke.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 10741u via TCP with SMTP; Sun, 20 Oct 2002 18:37:02 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Sun, 20 Oct 2002 18:37:07 +0100 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] enum: again Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Folks, from posts on this list, it seems that the enum: URI has raised its head again. I missed out on the fun in YOK so I may have missed discussions there, but... I raised some concerns that don't seem to have been resolved, so here we go again: Proposal: Use tel: with a parameter to indicate "search ENUM with the URL value". My Concerns: 'tel:' URL processors exist that follow RFC2806 policy which is to ignore unrecognised parameters. Any parameter we add to specify "search ENUM" is by definition unrecognised by existing 'tel:' URL processors. Thus such a parameter will be ignored by these existing processors. Note that the same is true by changing the RFC2806bis update to specify that, by default, the 'tel:' processor MUST search ENUM unless a parameter is included that specifies otherwise. It just won't work for existing 'tel:' processors as they don't check ENUM - stating that they must is not going to change anything. Comments on tel: versus enum: gratefully received... all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Oct 24 17:11:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23826 for ; Thu, 24 Oct 2002 17:11:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OLDTH12006 for enum-archive@odin.ietf.org; Thu, 24 Oct 2002 17:13:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OLDIv12001; Thu, 24 Oct 2002 17:13:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OLB7v11950 for ; Thu, 24 Oct 2002 17:11:07 -0400 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23742 for ; Thu, 24 Oct 2002 17:08:43 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g9OLB0b00927 for ; Thu, 24 Oct 2002 21:11:01 GMT Message-Id: <5.1.0.14.2.20021024170604.02406788@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 24 Oct 2002 17:11:22 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Folks I'm still looking for agenda items and slot requests for Atlanta... Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Beyond the highly anticipated 2916bis 02 revision and... "A compendium of enumservice registrations" A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservices-compendium-00.txt I should have a personal ID ( a straw man really) on Privacy and Security Consideration in ENUM that will be new. I understand we should have a SIP enum registration document and a submission to the SIPPING WG on how SIP should use ENUM. What other texts are forthcoming? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 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 mailnull@www1.ietf.org Fri Oct 25 15:11:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07238 for ; Fri, 25 Oct 2002 15:11:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PJDg924437 for enum-archive@odin.ietf.org; Fri, 25 Oct 2002 15:13:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PJDQv24429; Fri, 25 Oct 2002 15:13:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PJ9xv24299 for ; Fri, 25 Oct 2002 15:09:59 -0400 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07054 for ; Fri, 25 Oct 2002 15:07:33 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g9PJ9ob31011 for ; Fri, 25 Oct 2002 19:09:50 GMT Message-Id: <5.1.0.14.2.20021025150932.023e3aa0@wheresmymailserver.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 25 Oct 2002 15:10:04 -0400 To: enum@ietf.org From: Richard Shockey 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 www1.ietf.org id g9PJ9xv24300 Subject: [Enum] Proposed Agenda for ENUM WG IETF 55 Atlanta GA. Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Ouch.. I accidently sent this to the general IETF list .. OK ..this is what I have so far but it is subject to daily revisions... keep those notes to the list coming ... ############### MONDAY, November 18, 2002 1130-1300 Break 1300-1500 Afternoon Sessions I TSV enum Telephone Number Mapping WG Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Scribe Introduction … I am looking for a scribe ? VOLUNTEERS WANTED ASAP !!! It is my sad duty to report that our long standing scribe Jay Hilton is no longer with Telcordia and will not be attending IETF Atlanta. 1. RFC2916bis -0x REV - Faltstrom/Mealing (45 Min) ############### 2. J.Peterson (20min) Enumservice registration for SIP Addresses-of Record - Using ENUM for SIP applications Not yet posted to ID editors. ############### 3. R.Bradner &Co [20 Min ???] We definitely need to come to some consensus on how to work this issue. Title : 'A compendium of enumservice registrations' Author(s) : R. Brandner et al. Filename : draft-brandner-enumservices-compendium-00.txt Pages : 0 Date : 2002-9-16 This document includes a basic set of enumservice descriptions that are intended for use in deployments of ENUM. These descriptions form a set of enumservice registration requests, as laid out in section 3 of draft-ietf-enum-rfc2916bis-01.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservices-compendium-00.txt ################ 3. The 'enum' URI (L. Conroy 15 min) We discussed this some in Yokohama but did not come to a definitive conclusion whether this URI was appropriate or some extension to the TEL URL was sufficient. http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt 4. Open Discussion ... A. The Reverse ENUM issue .... I'd like to hear some more views on this. Does this need to be standardized? It seems to come up on the list with some regularity. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 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 mailnull@www1.ietf.org Mon Oct 28 12:12:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19265 for ; Mon, 28 Oct 2002 12:12:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SHE1h04298 for enum-archive@odin.ietf.org; Mon, 28 Oct 2002 12:14:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SHDmv04289; Mon, 28 Oct 2002 12:13:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SH8Zv04076 for ; Mon, 28 Oct 2002 12:08:35 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19056 for ; Mon, 28 Oct 2002 12:06:08 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g9SH8Tb13089 for ; Mon, 28 Oct 2002 17:08:29 GMT Message-Id: <5.1.0.14.2.20021028120557.0464ea78@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 12:08:34 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] H.323 enumservice registration ID Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This document has gone in the queue...I'm making it available early for your review ... I'll be adding Orit and this Draft to the ENUM WG agenda as well along with Jon Peterson who has also posted a SIP enumservice registration document. many many thanks to Orit for getting this ready in time for Atlanta ############################ Internet Draft O. Levin Document: draft-levin-enum-h323-00.txt RADVISION Expires: April 2003 October 2002 ENUM Service Registration for H.323 URL Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The H.323 specification [2] defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers an ENUM service for H.323 according to specifications and guidelines in RFC2916bis [3]. Levin Expires: April 2003 1 ENUM Service Registration for H.323 URL Table of Contents STATUS OF THIS MEMO......................................................1 ABSTRACT...............................................................1 INTRODUCTION...........................................................3 ENUM SERVICE REGISTRATION.................................................3 THE E2U+H323 ENUM SERVICE..................................................3 CONVENTIONS USED IN THIS DOCUMENT..........................................3 SECURITY CONSIDERATIONS..................................................3 IANA CONSIDERATIONS......................................................4 AUTHOR'S ADDRESSES.......................................................4 REFERENCES.............................................................4 Levin Expires: March 2003 2 ENUM Service Registration for H.323 URL Introduction The H.323 specification [2] defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. When H.323 is used in the context of the Internet, it would be useful to take advantages of such services as domain name system (DNS) and ENUM in order to help facilitate the completion of multimedia calls. This document registers an ENUM service for H.323 according to specifications and guidelines in RFC2916bis [3]. ENUM Service Registration As defined in [3], the following is a template covering information needed for the registration of the enumservice specified in this document. - Service Name: "E2U+H323" - URI Scheme(s): "h323:" - Functional Specification: see "The E2U+H323 ENUM Service" section - Security considerations: see "Security Considerations" section - Intended usage: COMMON - Author: Orit Levin - Any other information that the author deems interesting: None The E2U+H323 ENUM Service This document defines the "E2U+H323" service to be used in the "service" sub-field of the "enumservice" as defined in [3]. The H.323 related ENUM record MUST be populated with a standard H.323 URL as defined in [2]. This URL MAY include parameters specifying the specific protocols and the transport means the H.323 entity supports. The H.323 entity MUST fully comply with the procedures defined in [3] for both record retrieval and processing by the DNS client. If, as a result of the ENUM DNS lookup, an H.323 URL matching local policies and capabilities is retrieved, the procedure defined in section "Address Resolution Procedure using DNS" of [5] SHOULD be performed. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Security Considerations The h323-URL information, once populated in the DNS, effectively becomes publicly accessible. The access to the H.323 destinations Levin Expires: March 2003 3 ENUM Service Registration for H.323 URL (published using ENUM) can be secured by techniques and procedures defined in H.235 [4] - the security framework for H.323. The framework defines means for achieving integrity, authentication, non-repudiation, encryption, etc. for H.323 calls. IANA Considerations This document registers the "E2U+H323" ENUM service according to specifications and guidelines in RFC2916bis [3] and the definitions in this document. Author's Addresses Orit Levin RADVISION 266 Harristown Road Phone: +1-201-689-6330 Glen Rock, NJ USA Email: orit@radvision.com References 1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 2 "Packet-based multimedia communications systems", ITU-T Recommendation H.323, Nov 2000. 3 Faltstrom, P. and M. Mealling, "The E.164 to URI DDDS Application", draft-ietf-enum-rfc2916bis-01 (work in progress), June 2002. 4 "Security and encryption for H-Series(H.323 and other H.245- based) multimedia terminals", ITU-T Recommendation H.235, Nov 2000. 5 "Use of DNS in H.323 Systems", ITU-T Recommendation H.323 Annex O (work in progress). Levin >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 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 mailnull@www1.ietf.org Mon Oct 28 13:38:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23847 for ; Mon, 28 Oct 2002 13:38:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SIecs09056 for enum-archive@odin.ietf.org; Mon, 28 Oct 2002 13:40:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SIeXv09050; Mon, 28 Oct 2002 13:40:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SIbXv08931 for ; Mon, 28 Oct 2002 13:37:33 -0500 Received: from babelfish.srmr.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23793 for ; Mon, 28 Oct 2002 13:35:08 -0500 (EST) Received: from babelfish.srmr.co.uk ([193.118.192.111] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 1026u via TCP with SMTP; Mon, 28 Oct 2002 18:37:02 +0000 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.1.0.14.2.20021028120557.0464ea78@popd.ix.netcom.com> References: <5.1.0.14.2.20021028120557.0464ea78@popd.ix.netcom.com> Date: Mon, 28 Oct 2002 18:36:59 +0000 To: Richard Shockey From: Lawrence Conroy Subject: Re: [Enum] H.323 enumservice registration ID Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 12:08 pm -0500 28/10/02, Richard Shockey wrote: >This document has gone in the queue...I'm making it available early >for your review ... > >I'll be adding Orit and this Draft to the ENUM WG agenda as well >along with Jon Peterson who has also posted a SIP enumservice >registration document. > >many many thanks to Orit for getting this ready in time for Atlanta > > > Internet Draft O. Levin > Document: draft-levin-enum-h323-00.txt RADVISION > >The E2U+H323 ENUM Service Hi Rich, Folks, I note that Orit's draft refers [5] to the "extensive" contribution TD-WP2-0057 put into the SG16 meeting last week ( I understood that the outcome was that this was likely to be carved out into separate documents and/or reconsidered). - is this draft intended as one of those parts? - is the h323: URI spec coming out anytime soon? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Oct 28 13:55:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24544 for ; Mon, 28 Oct 2002 13:55:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SIvGr09784 for enum-archive@odin.ietf.org; Mon, 28 Oct 2002 13:57:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SIvEv09779; Mon, 28 Oct 2002 13:57:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SIukv09734 for ; Mon, 28 Oct 2002 13:56:46 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24449 for ; Mon, 28 Oct 2002 13:54:21 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g9SIufb17150; Mon, 28 Oct 2002 18:56:41 GMT Message-Id: <5.1.0.14.2.20021028135541.02564de0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 13:57:05 -0500 To: Lawrence Conroy From: Richard Shockey Subject: Re: [Enum] H.323 enumservice registration ID Cc: enum@ietf.org, Orit Levin In-Reply-To: References: <5.1.0.14.2.20021028120557.0464ea78@popd.ix.netcom.com> <5.1.0.14.2.20021028120557.0464ea78@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-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 06:36 PM 10/28/2002 +0000, Lawrence Conroy wrote: >At 12:08 pm -0500 28/10/02, Richard Shockey wrote: >>This document has gone in the queue...I'm making it available early for >>your review ... >> >>I'll be adding Orit and this Draft to the ENUM WG agenda as well along >>with Jon Peterson who has also posted a SIP enumservice registration document. >> >>many many thanks to Orit for getting this ready in time for Atlanta >> >> >> Internet Draft O. Levin >> Document: draft-levin-enum-h323-00.txt RADVISION >> >>The E2U+H323 ENUM Service > >Hi Rich, Folks, > >I note that Orit's draft refers [5] to the "extensive" contribution >TD-WP2-0057 >put into the SG16 meeting last week ( I understood that the outcome was that >this was likely to be carved out into separate documents and/or reconsidered). > >- is this draft intended as one of those parts? >- is the h323: URI spec coming out anytime soon? I'm not the person to ask ... I've cc Orit as well on this note. >all the best, > Lawrence >-- >----------------------------------------------------------------------- >Roke Manor Research : This information is provided "as is" and is not >: intended to create any contractual or legal > : relationship. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 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 mailnull@www1.ietf.org Mon Oct 28 14:05:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24961 for ; Mon, 28 Oct 2002 14:05:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SJ7LX10645 for enum-archive@odin.ietf.org; Mon, 28 Oct 2002 14:07:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SJ7Kv10608; Mon, 28 Oct 2002 14:07:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SJ6Hv10154 for ; Mon, 28 Oct 2002 14:06:17 -0500 Received: from nic-naa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24924 for ; Mon, 28 Oct 2002 14:03:51 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g9SJ6IlU024888; Mon, 28 Oct 2002 14:06:18 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200210281906.g9SJ6IlU024888@nic-naa.net> To: Richard Shockey cc: enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] H.323 enumservice registration ID In-Reply-To: Your message of "Mon, 28 Oct 2002 12:08:34 EST." <5.1.0.14.2.20021028120557.0464ea78@popd.ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24886.1035831978.1@nic-naa.net> Date: Mon, 28 Oct 2002 14:06:18 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Rich, Did you get a -00 privacy I-D in before this morning's cut-off? Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Oct 28 16:10:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00060 for ; Mon, 28 Oct 2002 16:10:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SLCih18117 for enum-archive@odin.ietf.org; Mon, 28 Oct 2002 16:12:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SLCbv18109; Mon, 28 Oct 2002 16:12:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SLBcv18088 for ; Mon, 28 Oct 2002 16:11:38 -0500 Received: from radvpost.RADVISION.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29997 for ; Mon, 28 Oct 2002 16:09:11 -0500 (EST) Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Oct 2002 16:09:10 -0500 Message-ID: From: Orit Levin To: "'Richard Shockey'" , Lawrence Conroy Cc: enum@ietf.org Subject: RE: [Enum] H.323 enumservice registration ID Date: Mon, 28 Oct 2002 16:09:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi guys! It is a very good observation. I have been contemplating this morning how I can clearly explain the past and future events that are required in order for the whole thing to happen. I will try to do it below: 1. The basic form of H.323 URL is a part of H.323v4 (that has been approved on Nov. 2000). [Done] 2. Basic H.323 URL needs to be registered with the IANA. [In the past was dependant on (1) and the IETF process]. Good news: it becomes a part of IPTEL WG agenda. I am resubmitting 05 draft for the Atlanta meeting and we all hope that it gets registered sooooon. 3. Revised telephone-uri needs to be registered with the IANA. [Annex O below depends on it] 4. H.323 Annex O (i.e. TD-WP2-0057) defines H.323 URL parameters and location procedures for H.323 systems using DNS (including SRV records' lookup). For example, one of the parameters is "user=phone" enabling inclusion of a telephone-uri within the H.323 URL. [Annex O approval is pending the standard revised telephone-uri definition and scheduled for the next ITU-T meeting! We hope that till the next ITU-T meeting (Q.1 2003) the revised telephone-uri will be approved and registered with IANA] Up till two weeks ago Annex O also included the ENUM definitions for H.323. During the last ITU-T meeting, it was suggested (by Siemens delegation, specifically) to create a separate H.323 Annex for ENUM for H.323. [It makes a lot of sense and would also resolve the standards' dependency issues as shown below] 5. The revised ENUM specification is approved. 6. The H.323 new ENUM Annex [dependant on Annex O] is approved. 7. The H.323 ENUM registration with IANA is performed. As you could see, the "ENUM for H.323" registration is the last thing to accomplish in this long standardization chain. That being said, it is a good thing to start the ball rolling, put some pressure on the standardization bodies and, most importantly, to create serious technical discussions among interested parties. I really hope that it helped somehow to clarify the issue. See you in Atlanta, Orit Levin Chief Architect RADVISION Tel: +1.201.6896330 > -----Original Message----- > From: Richard Shockey [mailto:rich.shockey@NeuStar.com] > Sent: Monday, October 28, 2002 1:57 PM > To: Lawrence Conroy > Cc: enum@ietf.org; Orit Levin > Subject: Re: [Enum] H.323 enumservice registration ID > > At 06:36 PM 10/28/2002 +0000, Lawrence Conroy wrote: > >At 12:08 pm -0500 28/10/02, Richard Shockey wrote: > >>This document has gone in the queue...I'm making it available early for > >>your review ... > >> > >>I'll be adding Orit and this Draft to the ENUM WG agenda as well along > >>with Jon Peterson who has also posted a SIP enumservice registration > document. > >> > >>many many thanks to Orit for getting this ready in time for Atlanta > >> > >> > >> Internet Draft O. Levin > >> Document: draft-levin-enum-h323-00.txt RADVISION > >> > >>The E2U+H323 ENUM Service > > > >Hi Rich, Folks, > > > >I note that Orit's draft refers [5] to the "extensive" contribution > >TD-WP2-0057 > >put into the SG16 meeting last week ( I understood that the outcome was > that > >this was likely to be carved out into separate documents and/or > reconsidered). > > > >- is this draft intended as one of those parts? > >- is the h323: URI spec coming out anytime soon? > > > I'm not the person to ask ... I've cc Orit as well on this note. > > > > >all the best, > > Lawrence > >-- > >----------------------------------------------------------------------- > >Roke Manor Research : This information is provided "as is" and is not > >: intended to create any contractual or legal > > : relationship. > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > 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 mailnull@www1.ietf.org Mon Oct 28 16:52:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01406 for ; Mon, 28 Oct 2002 16:52:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SLsQe19891 for enum-archive@odin.ietf.org; Mon, 28 Oct 2002 16:54:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SLsOv19886; Mon, 28 Oct 2002 16:54:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SLrhv19865 for ; Mon, 28 Oct 2002 16:53:43 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01367 for ; Mon, 28 Oct 2002 16:51:14 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g9SLrNb23457; Mon, 28 Oct 2002 21:53:23 GMT Message-Id: <5.1.0.14.2.20021028164916.042f7cd0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 16:53:38 -0500 To: Eric Brunner-Williams in Portland Maine From: Richard Shockey Subject: Re: [Enum] H.323 enumservice registration ID Cc: enum@ietf.org In-Reply-To: <200210281906.g9SJ6IlU024888@nic-naa.net> References: 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 www1.ietf.org id g9SLrhv19866 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit At 02:06 PM 10/28/2002 -0500, you wrote: >Rich, > >Did you get a -00 privacy I-D in before this morning's cut-off? Yes.. it may take a while for it to make it through so.... ############################## IETF ENUM WG Internet Draft Richard Shockey Document: NeuStar,Inc draft-shockey-enum-privacy-security-00.txt Expires: March 2003 October 2002 Privacy and Security Considerations in ENUM Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Many individuals and groups have expressed concerns about the privacy and security of personal information to be established in implementations of RFC 2916. This document discusses some of the technical as well as security and privacy considerations national implementations of ENUM should consider. This is a work in progress. Input from security and privacy experts is welcome. Expires - April 2003 [Page 1] draft-shockey-enum-privacy-security-00.txt October 2002 Discussion of this document is welcomed on the IETF ENUM mailing list. General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1) Introduction...............................................2 2) THE RATIONALE FOR ENUM.....................................3 3) THREE VIEWS OF ENUM........................................4 3.1 NUMBER TRANSLATION DATABASE...............................4 3.2 CALLED PARTY CONTROL OF ENUM ENABLED COMMUNICAITONS.......5 3.2.1 THE USE OF REAL AND OR ALIAS NAMES IN A SIP ADDRESS-OF- RECORD........................................................6 3.3 CALLING PARTY CONTROL OF COMMUNICATIONS...................7 3.4 OBSERVATIONS ON CALLED PARTY VS CALLING PARTY CONTROL.....8 4) WHAT INFORMATION IS NECESSARY FOR ENUM REGISTRATION?.......8 5) PRIVACY AND DATA PROTECTION CONSIDERATIONS IN THE NORTH AMERICAN CONTEXT.................................................9 6) PRIVACY and DATA PROTECTIONS CONSIDERATIONS IN THE EUROPEAN COMMUNITY CONTEXT...............................................10 7) SECURITY CONSIDERATIONS IN ENUM...........................10 7.1 SECURITY OF THE DNS......................................10 7.2 SECURITY OF ENUM PROVISIONING INFRASTRUCTURE.............10 8) References................................................10 9) Acknowledgments...........................................11 10) Author's Addresses........................................11 1) Introduction Readers of this Internet Draft are expected to have a working knowledge of the technology and principals embodied in [RFC2916bis]. Many individuals groups have expressed concerns about the privacy and data security implications of ENUM as it moves forward toward global deployment. In that context there are several different views Shockey Expires – April 2003 [Page 2] draft-shockey-enum-privacy-security-00.txt October 2002 of what ENUM is, what it does, and how a global ENUM system may affect personal privacy and the security of data contained in the global ENUM system. It is important to note that ENUM is first and foremost the DNS. Specifically ENUM is a system that translates E.164 phone numbers [ITU-T] into Fully Qualified Domain Names that can be queried to return a specific set of data (URI’s)in the form of NAPTR records [RFC 3403]. The global and distributed nature of the DNS means delegation and control can occur at any point within the ENUM defined FQDN. Many entities, service providers, enterprises and indeed some consumers could, control their own DNS servers for ENUM registered domain names. There are two forms of data required for the ENUM system to work. First is the actual data to be entered into the global ENUM DNS system, the NAPTR records, that can be accessed by any IP end point any where in the world, without restriction and second, the data that will be required to maintain appropriate authentication, valid registration, administrative and technical contact for DNS servers. Issues involving domain name registration are well known to the privacy and security communities and have continually surfaced in context with the Domain Name Registration industry and ICANN approved registry-registrar business practices. The agreements between the IAB and the ITU over the management and control of the e164.arpa namespace [RFC 3026] for those portions of the E.164 global numbering plan clearly articulates that the administration, management and control of the zones and administrative portions of the E.164 plan are nation-state issues governed by appropriate national laws and regulations, many of which have yet to be determined. 2) THE RATIONALE FOR ENUM Before a discussion of privacy and security issues can be applied to various parts of the global ENUM system it is essential to note why the IETF technical community developed ENUM, what applications it was designed to serve and the implications of those applications for privacy and security issues. Shockey Expires – April 2003 [Page 3] draft-shockey-enum-privacy-security-00.txt October 2002 Since Telephone Numbers are the global naming and addressing scheme for Public Switched Telephony, ENUM was designed to map phone numbers with the Internet DNS and its naming and addressing conventions (IP numbers and Domain Names). Principally ENUM enables the use of phone numbers as identifiers of services defined as URI’s on the Internet as well as facilitate the interconnection of systems that rely on telephone numbers with those that use URI’s to route transactions. It is well known that businesses and consumers are very comfortable with using telephone numbers for PSTN communications. The E.164 numbering plan is a well organized and internationally recognized system of naming and addressing that is essential to the proper functioning of the PSTN. Phone Numbers have the additional advantage of being easily understood, are a useful input mechanism on billions of terminal devices (telephones) that do not have QWERTY like keyboards and, significantly, are linguistically neutral, unlike domain names. Though it is clear that ENUM can and will be used for service routing of applications other than voice, the principal focus of attention on ENUM application development has, naturally, been voice communications based on SIP [RFC 3261] and ITU developed H.323, and the general concept of convergence in IP and PSTN networks. 3) THREE VIEWS OF ENUM Even within the technical community there are different views of what ENUM is and what it is designed to accomplish. 3.1 NUMBER TRANSLATION DATABASE One view sees ENUM in the DNS as essentially a benign number translation database that exposes on the minimal subset of data necessary to establish a connection between two endpoints. This is the model we essentially have in the DNS now. DNS translates the URI concept such as http://www.foobar.org to an IP number necessary for a client to find a server running HTTP. No other intervention by the DNS is necessary. Shockey Expires – April 2003 [Page 4] draft-shockey-enum-privacy-security-00.txt October 2002 This is also the function of the DNS in E-mail where the DNS is used to locate an MX record for a SMTP server within a domain. No policy or personal information is exposed in the DNS beyond a server name. This concept is roughly analogous to the concept of a Service Control Point within the architecture of the PSTN that provide routing data to a circuit switch based on the numeric input of a phone number. 3.2 CALLED PARTY CONTROL OF ENUM ENABLED COMMUNICAITONS An emerging view of ENUM is that it enables an advanced form of called party control of communications since it is presumed that the communications servers at the edge of network are under the administrative or operational control of the called party. Called party control of those servers permits policy in some form to be directly applied to inbound communications irrespective of the wishes of the calling party. This view is particularly relevant in the case of SIP based communication [PETERSON et.al.]. The classic SIP model is based on the use of proxies between end point client/user agents that can then negotiate information about each other in order to establish a session. The calling party has no need to discover the capabilities of the called parties end point since those are established during the signaling portion of a SIP session using Session Description Protocol. The called parties proxy can also be used to enforce policy about sessions including how, when and from whom to establish sessions. The presumption of this model is that only the minimum information about an endpoint is necessary to expose in the global DNS, since the proxies perform all other forms of session negotiation and policy enforcement. Consequently it is not necessary to expose in the DNS whether a particular SIP endpoint supports voice, instant messaging, video or fax or whether that endpoint operates on a wire line or wireless connection. Shockey Expires – April 2003 [Page 5] draft-shockey-enum-privacy-security-00.txt October 2002 3.3.1 THE USE OF REAL AND OR ALIAS NAMES IN A SIP ADDRESS-OF-RECORD. Because SIP can negotiate the session creation between end points, it is not necessary expose in the global DNS specific personal identification elements, such as a personal name, to establish a successful end-to-end SIP connection. Information, such as a personal name, is exposed only because an end user chooses to do so by configuration of their entries into the DNS. For example, a classic example of a ENUM response with a SIP URI using a personal name might be as follows: $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:patrik.faltstrom@foobar.se!" One alternative method of achieving the same result with out exposing a real name is to configure the called parties ENUM DNS entries to use other forms of names as aliases. In the following example, the identification of the SIP endpoint is configured using the generic format "sip:e164number@userdomain.foo" $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:4689761234@foobar.se!" OR $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:anon5613@foobar.se!" Where the user name "anon5616" is randomly selected. Notice that the ENUM query only returns information that a SIP proxy for the user "4689761234" or "anon5616" exists within the domain foobar.se. No personal information is exposed in the global DNS other than the domain to which a SIP proxy exists and a form of user name. From the perspective of the called parties SIP proxy, if properly configured, there is no functional difference between sip:patrik.faltstrom@foobar.se or sip:4689761234@foobar.se or sip:anon5651@foobar.se. Shockey Expires – April 2003 [Page 6] draft-shockey-enum-privacy-security-00.txt October 2002 All three could accurately describe a unique SIP client or user agent and transactions could be routed equally among all three names. These examples illustrate an alternate view of what is necessary to establish a connection between two parties using ENUM and SIP. This concept of can easily be applied to many applications which can be ENUM enabled. An individual may choose give out a form of personal SIP URI using their personal on their business card, but there is no practical reason this must be entered into the global DNS. Current discussion in the IETF ENUM WG have explored the concept of indirect resolution to all forms of communications, not just SIP, through the use of presence servers or a concept called a Service resolution service. Once again the called party who is registering their phone number in the global ENUM system would then have control of how he or she could be contacted by any method. The concept of a Service Resolution Service has not been defined in the IETF, however it is within the realm of technical possibility. TBD Examples 3.3 CALLING PARTY CONTROL OF COMMUNICATIONS One other view of ENUM wishes to give the calling party the maximum control and options over how they wish to contact someone else. The preference here is for the maximum amount of information exposed in the DNS to permit the calling party the choice of contact methodology to the called party. Not only are all potential communications endpoints exposed in the global DNS but verbose hints to the nature and capabilities of those endpoints are described in the NAPTR enumservice field.[BRADNER] The ENUM DNS query returns all the available URI’s listed, however the in these examples the called party has chosen to display other attributes about those services such as voice:home, sip:im , voice:mobile,mailto, etc. Shockey Expires – April 2003 [Page 7] draft-shockey-enum-privacy-security-00.txt October 2002 A client application or service parses the NAPTR records and displays the various options and the calling party then selects the most appropriate option based on their preference and not that of the called party. $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip:voice:home" "!^.*$!sip:patrik.faltstrom@foobar.se!" IN NAPTR 100 10 "u" "E2U+sip:voice:mobile" " !^.*$!sip:faltstrom@carrier.se!" IN NAPTR 100 10 "u" "E2U+mailto" "!^.*$!mailto:faltstrom@dorame.se!" IN NAPTR 100 10 "u" "E2U+sip:im" "!^.*$!sip:patrik@hugesoftwareco.se!" IN NAPTR 100 10 "u" "E2U+sip:fax" "!^.*$!sip:patrik@fasolaredo.se!" 3.4 OBSERVATIONS ON CALLED PARTY VS CALLING PARTY CONTROL It would be unreasonable and inappropriate to conclude that either view of ENUM enabled communications is right or wrong. There are clearly circumstances where consumers or businesses, for various reasons, might prefer each option. A variety of businesses and enterprises my wish to expose and individually describe the maximum number of contact points in the global DNS order to facilitate communications by calling parties by the most convenient means available. Consumers may prefer information about them to be masked or aliases in the DNS, in order to benefit from advanced IP communications, such as SIP, while preserving personal preferences and privacy. What is important is ENUM and the global ENUM system is flexible enough to permit either concept. The choice is directly a function of called parties registering their E.164 resources in the global ENUM system and configuring their NAPTR resources appropriately to their wishes. 4) WHAT OTHER INFORMATION IS NECESSARY FOR ENUM REGISTRATION? Shockey Expires – April 2003 [Page 8] draft-shockey-enum-privacy-security-00.txt October 2002 Various national ENUM groups have emerged with the task of developing policies and procedures for administrating the ENUM system within their various jurisdictions. Many of these forums have described a multi-tier model for ENUM registration and provisioning that will require some forms of personal data to be collected and stored as well as technical contact data on who is the responsible party for the management of the authoritive name servers that hold and manage ENUM records. Many concepts and principals have been borrowed from domain name registration where there are three distinct parties to the transaction, Registrant, Registrar and Registry. Various jurisdictions have different laws and regulations regarding data acquisition and the protection of data acquired from consumers (registrants). (See 5 and 6) Unlike the ICANN administered domain name industry, the global ENUM system has no requirement for a central WHOIS registry of registrants. Information on whom or what entity is in administrative control of a phone number is widely available as a part of normal telephone service subscription. What is different about the ENUM system is that it depends on the security and stability of DNS servers to function properly. It is necessary and prudent that this technical contact data for these servers be widely available to network administrators so that they can be contacted in the event there is a technical problem with aspects of the DNS under their management and control. Consequently it is suggested that national ENUM implementations SHOULD implement a form of WHOIS for the technical contact data appropriate to the registration of a E.164 number. 5) PRIVACY AND DATA PROTECTION CONSIDERATIONS IN THE NORTH AMERICAN CONTEXT TBD Shockey Expires – April 2003 [Page 9] draft-shockey-enum-privacy-security-00.txt October 2002 6) PRIVACY and DATA PROTECTIONS CONSIDERATIONS IN THE EUROPEAN COMMUNITY CONTEXT TBD 7) SECURITY CONSIDERATIONS IN ENUM 7.1 SECURITY OF THE DNS The security issues surrounding the DNS are well understood. This has enormous implications for emerging national ENUM administrations. In particular a DNS request can be subject to man-in-the-middle attacks where the response from the DNS may be altered in transit. This has serious implications for the accuracy and authentication of responses from the DNS to ENUM formatted queries by applications. The IETF has developed DNSSEC [ARENDS] to authenticate that the responses from the DNS are indeed from the zone from which they have been requested, however DNSSEC is still in early testing and deployment and has not been deployed in a large scale environment such as generic or country code Top Level Domain.[RFC 3130] Consequently it is premature for emerging national ENUM administrations to consider mandating DNSSEC for those Country Code zones and administrative number ranges under their control until such time as there is sufficient operational experience with DNSSEC. 7.2 SECURITY OF ENUM PROVISIONING INFRASTRUCTURE. TBD 8) References 1. [RFC2916bis] Faltstrom, P.& Mealling,M. “The E.164 to URI DDDS Applications”,draft-ietf-enum-rfc2916bis-01.txt, (work in progress), May 2002 Shockey Expires – April 2003 [Page 10] draft-shockey-enum-privacy-security-00.txt October 2002 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3. [ITU-T], "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. 4. [RFC3026] Blaine, R. ”Liaison to IETF/ISOC on ENUM” RFC 3026,January 2001 5. [RFC 3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The URI Resolution Application", RFC 3403 October 2002. 6. [PETERSON] Peterson, J. etal, “Using ENUM for SIP Applications”, draft-ietf-sipping-e164.02.txt, (work in progress), October 2002 7. [BRANDER] Brandner, R. et.al."Categorical enumservices", draft-brandner-enum-categorical-enumservices-00.txt, (work in progress, June 2002 8. [DNSEXT] Arends, R.,“DNS Security Introduction and Requirements”, draft-ietf-dnsext-dnssec-intro-03.txt, (work in progress) October 2002 9. [RFC 3130] Lewis, E. “Notes from the State-Of-The-Technology: DNSSEC” RFC 3130, June 2001 9) Acknowledgments The original suggestion for this document came from Allison Mankin and Scott Bradner. 10) Author's Addresses Richard Shockey NeuStar, Inc 46000 Center Oak Plaza Sterling, VA 20166 Phone: +1 571 434 5651 Email: richard.shockey@neustar.biz Shockey Expires – April 2003 [Page 11] draft-shockey-enum-privacy-security-00.txt October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 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 mailnull@www1.ietf.org Mon Oct 28 18:23:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03609 for ; Mon, 28 Oct 2002 18:23:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SNPqZ24230 for enum-archive@odin.ietf.org; Mon, 28 Oct 2002 18:25:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SNPmv24221; Mon, 28 Oct 2002 18:25:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SNOsv24198 for ; Mon, 28 Oct 2002 18:24:54 -0500 Received: from nic-naa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03578 for ; Mon, 28 Oct 2002 18:22:24 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g9SNOqlU025887; Mon, 28 Oct 2002 18:24:52 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200210282324.g9SNOqlU025887@nic-naa.net> To: enum@ietf.org cc: brunner@nic-naa.net Subject: Re: [Enum] H.323 enumservice registration ID In-Reply-To: Your message of "Mon, 28 Oct 2002 16:53:38 EST." <5.1.0.14.2.20021028164916.042f7cd0@popd.ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25885.1035847492.1@nic-naa.net> Date: Mon, 28 Oct 2002 18:24:52 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Richard, Item 4, the data necessary (and sufficient) for enum registration, may be easier to understand if everything that isn't "enum" is ignored. The sets of additional data necessary and sufficient to support fee-for-service, a hierarchy of state and an authoritative (ouch) root for distributed state (aka "multi-tier"), and aaa and data collection models can be added on as variations identify themselves. Item 5, and 6, there is a lot on ths subject. Pointers to the literature maay suffice. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Oct 28 20:32:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06344 for ; Mon, 28 Oct 2002 20:32:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9T1Yo829964 for enum-archive@odin.ietf.org; Mon, 28 Oct 2002 20:34:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T1Yjv29959; Mon, 28 Oct 2002 20:34:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T1Xkv29931 for ; Mon, 28 Oct 2002 20:33:46 -0500 Received: from maynard.mail.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06330 for ; Mon, 28 Oct 2002 20:31:17 -0500 (EST) Received: from user-uivenli.dsl.mindspring.com ([165.247.94.178] helo=dick.ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 186LG3-0001OV-00; Mon, 28 Oct 2002 20:33:28 -0500 Message-Id: <5.1.0.14.2.20021028203230.01dc59c0@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 20:33:54 -0500 To: Eric Brunner-Williams in Portland Maine , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] H.323 enumservice registration ID In-Reply-To: <200210282324.g9SNOqlU025887@nic-naa.net> 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-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 06:24 PM 10/28/2002 -0500, Eric Brunner-Williams in Portland Maine wrote: >Richard, > >Item 4, the data necessary (and sufficient) for enum registration, may be >easier to understand if everything that isn't "enum" is ignored. The sets >of additional data necessary and sufficient to support fee-for-service, a >hierarchy of state and an authoritative (ouch) root for distributed state >(aka "multi-tier"), and aaa and data collection models can be added on as >variations identify themselves. > >Item 5, and 6, there is a lot on ths subject. Pointers to the literature >maay suffice. send them along if you have some that are particularly relevant...in either context NA or EC...I'm sure folks on the list will find them valuable. tks >Eric >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 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 mailnull@www1.ietf.org Mon Oct 28 20:48:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06574 for ; Mon, 28 Oct 2002 20:48:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9T1o5h31029 for enum-archive@odin.ietf.org; Mon, 28 Oct 2002 20:50:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T1o4v31024; Mon, 28 Oct 2002 20:50:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T1nPv30989 for ; Mon, 28 Oct 2002 20:49:25 -0500 Received: from nic-naa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06560 for ; Mon, 28 Oct 2002 20:46:56 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g9T1nMlU026402; Mon, 28 Oct 2002 20:49:22 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200210290149.g9T1nMlU026402@nic-naa.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Richard Shockey cc: Eric Brunner-Williams in Portland Maine , enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] H.323 enumservice registration ID In-Reply-To: Message from Richard Shockey of "Mon, 28 Oct 2002 20:33:54 EST." <5.1.0.14.2.20021028203230.01dc59c0@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Oct 2002 20:49:22 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > send them along if you have some that are particularly relevant...in either > context NA or EC...I'm sure folks on the list will find them valuable. I'm more interested in the necessary and sufficient data and service mapping, the gist of item 4. I've done 5 and 6 several times, someone else can enjoy a tour through the woods. Canada is an OEDC jurisdiction, so +1 isn't uniform. Cheers, Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Oct 30 06:22:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09414 for ; Wed, 30 Oct 2002 06:22:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UBOo526945 for enum-archive@odin.ietf.org; Wed, 30 Oct 2002 06:24:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UBOev26932; Wed, 30 Oct 2002 06:24:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UBJpv26647 for ; Wed, 30 Oct 2002 06:19:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08658; Wed, 30 Oct 2002 06:17:27 -0500 (EST) Message-Id: <200210301117.GAA08658@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 30 Oct 2002 06:17:26 -0500 Subject: [Enum] I-D ACTION:draft-peterson-enum-sip-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : enumservice registration for SIP Addresses-of-Record Author(s) : J. Peterson Filename : draft-peterson-enum-sip-00.txt Pages : 16 Date : 2002-10-29 This document registers an ENUM service for SIP (the Session Initiation Protocol), pursuant to the guidelines in RFC2916bis. Specifically, this document focuses on provisioning SIP addresses-of- record in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-peterson-enum-sip-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-peterson-enum-sip-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-peterson-enum-sip-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: <2002-10-29125933.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-peterson-enum-sip-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-peterson-enum-sip-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-29125933.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Oct 30 10:25:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19234 for ; Wed, 30 Oct 2002 10:25:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UFRgK09689 for enum-archive@odin.ietf.org; Wed, 30 Oct 2002 10:27:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UFRdv09684; Wed, 30 Oct 2002 10:27:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UFOpv09582 for ; Wed, 30 Oct 2002 10:24:51 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19062 for ; Wed, 30 Oct 2002 10:22:25 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g9UFOlb16266 for ; Wed, 30 Oct 2002 15:24:47 GMT Message-Id: <5.1.0.14.2.20021030102453.02332e88@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 10:25:14 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-02.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >To: IETF-Announce: ; >Cc: sipping@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Date: Wed, 30 Oct 2002 06:20:16 -0500 >Subject: [Sipping] I-D ACTION:draft-ietf-sipping-e164-02.txt >Sender: sipping-admin@ietf.org >X-BeenThere: sipping@ietf.org >X-Mailman-Version: 2.0.12 >List-Unsubscribe: , > >List-Id: SIPPING Working Group (applications of SIP) >List-Post: >List-Help: >List-Subscribe: , > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Session Initiation Proposal Investigation >Working Group of the IETF. > > Title : Using ENUM for SIP Applications > Author(s) : J. Peterson, H. Liu, J. Yu, B. Campbell > Filename : draft-ietf-sipping-e164-02.txt > Pages : 24 > Date : 2002-10-29 > >Although SIP was clearly one of the primary applications for which >ENUM was created, there is nevertheless widespread uncertainty about >the use of SIP with ENUM. This document illustrates how the two >protocols might work in concert, and clarifies the authoring and >processing of ENUM records for SIP applications. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-02.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-sipping-e164-02.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-sipping-e164-02.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: <2002-10-29130610.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sipping-e164-02.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 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 mailnull@www1.ietf.org Thu Oct 31 09:56:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22577 for ; Thu, 31 Oct 2002 09:56:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VEw1k03759 for enum-archive@odin.ietf.org; Thu, 31 Oct 2002 09:58:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VEvcv03749; Thu, 31 Oct 2002 09:57:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VErwv03577 for ; Thu, 31 Oct 2002 09:53:59 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22100 for ; Thu, 31 Oct 2002 09:51:31 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g9VErtb20842 for ; Thu, 31 Oct 2002 14:53:55 GMT Message-Id: <5.1.0.14.2.20021031095115.042a11c8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Oct 2002 09:51:29 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: I-D ACTION:draft-shockey-enum-privacy-security-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-shockey-enum-privacy-security-00.txt >Date: Thu, 31 Oct 2002 06:13:03 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Privacy and Security Considerations in ENUM > Author(s) : R. Shockey > Filename : draft-shockey-enum-privacy-security-00.txt > Pages : 12 > Date : 2002-10-30 > >Many individuals and groups have expressed concerns about the >privacy and security of personal information to be established in >implementations of RFC 2916. This document discusses some of the >technical as well as security and privacy considerations national >implementations of ENUM should consider. >This is a work in progress. Input from security and privacy >experts is welcome. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-shockey-enum-privacy-security-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-shockey-enum-privacy-security-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-shockey-enum-privacy-security-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: <2002-10-30155401.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-shockey-enum-privacy-security-00.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 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