From enum-bounces@ietf.org Fri Feb 03 11:20:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F53g0-0001NX-0M; Fri, 03 Feb 2006 11:20:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F53fx-0001MN-Nm for enum@megatron.ietf.org; Fri, 03 Feb 2006 11:20:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16432 for ; Fri, 3 Feb 2006 11:18:57 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F53rP-0001Be-AQ for enum@ietf.org; Fri, 03 Feb 2006 11:32:35 -0500 Received: from [10.31.32.117] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k13GKqSM007010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Feb 2006 08:20:53 -0800 Message-ID: <43E382BF.5030402@shockey.us> Date: Fri, 03 Feb 2006 11:20:15 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Subject: [Enum] [Fwd: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org -------- Original Message -------- Subject: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA Date: Fri, 03 Feb 2006 00:00:01 -0500 From: ietf-secretariat@ietf.org To: ietf-announce@ietf.org There are two (2) Internet-Draft cutoff dates for the 65th IETF Meeting in Dallas, TX, USA: February 27th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, February 27th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, February 20th at 9:00 AM ET. March 6th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, March 6th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, March 20th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 65th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_65.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 03 11:35:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F53tm-00026n-Hy; Fri, 03 Feb 2006 11:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F53tk-00025G-Hi for enum@megatron.ietf.org; Fri, 03 Feb 2006 11:35:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17886 for ; Fri, 3 Feb 2006 11:32:55 -0500 (EST) Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F544u-0001r4-AN for enum@ietf.org; Fri, 03 Feb 2006 11:46:34 -0500 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1F53sf-0004n7-00 for enum@ietf.org; Fri, 03 Feb 2006 17:33:53 +0100 Date: Fri, 3 Feb 2006 17:33:25 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Enum] Why not re-use interim procedures for infrastructure ENUM? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi! I'd like to start a discussion about an alternative proposal to address the problem, on how tree infrastructure ENUM should look like (more details at the bottom of this email): Why can't we apply the same (interim) procedures for infrastructure ENUM ( http://www.itu.int/ITU-T/inr/enum/ ) as they exist for User ENUM? Those (interim) procedures have been set up with User ENUM in mind, but IMHO those procedure are _not_ restricted to User ENUM only. Therefore I believe, we could introduce a new infrastructure ENUM zone rather smoothly, without any need for changes at ITU or NRA level. Of course, discussions with RIPE are needed, but I do not expect any major disagreements or delay with RIPE. The zone for infrastructure ENUM could e.g. look like: - infra.e164.arpa. or - e164i.arpa. for all country codes, and there would be no branching between the numbers, as described in draft-haberler-carrier-enum-01. So why not to take this path forward and re-use, what is already out there, instead of introducing a new technical solution, which lacks backward compatibility? Or did I miss something? cheers, Bernie PS: Background of my proposal for discussion: ----------------------------------------- There are discussions ongoing, on how an infrastructure ENUM tree should look like. One solution is described in http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-01.txt That I/D dicusses two options on how a infractructure ENUM tree could look like, i.e. 1) Having a new subdomain of e164.arpa. (e.g. infra.e164.arpa.) 2) Making branches between country code and the rest of a E.164 number (e.g. 1.2.3.4.5.6.7.8.9.infra.1.4.e164.arpa.) Note, that I adjusted the terminology in the examples to reflect the recent decision about the naming convention (carrier -> infrastructure). Option 2) is further discussed and a solution is proposed. However, from technical point of view, option 2) is a bad choice, e.g. it is not backward compatibel. Option 1) is clean and easy from the technical point of view, but the authors of that I/D are affraid, that the process of introducing such a subdomain will delay the introduction of infrastructure ENUM: "In the first case, heavy involvement of ITU-T, RIPE as well as the applicable NRAs (National Regulatory Authorities) is needed during the setup phase. Also, reopening the discussion of the interim procedures already agreed is a tedious process, as is the adaptation of the current delegation mechanism." _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 03 11:57:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54FI-0003vd-FS; Fri, 03 Feb 2006 11:57:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54FF-0003uz-BH for enum@megatron.ietf.org; Fri, 03 Feb 2006 11:57:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19888 for ; Fri, 3 Feb 2006 11:55:24 -0500 (EST) Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F54Qc-0002h6-4w for enum@ietf.org; Fri, 03 Feb 2006 12:09:03 -0500 X-VirusChecked: Checked X-Env-Sender: sdlind@att.com X-Msg-Ref: server-8.tower-124.messagelabs.com!1138985757!6689462!12 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2087 invoked from network); 3 Feb 2006 16:56:46 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-8.tower-124.messagelabs.com with SMTP; 3 Feb 2006 16:56:46 -0000 Received: from KCCLUST05EVS1.ugd.att.com (135.38.164.86) by attrh3i.attrh.att.com (7.2.052) id 43D3BB52001B18CC; Fri, 3 Feb 2006 11:56:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Fri, 3 Feb 2006 10:56:44 -0600 Message-ID: Thread-Topic: [Enum] Why not re-use interim procedures for infrastructure ENUM? Thread-Index: AcYo4A41TW4fTCRiStGOS2UsIYbprgAAccMg From: "Lind, Steven D, ALABS" To: "Bernie Hoeneisen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Bernie, I think you've oversimplified the problem. You certainly could introduce a new tree or branch of the current tree above the country code, but the ITU would definitely have to change its procedures to recognize both trees. A country could opt-in to either of the two trees, both of them, or neither of them. The current interim procedures assume there is only one tree.=20 The national sovereignty issue still exists, so if you introduce something above the country code, the ITU must address it somehow. My fear is that it will reignite the same debate that has taken place in Study Group 2 over the last 4+ years. While some service providers, particularly in Europe, are concerned over the current delegation placement, the only way to avoid the ITU debate would be to make the provider ENUM tree branch below the country code, thus making such decisions national matters. Thanks for raising this issue again, it is a very important one. Steve -------------------------------------------------------- Steven D. Lind, AT&T Tel: 973-236-6787 180 Park Avenue, Rm. A201 Fax: 360-343-2875 Florham Park, NJ 07932 e-mail: sdlind@att.com -------------------------------------------------------- =20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Bernie Hoeneisen > Sent: Friday, February 03, 2006 11:33 AM > To: enum@ietf.org > Subject: [Enum] Why not re-use interim procedures for=20 > infrastructure ENUM? >=20 > Hi! >=20 > I'd like to start a discussion about an alternative proposal=20 > to address=20 > the problem, on how tree infrastructure ENUM should look like > (more details at the bottom of this email): >=20 > Why can't we apply the same (interim) procedures for=20 > infrastructure ENUM > ( http://www.itu.int/ITU-T/inr/enum/ ) as they exist for User ENUM? > Those (interim) procedures have been set up with User ENUM in=20 > mind, but=20 > IMHO those procedure are _not_ restricted to User ENUM only. >=20 > Therefore I believe, we could introduce a new infrastructure=20 > ENUM zone=20 > rather smoothly, without any need for changes at ITU or NRA level. > Of course, discussions with RIPE are needed, but I do not expect > any major disagreements or delay with RIPE. >=20 > The zone for infrastructure ENUM could e.g. look like: > - infra.e164.arpa. or > - e164i.arpa. > for all country codes, and there would be no branching between the=20 > numbers, as described in draft-haberler-carrier-enum-01. >=20 > So why not to take this path forward and re-use, what is already out=20 > there, instead of introducing a new technical solution, which lacks=20 > backward compatibility? Or did I miss something? >=20 > cheers, > Bernie >=20 >=20 > PS: >=20 > Background of my proposal for discussion: > ----------------------------------------- >=20 > There are discussions ongoing, on how an infrastructure ENUM=20 > tree should=20 > look like. One solution is described in >=20 > =20 > http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-01.txt >=20 > That I/D dicusses two options on how a infractructure ENUM tree could=20 > look like, i.e. >=20 > 1) Having a new subdomain of e164.arpa. (e.g. infra.e164.arpa.) >=20 > 2) Making branches between country code and the rest of a E.164 > number (e.g. 1.2.3.4.5.6.7.8.9.infra.1.4.e164.arpa.) >=20 > Note, that I adjusted the terminology in the examples to=20 > reflect the > recent decision about the naming convention (carrier ->=20 > infrastructure). >=20 >=20 > Option 2) is further discussed and a solution is proposed. > However, from technical point of view, option 2) is a bad choice, > e.g. it is not backward compatibel. >=20 > Option 1) is clean and easy from the technical point of view, but the=20 > authors of that I/D are affraid, that the process of=20 > introducing such a=20 > subdomain will delay the introduction of infrastructure ENUM: >=20 > "In the first case, heavy involvement of ITU-T, RIPE as well as the > applicable NRAs (National Regulatory Authorities) is needed during > the setup phase. Also, reopening the discussion of the interim > procedures already agreed is a tedious process, as is the=20 > adaptation > of the current delegation mechanism." >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 03 15:46:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57pG-0004O4-6M; Fri, 03 Feb 2006 15:46:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57pE-0004Mu-Ko for enum@megatron.ietf.org; Fri, 03 Feb 2006 15:46:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08865 for ; Fri, 3 Feb 2006 15:44:58 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F580s-0003wx-MZ for enum@ietf.org; Fri, 03 Feb 2006 15:58:39 -0500 Received: from [10.31.13.171] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k13KkuoD013389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Feb 2006 12:46:57 -0800 Message-ID: <43E3C128.9010905@shockey.us> Date: Fri, 03 Feb 2006 15:46:32 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Subject: [Enum] United States ENUM Trial (1.e164.arpa) Launches Feburary 21 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Press Release Source: Country Code 1 ENUM LLC US ENUM Trial Launches February 21 Friday February 3, 11:33 am ET Companies Interested in Participating in the Trial Should Plan on Attending This Meeting DENVER--(BUSINESS WIRE)--Feb. 3, 2006--The Country Code 1 ENUM LLC (LLC) today announced the formation of a committee to coordinate testing activities among participants in its upcoming US ENUM trial. The first meeting of this committee, to be known as the LLC's Trial Participants Advisory Committee (TPAC), will take place in Richardson, Texas, on February 21, 2006. Companies who have an interest in participating in the trial should plan on attending this meeting. Meeting details will be posted on the LLC's web site (http://enumllc.com). The US ENUM trial will be based on the ENUM Forum's "Framework Document for a US/CC1 ENUM Trials Program," which can be found at http://www.enumf.org/home. The U.S. trial is expected to be conducted over a six-month period beginning in March. Companies wishing to participate can fulfill one or more of the defined roles for the trial: Tier 1B Registry, Tier 2 Nameserver Provider, Registrar, Authorization Agency, Host Carrier, Application Service Provider, and User Registrant. Companies choosing to participate are responsible for their own costs and will be expected to sign a Memorandum of Understanding with the CC1 ENUM LLC, which will be available on the LLC's web site (http://enumllc.com). Several telecommunications and Internet companies have already indicated an interest in participating. ENUM is a technology that allows users to combine the resources of the Internet with traditional telephony, uniting these two diverse worlds of communications and enabling a whole new range of communication applications. The ENUM system effectively enables individuals, businesses and other organizations to maximize the use of both the public Internet and the Public Switched Telephone Network (PSTN) by associating telephone numbers with Internet domain names. As a result, phone numbers can be used to send traditional telephony services like voice calls or faxes which can be converted to packets for delivery to a variety of devices. On December 1, 2005, the U.S. government requested the temporary delegation of country code 1 to support an ENUM trial. That request was also supported in letters from the Canadian and Jamaican governments. Confirmation of the delegation is expected in mid-February, with the US ENUM trial expected to start in early March. During the next year, other NANP member countries may conduct national ENUM trials as well. The TPAC will coordinate the various trial activities and report the results of the trial to the LLC, which will publish the results and report them to various governmental agencies that have been following the industry's efforts toward ENUM implementation. The TPAC will be chaired by a Project Executive to be contracted for and selected by the LLC. Additional details and registration information for the meeting on February 21 will be posted on the LLC's web site. About Country Code 1 ENUM LLC The founding companies of Country Code 1 ENUM LLC are seeking to build a commercial implementation consistent with the relevant open standards of the Internet Engineering Task Force (IETF) and the International Telecommunication Union (ITU) upon which ENUM is based. The new company will help to implement a single, public ENUM system for those nations within the NANP that choose to participate. The North American implementation of ENUM will adhere to national and industry privacy requirements. Country Code 1 ENUM LLC will manage the public infrastructure that translates traditional telephone numbers into Internet domain names, combining the reach and capabilities of the Internet with the Public Switched Telephone Network (PSTN) to enable new communications capabilities. Contact: Karen N. Mulberry Sr. Project Manager, Numbering Verizon Network Architecture & Standards Office: +1.972.729.7914 Wireless: +1.972.896.8686 Fax: +1.425.963.5445 Pager: +1.800.664.2965 PLEASE NOTE NEW EMAIL ADDRESS Email: karen.mulberry@verizon.com Strategic Advantage, Inc. Dale Jones, 303-298-9630 -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 03 15:50:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57sw-0005Wu-3u; Fri, 03 Feb 2006 15:50:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57sa-0005Qg-Lg; Fri, 03 Feb 2006 15:50:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09136; Fri, 3 Feb 2006 15:48:25 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F584D-0004CY-Hp; Fri, 03 Feb 2006 16:02:05 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F57sY-0006Uv-4N; Fri, 03 Feb 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 03 Feb 2006 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-epp-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author(s) : B. Hoeneisen Filename : draft-ietf-enum-validation-epp-02.txt Pages : 25 Date : 2006-2-3 This document describes an EPP extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-epp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-validation-epp-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-enum-validation-epp-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. --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: <2006-2-3133214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-validation-epp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-validation-epp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-3133214.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Fri Feb 03 15:54:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57x3-0006EW-Gp; Fri, 03 Feb 2006 15:54:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57x1-0006E9-Tw for enum@megatron.ietf.org; Fri, 03 Feb 2006 15:54:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09688 for ; Fri, 3 Feb 2006 15:52:51 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F588T-0004OA-BD for enum@ietf.org; Fri, 03 Feb 2006 16:06:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Feb 2006 21:57:04 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4802@oefeg-s04.oefeg.loc> Thread-Topic: [Speermint] speermint now a working group Thread-Index: AcYo4NZyYnmFojL1RmyWyrGUmZWUBQAI4zfc From: "Stastny Richard" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Subject: [Enum] WG: [Speermint] speermint now a working group X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org And the other good news: ________________________________ Von: speermint-bounces@ietf.org im Auftrag von David Meyer Gesendet: Fr 03.02.2006 17:38 An: speermint@ietf.org Cc: Jason_Livingood@cable.comcast.com; jon.peterson@neustar.biz Betreff: [Speermint] speermint now a working group Folks, The IESG ok'ed the speermint charter yesterday, with Jason and me will as the co-chairs. So we're ready to go. I'll request a slot for Dallas, and I would like all of you to submit proposed agenda items to Jason and me. We'd also like to thank Allison Mankin for all of her support in shepherding us through the process, and Jon Peterson for his support in getting the WG chartered. Looking forward to seeing you all in Dallas. Dave & Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 03 19:05:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5AvY-0001kC-Vn; Fri, 03 Feb 2006 19:05:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5AvW-0001fs-OX for enum@megatron.ietf.org; Fri, 03 Feb 2006 19:05:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28954 for ; Fri, 3 Feb 2006 19:03:39 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F5B7C-0005Jb-2p for enum@ietf.org; Fri, 03 Feb 2006 19:17:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Sat, 4 Feb 2006 01:08:55 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4804@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Why not re-use interim procedures for infrastructure ENUM? Thread-Index: AcYo4A41TW4fTCRiStGOS2UsIYbprgAAccMgAA18nGg= From: "Stastny Richard" To: "Lind, Steven D, ALABS" , "Bernie Hoeneisen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Bernie, Steven, =20 In principle Bernie is correct, but only in principle, because also = Steven has a point in stating that this is an oversimplification. and it would IMHO unwise politically not to involve the ITU at all. =20 Michael and I have been discussing the issue off-list with some key = players to find potential ways forward. =20 We have studied the interim procedures=20 http://www.itu.int/ITU-T/inr/enum/procedures.html and came to the conclusion that the interim procedures COULD also be used for delegations within an Infrastructure ENUM tree such as proposed e.g. i.e164.arpa or e164i.arpa =20 The reasons for this are: 1. The interim procedures do NOT state ANY apex for ENUM at all, not even in e164.arpa, so the apex is not mentioned and therefor not = defined. =20 "These interim procedures are consistent with the agreed SG2 statement = that Member States will have the right to choose whether to participate = in the common designated ENUM domain, or not to participate in it, at = their discretion, and with the procedures currently under development as = specified in the future Recommendation(s). " =20 2. So basically it is at the discretion of the member states to = participate in the common designated ENUM domain. =20 3. The taslk of the ITU TSB according to the interim procedures is only = (somewhat simplfied): =20 a. When the TSB receives a request from RIPE NCC, it will first verify = that the country code (CC) mentioned in the request meets the formal = conditions for delegation for ENUM, namely: that the code is a = currently-assigned country code, ... =20 b If the (above) condition is met, and if the concerned Member State has = notified the TSB of its position regarding delegation for ENUM of its = CC, then the TSB will immediately make that position known to RIPE NCC. = ... =20 Period. =20 What has to be changed in any case is the RIPE procedures http://www.ripe.net/enum/instructions.html because these procedures given by IAB are clearly for e164.arpa 1. Instructions to the RIPE NCC regarding operations of the doamin = e164.arpa =20 So here the IAB MUST update the instructions to RIPE for the (to be = defined) infrastructure domain AND RIPE must be willing to host in addition also = the apex of this domain, e.g.=20 1 Instructions to the RIPE NCC regarding operations of the doamin = e164.arpa AND i.e164.arpa =20 A concerned Member state may now send in independently TWO requests to = RIPE and notify ITU TSB independantly for each request. =20 Michael Haberler and I are currently working on an up-issue for=20 http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-01.txt = = =20 proposing this way forward. =20 Since it is unclear if this works out in IAB, RIPE and ITU-T, and if, how long this takes, we still will include the second option, branching off the tree below, because this allows member states to IMMEDIATELY start trials or implementations of Infrastructure ENUM in a co-ordinated and compatible way. =20 Note: member states could do this anyway on their own discretion at any = time now in any part below their cc-code or in a completely different tree, but our proposal simply allows to put a pointer in e164.arpa to allow = internatioal interworking If finally the issues are worked out, the data could fe folded back into the common infrastructure tree at any time also at the discretion of the country. =20 The currently envisaged way forward is - discuss the proposal at the IETF meeting in Dallas The IETF (and the IAB) should come to a conclusion before RIPE and especially the ITU is involved. (note: if this is agreed, a simple addition of one or two lines to RFC3761 is sufficient) =20 - the next ITU SG2 meeting takes place first half of May 2005 so enough time to prepare a D contribution to explain the issue. (requires IAB and RIPE to principally agree) =20 - if ITU SG2 accepts that the interim procedures are also sufficient for valid requests of member states, it may instruct the ITU TSB by stating this in the meeting report to approve also requests to RIPE for infrastructure ENUM delegations in the same way as it is done now for User ENUM requests. This would be the optimum =20 - if ITU SG2 is not stating this in the meeting report (this could be for various reasons, eg no decision is made, the interim procedures need change, etc.) the next ITU SG2 meeting is in January 2006, (because of the ITU Plenipot Meeting in Fall in Turkey) =20 - in this case we could still proceed with option 2. best regards Richard Stastny ________________________________ Von: enum-bounces@ietf.org im Auftrag von Lind, Steven D, ALABS Gesendet: Fr 03.02.2006 17:56 An: Bernie Hoeneisen; enum@ietf.org Betreff: RE: [Enum] Why not re-use interim procedures for infrastructure = ENUM? Bernie, I think you've oversimplified the problem. You certainly could introduce a new tree or branch of the current tree above the country code, but the ITU would definitely have to change its procedures to recognize both trees. A country could opt-in to either of the two trees, both of them, or neither of them. The current interim procedures assume there is only one tree. The national sovereignty issue still exists, so if you introduce something above the country code, the ITU must address it somehow. My fear is that it will reignite the same debate that has taken place in Study Group 2 over the last 4+ years. While some service providers, particularly in Europe, are concerned over the current delegation placement, the only way to avoid the ITU debate would be to make the provider ENUM tree branch below the country code, thus making such decisions national matters. Thanks for raising this issue again, it is a very important one. Steve -------------------------------------------------------- Steven D. Lind, AT&T Tel: 973-236-6787 180 Park Avenue, Rm. A201 Fax: 360-343-2875 Florham Park, NJ 07932 e-mail: sdlind@att.com -------------------------------------------------------- > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > Behalf Of Bernie Hoeneisen > Sent: Friday, February 03, 2006 11:33 AM > To: enum@ietf.org > Subject: [Enum] Why not re-use interim procedures for > infrastructure ENUM? > > Hi! > > I'd like to start a discussion about an alternative proposal > to address > the problem, on how tree infrastructure ENUM should look like > (more details at the bottom of this email): > > Why can't we apply the same (interim) procedures for > infrastructure ENUM > ( http://www.itu.int/ITU-T/inr/enum/ ) as they exist for User ENUM? > Those (interim) procedures have been set up with User ENUM in > mind, but > IMHO those procedure are _not_ restricted to User ENUM only. > > Therefore I believe, we could introduce a new infrastructure > ENUM zone > rather smoothly, without any need for changes at ITU or NRA level. > Of course, discussions with RIPE are needed, but I do not expect > any major disagreements or delay with RIPE. > > The zone for infrastructure ENUM could e.g. look like: > - infra.e164.arpa. or > - e164i.arpa. > for all country codes, and there would be no branching between the > numbers, as described in draft-haberler-carrier-enum-01. > > So why not to take this path forward and re-use, what is already out > there, instead of introducing a new technical solution, which lacks > backward compatibility? Or did I miss something? > > cheers, > Bernie > > > PS: > > Background of my proposal for discussion: > ----------------------------------------- > > There are discussions ongoing, on how an infrastructure ENUM > tree should > look like. One solution is described in > > =20 > http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-01.txt > > That I/D dicusses two options on how a infractructure ENUM tree could > look like, i.e. > > 1) Having a new subdomain of e164.arpa. (e.g. infra.e164.arpa.) > > 2) Making branches between country code and the rest of a E.164 > number (e.g. 1.2.3.4.5.6.7.8.9.infra.1.4.e164.arpa.) > > Note, that I adjusted the terminology in the examples to > reflect the > recent decision about the naming convention (carrier -> > infrastructure). > > > Option 2) is further discussed and a solution is proposed. > However, from technical point of view, option 2) is a bad choice, > e.g. it is not backward compatibel. > > Option 1) is clean and easy from the technical point of view, but the > authors of that I/D are affraid, that the process of > introducing such a > subdomain will delay the introduction of infrastructure ENUM: > > "In the first case, heavy involvement of ITU-T, RIPE as well as the > applicable NRAs (National Regulatory Authorities) is needed during > the setup phase. Also, reopening the discussion of the interim > procedures already agreed is a tedious process, as is the > adaptation > of the current delegation mechanism." > > > > > > _______________________________________________ > 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 enum-bounces@ietf.org Sat Feb 04 18:07:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5WUh-0007bo-Qy; Sat, 04 Feb 2006 18:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5WUe-0007aM-8y; Sat, 04 Feb 2006 18:07:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16389; Sat, 4 Feb 2006 18:05:08 -0500 (EST) Received: from extmail09.cingular.com ([170.35.225.24] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5WgJ-00078Q-Ra; Sat, 04 Feb 2006 18:19:04 -0500 Received: from ([10.3.188.52]) by extmail09.cingular.com with ESMTP id KP-VYGZ6.56623417; Sat, 04 Feb 2006 18:06:19 -0500 Received: by s75202e004001.tdc.cingular.net with Internet Mail Service (5.5.2657.72) id <1FCB4FKL>; Sat, 4 Feb 2006 17:09:51 -0600 Message-ID: To: speermint@ietf.org, enum@ietf.org Date: Sat, 4 Feb 2006 17:07:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) From: "Stafford, Matthew" X-Spam-Score: 0.4 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c Cc: Subject: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1607742672==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1607742672== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C629DF.B67981A0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C629DF.B67981A0 Content-Type: text/plain I strongly agree with the following statement from draft-lendl-sip-peering-policy (lifted verbatim from section 6.2): => RFC 3263 builds on that. Quote: => If a SIP proxy, redirect server, or registrar is to be contacted => through the lookup of NAPTR records, there MUST be at least three => records - one with a "SIP+D2T" service field, one with a "SIP+D2U" => service field, and one with a "SIPS+D2T" service field. => => This "MUST" needs to be reconsidered in this context, as it forces => VSP to accept calls over unsecured SIP transports. In fact, I would go further, as explained below. The "u" flag defined in RFC 3761 doesn't say how to interpret the domain name in the returned URI. In the case of a SIP URI, RFC 3263 signaling (in particular, an additional layer of dereferencing embodied in a second NAPTR) makes perfect sense to me in a situation where you know nothing about the domain. But should RFC 3263 be "universally normative" for SIP URIs? It seems to me that the entity that provisions an ENUM NAPTR will in many cases already know something useful about the target domain. As a simple for-instance, suppose "transport=tcp" is included in the sip URI (as allowed by RFC 3261). In this case, there would be an efficiency advantage if the ENUM response could be followed directly by an SRV query. So I have argued that there will be circumstances where the second NAPTR doesn't buy you much. Of course there will also be circumstances where RFC 3263 signaling is warranted. I'm cross-posting to the ENUM working group for the following reason: flags could be used to distinguish the two kinds of signaling flows. Say a "g" flag (mnemonic for Gateway) that tells the recipient of the ENUM NAPTR that there is an SRV record (w/domain in the ENUM NAPTR as key) pointing to the gateway. I think the example just described is worthwhile. Moreover, I think the Lendl draft suggests that there are additional scenarios that might be facilitated by via new ENUM flags. I'm not clear whether this sort of thing would end up in "3761bis", so to speak, or in another document. Either way, I'd like to float the idea and see if there's interest. Best, Matt Stafford Vice Chair of Addressing Task Force, GSM North America ----------------------------------- Matthew Stafford Principal Member of Technical Staff Cingular Wireless, Inc. 9505 Arboretum Blvd Austin TX 78759 matthew.stafford@cingular.com Voice : +1(512)372-5623 Fax : +1(512)372-5891 ----------------------------------- This email and any files transmitted with it are property of Cingular Wireless, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 512/372-5623 and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this email is strictly prohibited. ------_=_NextPart_001_01C629DF.B67981A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I strongly agree with the following statement from draft-lendl-sip-peering-policy (lifted verbatim from section = 6.2):

 

=3D>   RFC 3263 builds on that.  = Quote:

=3D>      If a SIP = proxy, redirect server, or registrar is to be contacted

=3D>      through the = lookup of NAPTR records, there MUST be at least = three

=3D>      records - one = with a "SIP+D2T" service field, one with a = "SIP+D2U"

=3D>      service field, = and one with a "SIPS+D2T" service field.

=3D>

=3D>   This "MUST" needs to = be reconsidered in this context, as it forces

=3D>   VSP to accept calls over = unsecured SIP transports.

 

In fact, I would go further, as explained = below.

 

The "u" flag defined in RFC 3761 doesn't = say how to interpret the domain name in the returned URI. In the case of a SIP = URI, RFC 3263 signaling (in particular, an additional layer of dereferencing = embodied in a second NAPTR) makes perfect sense to me in a situation where you know = nothing about the domain.

 

But should RFC 3263 be "universally = normative" for SIP URIs? It seems to me that the entity that provisions an ENUM NAPTR = will in many cases already know something useful about the target domain. As a = simple for-instance, suppose "transport=3Dtcp" is included in the = sip URI (as allowed by RFC 3261). In this case, there would be an efficiency = advantage if the ENUM response could be followed directly by an SRV = query.

 

So I have argued that there will be circumstances = where the second NAPTR doesn't buy you much. Of course there will also be = circumstances where RFC 3263 signaling is warranted. I'm cross-posting to the ENUM = working group for the following reason: flags could be used to distinguish the = two kinds of signaling flows. Say a "g" flag (mnemonic for = Gateway) that tells the recipient of the ENUM NAPTR that there is an SRV record = (w/domain in the ENUM NAPTR as key) pointing to the = gateway.

 

I think the example just described is worthwhile. = Moreover, I think the Lendl draft suggests that there are additional scenarios = that might be facilitated by via new ENUM flags. I'm not clear whether this sort = of thing would end up in "3761bis", so to speak, or in another = document. Either way, I'd like to float the idea and see if there's = interest.

 

Best,

Matt Stafford

Vice Chair of Addressing Task Force, GSM North = America

 

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

Matthew Stafford

Principal Member of Technical Staff =

Cingular Wireless, Inc. =

9505 = Arboretum Blvd Austin TX 78759 =

matthew.stafford@cingular.com

Voice : +1(512)372-5623 =

Fax : +1(512)372-5891

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

This email and any files transmitted with it are = property of Cingular Wireless, are confidential, and are intended solely for the = use of the individual or entity to whom this email is addressed. If you are not = one of the named recipient(s) or otherwise have reason to believe that you have = received this message in error, please notify the sender at 512/372-5623 and = delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this email is = strictly prohibited.

 

------_=_NextPart_001_01C629DF.B67981A0-- --===============1607742672== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1607742672==-- From enum-bounces@ietf.org Sun Feb 05 07:33:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5j54-0007zK-GX; Sun, 05 Feb 2006 07:33:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5j52-0007xT-Ht; Sun, 05 Feb 2006 07:33:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04226; Sun, 5 Feb 2006 07:31:34 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5jGr-0002dY-25; Sun, 05 Feb 2006 07:45:37 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 1E0777BA20; Sun, 5 Feb 2006 12:32:27 +0000 (GMT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <82A9B943-EEDE-49F4-B2D0-96FF6E162232@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Date: Sun, 5 Feb 2006 12:32:25 +0000 To: "Stafford, Matthew" , Otmar Lendl X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Matt, Otmar, folks, This is an interesting posting for several reasons. The first is the process issue - what group (if any) coordinates between the different DDDS applications and their uses; this topic covers D2x NAPTRs (natural territory for SIP/SIPPING), E2U NAPTRs (natural territory for ENUM), and their use for peering (welcome, SPEERMINT). If it's useful to add clarifications for DDDS itself then who or what does that? To the substance of the post: I'm sure Otmar was not suggesting that D2x NAPTRs MUST be available for all domains before a SIP exchange can occur. For Service Providers it's fine, but... There are a number of individuals who do not need or use an intermediary provider for their SIP exchanges, so adding D2U NAPTRs is "overkill" I, for example, do not have D2x NAPTRs in my zone; there's no target domain redirection, so the NAPTRs would not be useful. I only have one SIP proxy so one could even argue that SRVs are excessive - it's not exactly a load balanced system. However, for Service Providers, we enter new territories. Do you know that your customers will want *every* insecure SIP invite to fail (i.e. those customers have said to you explicitly that a _sip transaction is not acceptable)? Is is a regulatory requirement that you at least tell the caller that this call has failed though a terminating service like UCB, rather than not even accept the attempt? Lastly, adding a new flag for ENUM *in general* is going to cause some problems for application developers like me - ALL of my ENUM clients will have to support this, or else these will be non-compliant to any 3761bis. It seems that your proposal is purely for Carrier/ Infrastructure/ Private ENUM; in this case, changing 3761 has unintended consequences for Public/User ENUM applications. It appears that the proposed 'g' flag is appropriate only for SIP use within Carrier ENUM, so one could WELL argue that this is an issue for the SIP URI - I don't see how it can be used for other Enumservices (like email:mailto, for example). Perhaps adding a SIP parameter (akin to ;user=phone) would be more appropriate, or adding a new Enumservice to run alongside the existing SIP one (i.e. to develop a new Enumservice definition RFC to specify a SIP Gateway service)? all the best, Lawrence On 4 Feb 2006, at 23:07, Stafford, Matthew wrote: > I strongly agree with the following statement from draft-lendl-sip- > peering-policy (lifted verbatim from section 6.2): > > => RFC 3263 builds on that. Quote: > > => If a SIP proxy, redirect server, or registrar is to be > contacted > > => through the lookup of NAPTR records, there MUST be at least > three > > => records - one with a "SIP+D2T" service field, one with a > "SIP+D2U" > > => service field, and one with a "SIPS+D2T" service field. > > => > > => This "MUST" needs to be reconsidered in this context, as it > forces > > => VSP to accept calls over unsecured SIP transports. > > In fact, I would go further, as explained below. > > The "u" flag defined in RFC 3761 doesn't say how to interpret the > domain name in the returned URI. In the case of a SIP URI, RFC 3263 > signaling (in particular, an additional layer of dereferencing > embodied in a second NAPTR) makes perfect sense to me in a > situation where you know nothing about the domain. > > But should RFC 3263 be "universally normative" for SIP URIs? It > seems to me that the entity that provisions an ENUM NAPTR will in > many cases already know something useful about the target domain. > As a simple for-instance, suppose "transport=tcp" is included in > the sip URI (as allowed by RFC 3261). In this case, there would be > an efficiency advantage if the ENUM response could be followed > directly by an SRV query. > > So I have argued that there will be circumstances where the second > NAPTR doesn't buy you much. Of course there will also be > circumstances where RFC 3263 signaling is warranted. I'm cross- > posting to the ENUM working group for the following reason: flags > could be used to distinguish the two kinds of signaling flows. Say > a "g" flag (mnemonic for Gateway) that tells the recipient of the > ENUM NAPTR that there is an SRV record (w/domain in the ENUM NAPTR > as key) pointing to the gateway. > > I think the example just described is worthwhile. Moreover, I think > the Lendl draft suggests that there are additional scenarios that > might be facilitated by via new ENUM flags. I'm not clear whether > this sort of thing would end up in "3761bis", so to speak, or in > another document. Either way, I'd like to float the idea and see if > there's interest. > > Best, > > Matt Stafford > > Vice Chair of Addressing Task Force, GSM North America _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Feb 05 11:26:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5miV-00013D-PV; Sun, 05 Feb 2006 11:26:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5miT-0000zQ-42; Sun, 05 Feb 2006 11:26:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23192; Sun, 5 Feb 2006 11:24:41 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5muT-00016h-T5; Sun, 05 Feb 2006 11:38:46 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k15GQP2r024116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Feb 2006 08:26:26 -0800 Message-ID: <43E62708.407@shockey.us> Date: Sun, 05 Feb 2006 11:25:44 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows References: <82A9B943-EEDE-49F4-B2D0-96FF6E162232@insensate.co.uk> In-Reply-To: <82A9B943-EEDE-49F4-B2D0-96FF6E162232@insensate.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, speermint@ietf.org, Otmar Lendl X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org lconroy wrote: > Hi Matt, Otmar, folks, > This is an interesting posting for several reasons. > The first is the process issue - what group (if any) coordinates > between the different DDDS applications and their uses; this topic > covers D2x NAPTRs (natural territory for SIP/SIPPING), E2U NAPTRs > (natural territory for ENUM), and their use for peering (welcome, > SPEERMINT). If it's useful to add clarifications for DDDS itself > then who or what does that? > > To the substance of the post: > I'm sure Otmar was not suggesting that D2x NAPTRs MUST be available > for all domains before a SIP exchange can occur. For Service Providers > it's fine, but... > There are a number of individuals who do not need or use an intermediary > provider for their SIP exchanges, so adding D2U NAPTRs is "overkill" > I, for example, do not have D2x NAPTRs in my zone; there's no target > domain redirection, so the NAPTRs would not be useful. I only have one > SIP proxy so one could even argue that SRVs are excessive - it's not > exactly a load balanced system. > > > Lastly, adding a new flag for ENUM *in general* is going to cause some > problems for application developers like me - ALL of my ENUM clients > will have to support this, or else these will be non-compliant to any > 3761bis. It seems that your proposal is purely for Carrier/Infrastructure/ > Private ENUM; in this case, changing 3761 has unintended consequences for > Public/User ENUM applications. > > It appears that the proposed 'g' flag is appropriate only for SIP use > within > Carrier ENUM, so one could WELL argue that this is an issue for the SIP URI > - I don't see how it can be used for other Enumservices (like email:mailto, > for example). Perhaps adding a SIP parameter (akin to ;user=phone) would be > more appropriate, or adding a new Enumservice to run alongside the existing > SIP one (i.e. to develop a new Enumservice definition RFC to specify a SIP > Gateway service)? Larry I agree with your view. If there were a general requirement for this form of tag its better done as an extension to a Enumservice field. Those fields are quite extensible you can add as many sub-types as you want so long as they are properly defined in a RFC. E2U+sip:gw strikes me as the right way to do this. The purpose of the flag field is not to hint at describe or the nature of endpoint after the rewrite but to define how to process the reg exp under certain defined conditions. This went to our past issue of how to use the replacement field, should someone find a way to use it properly. BTW we have realized we have a bit of a mess with the Enumservice registry in general and we will shortly have a WG draft addressing the problem > > all the best, > Lawrence > > > On 4 Feb 2006, at 23:07, Stafford, Matthew wrote: >> I strongly agree with the following statement from >> draft-lendl-sip-peering-policy (lifted verbatim from section 6.2): >> >> => RFC 3263 builds on that. Quote: >> >> => If a SIP proxy, redirect server, or registrar is to be contacted >> >> => through the lookup of NAPTR records, there MUST be at least three >> >> => records - one with a "SIP+D2T" service field, one with a >> "SIP+D2U" >> >> => service field, and one with a "SIPS+D2T" service field. >> >> => >> >> => This "MUST" needs to be reconsidered in this context, as it forces >> >> => VSP to accept calls over unsecured SIP transports. >> >> In fact, I would go further, as explained below. >> >> The "u" flag defined in RFC 3761 doesn't say how to interpret the >> domain name in the returned URI. In the case of a SIP URI, RFC 3263 >> signaling (in particular, an additional layer of dereferencing >> embodied in a second NAPTR) makes perfect sense to me in a situation >> where you know nothing about the domain. >> >> But should RFC 3263 be "universally normative" for SIP URIs? It seems >> to me that the entity that provisions an ENUM NAPTR will in many cases >> already know something useful about the target domain. As a simple >> for-instance, suppose "transport=tcp" is included in the sip URI (as >> allowed by RFC 3261). In this case, there would be an efficiency >> advantage if the ENUM response could be followed directly by an SRV >> query. >> >> So I have argued that there will be circumstances where the second >> NAPTR doesn't buy you much. Of course there will also be circumstances >> where RFC 3263 signaling is warranted. I'm cross-posting to the ENUM >> working group for the following reason: flags could be used to >> distinguish the two kinds of signaling flows. Say a "g" flag (mnemonic >> for Gateway) that tells the recipient of the ENUM NAPTR that there is >> an SRV record (w/domain in the ENUM NAPTR as key) pointing to the >> gateway. >> >> I think the example just described is worthwhile. Moreover, I think >> the Lendl draft suggests that there are additional scenarios that >> might be facilitated by via new ENUM flags. I'm not clear whether this >> sort of thing would end up in "3761bis", so to speak, or in another >> document. Either way, I'd like to float the idea and see if there's >> interest. >> >> Best, >> >> Matt Stafford >> >> Vice Chair of Addressing Task Force, GSM North America > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Feb 05 11:42:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5myO-0006eS-R1; Sun, 05 Feb 2006 11:42:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5myC-0006dA-QW; Sun, 05 Feb 2006 11:42:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24426; Sun, 5 Feb 2006 11:40:37 -0500 (EST) Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5n9t-0003Bh-6o; Sun, 05 Feb 2006 11:54:42 -0500 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.13.4) with ESMTP id k15GiVVQ025290; Sun, 5 Feb 2006 11:44:31 -0500 Received: from trutkowski-desk.verisign.com ([10.169.64.229]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Feb 2006 11:41:59 -0500 Message-Id: <7.0.1.0.2.20060205110918.035d3d70@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 05 Feb 2006 11:41:58 -0500 To: lconroy , "Stafford, Matthew" , Otmar Lendl From: Tony Rutkowski Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows In-Reply-To: <82A9B943-EEDE-49F4-B2D0-96FF6E162232@insensate.co.uk> References: <82A9B943-EEDE-49F4-B2D0-96FF6E162232@insensate.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 05 Feb 2006 16:41:59.0743 (UTC) FILETIME=[158744F0:01C62A73] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Lawrence, >The first is the process issue - what group (if any) coordinates >between the different DDDS applications and their uses; this topic ... >3761bis. It seems that your proposal is purely for Carrier/ Infrastructure/ >Private ENUM; in this case, changing 3761 has unintended consequences >for Public/User ENUM applications. These are great understatements. The use of E.164 identifiers, internationally and domestically, is subject to more statutory, regulatory, national security, and industry practice requirements than any identifier space in existence - not to mention well established institutional jurisdiction. The following list is a current tabulation of E.164 resolver-directory capability requirements, parsed into three categories, currently in play in various industry NGN forums. The recently enacted EC Data Retention Directive, and the U.S. Prevent Cyberstalking law, add further complexity to the mix. ;-) best, --tony >basic resolver capability > >supplementary capability > Number Portability > Priority Access > Roaming > Quality of Service > Directory Assistance > CallerID > Disability Assistance > Language preference > Personal emergency (E112/911) > Public emergency alerts > Law enforcement assistance > DoNotCall > Payment Methods > Intercarrier Compensation > Profile Management > Presence > Availability > Location > Push Management > Digital Rights Management > Device Management > Authentication Credentials > Information verification level > >protocol feature > Authentication > Auditing > Multiple Syntax Support > Mutiple Language Support > Extensibility and Localisation Mechanisms _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Feb 05 11:51:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5n6o-0000VO-MC; Sun, 05 Feb 2006 11:51:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F56tJ-0005gN-6X for enum@megatron.ietf.org; Fri, 03 Feb 2006 14:46:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04146 for ; Fri, 3 Feb 2006 14:45:07 -0500 (EST) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F574v-0001Ug-4J for enum@ietf.org; Fri, 03 Feb 2006 14:58:47 -0500 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Fri, 3 Feb 2006 14:42:17 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006020314421723965 ; Fri, 03 Feb 2006 14:42:17 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Feb 2006 14:42:17 -0500 Message-Id: From: "Roy, Radhika R." To: "Lind, Steven D, ALABS" , Bernie Hoeneisen , enum@ietf.org Subject: RE: [Enum] Why not re-use interim procedures for infrastructure E NUM? Date: Fri, 3 Feb 2006 14:40:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Sun, 05 Feb 2006 11:51:29 -0500 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi, all: I think that Steve has clarified an important point. Keeping this in mind, let us view all upcoming proposals. Cheers, Radhika _____ From: enum-bounces@ietf.org on behalf of Lind, Steven D, ALABS Sent: Fri 2/3/2006 11:56 AM To: Bernie Hoeneisen; enum@ietf.org Subject: RE: [Enum] Why not re-use interim procedures for infrastructure ENUM? Bernie, I think you've oversimplified the problem. You certainly could introduce a new tree or branch of the current tree above the country code, but the ITU would definitely have to change its procedures to recognize both trees. A country could opt-in to either of the two trees, both of them, or neither of them. The current interim procedures assume there is only one tree. The national sovereignty issue still exists, so if you introduce something above the country code, the ITU must address it somehow. My fear is that it will reignite the same debate that has taken place in Study Group 2 over the last 4+ years. While some service providers, particularly in Europe, are concerned over the current delegation placement, the only way to avoid the ITU debate would be to make the provider ENUM tree branch below the country code, thus making such decisions national matters. Thanks for raising this issue again, it is a very important one. Steve -------------------------------------------------------- Steven D. Lind, AT&T Tel: 973-236-6787 180 Park Avenue, Rm. A201 Fax: 360-343-2875 Florham Park, NJ 07932 e-mail: sdlind@att.com -------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 05:28:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F63c9-000499-R7; Mon, 06 Feb 2006 05:28:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F63c7-00048c-EB for enum@megatron.ietf.org; Mon, 06 Feb 2006 05:28:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04877 for ; Mon, 6 Feb 2006 05:27:11 -0500 (EST) Received: from mail114.messagelabs.com ([195.245.231.163]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F63o8-0004Dc-Sc for enum@ietf.org; Mon, 06 Feb 2006 05:41:26 -0500 X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cwmsg.cwplc.com X-Msg-Ref: server-7.tower-114.messagelabs.com!1139221708!24241971!1 X-StarScan-Version: 5.5.9.1; banners=cwmsg.cwplc.com,-,- X-Originating-IP: [194.6.6.11] Received: (qmail 12223 invoked from network); 6 Feb 2006 10:28:29 -0000 Received: from relay.cwplc.com (HELO relay.cwplc.com) (194.6.6.11) by server-7.tower-114.messagelabs.com with DES-CBC3-SHA encrypted SMTP; 6 Feb 2006 10:28:29 -0000 Received: from GBCWSWIEV001.ad.plc.cwintra.com ([148.185.93.211]) by relay.cwplc.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k16AS5R19392 for ; Mon, 6 Feb 2006 10:28:06 GMT Received: from GBCWSWIEC001.ad.plc.cwintra.com (unverified) by GBCWSWIEV001.ad.plc.cwintra.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Mon, 6 Feb 2006 10:28:55 +0000 Received: from GBCWSWIEM002.ad.plc.cwintra.com ([148.185.93.204]) by GBCWSWIEC001.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Feb 2006 10:28:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Mon, 6 Feb 2006 10:28:55 -0000 Message-ID: <9322B78036E1534A99B0BC51DEB0F9D6022CCEED@GBCWSWIEM002.ad.plc.cwintra.com> Thread-Topic: [Enum] Why not re-use interim procedures for infrastructure ENUM? Thread-Index: AcYo4A41TW4fTCRiStGOS2UsIYbprgAAccMgAA18nGgAe8QtMA== From: "Rosbotham, Paul" To: X-OriginalArrivalTime: 06 Feb 2006 10:28:55.0385 (UTC) FILETIME=[21D30C90:01C62B08] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Thanks=20Richard, I=20like=20your=20way=20forward.=20=20I=20continue=20to=20have=20severe=20= reservations=20of=20the=20Plan=20B=20approach,=20ie=20i.c.c.e164.arpa,=20l= eaving=20things=20to=20national=20matters.=20=20 I=20think=20that=20approach=20is=20fine=20where=20the=20ENUM=20delegation=20= hasn't=20been=20made,=20or=20where=20it's=20been=20made=20for=20limited=20= trial=20purposes.=20=20In=20these=20scenarios,=20the=20choice=20of=20Tier=20= One=20for=20commercial=20service=20could=20then=20be=20made=20according=20= to=20the=20needs=20of=20both=20user=20and=20infrastructure=20ENUM. However,=20where=20delegation=20has=20already=20made=20for=20commercial=20= service,=20this=20delegation=20was=20very=20much=20made=20under=20the=20cr= iteria=20of=20the=20Tier=20One=20being=20selected=20for=20*USER*=20ENUM.=20= =20These=20criteria=20may=20or=20may=20not=20be=20applicable=20for=20infra= structure=20ENUM.=20=20For=20example,=20it=20is=20a=20reasonable=20expecta= tion=20that=20the=20telcos=20in=20the=20country=20concerned=20may=20=20req= uire=20some=20degree=20of=20joint=20control=20over=20the=20infrastructure=20= ENUM=20Tier=20One,=20given=20its=20actions/performance=20would=20be=20crit= ical=20in=20the=20routeing=20of=20calls=20to=20their=20customers.=20=20The= =20choice=20of=20Tier=20One=20for=20User=20ENUM=20certainly=20wouldn't=20h= ave=20factored=20this=20in,=20or=20at=20least=20if=20it=20has=20it=20would= =20be=20by=20co-incidence=20of=20similar=20stakeholder=20communities. Having=20the=20discussion=20at=20ITU=20may=20be=20painful....but=20it=20wi= ll=20be=20far=20less=20painful=20than=20half=20of=20the=20world's=20number= s=20not=20being=20in=20infrastructure=20ENUM=20because=20the=20telco=20ass= ignees=20aren't=20willing=20to=20participate=20in=20something=20that=20the= y=20have=20no=20influence=20over.... Paul=20Rosbotham -----Original=20Message----- From:=20enum-bounces@ietf.org=20[mailto:enum-bounces@ietf.org]On=20Behalf=20= Of Stastny=20Richard Sent:=20Saturday,=20February=2004,=202006=2012:09=20AM To:=20Lind,=20Steven=20D,=20ALABS;=20Bernie=20Hoeneisen;=20enum@ietf.org Subject:=20Re:=20[Enum]=20Why=20not=20re-use=20interim=20procedures=20for=20= infrastructure ENUM? Bernie,=20Steven, =20 In=20principle=20Bernie=20is=20correct,=20but=20only=20in=20principle,=20b= ecause=20also=20Steven has=20a=20point=20in=20stating=20that=20this=20is=20an=20oversimplificatio= n.=20and=20it would=20IMHO=20unwise=20politically=20not=20to=20involve=20the=20ITU=20at=20= all. =20 The=20currently=20envisaged=20way=20forward=20is -=20discuss=20the=20proposal=20at=20the=20IETF=20meeting=20in=20Dallas The=20IETF=20(and=20the=20IAB)=20should=20come=20to=20a=20conclusion before=20RIPE=20and=20especially=20the=20ITU=20is=20involved. (note:=20if=20this=20is=20agreed,=20a=20simple=20addition=20of=20one=20or=20= two=20lines to=20RFC3761=20is=20sufficient) =20 -=20the=20next=20ITU=20SG2=20meeting=20takes=20place=20first=20half=20of=20= May=202005 so=20enough=20time=20to=20prepare=20a=20D=20contribution=20to=20explain the=20issue.=20(requires=20IAB=20and=20RIPE=20to=20principally=20agree) =20 -=20if=20ITU=20SG2=20accepts=20that=20the=20interim=20procedures=20are also=20sufficient=20for=20valid=20requests=20of=20member=20states,=20it may=20instruct=20the=20ITU=20TSB=20by=20stating=20this=20in=20the=20meetin= g report=20to=20approve=20also=20requests=20to=20RIPE=20for=20infrastructure= ENUM=20delegations=20in=20the=20same=20way=20as=20it=20is=20done=20now=20f= or User=20ENUM=20requests.=20This=20would=20be=20the=20optimum =20 -=20if=20ITU=20SG2=20is=20not=20stating=20this=20in=20the=20meeting=20repo= rt (this=20could=20be=20for=20various=20reasons,=20eg=20no=20decision=20is made,=20the=20interim=20procedures=20need=20change,=20etc.) the=20next=20ITU=20SG2=20meeting=20is=20in=20January=202006,=20(because of=20the=20ITU=20Plenipot=20Meeting=20in=20Fall=20in=20Turkey) =20 -=20in=20this=20case=20we=20could=20still=20proceed=20with=20option=202. best=20regards Richard=20Stastny This=20e-mail=20has=20been=20scanned=20for=20viruses=20by=20the=20Cable=20= &=20Wireless=20e-mail=20security=20system=20-=20powered=20by=20MessageLabs= .=20For=20more=20information=20on=20a=20proactive=20managed=20e-mail=20sec= urity=20service,=20=20visit=20http://www.cw.com/uk/emailprotection/=20 =20 The=20information=20contained=20in=20this=20e-mail=20is=20confidential=20a= nd=20may=20also=20be=20subject=20to=20legal=20privilege.=20It=20is=20inten= ded=20only=20for=20the=20recipient(s)=20named=20above.=20If=20you=20are=20= not=20named=20above=20as=20a=20recipient,=20you=20must=20not=20read,=20cop= y,=20disclose,=20forward=20or=20otherwise=20use=20the=20information=20cont= ained=20in=20this=20email.=20If=20you=20have=20received=20this=20e-mail=20= in=20error,=20please=20notify=20the=20sender=20(whose=20contact=20details=20= are=20above)=20immediately=20by=20reply=20e-mail=20and=20delete=20the=20me= ssage=20and=20any=20attachments=20without=20retaining=20any=20copies. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 07:00:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F652i-0002T0-0i; Mon, 06 Feb 2006 07:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F652g-0002SV-KO for enum@megatron.ietf.org; Mon, 06 Feb 2006 07:00:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11519 for ; Mon, 6 Feb 2006 06:58:31 -0500 (EST) Received: from gw3.domain-registry.nl ([193.176.144.141] helo=gw.domain-registry.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F65Ec-0003FJ-Fq for enum@ietf.org; Mon, 06 Feb 2006 07:12:47 -0500 Received: (from root@localhost) by gw.domain-registry.nl (8.9.3c/8.6.12) id MAA55344 for ; Mon, 6 Feb 2006 12:59:48 +0100 (CET) Received: by gw3.domain-registry.nl (TUNIX/Firewall SMTP Server) for id sma055202; Mon, 6 Feb 06 12:58:26 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Mon, 6 Feb 2006 12:58:25 +0100 Message-ID: Thread-Topic: [Enum] Why not re-use interim procedures for infrastructure ENUM? Thread-Index: AcYo4A41TW4fTCRiStGOS2UsIYbprgAAccMgAA18nGgAe8QtMAADTl9w From: "Antoin Verschuren" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Monday, February 06, 2006 11:29 AM Rosbotham, Paul wrote: > However, where delegation has already made for commercial service, > this delegation was very much made under the criteria of the Tier One > being selected for *USER* ENUM. These criteria may or may not be > applicable for infrastructure ENUM. For example, it is a reasonable > expectation that the telcos in the country concerned may require > some degree of joint control over the infrastructure ENUM Tier One, > given its actions/performance would be critical in the routeing of > calls to their customers. The choice of Tier One for User ENUM > certainly wouldn't have factored this in, or at least if it has it > would be by co-incidence of similar stakeholder communities. =20 My motivation to opose to that is strictly apolitical. I would not want to see 2 different clubs trying to develop 2 different kinds of ENUM.=20 For transparancy by the market (for both Users AND Telcos) we should avoid 2 different protocols being developed.=20 I'm in favour of the Infrastructure ENUM tree being delegated under the country code tree so it is clear who is responsible for the delegation rules on a national level, and the technical development and implementation is done by one and the same independent none biased player. =20 There is more than one danger in using ENUM as "club member" definition. Besides the risk of propiatary Infrastructure ENUM solutions being developed, it will also create the posibility that innovative players are refused from the Infrastructure ENUM market for competition reasons, and development of the USER ENUM market might be stopped. =20 I believe that this strategic member club forming should not take place at te ENUM level, but should take place at the (sip) peering level.=20 Telcos' are now trying to abuse ENUM as their peering platform definition since sip peering is not developed enough yet to define parameters like QOS, security level, fee definition etc. This does not belong in the ENUM definition. ENUM is only routing information, not interconnection policy definition. =20 So, ENUM is ENUM, and political games should be played at a different level.=20 The success of ENUM is in the lightweight of the protocol, without overhead information.=20 The overhead should be in the peering definitions, so USER ENUM does not need to be bothered with it.=20 Besides these development issues, I also see operational benefits in a joint User and Infrastructure ENUM registry.=20 When you want to switch from one tree to another (User-Infrastructure) for the same phone number during a lookup, it would be nice if you didn't need to resolve a complete new tree, or aquire new routing Information for your lookup. Lookups wil go faster if both trees are=20 linked lower down in the tree.=20 It's also cheaper if you use the same infrastructure. =20 Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren@sidn.nl W http://www.sidn.nl/ _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 07:48:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F65n9-0004Jw-Gm; Mon, 06 Feb 2006 07:48:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F65n8-0004Jn-RE for enum@megatron.ietf.org; Mon, 06 Feb 2006 07:48:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14566 for ; Mon, 6 Feb 2006 07:46:46 -0500 (EST) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F65zI-0003XJ-HK for enum@ietf.org; Mon, 06 Feb 2006 08:01:03 -0500 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id k16CmCd3027381; Mon, 6 Feb 2006 12:48:12 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Mon, 6 Feb 2006 12:48:06 +0000 To: "Antoin Verschuren" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Feb 6, 2006, at 11:58, Antoin Verschuren wrote: > I'm in favour of the Infrastructure ENUM tree being delegated under > the > country code tree so it is clear who is responsible for the delegation > rules on a national level Antoin, this idea is a non-starter IMO because it requires everything that might play in this space to always have complete, up to date knowledge of E.164 "country codes". Good luck getting the world's handsets and SIP servers -- to pick just two examples -- to do that. The algorithm for transforming an E.164 number into a domain name for Infrastructure/Carrier ENUM has to be simple. Just use RFC3761's with something other than "e164.arpa" as the apex and we're done. For me this discussion is back to front. We're talking about delegation models and suchlike. But no requirements for Infrastructure ENUM have been proposed yet. We don't even appear to have an agreed terminology or definitions. Until this is done, it seems unwise to be discusing what's going to be built or how it will be constructed. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 08:24:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F66MJ-00063n-CV; Mon, 06 Feb 2006 08:24:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F66MH-00063R-K5 for enum@megatron.ietf.org; Mon, 06 Feb 2006 08:24:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17814 for ; Mon, 6 Feb 2006 08:22:44 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F66Y0-0001ii-76 for enum@ietf.org; Mon, 06 Feb 2006 08:37:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Mon, 6 Feb 2006 14:27:43 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C480C@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Why not re-use interim procedures for infrastructure ENUM? Thread-Index: AcYo4A41TW4fTCRiStGOS2UsIYbprgAAccMgAA18nGgAe8QtMAAF8TJ0 From: "Stastny Richard" To: "Rosbotham, Paul" , X-Spam-Score: 0.2 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Pail wrote: >I like your way forward. I continue to have severe reservations of the = Plan B approach, ie i.c.c.e164.arpa, leaving things to >national = matters.=20 It is always national matters >I think that approach is fine where the ENUM delegation hasn't been = made, or where it's been made for limited trial >purposes. In these = scenarios, the choice of Tier One for commercial service could then be = made according to the needs of >both user and infrastructure ENUM. The entity responsible for the delegation may at ANY time switch the = delegation. So if they requested delegation for trial and now go to = commercial service and are not happy with the registry running the = trial, they can request a re-delegation to somebody else >However, where delegation has already made for commercial service, this = delegation was very much made under the criteria >of the Tier One being = selected for *USER* ENUM. These criteria may or may not be applicable = for infrastructure ENUM. >For example, it is a reasonable expectation = that the telcos in the country concerned may require some degree of = joint >control over the infrastructure ENUM Tier One, given its = actions/performance would be critical in the routeing of calls to >their = customers. The choice of Tier One for User ENUM certainly wouldn't have = factored this in, or at least if it has it would >be by co-incidence of = similar stakeholder communities. =20 I sometimes get the impression that some consider User ENUM as a toy and = Infrastructure ENUM as serious. In Austia and also now in Germany there = are businesses depending on User ENUM and they expect both Tier 0 and = Tier 1 to work appropriate. As I said above, it is up to the domain name = holder (the NRA) to select a company running the Tier 1 properly in both = cases, and not to have different requirements for the two. In the above = mentioned option delegating below the CC still another registry running = the Tier 1 may be selected, although delegated to by the User ENUM Tier = 1. On the other hand it should be noted that currently the common consensus = seems to be to go for option 1 splitting Infrastructure ENUM off at or directly below e164.arpa. So the option2 = is only transitory to be used by countries who do not wnat to wait until = the IAB, RIPE and ITU-T thing is sorted out, mainly because nobody now = is able to say how long this might take, but the issue is urgent. >Having the discussion at ITU may be painful....but it will be far less = painful than half of the world's numbers not being in >infrastructure = ENUM because the telco assignees aren't willing to participate in = something that they have no influence >over.... =20 We should not always blame ITU-T. First the issue hads to be sorted out = with the IAB, then with RIPE and only if this is done we should bother = ITU. I should be done until mid of April, but I have slight doubts ;-) >Paul Rosbotham -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of Stastny Richard Sent: Saturday, February 04, 2006 12:09 AM To: Lind, Steven D, ALABS; Bernie Hoeneisen; enum@ietf.org Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? Bernie, Steven, In principle Bernie is correct, but only in principle, because also = Steven has a point in stating that this is an oversimplification. and it would IMHO unwise politically not to involve the ITU at all. The currently envisaged way forward is - discuss the proposal at the IETF meeting in Dallas The IETF (and the IAB) should come to a conclusion before RIPE and especially the ITU is involved. (note: if this is agreed, a simple addition of one or two lines to RFC3761 is sufficient) - the next ITU SG2 meeting takes place first half of May 2005 so enough time to prepare a D contribution to explain the issue. (requires IAB and RIPE to principally agree) - if ITU SG2 accepts that the interim procedures are also sufficient for valid requests of member states, it may instruct the ITU TSB by stating this in the meeting report to approve also requests to RIPE for infrastructure ENUM delegations in the same way as it is done now for User ENUM requests. This would be the optimum - if ITU SG2 is not stating this in the meeting report (this could be for various reasons, eg no decision is made, the interim procedures need change, etc.) the next ITU SG2 meeting is in January 2006, (because of the ITU Plenipot Meeting in Fall in Turkey) - in this case we could still proceed with option 2. best regards Richard Stastny This e-mail has been scanned for viruses by the Cable & Wireless e-mail = security system - powered by MessageLabs. For more information on a = proactive managed e-mail security service, visit = http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be = subject to legal privilege. It is intended only for the recipient(s) = named above. If you are not named above as a recipient, you must not = read, copy, disclose, forward or otherwise use the information contained = in this email. If you have received this e-mail in error, please notify = the sender (whose contact details are above) immediately by reply e-mail = and delete the message and any attachments without retaining any copies. _______________________________________________ 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 enum-bounces@ietf.org Mon Feb 06 08:40:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F66b4-0001nY-Lf; Mon, 06 Feb 2006 08:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F66b3-0001mL-2J for enum@megatron.ietf.org; Mon, 06 Feb 2006 08:40:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18781 for ; Mon, 6 Feb 2006 08:38:20 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F66nE-0004zQ-9M for enum@ietf.org; Mon, 06 Feb 2006 08:52:37 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k16DeJeP010954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2006 05:40:22 -0800 Message-ID: <43E75196.6070002@shockey.us> Date: Mon, 06 Feb 2006 08:39:34 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jim Reid Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jim Reid wrote: > On Feb 6, 2006, at 11:58, Antoin Verschuren wrote: > >> I'm in favour of the Infrastructure ENUM tree being delegated under the >> country code tree so it is clear who is responsible for the delegation >> rules on a national level Functionally however given the interim rules it makes no difference. The delegation of either Infrastructure or User ENUM branch for a specific CC would ultimately require the consent of the appropriate National Regulatory Authority even if the CC had been delegated. > Antoin, this idea is a non-starter IMO because it requires everything > that might play in this space to always have complete, up to date > knowledge of E.164 "country codes". Thank you Jim .. that is exactly the reason. The soft switches and network elements that have to implement the system need the simplest possible rewrite rule delegation at a predetermined apex is IMHO the only way. Good luck getting the world's > handsets and SIP servers -- to pick just two examples -- to do that. The > algorithm for transforming an E.164 number into a domain name for > Infrastructure/Carrier ENUM has to be simple. Just use RFC3761's with > something other than "e164.arpa" as the apex and we're done. That has been my inescapable conclusion since this discussion began. > > For me this discussion is back to front. We're talking about delegation > models and suchlike. But no requirements for Infrastructure ENUM have > been proposed yet. We don't even appear to have an agreed terminology or > definitions. Until this is done, it seems unwise to be discusing what's > going to be built or how it will be constructed. We do have WG items on this and once again Msr's Pfautz and Lind will be reviewing their document in Dallas. All other issues are essentially political. > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 08:53:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F66nw-0005DN-Vs; Mon, 06 Feb 2006 08:53:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F66nv-0005Br-CH for enum@megatron.ietf.org; Mon, 06 Feb 2006 08:53:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19879 for ; Mon, 6 Feb 2006 08:51:36 -0500 (EST) Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6705-0007I2-0v for enum@ietf.org; Mon, 06 Feb 2006 09:05:54 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.13.4) with ESMTP id k16DtgiD028289; Mon, 6 Feb 2006 08:55:44 -0500 Received: from trutkowski-desk.verisign.com ([10.169.64.229]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 08:52:58 -0500 Message-Id: <7.0.1.0.2.20060206083327.035feee8@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 06 Feb 2006 08:52:57 -0500 To: "Stastny Richard" , "Rosbotham, Paul" , From: Tony Rutkowski Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C480C@oefeg-s04.oefeg.loc > References: <32755D354E6B65498C3BD9FD496C7D462C480C@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 06 Feb 2006 13:52:58.0512 (UTC) FILETIME=[A34BF900:01C62B24] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Richard, >The entity responsible for the delegation may at ANY time switch the >delegation. So if they requested delegation for trial and now go to >commercial service and are not happy with the registry running the >trial, they can request a re-delegation to somebody else Sage advice. In the U.S., as in many countries, anyone can get an authorization to do ENUM trials. They are intended only to demonstrate and test technology - usually with performance measurements for use in subsequent proceedings. National public ENUM infrastructure platforms will be determined through regulatory agency proceedings and be expected to meet existing infrastructure requirements. Infrastructure trials don't get morphed into national operational systems. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 08:57:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F66sQ-0006PX-9f; Mon, 06 Feb 2006 08:57:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F66sP-0006Ou-BE for enum@megatron.ietf.org; Mon, 06 Feb 2006 08:57:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20314 for ; Mon, 6 Feb 2006 08:56:08 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F674T-0007Tm-Gs for enum@ietf.org; Mon, 06 Feb 2006 09:10:25 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k16DwAeb013337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2006 05:58:11 -0800 Message-ID: <43E755C5.8000905@shockey.us> Date: Mon, 06 Feb 2006 08:57:25 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? References: <32755D354E6B65498C3BD9FD496C7D462C480C@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C480C@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.0 (+) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "Rosbotham, Paul" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: > Pail wrote: > >> I like your way forward. I continue to have severe reservations of the Plan B approach, ie i.c.c.e164.arpa, leaving things to >national matters. > > It is always national matters Exactly > > We should not always blame ITU-T. First the issue hads to be sorted out with the IAB, then with RIPE and only if this is done we should bother ITU. I should be done until mid of April, but I have slight doubts ;-) > Richard is again right ..we should not blame the ITU-T for being what they are. In fact they seem to be running aspects their operation better than the IETF. The simple fact is the procedures we have in place right now are working remarkably well. Far beyond the expectations of those of us that wrote the rules in the first place. However the "issue" as you call it Richard IMHO would not lie with the IAB. You should re read the charter of the IAB. It would lie with the IESG upon creation of the appropriate RFC that designated an Infrastructure apex. If the RFC is approved there is little or nothing the IAB can do to impede its deployment. Certainly there would have to be renegotiations of various agreements but the working model is in place and could be reasonably modified. So long as the fundamental principal of respect for the national sovereign rights of Nation States to regulate the use of their portions of the E.164 plan is maintained and preserved I do not see a lot of problems at the ITU, only be the usual problems of gratuitous bashing of United States policy over control of the root. > > > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of > Stastny Richard > Sent: Saturday, February 04, 2006 12:09 AM > To: Lind, Steven D, ALABS; Bernie Hoeneisen; enum@ietf.org > Subject: Re: [Enum] Why not re-use interim procedures for infrastructure > ENUM? > > > Bernie, Steven, > > In principle Bernie is correct, but only in principle, because also Steven > has a point in stating that this is an oversimplification. and it > would IMHO unwise politically not to involve the ITU at all. > > The currently envisaged way forward is > > - discuss the proposal at the IETF meeting in Dallas > The IETF (and the IAB) should come to a conclusion > before RIPE and especially the ITU is involved. > (note: if this is agreed, a simple addition of one or two lines > to RFC3761 is sufficient) > > - the next ITU SG2 meeting takes place first half of May 2005 > so enough time to prepare a D contribution to explain > the issue. (requires IAB and RIPE to principally agree) > > - if ITU SG2 accepts that the interim procedures are > also sufficient for valid requests of member states, it > may instruct the ITU TSB by stating this in the meeting > report to approve also requests to RIPE for infrastructure > ENUM delegations in the same way as it is done now for > User ENUM requests. This would be the optimum > > - if ITU SG2 is not stating this in the meeting report > (this could be for various reasons, eg no decision is > made, the interim procedures need change, etc.) > the next ITU SG2 meeting is in January 2006, (because > of the ITU Plenipot Meeting in Fall in Turkey) > > - in this case we could still proceed with option 2. > > best regards > Richard Stastny > > > This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ > > The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. > > _______________________________________________ > 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, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 09:42:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F67Zb-0000Nv-TX; Mon, 06 Feb 2006 09:42:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F67Za-0000NT-Ry for enum@megatron.ietf.org; Mon, 06 Feb 2006 09:42:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23822 for ; Mon, 6 Feb 2006 09:40:38 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F67lY-0005gt-3T for enum@ietf.org; Mon, 06 Feb 2006 09:54:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Mon, 6 Feb 2006 15:45:57 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C480E@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Why not re-use interim procedures for infrastructure ENUM? Thread-Index: AcYrJd983S9QnxxiTFahAnU1H4kBVgABRyO5 From: "Stastny Richard" To: "Richard Shockey" X-Spam-Score: 1.0 (+) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard Shockey wrote: =20 >However the "issue" as you call it Richard IMHO would not lie with the >IAB. You should re read the charter of the IAB. >It would lie with the IESG upon creation of the appropriate RFC that >designated an Infrastructure apex. If the RFC is approved there is >little or nothing the IAB can do to impede its deployment. So to get this going, we first need a RFC 3761bis defining the apex If the IESG approves, IAB will start negotiating with RIPE and ITU Translated to practical issues this means: 1. we have to move forward with our draft to get a workable solution for = the next 1 or 2 years (option2) 2. we also have to start the procedure by creating = draft-enum-rfc3761bis. Since 2 cannot be finished before May 2006, the question is, should be = bother ITU-T already now or wait for January 2007? regards Richard ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Mo 06.02.2006 14:57 An: Stastny Richard Cc: Rosbotham, Paul; enum@ietf.org Betreff: Re: [Enum] Why not re-use interim procedures for infrastructure = ENUM? Stastny Richard wrote: > Pail wrote: > >> I like your way forward. I continue to have severe reservations of = the Plan B approach, ie i.c.c.e164.arpa, leaving things to >national matters. > > It is always national matters Exactly > > We should not always blame ITU-T. First the issue hads to be sorted = out with the IAB, then with RIPE and only if this is done we should bother ITU. I should be done until mid of April, but I have slight doubts ;-) > Richard is again right ..we should not blame the ITU-T for being what they are. In fact they seem to be running aspects their operation better than the IETF. The simple fact is the procedures we have in place right now are working remarkably well. Far beyond the expectations of those of us that wrote the rules in the first place. However the "issue" as you call it Richard IMHO would not lie with the IAB. You should re read the charter of the IAB. It would lie with the IESG upon creation of the appropriate RFC that designated an Infrastructure apex. If the RFC is approved there is little or nothing the IAB can do to impede its deployment. Certainly there would have to be renegotiations of various agreements but the working model is in place and could be reasonably modified. So long as the fundamental principal of respect for the national sovereign rights of Nation States to regulate the use of their portions of the E.164 plan is maintained and preserved I do not see a lot of problems at the ITU, only be the usual problems of gratuitous bashing of United States policy over control of the root. > > > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of > Stastny Richard > Sent: Saturday, February 04, 2006 12:09 AM > To: Lind, Steven D, ALABS; Bernie Hoeneisen; enum@ietf.org > Subject: Re: [Enum] Why not re-use interim procedures for = infrastructure > ENUM? > > > Bernie, Steven, > > In principle Bernie is correct, but only in principle, because also = Steven > has a point in stating that this is an oversimplification. and it > would IMHO unwise politically not to involve the ITU at all. > > The currently envisaged way forward is > > - discuss the proposal at the IETF meeting in Dallas > The IETF (and the IAB) should come to a conclusion > before RIPE and especially the ITU is involved. > (note: if this is agreed, a simple addition of one or two lines > to RFC3761 is sufficient) > > - the next ITU SG2 meeting takes place first half of May 2005 > so enough time to prepare a D contribution to explain > the issue. (requires IAB and RIPE to principally agree) > > - if ITU SG2 accepts that the interim procedures are > also sufficient for valid requests of member states, it > may instruct the ITU TSB by stating this in the meeting > report to approve also requests to RIPE for infrastructure > ENUM delegations in the same way as it is done now for > User ENUM requests. This would be the optimum > > - if ITU SG2 is not stating this in the meeting report > (this could be for various reasons, eg no decision is > made, the interim procedures need change, etc.) > the next ITU SG2 meeting is in January 2006, (because > of the ITU Plenipot Meeting in Fall in Turkey) > > - in this case we could still proceed with option 2. > > best regards > Richard Stastny > > > This e-mail has been scanned for viruses by the Cable & Wireless = e-mail security system - powered by MessageLabs. For more information on = a proactive managed e-mail security service, visit = http://www.cw.com/uk/emailprotection/ > > The information contained in this e-mail is confidential and may also = be subject to legal privilege. It is intended only for the recipient(s) = named above. If you are not named above as a recipient, you must not = read, copy, disclose, forward or otherwise use the information contained = in this email. If you have received this e-mail in error, please notify = the sender (whose contact details are above) immediately by reply e-mail = and delete the message and any attachments without retaining any copies. > > _______________________________________________ > 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, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 09:59:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F67qR-00055g-Ah; Mon, 06 Feb 2006 09:59:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F67qO-00054w-Ln for enum@megatron.ietf.org; Mon, 06 Feb 2006 09:59:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24999 for ; Mon, 6 Feb 2006 09:58:03 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F682N-0000gE-II for enum@ietf.org; Mon, 06 Feb 2006 10:12:22 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id k16ExZl1000260Mon, 6 Feb 2006 14:59:35 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1F67q3-000Ajh-00; Mon, 06 Feb 2006 14:59:35 +0000 Date: Mon, 6 Feb 2006 14:59:35 +0000 From: "Clive D.W. Feather" To: Jim Reid Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? Message-ID: <20060206145934.GG526@finch-staff-1.thus.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jim Reid said: > Antoin, this idea is a non-starter IMO because it requires everything > that might play in this space to always have complete, up to date > knowledge of E.164 "country codes". Not so. You could assume that the country code was always 3 digits long. This would require a little more administration by those countries with 1 or 2 digit codes, but not a lot. Or the rule could be to try 3, 2, and 1 digits in that order. DNS caching will take care of most of the inefficiencies in this. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 10:13:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F683l-0000wQ-Ns; Mon, 06 Feb 2006 10:13:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F683k-0000w1-EZ for enum@megatron.ietf.org; Mon, 06 Feb 2006 10:13:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26044; Mon, 6 Feb 2006 10:11:55 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F68Fn-00025S-G3; Mon, 06 Feb 2006 10:26:13 -0500 Received: from [10.31.32.128] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k16FDrJC023049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2006 07:13:54 -0800 Message-ID: <43E76779.90706@shockey.us> Date: Mon, 06 Feb 2006 10:12:57 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: iesg-secretary@ietf.org, Allison Mankin , "Peterson, Jon" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] Request for Publication - draft-ietf-enum-pstn-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a request for publication for one IETF ENUM WG working group document. A two week WG last call on this document concluded on Feb 6, 2006. The document listed below is being proposed for Standards Track RFC. Status- Proposed Standard Title : IANA Registration for an Enumservice Containing PSTN Signaling Information Author(s) : J. Livingood, R. Shockey Filename : draft-ietf-enum-pstn-03.txt Pages : 12 Date : 2006-1-18 This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype " sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where Number Portability exists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-03.txt -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 10:20:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68AM-0002tI-TI; Mon, 06 Feb 2006 10:20:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68AL-0002rb-S1 for enum@megatron.ietf.org; Mon, 06 Feb 2006 10:20:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26490 for ; Mon, 6 Feb 2006 10:18:47 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F68MT-0002PK-3g for enum@ietf.org; Mon, 06 Feb 2006 10:33:06 -0500 Received: from [10.31.32.128] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k16FKmu4023708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2006 07:20:49 -0800 Message-ID: <43E76919.9020509@shockey.us> Date: Mon, 06 Feb 2006 10:19:53 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? References: <32755D354E6B65498C3BD9FD496C7D462C480E@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C480E@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: > Richard Shockey wrote: > >> However the "issue" as you call it Richard IMHO would not lie with the >> IAB. You should re read the charter of the IAB. > >> It would lie with the IESG upon creation of the appropriate RFC that >> designated an Infrastructure apex. If the RFC is approved there is >> little or nothing the IAB can do to impede its deployment. > > > So to get this going, we first need a RFC 3761bis defining the apex > If the IESG approves, IAB will start negotiating with RIPE and ITU This is only a personal opinion but I do not believe you need to wait for 3761bis this could be defined in a separate document once there is agreement on the requirements. As is usual IETF procedure ..requirements _first_ ..then the solution. > > Translated to practical issues this means: > 1. we have to move forward with our draft to get a workable solution for the next 1 or 2 years (option2) > 2. we also have to start the procedure by creating draft-enum-rfc3761bis. > > Since 2 cannot be finished before May 2006, the question is, should be bother ITU-T already > now or wait for January 2007? > > regards > Richard > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 10:33:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68MQ-0006Rs-PQ; Mon, 06 Feb 2006 10:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68MP-0006RI-Sm for enum@megatron.ietf.org; Mon, 06 Feb 2006 10:33:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27306 for ; Mon, 6 Feb 2006 10:31:12 -0500 (EST) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F68YT-0003QN-Qr for enum@ietf.org; Mon, 06 Feb 2006 10:45:31 -0500 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id k16FWod3027533; Mon, 6 Feb 2006 15:32:50 GMT In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C480E@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C480E@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Mon, 6 Feb 2006 15:32:44 +0000 To: "Stastny Richard" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Feb 6, 2006, at 14:45, Stastny Richard wrote: > Translated to practical issues this means: > 1. we have to move forward with our draft to get a workable > solution for the next 1 or 2 years (option2) > 2. we also have to start the procedure by creating draft-enum- > rfc3761bis. > > Since 2 cannot be finished before May 2006, the question is, should > be bother ITU-T already > now or wait for January 2007? There doesn't seem any point approaching ITU-T until this WG has something for them to consider. OTOH, it wouldn't hurt to give SG2 a heads-up that this group is working on Infrastructure/Carrier ENUM. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 10:33:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68Ms-0006ZC-Ay; Mon, 06 Feb 2006 10:33:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68Mb-0006Se-Si for enum@megatron.ietf.org; Mon, 06 Feb 2006 10:33:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27315 for ; Mon, 6 Feb 2006 10:31:22 -0500 (EST) Message-Id: <200602061531.KAA27315@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F68Yd-0003QX-0k for enum@ietf.org; Mon, 06 Feb 2006 10:45:41 -0500 Received: (qmail 30782 invoked by uid 510); 6 Feb 2006 10:57:33 -0500 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(67.187.111.112):. Processed in 1.832981 secs); 06 Feb 2006 15:57:33 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.111.112):. Processed in 1.832981 secs Process 30776) Received: from c-67-187-111-112.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@67.187.111.112) by 192.246.69.184 with SMTP; Mon, 06 Feb 2006 15:57:31 +0000 From: "Henry Sinnreich" To: "'Tony Rutkowski'" , "'lconroy'" , "'Stafford, Matthew'" , "'Otmar Lendl'" Subject: RE: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Date: Mon, 6 Feb 2006 09:32:51 -0600 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <7.0.1.0.2.20060205110918.035d3d70@verisign.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYrM7NpmUSoI38oSL2GC2uIJC/XEAAAoR5g X-Antivirus-MYDOMAIN-Message-ID: <113924145183530776@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The information provided by Tony Rutkowski are a welcome reminder that phone numbers are not only a crippled addressing system but a huge trap with legacy telecom regulatory issues and big legal staffing costs. Let's use the Internet and the DNS for what they were designed: URIs The other alternative are the name spaces in P2P systems. Sincere apology to all my friends working on ENUM: Keep it within strict bounds, simple and use with caution. Thanks, Henry -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Sunday, February 05, 2006 10:42 AM To: lconroy; Stafford, Matthew; Otmar Lendl Cc: enum@ietf.org; speermint@ietf.org Subject: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Hi Lawrence, >The first is the process issue - what group (if any) coordinates >between the different DDDS applications and their uses; this topic ... >3761bis. It seems that your proposal is purely for Carrier/ Infrastructure/ >Private ENUM; in this case, changing 3761 has unintended consequences >for Public/User ENUM applications. These are great understatements. The use of E.164 identifiers, internationally and domestically, is subject to more statutory, regulatory, national security, and industry practice requirements than any identifier space in existence - not to mention well established institutional jurisdiction. The following list is a current tabulation of E.164 resolver-directory capability requirements, parsed into three categories, currently in play in various industry NGN forums. The recently enacted EC Data Retention Directive, and the U.S. Prevent Cyberstalking law, add further complexity to the mix. ;-) best, --tony >basic resolver capability > >supplementary capability > Number Portability > Priority Access > Roaming > Quality of Service > Directory Assistance > CallerID > Disability Assistance > Language preference > Personal emergency (E112/911) > Public emergency alerts > Law enforcement assistance > DoNotCall > Payment Methods > Intercarrier Compensation > Profile Management > Presence > Availability > Location > Push Management > Digital Rights Management > Device Management > Authentication Credentials > Information verification level > >protocol feature > Authentication > Auditing > Multiple Syntax Support > Mutiple Language Support > Extensibility and Localisation Mechanisms _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 10:40:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68U4-0008Mk-HY; Mon, 06 Feb 2006 10:40:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68U2-0008Lu-UF for enum@megatron.ietf.org; Mon, 06 Feb 2006 10:40:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27873 for ; Mon, 6 Feb 2006 10:39:08 -0500 (EST) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F68gB-0003vQ-57 for enum@ietf.org; Mon, 06 Feb 2006 10:53:27 -0500 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id k16Feld3027547; Mon, 6 Feb 2006 15:40:47 GMT In-Reply-To: <20060206145934.GG526@finch-staff-1.thus.net> References: <20060206145934.GG526@finch-staff-1.thus.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Mon, 6 Feb 2006 15:40:41 +0000 To: "Clive D.W. Feather" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Feb 6, 2006, at 14:59, Clive D.W. Feather wrote: > Jim Reid said: >> Antoin, this idea is a non-starter IMO because it requires everything >> that might play in this space to always have complete, up to date >> knowledge of E.164 "country codes". > > Not so. > > You could assume that the country code was always 3 digits long. > This would > require a little more administration by those countries with 1 or 2 > digit > codes, but not a lot. Or the rule could be to try 3, 2, and 1 > digits in > that order. DNS caching will take care of most of the > inefficiencies in > this. "With sufficient thrust, pigs will fly". What you are suggesting Clive is theoretically possible. But from a practical perspective, it's nonsense. Sorry. Even with DNS cacheing, the extra latency induced by additional and unnecessary lookups is a killer. And it's just crazy to suggest a scheme where significant numbers of DNS lookups will fail BY DESIGN. Especially when the overwhelming bulk of the world's telephone numbers live under 1 or 2 digit country codes. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 10:45:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68YK-0000pu-Un; Mon, 06 Feb 2006 10:45:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68YJ-0000p1-CD for enum@megatron.ietf.org; Mon, 06 Feb 2006 10:45:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28153 for ; Mon, 6 Feb 2006 10:43:37 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F68kV-0004Dp-Le for enum@ietf.org; Mon, 06 Feb 2006 10:57:57 -0500 Received: from [10.31.32.128] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k16FjaLn027186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2006 07:45:37 -0800 Message-ID: <43E76EE9.5060201@shockey.us> Date: Mon, 06 Feb 2006 10:44:41 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jim Reid Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? References: <32755D354E6B65498C3BD9FD496C7D462C480E@oefeg-s04.oefeg.loc> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jim Reid wrote: > On Feb 6, 2006, at 14:45, Stastny Richard wrote: > >> Translated to practical issues this means: >> 1. we have to move forward with our draft to get a workable solution >> for the next 1 or 2 years (option2) >> 2. we also have to start the procedure by creating draft-enum-rfc3761bis. >> >> Since 2 cannot be finished before May 2006, the question is, should be >> bother ITU-T already >> now or wait for January 2007? > > There doesn't seem any point approaching ITU-T until this WG has > something for them to consider. Correct. OTOH, it wouldn't hurt to give SG2 a > heads-up that this group is working on Infrastructure/Carrier ENUM. Nope ...no formal IETF liaison is necessary. The extensive readership of this list in Geneva circles is sufficient :-) > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 10:45:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68Yt-0001KW-P4; Mon, 06 Feb 2006 10:45:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68Yf-00019M-JY for enum@megatron.ietf.org; Mon, 06 Feb 2006 10:45:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28195 for ; Mon, 6 Feb 2006 10:43:59 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F68ks-0004FG-OX for enum@ietf.org; Mon, 06 Feb 2006 10:58:19 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id k16FjdS4019836Mon, 6 Feb 2006 15:45:39 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1F68Yd-000BYB-00; Mon, 06 Feb 2006 15:45:39 +0000 Date: Mon, 6 Feb 2006 15:45:39 +0000 From: "Clive D.W. Feather" To: Jim Reid Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? Message-ID: <20060206154539.GH526@finch-staff-1.thus.net> References: <20060206145934.GG526@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jim Reid said: >> You could assume that the country code was always 3 digits long. >> This would >> require a little more administration by those countries with 1 or 2 >> digit >> codes, but not a lot. > practical perspective, it's nonsense. Sorry. Even with DNS cacheing, > the extra latency induced by additional and unnecessary lookups is a > killer. And it's just crazy to suggest a scheme where significant > numbers of DNS lookups will fail BY DESIGN. Especially when the > overwhelming bulk of the world's telephone numbers live under 1 or 2 > digit country codes. That doesn't prevent use of my other suggestion. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 10:50:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68dj-0003JF-Be; Mon, 06 Feb 2006 10:50:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68df-0003I1-Sf; Mon, 06 Feb 2006 10:50:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28506; Mon, 6 Feb 2006 10:49:01 -0500 (EST) Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F68pd-0004OT-ML; Mon, 06 Feb 2006 11:03:19 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-6.tower-124.messagelabs.com!1139241003!6561632!7 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 10153 invoked from network); 6 Feb 2006 15:50:22 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-6.tower-124.messagelabs.com with SMTP; 6 Feb 2006 15:50:22 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 43CF0375002B25BB; Mon, 6 Feb 2006 10:50:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish post-ENUM signaling f lows Date: Mon, 6 Feb 2006 10:50:18 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0C15E4BC@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish post-ENUM signaling f lows Thread-Index: AcYrM7NpmUSoI38oSL2GC2uIJC/XEAAAoR5gAAB0RnA= From: "Pfautz, Penn L, NEO" To: , "Tony Rutkowski" , "lconroy" , "Stafford, Matthew" , "Otmar Lendl" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Right now, however, phone numbers are a little like democracy - "the worst system imaginable except for all others" P2P folks don't seem serious about interoperability (look at IM) and only TNs provide reachability from the PSTN. Penn (sorry, Henry, couldn't resist) -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Monday, February 06, 2006 10:33 AM To: 'Tony Rutkowski'; 'lconroy'; 'Stafford, Matthew'; 'Otmar Lendl' Cc: enum@ietf.org; speermint@ietf.org Subject: RE: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish post-ENUM signaling f lows The information provided by Tony Rutkowski are a welcome reminder that phone numbers are not only a crippled addressing system but a huge trap with legacy telecom regulatory issues and big legal staffing costs. Let's use the Internet and the DNS for what they were designed: URIs The other alternative are the name spaces in P2P systems. Sincere apology to all my friends working on ENUM:=20 Keep it within strict bounds, simple and use with caution. Thanks, Henry =20 -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Sunday, February 05, 2006 10:42 AM To: lconroy; Stafford, Matthew; Otmar Lendl Cc: enum@ietf.org; speermint@ietf.org Subject: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Hi Lawrence, >The first is the process issue - what group (if any) coordinates >between the different DDDS applications and their uses; this topic ... >3761bis. It seems that your proposal is purely for Carrier/ Infrastructure/ >Private ENUM; in this case, changing 3761 has unintended consequences >for Public/User ENUM applications. These are great understatements. The use of E.164 identifiers, internationally and domestically, is subject to more statutory, regulatory, national security, and industry practice requirements than any identifier space in existence - not to mention well established institutional jurisdiction. The following list is a current tabulation of E.164 resolver-directory capability requirements, parsed into three categories, currently in play in various industry NGN forums. The recently enacted EC Data Retention Directive, and the U.S. Prevent Cyberstalking law, add further complexity to the mix. ;-) best, --tony >basic resolver capability > >supplementary capability > Number Portability > Priority Access > Roaming > Quality of Service > Directory Assistance > CallerID > Disability Assistance > Language preference > Personal emergency (E112/911) > Public emergency alerts > Law enforcement assistance > DoNotCall > Payment Methods > Intercarrier Compensation > Profile Management > Presence > Availability > Location > Push Management > Digital Rights Management > Device Management > Authentication Credentials > Information verification level > >protocol feature > Authentication > Auditing > Multiple Syntax Support > Mutiple Language Support > Extensibility and Localisation Mechanisms _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 13:32:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6BA1-0002so-3q; Mon, 06 Feb 2006 13:32:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6B9z-0002sj-9y for enum@megatron.ietf.org; Mon, 06 Feb 2006 13:32:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10639 for ; Mon, 6 Feb 2006 13:30:42 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6BMC-0005TG-IJ for enum@ietf.org; Mon, 06 Feb 2006 13:45:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Mon, 6 Feb 2006 19:32:32 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4814@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Why not re-use interim procedures for infrastructure ENUM? Thread-Index: AcYrS2XT6Oqxd5ARRjOFwF0kXeYXRgAAEuiz From: "Stastny Richard" To: "lconroy" , "Richard Shockey" X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > (i) Requirements first - that should be fun. What's the schedule=20 >for ITU SG2 > meetings after January 2007? good question =20 BTW, talking about doing requirements first: I just got asked here at the ETSI TISPAN meeting, why then the=20 enumservice pstn is closing WGLC already, because this is definitely for Infrastructure ENUM. =20 There was also a mumbling about "quod licet jovi, not licet bovi" =20 Just asking ;-) =20 Richard =20 ________________________________ Von: lconroy [mailto:lconroy@insensate.co.uk] Gesendet: Mo 06.02.2006 19:26 An: Richard Shockey Cc: Stastny Richard; enum@ietf.org Betreff: Re: [Enum] Why not re-use interim procedures for infrastructure = ENUM? Hi Richards, folks, (i) Requirements first - that should be fun. What's the schedule=20 for ITU SG2 meetings after January 2007? (ii) People keep talking about rfc3761bis, but I think we're=20 talking about different things - some folks seem to be talking about a=20 "traditional" rfc3761bis (i.e. obsoleting the current RFC 3761); others seem=20 more interested in an RFC3761-doppelganger (i.e. in parallel with=20 RFC 3761). So... are we to work on a replacement doc or one to run in parallel? I'm assuming that the Pfautz/Linn draft is the one you take for=20 requirements. That would seem to tie in with the doppelganger approach, as that draft covers requirements for Infrastructure ENUM only. all the best, Lawrence On 6 Feb 2006, at 15:19, Richard Shockey wrote: > Stastny Richard wrote: >> Richard Shockey wrote: >>> However the "issue" as you call it Richard IMHO would not lie=20 >>> with the >>> IAB. You should re read the charter of the IAB. >>> It would lie with the IESG upon creation of the appropriate RFC that >>> designated an Infrastructure apex. If the RFC is approved there is >>> little or nothing the IAB can do to impede its deployment. >> So to get this going, we first need a RFC 3761bis defining the apex >> If the IESG approves, IAB will start negotiating with RIPE and ITU > > > This is only a personal opinion but I do not believe you need to=20 > wait for 3761bis this could be defined in a separate document once=20 > there is agreement on the requirements. > > As is usual IETF procedure ..requirements _first_ ..then the solution. > >> Translated to practical issues this means: >> 1. we have to move forward with our draft to get a workable=20 >> solution for the next 1 or 2 years (option2) >> 2. we also have to start the procedure by creating draft-enum- >> rfc3761bis. >> Since 2 cannot be finished before May 2006, the question is,=20 >> should be bother ITU-T already >> now or wait for January 2007? >> regards >> Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 13:54:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6BVV-0000cI-0E; Mon, 06 Feb 2006 13:54:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6BVM-0000be-Qj; Mon, 06 Feb 2006 13:54:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12116; Mon, 6 Feb 2006 13:52:29 -0500 (EST) Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6BhI-0006fX-Sn; Mon, 06 Feb 2006 14:06:50 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.1/8.13.4) with ESMTP id k16IuKBD025104; Mon, 6 Feb 2006 13:56:20 -0500 Received: from trutkowski-desk.verisign.com ([10.169.64.229]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 13:53:59 -0500 Message-Id: <7.0.1.0.2.20060206133609.039bf6a8@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 06 Feb 2006 13:53:58 -0500 To: , "'lconroy'" , "'Stafford, Matthew'" , "'Otmar Lendl'" From: Tony Rutkowski In-Reply-To: <20060206153254.6D98B356A13@mail1-vs-brn.bigfish.com> References: <7.0.1.0.2.20060205110918.035d3d70@verisign.com> <20060206153254.6D98B356A13@mail1-vs-brn.bigfish.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 06 Feb 2006 18:53:59.0181 (UTC) FILETIME=[B04B5BD0:01C62B4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: enum@ietf.org, speermint@ietf.org Subject: [Enum] ENUM Test Specificatiobns X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Henry, The primary purpose of test implementations of new technology as public infrastructure is to establish test suites that provide real-world performance data under various use stress levels and failure scenarios. For ENUM, this would include alternative architectures. Has anyone developed ENUM test suites or data? ETSI did some plug-tests some time ago, but the focus seemed primarily on demonstrating interoperability. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 14:03:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6BeR-0002wY-U0; Mon, 06 Feb 2006 14:03:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6BeQ-0002vY-L2 for enum@megatron.ietf.org; Mon, 06 Feb 2006 14:03:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12839 for ; Mon, 6 Feb 2006 14:02:09 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Bqe-0007K2-QR for enum@ietf.org; Mon, 06 Feb 2006 14:16:30 -0500 Received: from [10.31.13.216] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k16J45Kr023988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2006 11:04:06 -0800 Message-ID: <43E79D81.3000809@shockey.us> Date: Mon, 06 Feb 2006 14:03:29 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? References: <32755D354E6B65498C3BD9FD496C7D462C4814@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4814@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, lconroy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: >> (i) Requirements first - that should be fun. What's the schedule >> for ITU SG2 >> meetings after January 2007? > > good question > > BTW, talking about doing requirements first: > > I just got asked here at the ETSI TISPAN meeting, why then the > enumservice pstn is closing WGLC already, because this is > definitely for Infrastructure ENUM. Its actually a valid point and this is the third question I've had on that subject this morning since I issued the request for publication. We had WGLC on this and if anyone had asked a question we certainly could have responded with the business case in more detail. As we pointed out in various fora Enumservice PSTN may or _may not_ integrate with Infrastructure ENUM. How it is integrated is a "national matter" based on local policy involving LNP and who has access to that data under the relevant national policy. The proposed RFC, today, has a great deal to do with the desire of some operators _right now_ to query a well known database about LNP data in IP friendly ( aka NO TCAP ) query response format. If the softswitch/proxy can query for LNP data at call origination it can then signal the media gateway at the VoIP network edge what is the true route path is and thus eliminate an unnecessary and expensive TCAP queries and SS7/C7 PRI links. TCAP - BAD DNS - GOOD! I do have hats these days btw. The "well known database" is presumably "private" as we described in the draft however it may be a form of highly localized cached DNS server ( the IP-SCP if you want to call it that) inside the service providers network as well as a network based server. Using high performance internal cacheing servers eliminates, in the opinion of some, considerable time in call setup operations. Vital milliseconds, especially in some IMS operations. How that "well known database" is provisioned was outside the scope of this document. This proposed RFC solves genuine network problems for VoIP softswitches today as well as tomorrow. > > There was also a mumbling about "quod licet jovi, not licet bovi" > > Just asking ;-) > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 14:09:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6BkG-0004F4-06; Mon, 06 Feb 2006 14:09:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6BkD-0004Bu-KR for enum@megatron.ietf.org; Mon, 06 Feb 2006 14:09:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13443 for ; Mon, 6 Feb 2006 14:08:08 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6BwS-0007gi-SA for enum@ietf.org; Mon, 06 Feb 2006 14:22:29 -0500 Received: from [10.31.13.216] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k16JA9Kl025207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2006 11:10:11 -0800 Message-ID: <43E79EEA.1090101@shockey.us> Date: Mon, 06 Feb 2006 14:09:30 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? References: <32755D354E6B65498C3BD9FD496C7D462C480E@oefeg-s04.oefeg.loc> <43E76919.9020509@shockey.us> <7898FA89-F9B4-47F5-8C1F-40F9C5EFFDE2@insensate.co.uk> In-Reply-To: <7898FA89-F9B4-47F5-8C1F-40F9C5EFFDE2@insensate.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org lconroy wrote: > Hi Richards, folks, > (i) Requirements first - that should be fun. Lawrence ... you know the IETF drill here. We agreed some form of Requirements documentation was necessary. That _MUST_ come first. What's the schedule for > ITU SG2 > meetings after January 2007? > (ii) People keep talking about rfc3761bis, but I think we're talking about > different things - some folks seem to be talking about a > "traditional" rfc3761bis (i.e. obsoleting the current RFC 3761) That is a item on our charter if you recall. ; others seem more interested in an RFC3761-doppelganger (i.e. in parallel with RFC > 3761). > > So... are we to work on a replacement doc or one to run in parallel? It is the opinion of this particular co-chair that the revision of RFC3761bis to go to Draft Standard and a document outlining a protocol solution to the Requirements for Infrastructure ENUM are orthogonal issues. They are separate documents but may be run in parallel. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 14:11:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Blm-0004gf-4O; Mon, 06 Feb 2006 14:11:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Blj-0004fz-KV; Mon, 06 Feb 2006 14:11:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13595; Mon, 6 Feb 2006 14:09:42 -0500 (EST) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Bxx-0007mL-LL; Mon, 06 Feb 2006 14:24:03 -0500 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id k16JBId3027936; Mon, 6 Feb 2006 19:11:18 GMT In-Reply-To: <7.0.1.0.2.20060206133609.039bf6a8@verisign.com> References: <7.0.1.0.2.20060205110918.035d3d70@verisign.com> <20060206153254.6D98B356A13@mail1-vs-brn.bigfish.com> <7.0.1.0.2.20060206133609.039bf6a8@verisign.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <134B5C86-A17B-48D5-A1FF-CB2EDF5A7696@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] ENUM Test Specificatiobns Date: Mon, 6 Feb 2006 19:11:12 +0000 To: Tony Rutkowski X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, speermint@ietf.org, 'Otmar Lendl' , henry@pulver.com, 'lconroy' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Feb 6, 2006, at 18:53, Tony Rutkowski wrote: > Has anyone developed ENUM test suites or data? Yes. Lawrence Conroy and I came up with some for the ETSI ENUM Plugtest last summer. The infrastructure to support that -- name servers and SIP server connected to a PBX -- was torn down after the event. It all ran on borrowed equipment. I was also a little bit naughty because the testbed used some UK drama numbers (equivalents of 555 numbers in the USA) that shouldn't have been delegated, let alone used for these tests. There's an action on me from the RIPE ENUM WG to try and get a semi- permanent testbed established. The first thing is to get the requirements documented. Contributions welcomed. Funding is even more welcome. :-) > ETSI did some plug-tests some time ago, but the focus > seemed primarily on demonstrating interoperability. Not really. The prime focus of those tests was to find out how implementations behaved under wierd or unusual inputs: lame delegations, malformed NAPTR records, tel: URIs that pointed at bogus or illegal numbers, truncated responses, etc, etc. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 14:18:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Bsu-0006M3-VH; Mon, 06 Feb 2006 14:18:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Bss-0006Jf-Oo; Mon, 06 Feb 2006 14:18:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14080; Mon, 6 Feb 2006 14:16:45 -0500 (EST) Received: from ws1.dns-hosting.info ([81.23.228.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6C4m-0008DN-Ch; Mon, 06 Feb 2006 14:31:05 -0500 Received: from [192.168.0.6] (mit.xs4all.nl [213.84.95.205]) (authenticated bits=0) by ws1.dns-hosting.info (8.13.5/8.13.5/Debian-3) with ESMTP id k16JI3b1024876 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 6 Feb 2006 20:18:04 +0100 In-Reply-To: <7.0.1.0.2.20060206133609.039bf6a8@verisign.com> References: <7.0.1.0.2.20060205110918.035d3d70@verisign.com> <20060206153254.6D98B356A13@mail1-vs-brn.bigfish.com> <7.0.1.0.2.20060206133609.039bf6a8@verisign.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Adrian Georgescu Subject: Re: [Enum] ENUM Test Specificatiobns Date: Mon, 6 Feb 2006 20:18:02 +0100 To: Tony Rutkowski X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Tony, The ENUM plugtest provided exactly the scenarios where things could go wrong and interested people learned how to deal with those situations. The test scenarios were quire comprehensive, thanks to Jim Reid and Lawrence Conroy excellent program. See the report from: http://www.etsi.org/plugtests/History/2005ENUM.htm Regards, Adrian On Feb 6, 2006, at 7:53 PM, Tony Rutkowski wrote: > Henry, > > The primary purpose of test implementations of new > technology as public infrastructure is to establish > test suites that provide real-world performance data > under various use stress levels and failure scenarios. > For ENUM, this would include alternative architectures. > > Has anyone developed ENUM test suites or data? ETSI > did some plug-tests some time ago, but the focus > seemed primarily on demonstrating interoperability. > > --tony > > > _______________________________________________ > 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 enum-bounces@ietf.org Mon Feb 06 15:57:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6DQV-0000xO-OM; Mon, 06 Feb 2006 15:57:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6DQU-0000vB-CD for enum@megatron.ietf.org; Mon, 06 Feb 2006 15:57:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10308 for ; Mon, 6 Feb 2006 13:25:08 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6BGn-0005AV-4b for enum@ietf.org; Mon, 06 Feb 2006 13:39:28 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id B113F7BC51; Mon, 6 Feb 2006 18:26:16 +0000 (GMT) In-Reply-To: <43E76919.9020509@shockey.us> References: <32755D354E6B65498C3BD9FD496C7D462C480E@oefeg-s04.oefeg.loc> <43E76919.9020509@shockey.us> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7898FA89-F9B4-47F5-8C1F-40F9C5EFFDE2@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Mon, 6 Feb 2006 18:26:15 +0000 To: Richard Shockey X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Richards, folks, (i) Requirements first - that should be fun. What's the schedule for ITU SG2 meetings after January 2007? (ii) People keep talking about rfc3761bis, but I think we're talking about different things - some folks seem to be talking about a "traditional" rfc3761bis (i.e. obsoleting the current RFC 3761); others seem more interested in an RFC3761-doppelganger (i.e. in parallel with RFC 3761). So... are we to work on a replacement doc or one to run in parallel? I'm assuming that the Pfautz/Linn draft is the one you take for requirements. That would seem to tie in with the doppelganger approach, as that draft covers requirements for Infrastructure ENUM only. all the best, Lawrence On 6 Feb 2006, at 15:19, Richard Shockey wrote: > Stastny Richard wrote: >> Richard Shockey wrote: >>> However the "issue" as you call it Richard IMHO would not lie >>> with the >>> IAB. You should re read the charter of the IAB. >>> It would lie with the IESG upon creation of the appropriate RFC that >>> designated an Infrastructure apex. If the RFC is approved there is >>> little or nothing the IAB can do to impede its deployment. >> So to get this going, we first need a RFC 3761bis defining the apex >> If the IESG approves, IAB will start negotiating with RIPE and ITU > > > This is only a personal opinion but I do not believe you need to > wait for 3761bis this could be defined in a separate document once > there is agreement on the requirements. > > As is usual IETF procedure ..requirements _first_ ..then the solution. > >> Translated to practical issues this means: >> 1. we have to move forward with our draft to get a workable >> solution for the next 1 or 2 years (option2) >> 2. we also have to start the procedure by creating draft-enum- >> rfc3761bis. >> Since 2 cannot be finished before May 2006, the question is, >> should be bother ITU-T already >> now or wait for January 2007? >> regards >> Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 06 16:35:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6E14-0001Au-D2; Mon, 06 Feb 2006 16:35:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6E13-0001Ad-7E for enum@megatron.ietf.org; Mon, 06 Feb 2006 16:35:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05375 for ; Mon, 6 Feb 2006 16:33:39 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6EDF-0002T1-GN for enum@ietf.org; Mon, 06 Feb 2006 16:48:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Mon, 6 Feb 2006 22:38:55 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4819@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Why not re-use interim procedures for infrastructure ENUM? Thread-Index: AcYrYqSq1IX1m9NkRUeIbRsaWQvQ3wAAcre/ From: "Stastny Richard" To: "lconroy" , "Richard Shockey" X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org RFC 3761 Doppelganger proposal: =20 To fullfil the requirements for Infrastructure ENUM stated in=20 http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-0= 1.txt especially the requirement stated in 2.6. Infrastructure ENUM SHALL be implemented under a TLD that can support reliability and performance suitable for PSTN applications. RFC3761 is endorsed as is with the replacement of step 4 in section 2.4 Valid databases:with 4. Append the string "i.e164.arpa" to the end. Example: 8.4.1.0.6.4.9.7.0.2.4.4.i.e164.arpa OR 4. Append the string ".e164i.arpa" to the end. Example: 8.4.1.0.6.4.9.7.0.2.4.4.e164i.arpa This could be placed in the requiements document itself Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von lconroy Gesendet: Mo 06.02.2006 19:26 An: Richard Shockey Cc: enum@ietf.org; Stastny Richard Betreff: Re: [Enum] Why not re-use interim procedures for infrastructure = ENUM? Hi Richards, folks, (i) Requirements first - that should be fun. What's the schedule=20 for ITU SG2 meetings after January 2007? (ii) People keep talking about rfc3761bis, but I think we're=20 talking about different things - some folks seem to be talking about a=20 "traditional" rfc3761bis (i.e. obsoleting the current RFC 3761); others seem=20 more interested in an RFC3761-doppelganger (i.e. in parallel with=20 RFC 3761). So... are we to work on a replacement doc or one to run in parallel? I'm assuming that the Pfautz/Linn draft is the one you take for=20 requirements. That would seem to tie in with the doppelganger approach, as that draft covers requirements for Infrastructure ENUM only. all the best, Lawrence On 6 Feb 2006, at 15:19, Richard Shockey wrote: > Stastny Richard wrote: >> Richard Shockey wrote: >>> However the "issue" as you call it Richard IMHO would not lie=20 >>> with the >>> IAB. You should re read the charter of the IAB. >>> It would lie with the IESG upon creation of the appropriate RFC that >>> designated an Infrastructure apex. If the RFC is approved there is >>> little or nothing the IAB can do to impede its deployment. >> So to get this going, we first need a RFC 3761bis defining the apex >> If the IESG approves, IAB will start negotiating with RIPE and ITU > > > This is only a personal opinion but I do not believe you need to=20 > wait for 3761bis this could be defined in a separate document once=20 > there is agreement on the requirements. > > As is usual IETF procedure ..requirements _first_ ..then the solution. > >> Translated to practical issues this means: >> 1. we have to move forward with our draft to get a workable=20 >> solution for the next 1 or 2 years (option2) >> 2. we also have to start the procedure by creating draft-enum- >> rfc3761bis. >> Since 2 cannot be finished before May 2006, the question is,=20 >> should be bother ITU-T already >> now or wait for January 2007? >> regards >> Richard _______________________________________________ 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 enum-bounces@ietf.org Tue Feb 07 03:29:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ODu-00050J-UZ; Tue, 07 Feb 2006 03:29:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ODs-0004wy-Qz; Tue, 07 Feb 2006 03:29:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02953; Tue, 7 Feb 2006 03:27:35 -0500 (EST) Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6OQE-00067i-0R; Tue, 07 Feb 2006 03:42:03 -0500 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 3B97A7211C8; Tue, 7 Feb 2006 09:28:56 +0100 (CET) Message-ID: <43E85A4C.8020207@pernau.at> Date: Tue, 07 Feb 2006 09:29:00 +0100 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Duane Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish post-ENUM signaling f lows References: <34DA635B184A644DA4588E260EC0A25A0C15E4BC@ACCLUST02EVS1.ugd.att.com> <43E772D3.5010801@e164.org> In-Reply-To: <43E772D3.5010801@e164.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, speermint@ietf.org, lconroy , "Pfautz, Penn L, NEO" , Tony Rutkowski X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Duane wrote: > Pfautz, Penn L, NEO wrote: > >> Right now, however, phone numbers are a little like democracy - "the >> worst system imaginable except for all others" >> P2P folks don't seem serious about interoperability (look at IM) and >> only TNs provide reachability from the PSTN. > > > Not entirely true, the guys from Jabber use enum lookups and resolve > Jabber IDs from our zone (e164.org). > > Also we're currently working on plugins for thunderbird/firefox to do > phone number to email/website with the idea of unification on business > cards of 10 different pieces of contact information to just a phone > number if people want to go that route. FYI: There already exists a firefox plugin (firefox 1.0.x only). http://falb.at/enum4firefox/enummapper-0.1.0.xpi regards klaus _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 07 04:37:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6PI3-00057r-Es; Tue, 07 Feb 2006 04:37:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6PI1-00057P-Ge for enum@megatron.ietf.org; Tue, 07 Feb 2006 04:37:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07129 for ; Tue, 7 Feb 2006 04:35:55 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6PUH-0008Oc-CE for enum@ietf.org; Tue, 07 Feb 2006 04:50:24 -0500 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Tue, 07 Feb 2006 10:37:03 +0100 id 0006C09B.43E86A3F.00004F44 Message-ID: <43E86A30.5030209@enum.at> Date: Tue, 07 Feb 2006 10:36:48 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: enum@ietf.org, Otmar Lendl Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] NITS review for draft-ietf-enum-validation-token-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org All, i've performed a NITS review of said draft - Otmar will provide an updated version before Dallas. Generally, the document is in a good shape, and i'd be happy if we could get this out of the door together with the other validation documents pretty soon - they have been lurking around now for over a year. My comments are as follows: - idnits complains that references are not split between Normative and Informative. - Introduction: "ENUM" needs to be spelled out, E.164 is missing the reference. I'm unsure whether "XML" needs to be spelled out or is well known - question to the RFC editors pending. - Data requirements: I'd add "piece of" between "only .. data". "Token's" should be changed to "Tokens" in the second bullet. - Digital Signature: XML-DSIG needs to be spelled out. Unsure about "RSA-SHA1". Reference to X.509 is missing. "CA" needs to be spelled out. - Field descriptions: Tags are sometimes called "tag", sometimes "attributes" or "strings". This needs to be unified. The "computerized directory assistance" fragment should be moved in front of the first occurance of "E.115". - Verification stuff: This should probably be generalized, since not only the Registry might do verification of the token. Especially the security considerations section would benefit from that. - XML schemas: Please add "BEGIN" and "END" to the schemas to aid automatic schema extraction (see eg. RFC4114 for example). Both schemas pass the checking at http://www.w3c.org/2001/03/webdata/xsv tia, Alex Mayrhofer _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 07 05:43:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6QK1-0007PR-DP; Tue, 07 Feb 2006 05:43:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6QJv-0006uw-3n; Tue, 07 Feb 2006 05:43:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03199; Mon, 6 Feb 2006 20:31:23 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6HvN-0007y3-IM; Mon, 06 Feb 2006 20:45:46 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id B35CC7BCC1; Tue, 7 Feb 2006 01:32:51 +0000 (GMT) In-Reply-To: <134B5C86-A17B-48D5-A1FF-CB2EDF5A7696@rfc1035.com> References: <7.0.1.0.2.20060205110918.035d3d70@verisign.com> <20060206153254.6D98B356A13@mail1-vs-brn.bigfish.com> <7.0.1.0.2.20060206133609.039bf6a8@verisign.com> <134B5C86-A17B-48D5-A1FF-CB2EDF5A7696@rfc1035.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] ENUM Test Specificatiobns Date: Tue, 7 Feb 2006 01:32:50 +0000 To: Jim Reid X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, speermint@ietf.org, 'Otmar Lendl' , Tony Rutkowski , henry@pulver.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Tony, Jim, folks, as the other half of that particular double act, I can chime in here. Tony - you should know better :). There was a VSGN chap at the plugtest and he therefore has the final report, in which the tests we ran are listed. I should point out that these broke everyone's implementations, but the clueful fixed theirs during the tests. We didn't go to the South of France to sun ourselves - we were stuck in a concrete dungeon, as Otmar can attest. As with all real plugtests(tm), whilst Interoperation is important, getting it right is better. There was a similar issue with the first ROHC tests - everyone had read the spec in the same wrong way (bit/byte order issue, as I recall), and they all interoperated, but were all wrong. That was fixed, IIRC, during the frantic last day of that test. all the best, Lawrence On 6 Feb 2006, at 19:11, Jim Reid wrote: > On Feb 6, 2006, at 18:53, Tony Rutkowski wrote: > >> Has anyone developed ENUM test suites or data? > > Yes. Lawrence Conroy and I came up with some for the ETSI ENUM > Plugtest last summer. The infrastructure to support that -- name > servers and SIP server connected to a PBX -- was torn down after > the event. It all ran on borrowed equipment. I was also a little > bit naughty because the testbed used some UK drama numbers > (equivalents of 555 numbers in the USA) that shouldn't have been > delegated, let alone used for these tests. > > There's an action on me from the RIPE ENUM WG to try and get a semi- > permanent testbed established. The first thing is to get the > requirements documented. Contributions welcomed. Funding is even > more welcome. :-) > >> ETSI did some plug-tests some time ago, but the focus >> seemed primarily on demonstrating interoperability. > > Not really. The prime focus of those tests was to find out how > implementations behaved under wierd or unusual inputs: lame > delegations, malformed NAPTR records, tel: URIs that pointed at > bogus or illegal numbers, truncated responses, etc, etc. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 07 06:09:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6QjH-0000FW-8G; Tue, 07 Feb 2006 06:09:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6QjF-0000Di-Uw for enum@megatron.ietf.org; Tue, 07 Feb 2006 06:09:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13720 for ; Tue, 7 Feb 2006 06:07:57 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6QvQ-0003Ra-FP for enum@ietf.org; Tue, 07 Feb 2006 06:22:25 -0500 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Tue, 07 Feb 2006 12:09:20 +0100 id 0006C09B.43E87FE0.000009C6 Message-ID: <43E87FCF.3090504@enum.at> Date: Tue, 07 Feb 2006 12:09:03 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Enum] input for Enumservice registration BCP sought X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org All, i'm seeking input for a BCP on Enumservice registrations. Various members of the working group have expressed their opinion that the existing registration template is suboptimal, and a BCP on registration would be welcome. The document should ease Enumservice registrations, and help to prevent repeated discussions every time a new registration is presented to the WG (type vs. subtype, protocol vs. application types, etc. comes to my mind) So, please speak up what you would like to see in such a document - i'm attempting to prepare a draft before Dallas. cheers alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From speermint-bounces@ietf.org Tue Feb 07 08:50:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6TET-0000Ak-OL; Tue, 07 Feb 2006 08:50:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6TE2-0008Sw-6i; Tue, 07 Feb 2006 08:50:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26709; Tue, 7 Feb 2006 08:47:55 -0500 (EST) Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6TQE-0000WH-LZ; Tue, 07 Feb 2006 09:02:26 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-5.tower-124.messagelabs.com!1139320103!6908890!21 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9609 invoked from network); 7 Feb 2006 13:49:22 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-5.tower-124.messagelabs.com with SMTP; 7 Feb 2006 13:49:22 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 43CF0375002D9372; Tue, 7 Feb 2006 08:49:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] and are phone numbers a borken addressing system? Date: Tue, 7 Feb 2006 08:49:20 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0C197939@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Speermint] and are phone numbers a borken addressing system? Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQ From: "Pfautz, Penn L, NEO" To: "Klaus Darilion" , "Duane" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org, lconroy , Tony Rutkowski X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org All neat stuff I'm sure. But it lacks the kind of universality and authoritativeness that are ultimately required for a system that's going to be more than an adjunct, however popular.=20 My point about IM was simply that the major offers don't make much of an attempt to interoperate which puts them where the telephone system was about a century ago when you could only call me if we had the same phone company. Likewise the "non-connected" VoIP systems: how does Googletalk interwork with Skype?=20 Pity, because IP handles the interconnection problem (at layer 3) so elegantly compared to the phone network. The object of Speermint is do bring this elegance to layer 5. I hope we'll do that, but if you want to make the PSTN go away you'll need an industrial strength addressing system. ENUM is great because is marries the good properties of E.164 to the flexibility of the net. I haven't seen anything else that gets the whole job done. My personal view... Penn =20 -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 Sent: Tuesday, February 07, 2006 3:29 AM To: Duane Cc: Pfautz, Penn L, NEO; enum@ietf.org; speermint@ietf.org; Tony Rutkowski; lconroy Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish post-ENUM signaling f lows Duane wrote: > Pfautz, Penn L, NEO wrote: >=20 >> Right now, however, phone numbers are a little like democracy - "the >> worst system imaginable except for all others" >> P2P folks don't seem serious about interoperability (look at IM) and >> only TNs provide reachability from the PSTN. >=20 >=20 > Not entirely true, the guys from Jabber use enum lookups and resolve=20 > Jabber IDs from our zone (e164.org). >=20 > Also we're currently working on plugins for thunderbird/firefox to do=20 > phone number to email/website with the idea of unification on business > cards of 10 different pieces of contact information to just a phone=20 > number if people want to go that route. FYI: There already exists a firefox plugin (firefox 1.0.x only). http://falb.at/enum4firefox/enummapper-0.1.0.xpi regards klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From enum-bounces@ietf.org Tue Feb 07 08:50:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6TES-0000AY-DW; Tue, 07 Feb 2006 08:50:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6TE2-0008Sw-6i; Tue, 07 Feb 2006 08:50:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26709; Tue, 7 Feb 2006 08:47:55 -0500 (EST) Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6TQE-0000WH-LZ; Tue, 07 Feb 2006 09:02:26 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-5.tower-124.messagelabs.com!1139320103!6908890!21 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9609 invoked from network); 7 Feb 2006 13:49:22 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-5.tower-124.messagelabs.com with SMTP; 7 Feb 2006 13:49:22 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 43CF0375002D9372; Tue, 7 Feb 2006 08:49:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Feb 2006 08:49:20 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0C197939@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Speermint] and are phone numbers a borken addressing system? Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQ From: "Pfautz, Penn L, NEO" To: "Klaus Darilion" , "Duane" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org, lconroy , Tony Rutkowski Subject: [Enum] RE: [Speermint] and are phone numbers a borken addressing system? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org All neat stuff I'm sure. But it lacks the kind of universality and authoritativeness that are ultimately required for a system that's going to be more than an adjunct, however popular.=20 My point about IM was simply that the major offers don't make much of an attempt to interoperate which puts them where the telephone system was about a century ago when you could only call me if we had the same phone company. Likewise the "non-connected" VoIP systems: how does Googletalk interwork with Skype?=20 Pity, because IP handles the interconnection problem (at layer 3) so elegantly compared to the phone network. The object of Speermint is do bring this elegance to layer 5. I hope we'll do that, but if you want to make the PSTN go away you'll need an industrial strength addressing system. ENUM is great because is marries the good properties of E.164 to the flexibility of the net. I haven't seen anything else that gets the whole job done. My personal view... Penn =20 -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 Sent: Tuesday, February 07, 2006 3:29 AM To: Duane Cc: Pfautz, Penn L, NEO; enum@ietf.org; speermint@ietf.org; Tony Rutkowski; lconroy Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish post-ENUM signaling f lows Duane wrote: > Pfautz, Penn L, NEO wrote: >=20 >> Right now, however, phone numbers are a little like democracy - "the >> worst system imaginable except for all others" >> P2P folks don't seem serious about interoperability (look at IM) and >> only TNs provide reachability from the PSTN. >=20 >=20 > Not entirely true, the guys from Jabber use enum lookups and resolve=20 > Jabber IDs from our zone (e164.org). >=20 > Also we're currently working on plugins for thunderbird/firefox to do=20 > phone number to email/website with the idea of unification on business > cards of 10 different pieces of contact information to just a phone=20 > number if people want to go that route. FYI: There already exists a firefox plugin (firefox 1.0.x only). http://falb.at/enum4firefox/enummapper-0.1.0.xpi regards klaus _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 07 09:48:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6U8X-0004nU-Gc; Tue, 07 Feb 2006 09:48:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6U8M-0004lW-Qv for enum@megatron.ietf.org; Tue, 07 Feb 2006 09:48:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00895 for ; Tue, 7 Feb 2006 09:46:07 -0500 (EST) Message-Id: <200602071446.JAA00895@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6UKc-0002Qk-6G for enum@ietf.org; Tue, 07 Feb 2006 10:00:38 -0500 Received: (qmail 29648 invoked by uid 510); 7 Feb 2006 10:12:42 -0500 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(67.187.111.112):. Processed in 1.82195 secs); 07 Feb 2006 15:12:42 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.111.112):. Processed in 1.82195 secs Process 29643) Received: from c-67-187-111-112.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@67.187.111.112) by 192.246.69.184 with SMTP; Tue, 07 Feb 2006 15:12:39 +0000 From: "Henry Sinnreich" To: "'Pfautz, Penn L, NEO'" , "'Klaus Darilion'" , "'Duane'" Date: Tue, 7 Feb 2006 08:47:35 -0600 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQAAKZZWA= In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0C197939@ACCLUST02EVS1.ugd.att.com> X-Antivirus-MYDOMAIN-Message-ID: <113932516083529643@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, speermint@ietf.org, 'lconroy' , 'Tony Rutkowski' Subject: [Enum] RE: [Speermint] and are phone numbers a borken addressing system? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Penn, I have to agree with you: >My point about IM was simply that the major offers don't make much of an >attempt to interoperate which puts them where the telephone system was >about a century ago when you could only call me if we had the same phone. Maybe the time is right for another Theodore Vail. Also, the IM companies carry most of the VoIP traffic and have by far the largest number of users. Only the new Microsoft IM and Yahoo IM are SIP. AOL and Google have the "intention" to support SIP and Skype uses SIP to interconnect to PSTN gateway providers. My Skype reads 5,259,584 users online... Maybe folks on the list have more accurate information. Coming to the point: What about peering for presence and IM? Or should we wait for another Theodore Vail? Thanks, Henry -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Pfautz, Penn L, NEO Sent: Tuesday, February 07, 2006 7:49 AM To: Klaus Darilion; Duane Cc: enum@ietf.org; speermint@ietf.org; lconroy; Tony Rutkowski Subject: RE: [Speermint] and are phone numbers a borken addressing system? All neat stuff I'm sure. But it lacks the kind of universality and authoritativeness that are ultimately required for a system that's going to be more than an adjunct, however popular. My point about IM was simply that the major offers don't make much of an attempt to interoperate which puts them where the telephone system was about a century ago when you could only call me if we had the same phone company. Likewise the "non-connected" VoIP systems: how does Googletalk interwork with Skype? Pity, because IP handles the interconnection problem (at layer 3) so elegantly compared to the phone network. The object of Speermint is do bring this elegance to layer 5. I hope we'll do that, but if you want to make the PSTN go away you'll need an industrial strength addressing system. ENUM is great because is marries the good properties of E.164 to the flexibility of the net. I haven't seen anything else that gets the whole job done. My personal view... Penn -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Sent: Tuesday, February 07, 2006 3:29 AM To: Duane Cc: Pfautz, Penn L, NEO; enum@ietf.org; speermint@ietf.org; Tony Rutkowski; lconroy Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish post-ENUM signaling f lows Duane wrote: > Pfautz, Penn L, NEO wrote: > >> Right now, however, phone numbers are a little like democracy - "the >> worst system imaginable except for all others" >> P2P folks don't seem serious about interoperability (look at IM) and >> only TNs provide reachability from the PSTN. > > > Not entirely true, the guys from Jabber use enum lookups and resolve > Jabber IDs from our zone (e164.org). > > Also we're currently working on plugins for thunderbird/firefox to do > phone number to email/website with the idea of unification on business > cards of 10 different pieces of contact information to just a phone > number if people want to go that route. FYI: There already exists a firefox plugin (firefox 1.0.x only). http://falb.at/enum4firefox/enummapper-0.1.0.xpi regards klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 07 10:53:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6V9R-0003Fy-AR; Tue, 07 Feb 2006 10:53:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6V9K-00037V-D9 for enum@megatron.ietf.org; Tue, 07 Feb 2006 10:53:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05813 for ; Tue, 7 Feb 2006 10:51:18 -0500 (EST) From: Robert.Shaw@itu.int Received: from protext02.itu.ch ([156.106.192.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6VLj-0004k2-4U for enum@ietf.org; Tue, 07 Feb 2006 11:05:51 -0500 Received: from protext02.itu.ch ([156.106.192.19]) by protext02.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Feb 2006 16:52:33 +0100 Received: From PROTINT1.blue.itu.ch ([156.106.128.47]) by protext02.itu.ch (WebShield SMTP v4.5 MR1a); id 113932755366; Tue, 7 Feb 2006 16:52:33 +0100 Received: from MAILBOX1.blue.itu.ch ([156.106.130.106]) by PROTINT1.blue.itu.ch with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Feb 2006 16:52:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken addressingsystem? Date: Tue, 7 Feb 2006 16:52:30 +0100 Message-ID: <2ECA12DF5FCB7948A1CD9047C3DAF3DC010DDFA7@MAILBOX1.blue.itu.ch> Thread-Topic: [Enum] RE: [Speermint] and are phone numbers a borken addressingsystem? Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQAAT3CsA= To: , , X-OriginalArrivalTime: 07 Feb 2006 15:52:32.0912 (UTC) FILETIME=[81FC4900:01C62BFE] X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org, lconroy@insensate.co.uk, trutkowski@verisign.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > All neat stuff I'm sure. But it lacks the kind of universality and > authoritativeness that are ultimately required for a system=20 > that's going to be more than an adjunct, however popular.=20 Indeed. There are about 3.4 billion mobile + fixed subscribers out there with most of them now *mobile* and growing fast. At=20 this time, provider-based URI schemes are barely a blip on this=20 radar screen. > Maybe the time is right for another Theodore Vail. The logic of this is lost on me. A cornerstone of Vail's strategy=20 was to dominate by control over technology. Been there. Done that. RS _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 07 13:08:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6XG4-0007jE-Pn; Tue, 07 Feb 2006 13:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6XG2-0007f9-By; Tue, 07 Feb 2006 13:08:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17018; Tue, 7 Feb 2006 13:06:25 -0500 (EST) Received: from extmail09.cingular.com ([170.35.225.24] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6XSS-0001Bt-UT; Tue, 07 Feb 2006 13:20:57 -0500 Received: from ([10.3.188.52]) by extmail09.cingular.com with ESMTP id KP-VYGZ6.56945499; Tue, 07 Feb 2006 13:07:28 -0500 Received: by s75202e004001.tdc.cingular.net with Internet Mail Service (5.5.2657.72) id <1FCBYR00>; Tue, 7 Feb 2006 12:11:03 -0600 Message-ID: To: lconroy Subject: RE: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Date: Tue, 7 Feb 2006 12:08:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) From: "Stafford, Matthew" X-Spam-Score: 0.5 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0136706393==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0136706393== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62C11.73FE4E30" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C62C11.73FE4E30 Content-Type: text/plain Lawrence- Thanks for your comments... good discussion points here! Inline. Best, Matt -----Original Message----- From: lconroy [mailto:lconroy@insensate.co.uk] Sent: Sunday, February 05, 2006 6:32 AM To: Stafford, Matthew; Otmar Lendl Cc: speermint@ietf.org; enum@ietf.org Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Hi Matt, Otmar, folks, This is an interesting posting for several reasons. The first is the process issue - what group (if any) coordinates between the different DDDS applications and their uses; this topic covers D2x NAPTRs (natural territory for SIP/SIPPING), E2U NAPTRs (natural territory for ENUM), and their use for peering (welcome, SPEERMINT). If it's useful to add clarifications for DDDS itself then who or what does that? ==> Agree that this is not a trivial question. To the substance of the post: I'm sure Otmar was not suggesting that D2x NAPTRs MUST be available for all domains before a SIP exchange can occur. For Service Providers it's fine, but... There are a number of individuals who do not need or use an intermediary provider for their SIP exchanges, so adding D2U NAPTRs is "overkill" I, for example, do not have D2x NAPTRs in my zone; there's no target domain redirection, so the NAPTRs would not be useful. I only have one SIP proxy so one could even argue that SRVs are excessive - it's not exactly a load balanced system. ==> The way I read (this portion of) the Lendl draft is as follows (correct ==> me if I misinterpret): ==> *If* you want to dereference SIP URIs using D2x NAPTRs *but* you will ==> not accept SIP signaling over UDP, then RFC 3263 is telling you to do ==> something that doesn't make much sense (namely, post a D2U NAPTR ==> anyway). ==> My reading of RFC 3263 doesn't seem to say you MUST dereference SIP URIs ==> via D2x NAPTRs. But AFAICT, nothing systematic is specified re: other ==> signaling flows for resolving SIP URIs. BTW, strongly agree with your ==> suggestion that other signaling flows make sense in many cases. However, for Service Providers, we enter new territories. Do you know that your customers will want *every* insecure SIP invite to fail (i.e. those customers have said to you explicitly that a _sip transaction is not acceptable)? Is is a regulatory requirement that you at least tell the caller that this call has failed though a terminating service like UCB, rather than not even accept the attempt? ==> Another interesting point. Lastly, adding a new flag for ENUM *in general* is going to cause some problems for application developers like me - ALL of my ENUM clients will have to support this, or else these will be non-compliant to any 3761bis. It seems that your proposal is purely for Carrier/ Infrastructure/ Private ENUM; in this case, changing 3761 has unintended consequences for Public/User ENUM applications. ==> I take your point regarding the headaches w/changes to clients. ==> However, I'm not sure I agree that this is limited to carrier/infra- ==> ENUM, at least if we think of that in terms of traditional telcos/ ==> cellcos. For example, does this discussion really bear no relevance ==> to enterprise applications (e.g., I want to call into my company's ==> IP PBX while I'm on the road?) It appears that the proposed 'g' flag is appropriate only for SIP use within Carrier ENUM, so one could WELL argue that this is an issue for the SIP URI - I don't see how it can be used for other Enumservices (like email:mailto, for example). Perhaps adding a SIP parameter (akin to ;user=phone) would be more appropriate, or adding a new Enumservice to run alongside the existing SIP one (i.e. to develop a new Enumservice definition RFC to specify a SIP Gateway service)? ==> That would have a similar effect to the flag proposal, in the sense ==> that the contents of the ENUM NAPTR offer guidance on what to do next ==> (which is really what I'm after) ==> For the sake of discussion, here's a similar example using the recently-==> standardized Enumservice mms:mailto... an 'm' flag indicating that the ==> NAPTR recipient should now look for an MX Resource Record. all the best, Lawrence On 4 Feb 2006, at 23:07, Stafford, Matthew wrote: > I strongly agree with the following statement from draft-lendl-sip- > peering-policy (lifted verbatim from section 6.2): > > => RFC 3263 builds on that. Quote: > > => If a SIP proxy, redirect server, or registrar is to be > contacted > > => through the lookup of NAPTR records, there MUST be at least > three > > => records - one with a "SIP+D2T" service field, one with a > "SIP+D2U" > > => service field, and one with a "SIPS+D2T" service field. > > => > > => This "MUST" needs to be reconsidered in this context, as it > forces > > => VSP to accept calls over unsecured SIP transports. > > In fact, I would go further, as explained below. > > The "u" flag defined in RFC 3761 doesn't say how to interpret the > domain name in the returned URI. In the case of a SIP URI, RFC 3263 > signaling (in particular, an additional layer of dereferencing > embodied in a second NAPTR) makes perfect sense to me in a > situation where you know nothing about the domain. > > But should RFC 3263 be "universally normative" for SIP URIs? It > seems to me that the entity that provisions an ENUM NAPTR will in > many cases already know something useful about the target domain. > As a simple for-instance, suppose "transport=tcp" is included in > the sip URI (as allowed by RFC 3261). In this case, there would be > an efficiency advantage if the ENUM response could be followed > directly by an SRV query. > > So I have argued that there will be circumstances where the second > NAPTR doesn't buy you much. Of course there will also be > circumstances where RFC 3263 signaling is warranted. I'm cross- > posting to the ENUM working group for the following reason: flags > could be used to distinguish the two kinds of signaling flows. Say > a "g" flag (mnemonic for Gateway) that tells the recipient of the > ENUM NAPTR that there is an SRV record (w/domain in the ENUM NAPTR > as key) pointing to the gateway. > > I think the example just described is worthwhile. Moreover, I think > the Lendl draft suggests that there are additional scenarios that > might be facilitated by via new ENUM flags. I'm not clear whether > this sort of thing would end up in "3761bis", so to speak, or in > another document. Either way, I'd like to float the idea and see if > there's interest. > > Best, > > Matt Stafford > > Vice Chair of Addressing Task Force, GSM North America ------_=_NextPart_001_01C62C11.73FE4E30 Content-Type: text/html RE: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows

Lawrence- Thanks for your comments... good discussion points here! Inline.

Best,
Matt

-----Original Message-----
From: lconroy [mailto:lconroy@insensate.co.uk]
Sent: Sunday, February 05, 2006 6:32 AM
To: Stafford, Matthew; Otmar Lendl
Cc: speermint@ietf.org; enum@ietf.org
Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows

Hi Matt, Otmar, folks,
  This is an interesting posting for several reasons.
The first is the process issue - what group (if any) coordinates
between the different DDDS applications and their uses; this topic
covers D2x NAPTRs (natural territory for SIP/SIPPING), E2U NAPTRs
(natural territory for ENUM), and their use for peering (welcome,
SPEERMINT). If it's useful to add clarifications for DDDS itself
then who or what does that?

==> Agree that this is not a trivial question.

To the substance of the post:
I'm sure Otmar was not suggesting that D2x NAPTRs MUST be available
for all domains before a SIP exchange can occur. For Service Providers
it's fine, but...
There are a number of individuals who do not need or use an intermediary
provider for their SIP exchanges, so adding D2U NAPTRs is "overkill"
I, for example, do not have D2x NAPTRs in my zone; there's no target
domain redirection, so the NAPTRs would not be useful. I only have one
SIP proxy so one could even argue that SRVs are excessive - it's not
exactly a load balanced system.

==> The way I read (this portion of) the Lendl draft is as follows (correct
==> me if I misinterpret):
==> *If* you want to dereference SIP URIs using D2x NAPTRs *but* you will
==> not accept SIP signaling over UDP, then RFC 3263 is telling you to do
==> something that doesn't make much sense (namely, post a D2U NAPTR
==> anyway).

==> My reading of RFC 3263 doesn't seem to say you MUST dereference SIP URIs
==> via D2x NAPTRs. But AFAICT, nothing systematic is specified re: other
==> signaling flows for resolving SIP URIs. BTW, strongly agree with your
==> suggestion that other signaling flows make sense in many cases.

However, for Service Providers, we enter new territories. Do you know
that your customers will want *every* insecure SIP invite to fail (i.e.
those customers have said to you explicitly that a _sip transaction is
not acceptable)? Is is a regulatory requirement that you at least tell
the caller that this call has failed though a terminating service like
UCB, rather than not even accept the attempt?

==> Another interesting point.

Lastly, adding a new flag for ENUM *in general* is going to cause some
problems for application developers like me - ALL of my ENUM clients
will have to support this, or else these will be non-compliant to any
3761bis. It seems that your proposal is purely for Carrier/
Infrastructure/
Private ENUM; in this case, changing 3761 has unintended consequences 
for
Public/User ENUM applications.

==> I take your point regarding the headaches w/changes to clients.
==> However, I'm not sure I agree that this is limited to carrier/infra-
==> ENUM, at least if we think of that in terms of traditional telcos/
==> cellcos. For example, does this discussion really bear no relevance
==> to enterprise applications (e.g., I want to call into my company's
==> IP PBX while I'm on the road?)

It appears that the proposed 'g' flag is appropriate only for SIP use 
within
Carrier ENUM, so one could WELL argue that this is an issue for the 
SIP URI
- I don't see how it can be used for other Enumservices (like 
email:mailto,
for example). Perhaps adding a SIP parameter (akin to ;user=phone) 
would be
more appropriate, or adding a new Enumservice to run alongside the 
existing
SIP one (i.e. to develop a new Enumservice definition RFC to specify 
a SIP
Gateway service)?

==> That would have a similar effect to the flag proposal, in the sense
==> that the contents of the ENUM NAPTR offer guidance on what to do next
==> (which is really what I'm after)

==> For the sake of discussion, here's a similar example using the recently-==> standardized Enumservice mms:mailto... an 'm' flag indicating that the ==> NAPTR recipient should now look for an MX Resource Record.

all the best,
   Lawrence


On 4 Feb 2006, at 23:07, Stafford, Matthew wrote:
> I strongly agree with the following statement from draft-lendl-sip-
> peering-policy (lifted verbatim from section 6.2):
>
> =>   RFC 3263 builds on that.  Quote:
>
> =>      If a SIP proxy, redirect server, or registrar is to be 
> contacted
>
> =>      through the lookup of NAPTR records, there MUST be at least 
> three
>
> =>      records - one with a "SIP+D2T" service field, one with a 
> "SIP+D2U"
>
> =>      service field, and one with a "SIPS+D2T" service field.
>
> =>
>
> =>   This "MUST" needs to be reconsidered in this context, as it 
> forces
>
> =>   VSP to accept calls over unsecured SIP transports.
>
>  In fact, I would go further, as explained below.
>
> The "u" flag defined in RFC 3761 doesn't say how to interpret the 
> domain name in the returned URI. In the case of a SIP URI, RFC 3263 
> signaling (in particular, an additional layer of dereferencing 
> embodied in a second NAPTR) makes perfect sense to me in a 
> situation where you know nothing about the domain.
>
> But should RFC 3263 be "universally normative" for SIP URIs? It 
> seems to me that the entity that provisions an ENUM NAPTR will in 
> many cases already know something useful about the target domain. 
> As a simple for-instance, suppose "transport=tcp" is included in 
> the sip URI (as allowed by RFC 3261). In this case, there would be 
> an efficiency advantage if the ENUM response could be followed 
> directly by an SRV query.
>
> So I have argued that there will be circumstances where the second 
> NAPTR doesn't buy you much. Of course there will also be 
> circumstances where RFC 3263 signaling is warranted. I'm cross-
> posting to the ENUM working group for the following reason: flags 
> could be used to distinguish the two kinds of signaling flows. Say 
> a "g" flag (mnemonic for Gateway) that tells the recipient of the 
> ENUM NAPTR that there is an SRV record (w/domain in the ENUM NAPTR 
> as key) pointing to the gateway.
>
> I think the example just described is worthwhile. Moreover, I think 
> the Lendl draft suggests that there are additional scenarios that 
> might be facilitated by via new ENUM flags. I'm not clear whether 
> this sort of thing would end up in "3761bis", so to speak, or in 
> another document. Either way, I'd like to float the idea and see if 
> there's interest.
>
> Best,
>
> Matt Stafford
>
> Vice Chair of Addressing Task Force, GSM North America

------_=_NextPart_001_01C62C11.73FE4E30-- --===============0136706393== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0136706393==-- From enum-bounces@ietf.org Tue Feb 07 13:12:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6XKL-0000JK-6j; Tue, 07 Feb 2006 13:12:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6XKE-00009f-Kf; Tue, 07 Feb 2006 13:12:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17286; Tue, 7 Feb 2006 13:10:37 -0500 (EST) Received: from extmail09.cingular.com ([170.35.225.24] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6XWX-0001Kw-2Z; Tue, 07 Feb 2006 13:25:10 -0500 Received: from ([10.3.188.52]) by extmail09.cingular.com with ESMTP id KP-VYGZ6.56946055; Tue, 07 Feb 2006 13:11:47 -0500 Received: by s75202e004001.tdc.cingular.net with Internet Mail Service (5.5.2657.72) id <1FCBYSPN>; Tue, 7 Feb 2006 12:15:22 -0600 Message-ID: To: Richard Shockey Subject: RE: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Date: Tue, 7 Feb 2006 12:12:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) From: "Stafford, Matthew" X-Spam-Score: 1.3 (+) X-Scan-Signature: a38f40f81e96f7c17c0b6f9de20b7099 Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1032029251==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1032029251== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62C12.0D407780" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C62C12.0D407780 Content-Type: text/plain Richard- I'm interested to see what will happen with ENUMservices; thanks for the info. The only problem I see is that sometimes (e.g., the recently-standardized E2U+mms:mailto) the subtype is already used to specify a URI scheme. So, for instance, that would not allow use of the subtype to indicate that the recipient of the ENUM NAPTR should look for an MX RR as a next step. Best, Matt -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Sunday, February 05, 2006 10:26 AM To: lconroy Cc: Stafford, Matthew; Otmar Lendl; enum@ietf.org; speermint@ietf.org Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows lconroy wrote: > Hi Matt, Otmar, folks, > This is an interesting posting for several reasons. > The first is the process issue - what group (if any) coordinates > between the different DDDS applications and their uses; this topic > covers D2x NAPTRs (natural territory for SIP/SIPPING), E2U NAPTRs > (natural territory for ENUM), and their use for peering (welcome, > SPEERMINT). If it's useful to add clarifications for DDDS itself > then who or what does that? > > To the substance of the post: > I'm sure Otmar was not suggesting that D2x NAPTRs MUST be available > for all domains before a SIP exchange can occur. For Service Providers > it's fine, but... > There are a number of individuals who do not need or use an intermediary > provider for their SIP exchanges, so adding D2U NAPTRs is "overkill" > I, for example, do not have D2x NAPTRs in my zone; there's no target > domain redirection, so the NAPTRs would not be useful. I only have one > SIP proxy so one could even argue that SRVs are excessive - it's not > exactly a load balanced system. > > > Lastly, adding a new flag for ENUM *in general* is going to cause some > problems for application developers like me - ALL of my ENUM clients > will have to support this, or else these will be non-compliant to any > 3761bis. It seems that your proposal is purely for Carrier/Infrastructure/ > Private ENUM; in this case, changing 3761 has unintended consequences for > Public/User ENUM applications. > > It appears that the proposed 'g' flag is appropriate only for SIP use > within > Carrier ENUM, so one could WELL argue that this is an issue for the SIP URI > - I don't see how it can be used for other Enumservices (like email:mailto, > for example). Perhaps adding a SIP parameter (akin to ;user=phone) would be > more appropriate, or adding a new Enumservice to run alongside the existing > SIP one (i.e. to develop a new Enumservice definition RFC to specify a SIP > Gateway service)? Larry I agree with your view. If there were a general requirement for this form of tag its better done as an extension to a Enumservice field. Those fields are quite extensible you can add as many sub-types as you want so long as they are properly defined in a RFC. E2U+sip:gw strikes me as the right way to do this. The purpose of the flag field is not to hint at describe or the nature of endpoint after the rewrite but to define how to process the reg exp under certain defined conditions. This went to our past issue of how to use the replacement field, should someone find a way to use it properly. BTW we have realized we have a bit of a mess with the Enumservice registry in general and we will shortly have a WG draft addressing the problem > > all the best, > Lawrence > > > On 4 Feb 2006, at 23:07, Stafford, Matthew wrote: >> I strongly agree with the following statement from >> draft-lendl-sip-peering-policy (lifted verbatim from section 6.2): >> >> => RFC 3263 builds on that. Quote: >> >> => If a SIP proxy, redirect server, or registrar is to be contacted >> >> => through the lookup of NAPTR records, there MUST be at least three >> >> => records - one with a "SIP+D2T" service field, one with a >> "SIP+D2U" >> >> => service field, and one with a "SIPS+D2T" service field. >> >> => >> >> => This "MUST" needs to be reconsidered in this context, as it forces >> >> => VSP to accept calls over unsecured SIP transports. >> >> In fact, I would go further, as explained below. >> >> The "u" flag defined in RFC 3761 doesn't say how to interpret the >> domain name in the returned URI. In the case of a SIP URI, RFC 3263 >> signaling (in particular, an additional layer of dereferencing >> embodied in a second NAPTR) makes perfect sense to me in a situation >> where you know nothing about the domain. >> >> But should RFC 3263 be "universally normative" for SIP URIs? It seems >> to me that the entity that provisions an ENUM NAPTR will in many cases >> already know something useful about the target domain. As a simple >> for-instance, suppose "transport=tcp" is included in the sip URI (as >> allowed by RFC 3261). In this case, there would be an efficiency >> advantage if the ENUM response could be followed directly by an SRV >> query. >> >> So I have argued that there will be circumstances where the second >> NAPTR doesn't buy you much. Of course there will also be circumstances >> where RFC 3263 signaling is warranted. I'm cross-posting to the ENUM >> working group for the following reason: flags could be used to >> distinguish the two kinds of signaling flows. Say a "g" flag (mnemonic >> for Gateway) that tells the recipient of the ENUM NAPTR that there is >> an SRV record (w/domain in the ENUM NAPTR as key) pointing to the >> gateway. >> >> I think the example just described is worthwhile. Moreover, I think >> the Lendl draft suggests that there are additional scenarios that >> might be facilitated by via new ENUM flags. I'm not clear whether this >> sort of thing would end up in "3761bis", so to speak, or in another >> document. Either way, I'd like to float the idea and see if there's >> interest. >> >> Best, >> >> Matt Stafford >> >> Vice Chair of Addressing Task Force, GSM North America > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ------_=_NextPart_001_01C62C12.0D407780 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Enum] a suggestion re: using flags to distinguish post-ENUM = signaling f lows

Richard- I'm interested to see what will happen with = ENUMservices; thanks for the info. The only problem I see is that = sometimes (e.g., the recently-standardized E2U+mms:mailto) the subtype = is already used to specify a URI scheme. So, for instance, that would = not allow use of the subtype to indicate that the recipient of the ENUM = NAPTR should look for an MX RR as a next step.

Best,
Matt

-----Original Message-----
From: Richard Shockey [mailto:richard@shockey.us] =
Sent: Sunday, February 05, 2006 10:26 AM
To: lconroy
Cc: Stafford, Matthew; Otmar Lendl; enum@ietf.org; = speermint@ietf.org
Subject: Re: [Enum] a suggestion re: using flags to = distinguish post-ENUM signaling f lows

lconroy wrote:
> Hi Matt, Otmar, folks,
>  This is an interesting posting for = several reasons.
> The first is the process issue - what group (if = any) coordinates
> between the different DDDS applications and = their uses; this topic
> covers D2x NAPTRs (natural territory for = SIP/SIPPING), E2U NAPTRs
> (natural territory for ENUM), and their use for = peering (welcome,
> SPEERMINT). If it's useful to add = clarifications for DDDS itself
> then who or what does that?
>
> To the substance of the post:
> I'm sure Otmar was not suggesting that D2x = NAPTRs MUST be available
> for all domains before a SIP exchange can = occur. For Service Providers
> it's fine, but...
> There are a number of individuals who do not = need or use an intermediary
> provider for their SIP exchanges, so adding D2U = NAPTRs is "overkill"
> I, for example, do not have D2x NAPTRs in my = zone; there's no target
> domain redirection, so the NAPTRs would not be = useful. I only have one
> SIP proxy so one could even argue that SRVs are = excessive - it's not
> exactly a load balanced system.
>
>
> Lastly, adding a new flag for ENUM *in general* = is going to cause some
> problems for application developers like me - = ALL of my ENUM clients
> will have to support this, or else these will = be non-compliant to any
> 3761bis. It seems that your proposal is purely = for Carrier/Infrastructure/
> Private ENUM; in this case, changing 3761 has = unintended consequences for
> Public/User ENUM applications.
>
> It appears that the proposed 'g' flag is = appropriate only for SIP use
> within
> Carrier ENUM, so one could WELL argue that this = is an issue for the SIP URI
> - I don't see how it can be used for other = Enumservices (like email:mailto,
> for example). Perhaps adding a SIP parameter = (akin to ;user=3Dphone) would be
> more appropriate, or adding a new Enumservice = to run alongside the existing
> SIP one (i.e. to develop a new Enumservice = definition RFC to specify a SIP
> Gateway service)?


Larry I agree with your view.

If there were a general requirement for this form of = tag its better done
as an extension to a Enumservice field.

Those fields are quite extensible you can add as many = sub-types as you
want so long as they are properly defined in a = RFC.

E2U+sip:gw

strikes me as the right way to do this.

The purpose of the flag field is not to hint at = describe or the nature
of endpoint after the rewrite but to define how to = process the reg exp
under certain defined conditions. This went to our = past issue of how to
use the replacement field, should someone find a way = to use it properly.

BTW we have realized we have a bit of a mess with the = Enumservice
registry in general and we will shortly have a WG = draft addressing the
problem




>
> all the best,
>   Lawrence
>
>
> On 4 Feb 2006, at 23:07, Stafford, Matthew = wrote:
>> I strongly agree with the following = statement from
>> draft-lendl-sip-peering-policy (lifted = verbatim from section 6.2):
>>
>> =3D>   RFC 3263 builds on = that.  Quote:
>>
>> =3D>      If a = SIP proxy, redirect server, or registrar is to be contacted
>>
>> =3D>      = through the lookup of NAPTR records, there MUST be at least = three
>>
>> =3D>      = records - one with a "SIP+D2T" service field, one with a =
>> "SIP+D2U"
>>
>> =3D>      = service field, and one with a "SIPS+D2T" service = field.
>>
>> =3D>
>>
>> =3D>   This "MUST" = needs to be reconsidered in this context, as it forces
>>
>> =3D>   VSP to accept calls = over unsecured SIP transports.
>>
>>  In fact, I would go further, as = explained below.
>>
>> The "u" flag defined in RFC 3761 = doesn't say how to interpret the
>> domain name in the returned URI. In the = case of a SIP URI, RFC 3263
>> signaling (in particular, an additional = layer of dereferencing
>> embodied in a second NAPTR) makes perfect = sense to me in a situation
>> where you know nothing about the = domain.
>>
>> But should RFC 3263 be "universally = normative" for SIP URIs? It seems
>> to me that the entity that provisions an = ENUM NAPTR will in many cases
>> already know something useful about the = target domain. As a simple
>> for-instance, suppose = "transport=3Dtcp" is included in the sip URI (as
>> allowed by RFC 3261). In this case, there = would be an efficiency
>> advantage if the ENUM response could be = followed directly by an SRV
>> query.
>>
>> So I have argued that there will be = circumstances where the second
>> NAPTR doesn't buy you much. Of course there = will also be circumstances
>> where RFC 3263 signaling is warranted. I'm = cross-posting to the ENUM
>> working group for the following reason: = flags could be used to
>> distinguish the two kinds of signaling = flows. Say a "g" flag (mnemonic
>> for Gateway) that tells the recipient of = the ENUM NAPTR that there is
>> an SRV record (w/domain in the ENUM NAPTR = as key) pointing to the
>> gateway.
>>
>> I think the example just described is = worthwhile. Moreover, I think
>> the Lendl draft suggests that there are = additional scenarios that
>> might be facilitated by via new ENUM flags. = I'm not clear whether this
>> sort of thing would end up in = "3761bis", so to speak, or in another
>> document. Either way, I'd like to float the = idea and see if there's
>> interest.
>>
>> Best,
>>
>> Matt Stafford
>>
>> Vice Chair of Addressing Task Force, GSM = North America
>
> = _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum=
>


--


 >>>>>>>>>>>>>>&= gt;>>>>>>>>>>>>>>>>>&= gt;>>>>>>>>>>>>>>>>>&= gt;>>
Richard Shockey, Director - Member of Technical = Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, = VA  20166
sip:rshockey(at)iptel.org   = sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 = 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us&g= t; or
<mailto:richard.shockey(at= )neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<= ;<<<<<<<<<<<<<<<<<<= ;<<<<<<<<<<<<<<<<<<= ;<

------_=_NextPart_001_01C62C12.0D407780-- --===============1032029251== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1032029251==-- From enum-bounces@ietf.org Tue Feb 07 13:20:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6XSN-0003aX-WB; Tue, 07 Feb 2006 13:20:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6XSK-0003Yt-Hg; Tue, 07 Feb 2006 13:20:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17836; Tue, 7 Feb 2006 13:18:57 -0500 (EST) Received: from extmail09.cingular.com ([170.35.225.24] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Xeb-0001at-Aj; Tue, 07 Feb 2006 13:33:30 -0500 Received: from ([10.3.188.52]) by extmail09.cingular.com with ESMTP id KP-VYGZ6.56947271; Tue, 07 Feb 2006 13:20:13 -0500 Received: by s75202e004001.tdc.cingular.net with Internet Mail Service (5.5.2657.72) id <1FCBYTQ2>; Tue, 7 Feb 2006 12:23:48 -0600 Message-ID: To: Tony Rutkowski Subject: RE: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Date: Tue, 7 Feb 2006 12:20:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) From: "Stafford, Matthew" X-Spam-Score: 1.6 (+) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0385326954==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0385326954== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62C13.3E107BCA" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C62C13.3E107BCA Content-Type: text/plain Tony- The E.164 space is a many-encumbered thing. No argument there. All the same, I see two benefits of E.164 numbers: although *some* mobile devices have QWERTY keyboards, many of them still don't. IMO a telephone number is far and away the easiest thing to punch into a cellphone keypad. That's the first one. The second one is (essentially) number portability. My SIP URI can change from sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. As long as my phone number stays the same, it can be used to obtain my current SIP URI. Best, Matt -----Original Message----- From: Tony Rutkowski [mailto:trutkowski@verisign.com] Sent: Sunday, February 05, 2006 10:42 AM To: lconroy; Stafford, Matthew; Otmar Lendl Cc: enum@ietf.org; speermint@ietf.org Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Hi Lawrence, >The first is the process issue - what group (if any) coordinates >between the different DDDS applications and their uses; this topic ... >3761bis. It seems that your proposal is purely for Carrier/ Infrastructure/ >Private ENUM; in this case, changing 3761 has unintended consequences >for Public/User ENUM applications. These are great understatements. The use of E.164 identifiers, internationally and domestically, is subject to more statutory, regulatory, national security, and industry practice requirements than any identifier space in existence - not to mention well established institutional jurisdiction. The following list is a current tabulation of E.164 resolver-directory capability requirements, parsed into three categories, currently in play in various industry NGN forums. The recently enacted EC Data Retention Directive, and the U.S. Prevent Cyberstalking law, add further complexity to the mix. ;-) best, --tony >basic resolver capability > >supplementary capability > Number Portability > Priority Access > Roaming > Quality of Service > Directory Assistance > CallerID > Disability Assistance > Language preference > Personal emergency (E112/911) > Public emergency alerts > Law enforcement assistance > DoNotCall > Payment Methods > Intercarrier Compensation > Profile Management > Presence > Availability > Location > Push Management > Digital Rights Management > Device Management > Authentication Credentials > Information verification level > >protocol feature > Authentication > Auditing > Multiple Syntax Support > Mutiple Language Support > Extensibility and Localisation Mechanisms ------_=_NextPart_001_01C62C13.3E107BCA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Enum] a suggestion re: using flags to distinguish post-ENUM = signaling f lows

Tony- The E.164 space is a many-encumbered thing. No = argument there.

All the same, I see two benefits of E.164 numbers: = although *some* mobile devices have QWERTY keyboards, many of them = still don't. IMO a telephone number is far and away the easiest thing = to punch into a cellphone keypad. That's the first one. The second one = is (essentially) number portability. My SIP URI can change from = sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. As long = as my phone number stays the same, it can be used to obtain my current = SIP URI.

Best,
Matt

-----Original Message-----
From: Tony Rutkowski [mailto:trutkowski@verisign.com]
Sent: Sunday, February 05, 2006 10:42 AM
To: lconroy; Stafford, Matthew; Otmar Lendl
Cc: enum@ietf.org; speermint@ietf.org
Subject: Re: [Enum] a suggestion re: using flags to = distinguish post-ENUM signaling f lows

Hi Lawrence,

>The first is the process issue - what group (if = any) coordinates
>between the different DDDS applications and = their uses; this topic
...
>3761bis. It seems that your proposal is purely = for Carrier/ Infrastructure/
>Private ENUM; in this case, changing 3761 has = unintended consequences
>for Public/User ENUM applications.

These are great understatements.  The use = of
E.164 identifiers, internationally and
domestically, is subject to more statutory,
regulatory, national security, and industry
practice requirements than any identifier
space in existence - not to mention well
established institutional jurisdiction.

The following list is a current tabulation
of E.164 resolver-directory capability
requirements, parsed into three categories,
currently in play in various industry NGN
forums.  The recently enacted EC Data
Retention Directive, and the U.S. Prevent
Cyberstalking law, add further complexity
to the mix. ;-)

best,
--tony

>basic resolver capability
>
>supplementary capability
>         = Number Portability
>         = Priority Access
>         = Roaming
>         = Quality of Service
>         = Directory Assistance
>         = CallerID
>         = Disability Assistance
>         = Language preference
>         = Personal emergency (E112/911)
>         = Public emergency alerts
>         = Law enforcement assistance
>         = DoNotCall
>         = Payment Methods
>         = Intercarrier Compensation
>         = Profile Management
>         = Presence
>         = Availability
>         = Location
>         = Push Management
>         = Digital Rights Management
>         = Device Management
>         = Authentication Credentials
>         = Information verification level
>
>protocol feature
>         = Authentication
>         = Auditing
>         = Multiple Syntax Support
>         = Mutiple Language Support
>         = Extensibility and Localisation Mechanisms

------_=_NextPart_001_01C62C13.3E107BCA-- --===============0385326954== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0385326954==-- From enum-bounces@ietf.org Tue Feb 07 13:37:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Xi6-0003XT-Vh; Tue, 07 Feb 2006 13:37:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Xi2-0003WX-1l; Tue, 07 Feb 2006 13:37:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18980; Tue, 7 Feb 2006 13:35:13 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6XuL-00028Z-I2; Tue, 07 Feb 2006 13:49:45 -0500 Received: from [10.31.13.183] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k17IapLF028802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2006 10:36:52 -0800 Message-ID: <43E8E897.3060609@shockey.us> Date: Tue, 07 Feb 2006 13:36:07 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Stafford, Matthew" Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, speermint@ietf.org, lconroy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > ==> I take your point regarding the headaches w/changes to clients. > ==> However, I'm not sure I agree that this is limited to carrier/infra- > ==> ENUM, at least if we think of that in terms of traditional telcos/ > ==> cellcos. For example, does this discussion really bear no relevance > ==> to enterprise applications (e.g., I want to call into my company's > ==> IP PBX while I'm on the road?) > > It appears that the proposed 'g' flag is appropriate only for SIP use > within Carrier ENUM, so one could WELL argue that this is an issue for the > SIP URI - I don't see how it can be used for other Enumservices (like > email:mailto, for example). Perhaps adding a SIP parameter (akin to ;user=phone) > would be more appropriate, or adding a new Enumservice to run alongside the > existing SIP one (i.e. to develop a new Enumservice definition RFC to specify > a SIP Gateway service)? That would be my strong recommendation. Something like E2U+sip:pstngw > > ==> That would have a similar effect to the flag proposal, in the sense > ==> that the contents of the ENUM NAPTR offer guidance on what to do next > ==> (which is really what I'm after) > > ==> For the sake of discussion, here's a similar example using the > recently-==> standardized Enumservice mms:mailto... an 'm' flag > indicating that the ==> NAPTR recipient should now look for an MX > Resource Record. Lets not even start a discussion over using the flag field ..I do't think that will go very far. IMHO a non starter. URI extentions or Enumservice definitions are the way to go > > all the best, > Lawrence > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 07 13:42:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Xnj-0004TD-6W; Tue, 07 Feb 2006 13:42:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Xn3-0004DP-L6; Tue, 07 Feb 2006 13:42:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19338; Tue, 7 Feb 2006 13:40:03 -0500 (EST) Received: from ws1.dns-hosting.info ([81.23.228.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Xz2-0002J9-0j; Tue, 07 Feb 2006 13:54:36 -0500 Received: from [192.168.0.6] (mit.xs4all.nl [213.84.95.205]) (authenticated bits=0) by ws1.dns-hosting.info (8.13.5/8.13.5/Debian-3) with ESMTP id k17IfS1s009647 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 7 Feb 2006 19:41:30 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <3DB884D5-3577-46B4-894F-658007636BA6@ag-projects.com> From: Adrian Georgescu Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Date: Tue, 7 Feb 2006 19:41:27 +0100 To: "Stafford, Matthew" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 1.3 (+) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: enum@ietf.org, speermint@ietf.org, Tony Rutkowski X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1972083551==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1972083551== Content-Type: multipart/alternative; boundary=Apple-Mail-33--30785880 --Apple-Mail-33--30785880 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Matt, May I refine your logic? The best description should be: I can change my telephone number whenever I change my operator. But as long as I can control my own SIP URI ag@ag-projects.com I can map my URI from ag@provider1.com to ag@provider2.com and people can reach me at my own URI regardless of operator I am using for the voice/whatever service. The main identity is the SIP URI, is not anymore the telephone number. The telephone number is just another attribute of a SIP URI. I can have one or more telephone numbers pointing to the same URI. The opposite is impossible to realize due to scarcity, regulatory issues and geographic nature of telephone numbers. Regards, Adrian On Feb 7, 2006, at 7:20 PM, Stafford, Matthew wrote: > Tony- The E.164 space is a many-encumbered thing. No argument there. > > All the same, I see two benefits of E.164 numbers: although *some* > mobile devices have QWERTY keyboards, many of them still don't. IMO > a telephone number is far and away the easiest thing to punch into > a cellphone keypad. That's the first one. The second one is > (essentially) number portability. My SIP URI can change from > sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. As > long as my phone number stays the same, it can be used to obtain my > current SIP URI. > > Best, > Matt > > -----Original Message----- > From: Tony Rutkowski [mailto:trutkowski@verisign.com] > Sent: Sunday, February 05, 2006 10:42 AM > To: lconroy; Stafford, Matthew; Otmar Lendl > Cc: enum@ietf.org; speermint@ietf.org > Subject: Re: [Enum] a suggestion re: using flags to distinguish > post-ENUM signaling f lows > > Hi Lawrence, > > >The first is the process issue - what group (if any) coordinates > >between the different DDDS applications and their uses; this topic > ... > >3761bis. It seems that your proposal is purely for Carrier/ > Infrastructure/ > >Private ENUM; in this case, changing 3761 has unintended consequences > >for Public/User ENUM applications. > > These are great understatements. The use of > E.164 identifiers, internationally and > domestically, is subject to more statutory, > regulatory, national security, and industry > practice requirements than any identifier > space in existence - not to mention well > established institutional jurisdiction. > > The following list is a current tabulation > of E.164 resolver-directory capability > requirements, parsed into three categories, > currently in play in various industry NGN > forums. The recently enacted EC Data > Retention Directive, and the U.S. Prevent > Cyberstalking law, add further complexity > to the mix. ;-) > > best, > --tony > > >basic resolver capability > > > >supplementary capability > > Number Portability > > Priority Access > > Roaming > > Quality of Service > > Directory Assistance > > CallerID > > Disability Assistance > > Language preference > > Personal emergency (E112/911) > > Public emergency alerts > > Law enforcement assistance > > DoNotCall > > Payment Methods > > Intercarrier Compensation > > Profile Management > > Presence > > Availability > > Location > > Push Management > > Digital Rights Management > > Device Management > > Authentication Credentials > > Information verification level > > > >protocol feature > > Authentication > > Auditing > > Multiple Syntax Support > > Mutiple Language Support > > Extensibility and Localisation Mechanisms > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum --Apple-Mail-33--30785880 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Matt,

May I refine your = logic?=A0The best description should be:

I can change my telephone = number whenever I change my operator. But as long as I can control my = own SIP URI ag@ag-projects.com = I can map my URI from=A0 ag@provider1.com to ag@provider2.com and people can = reach me at my own URI regardless of operator I am using for the = voice/whatever service.

The main identity is the = SIP URI, is not anymore the telephone number. The telephone number is = just another attribute of a SIP URI. I can have one or more telephone = numbers pointing to the same URI. The opposite is impossible to realize = due to scarcity, regulatory issues and geographic nature of telephone = numbers.

Regards,
Adrian
=A0

On Feb 7, 2006, at 7:20 PM, Stafford, = Matthew wrote:

Tony- The E.164 space is a = many-encumbered thing. No argument there.

All the same, I see two benefits of E.164 numbers: although = *some* mobile devices have QWERTY keyboards, many of them still don't. = IMO a telephone number is far and away the easiest thing to punch into a = cellphone keypad. That's the first one. The second one is (essentially) = number portability. My SIP URI can change from sip:mstafford@provider-A.net = to sip:mstafford@provider-B.biz. = As long as my phone number stays the same, it can be used to obtain my = current SIP URI.

Best,
Matt

-----Original = Message-----
From: Tony Rutkowski [mailto:trutkowski@verisign.com= ]
Sent: Sunday, February 05, 2006 10:42 = AM
To: lconroy; Stafford, Matthew; Otmar = Lendl
Cc: enum@ietf.org; speermint@ietf.org =
Subject: Re: [Enum] a suggestion re: using flags to = distinguish post-ENUM signaling f lows

Hi = Lawrence,

>The first is the process = issue - what group (if any) coordinates
>between the different DDDS applications and their uses; = this topic
...
>3761bis. It seems that your proposal is purely for = Carrier/ Infrastructure/
>Private ENUM; = in this case, changing 3761 has unintended consequences
>for Public/User ENUM applications.

These are great understatements.=A0 The use of =
E.164 identifiers, internationally and =
domestically, is subject to more statutory, =
regulatory, national security, and industry =
practice requirements than any identifier =
space in existence - not to mention well =
established institutional jurisdiction. =

The following list is a current = tabulation
of E.164 resolver-directory = capability
requirements, parsed into three = categories,
currently in play in various = industry NGN
forums.=A0 The recently enacted = EC Data
Retention Directive, and the U.S. = Prevent
Cyberstalking law, add further = complexity
to the mix. ;-) =

best,
--tony =

>basic resolver capability
>
>supplementary = capability
>=A0=A0=A0=A0=A0=A0=A0=A0 = Number Portability
>=A0=A0=A0=A0=A0=A0=A0=A0= Priority Access
>=A0=A0=A0=A0=A0=A0=A0=A0 = Roaming
>=A0=A0=A0=A0=A0=A0=A0=A0 Quality = of Service
>=A0=A0=A0=A0=A0=A0=A0=A0 = Directory Assistance
>=A0=A0=A0=A0=A0=A0=A0= =A0 CallerID
>=A0=A0=A0=A0=A0=A0=A0=A0 = Disability Assistance
>=A0=A0=A0=A0=A0=A0=A0= =A0 Language preference
>=A0=A0=A0=A0=A0=A0= =A0=A0 Personal emergency (E112/911)
>=A0=A0=A0=A0=A0=A0=A0=A0 Public emergency alerts =
>=A0=A0=A0=A0=A0=A0=A0=A0 Law enforcement = assistance
>=A0=A0=A0=A0=A0=A0=A0=A0 = DoNotCall
>=A0=A0=A0=A0=A0=A0=A0=A0 = Payment Methods
>=A0=A0=A0=A0=A0=A0=A0=A0 = Intercarrier Compensation
>=A0=A0=A0=A0=A0=A0= =A0=A0 Profile Management
>=A0=A0=A0=A0=A0=A0= =A0=A0 Presence
>=A0=A0=A0=A0=A0=A0=A0=A0 = Availability
>=A0=A0=A0=A0=A0=A0=A0=A0 = Location
>=A0=A0=A0=A0=A0=A0=A0=A0 Push = Management
>=A0=A0=A0=A0=A0=A0=A0=A0 = Digital Rights Management
>=A0=A0=A0=A0=A0=A0= =A0=A0 Device Management
>=A0=A0=A0=A0=A0=A0= =A0=A0 Authentication Credentials
>=A0=A0=A0= =A0=A0=A0=A0=A0 Information verification level
>
>protocol feature =
>=A0=A0=A0=A0=A0=A0=A0=A0 Authentication =
>=A0=A0=A0=A0=A0=A0=A0=A0 Auditing =
>=A0=A0=A0=A0=A0=A0=A0=A0 Multiple Syntax = Support
>=A0=A0=A0=A0=A0=A0=A0=A0 Mutiple = Language Support
>=A0=A0=A0=A0=A0=A0=A0=A0 = Extensibility and Localisation Mechanisms

enum mailing list
=

= --Apple-Mail-33--30785880-- --===============1972083551== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1972083551==-- From enum-bounces@ietf.org Tue Feb 07 13:46:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6XrX-00051w-M1; Tue, 07 Feb 2006 13:46:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6XrV-00051J-Sl; Tue, 07 Feb 2006 13:46:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19699; Tue, 7 Feb 2006 13:44:58 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6Y3n-0002Tx-4Q; Tue, 07 Feb 2006 13:59:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Date: Tue, 7 Feb 2006 19:50:12 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4820@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Thread-Index: AcYsFBqynbyURv/vRJ6PPsLklGRjLgAAcEuP From: "Stastny Richard" To: "Stafford, Matthew" X-Spam-Score: 0.8 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >The second one is (essentially) number portability. My SIP URI can = change from sip:mstafford@provider-A.net to = >sip:mstafford@provider-B.biz. As long as my phone number stays the = same, it can be used to obtain my current SIP URI. What I want to have is SIP URI portability too, or in other words: I = want to have my sip URI sip:richard@stastny.com hosted by one provider and the possibility to port this to another. Especially if I am a company. =20 For more information see the ECMA christmas wish-list presented today at = ETSI TISPAN: Technical Report TR/91 Enterprise Communication in Next Generation Corporate Networks (NGCN) = involving Public Next Generation Networks (NGN) (December 2005) http://www.ecma-international.org/publications/files/ECMA-TR/TR-091.pdf =20 and also Technical Report TR/92 Corporate Telecommunication Networks - Mobility for Enterprise = Communications (December 2005) http://www.ecma-international.org/publications/files/ECMA-TR/TR-092.pdf =20 The scenarios and requirements described in these two documents will not be really easy to implement with NGNs ;-) Of course they want to have best of both sides: peering with each other = in all variants AND in addition to be connected to an NGN, just to be on the safe side. One could also say: the overflow traffic is for the telcos (say max 20%) =20 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Stafford, Matthew Gesendet: Di 07.02.2006 19:20 An: Tony Rutkowski Cc: enum@ietf.org; speermint@ietf.org Betreff: RE: [Enum] a suggestion re: using flags to distinguish = post-ENUM signaling f lows Tony- The E.164 space is a many-encumbered thing. No argument there.=20 All the same, I see two benefits of E.164 numbers: although *some* = mobile devices have QWERTY keyboards, many of them still don't. IMO a = telephone number is far and away the easiest thing to punch into a = cellphone keypad. That's the first one. The second one is (essentially) = number portability. My SIP URI can change from = sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. As long as = my phone number stays the same, it can be used to obtain my current SIP = URI. Best,=20 Matt=20 -----Original Message-----=20 From: Tony Rutkowski [mailto:trutkowski@verisign.com]=20 Sent: Sunday, February 05, 2006 10:42 AM=20 To: lconroy; Stafford, Matthew; Otmar Lendl=20 Cc: enum@ietf.org; speermint@ietf.org=20 Subject: Re: [Enum] a suggestion re: using flags to distinguish = post-ENUM signaling f lows=20 Hi Lawrence,=20 >The first is the process issue - what group (if any) coordinates=20 >between the different DDDS applications and their uses; this topic=20 ...=20 >3761bis. It seems that your proposal is purely for Carrier/ = Infrastructure/=20 >Private ENUM; in this case, changing 3761 has unintended consequences=20 >for Public/User ENUM applications.=20 These are great understatements. The use of=20 E.164 identifiers, internationally and=20 domestically, is subject to more statutory,=20 regulatory, national security, and industry=20 practice requirements than any identifier=20 space in existence - not to mention well=20 established institutional jurisdiction.=20 The following list is a current tabulation=20 of E.164 resolver-directory capability=20 requirements, parsed into three categories,=20 currently in play in various industry NGN=20 forums. The recently enacted EC Data=20 Retention Directive, and the U.S. Prevent=20 Cyberstalking law, add further complexity=20 to the mix. ;-)=20 best,=20 --tony=20 >basic resolver capability=20 >=20 >supplementary capability=20 > Number Portability=20 > Priority Access=20 > Roaming=20 > Quality of Service=20 > Directory Assistance=20 > CallerID=20 > Disability Assistance=20 > Language preference=20 > Personal emergency (E112/911)=20 > Public emergency alerts=20 > Law enforcement assistance=20 > DoNotCall=20 > Payment Methods=20 > Intercarrier Compensation=20 > Profile Management=20 > Presence=20 > Availability=20 > Location=20 > Push Management=20 > Digital Rights Management=20 > Device Management=20 > Authentication Credentials=20 > Information verification level=20 >=20 >protocol feature=20 > Authentication=20 > Auditing=20 > Multiple Syntax Support=20 > Mutiple Language Support=20 > Extensibility and Localisation Mechanisms=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 07 13:54:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6XzI-0008GY-NO; Tue, 07 Feb 2006 13:54:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6XzH-0008DY-HR; Tue, 07 Feb 2006 13:54:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20357; Tue, 7 Feb 2006 13:53:10 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6YBj-0002l1-1S; Tue, 07 Feb 2006 14:07:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUMsignaling f lows Date: Tue, 7 Feb 2006 19:54:29 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4821@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] a suggestion re: using flags to distinguish post-ENUMsignaling f lows Thread-Index: AcYsFtAfom9HqPaQTVmk9jLWhxn19AAARzg1 From: "Stastny Richard" To: "Richard Shockey" , "Stafford, Matthew" X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org, lconroy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >Something like E2U+sip:pstngw =20 I thought E2U+sip:pstn is pointing to a gw service already =20 >URI extentions or Enumservice definitions are the way to go E2U+mms:mailto:mx ? or mailto:a@example.com;mx=3Dyes/no ? E2U+sip:srv=20 or sip:a@example.com;srv=3Dyes/no =20 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Richard Shockey Gesendet: Di 07.02.2006 19:36 An: Stafford, Matthew Cc: enum@ietf.org; speermint@ietf.org; lconroy Betreff: Re: [Enum] a suggestion re: using flags to distinguish = post-ENUMsignaling f lows > =3D=3D> I take your point regarding the headaches w/changes to = clients. > =3D=3D> However, I'm not sure I agree that this is limited to = carrier/infra- > =3D=3D> ENUM, at least if we think of that in terms of traditional = telcos/ > =3D=3D> cellcos. For example, does this discussion really bear no = relevance > =3D=3D> to enterprise applications (e.g., I want to call into my = company's > =3D=3D> IP PBX while I'm on the road?) > > It appears that the proposed 'g' flag is appropriate only for SIP use > within Carrier ENUM, so one could WELL argue that this is an issue for = the > SIP URI - I don't see how it can be used for other Enumservices (like > email:mailto, for example). Perhaps adding a SIP parameter (akin to = ;user=3Dphone) > would be more appropriate, or adding a new Enumservice to run = alongside the > existing SIP one (i.e. to develop a new Enumservice definition RFC to = specify > a SIP Gateway service)? That would be my strong recommendation. Something like E2U+sip:pstngw > > =3D=3D> That would have a similar effect to the flag proposal, in the = sense > =3D=3D> that the contents of the ENUM NAPTR offer guidance on what to = do next > =3D=3D> (which is really what I'm after) > > =3D=3D> For the sake of discussion, here's a similar example using the > recently-=3D=3D> standardized Enumservice mms:mailto... an 'm' flag > indicating that the =3D=3D> NAPTR recipient should now look for an MX > Resource Record. Lets not even start a discussion over using the flag field ..I do't think that will go very far. IMHO a non starter. URI extentions or Enumservice definitions are the way to go > > all the best, > Lawrence > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 07 14:05:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6YA2-0005FE-UQ; Tue, 07 Feb 2006 14:05:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Y9z-0005DY-Jj; Tue, 07 Feb 2006 14:05:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21412; Tue, 7 Feb 2006 14:04:06 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6YMI-0003DT-2j; Tue, 07 Feb 2006 14:18:39 -0500 Received: from [10.31.13.183] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k17J6BrP000542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2006 11:06:12 -0800 Message-ID: <43E8EF7B.9000104@shockey.us> Date: Tue, 07 Feb 2006 14:05:31 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows References: <32755D354E6B65498C3BD9FD496C7D462C4820@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4820@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: >> The second one is (essentially) number portability. My SIP URI can change from sip:mstafford@provider-A.net to >sip:mstafford@provider-B.biz. As long as my phone number stays the same, it can be used to obtain my current SIP URI. > > What I want to have is SIP URI portability too, or in other words: I want to have my sip URI sip:richard@stastny.com > hosted by one provider and the possibility to port this to another. > > Especially if I am a company. > > For more information see the ECMA christmas wish-list presented today at ETSI TISPAN: > Technical Report TR/91 > Enterprise Communication in Next Generation Corporate Networks (NGCN) involving Public Next Generation Networks (NGN) > (December 2005) > http://www.ecma-international.org/publications/files/ECMA-TR/TR-091.pdf > > and also > Technical Report TR/92 > Corporate Telecommunication Networks - Mobility for Enterprise Communications > (December 2005) > http://www.ecma-international.org/publications/files/ECMA-TR/TR-092.pdf > > The scenarios and requirements described in these two documents will not > be really easy to implement with NGNs ;-) > Of course they want to have best of both sides: peering with each other in all variants > AND in addition to be connected to an NGN, just to be on the safe side. > One could also say: the overflow traffic is for the telcos (say max 20%) And ..just to make sure everyone is totally confused and bewildered by all of this, the SIP Forum is very close to publishing its Proposed Recommendation on IP-PBX to Service Provider interface. Draft version four of the IP PBX / SP Interoperability specification is now available online for your review at the following URL: The list for this document is taking final comments for the next 30 days. http://data.memberclicks.com/bbattach/123566/sf-draft-twg-IP_PBX_SP_Interop-sibley-v4.pdf >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 07 14:07:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6YBa-0006l5-BA; Tue, 07 Feb 2006 14:07:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6YBY-0006jj-L0; Tue, 07 Feb 2006 14:07:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21573; Tue, 7 Feb 2006 14:05:43 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6YNs-0003Hf-Dh; Tue, 07 Feb 2006 14:20:16 -0500 Received: from [10.31.13.183] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k17J7jNg000811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2006 11:07:47 -0800 Message-ID: <43E8EFDA.7020207@shockey.us> Date: Tue, 07 Feb 2006 14:07:06 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUMsignaling f lows References: <32755D354E6B65498C3BD9FD496C7D462C4821@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4821@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, speermint@ietf.org, lconroy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: >> Something like E2U+sip:pstngw > > I thought E2U+sip:pstn > is pointing to a gw service already > Good point! I forgot about that definition. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 07 17:46:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6bbT-0003Bh-1v; Tue, 07 Feb 2006 17:46:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6bbL-0003B8-0J; Tue, 07 Feb 2006 17:46:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08703; Tue, 7 Feb 2006 17:44:28 -0500 (EST) Received: from extmail09.cingular.com ([170.35.225.24] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6bnc-0002ZV-0T; Tue, 07 Feb 2006 17:59:04 -0500 Received: from ([10.3.188.52]) by extmail09.cingular.com with ESMTP id KP-VYGZ6.56986858; Tue, 07 Feb 2006 17:45:34 -0500 Received: by s75202e004001.tdc.cingular.net with Internet Mail Service (5.5.2657.72) id <1FCBZW59>; Tue, 7 Feb 2006 16:49:09 -0600 Message-ID: To: Stastny Richard Subject: RE: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Date: Tue, 7 Feb 2006 16:46:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) From: "Stafford, Matthew" X-Spam-Score: 1.3 (+) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0423387815==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0423387815== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62C38.4F8638E8" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C62C38.4F8638E8 Content-Type: text/plain Richard- ===> What I want to have is SIP URI portability too, or in other words: I ===> want to have my sip URI sip:richard@stastny.com ===> hosted by one provider and the possibility to port this to another. No disagreement there. I guess I view these portability options as complementary (i.e., both useful depending on individual preferences). Thanks for the document pointers. Matt -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, February 07, 2006 12:50 PM To: Stafford, Matthew Cc: enum@ietf.org; speermint@ietf.org Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows >The second one is (essentially) number portability. My SIP URI can change from sip:mstafford@provider-A.net to >sip:mstafford@provider-B.biz. As long as my phone number stays the same, it can be used to obtain my current SIP URI. What I want to have is SIP URI portability too, or in other words: I want to have my sip URI sip:richard@stastny.com hosted by one provider and the possibility to port this to another. Especially if I am a company. For more information see the ECMA christmas wish-list presented today at ETSI TISPAN: Technical Report TR/91 Enterprise Communication in Next Generation Corporate Networks (NGCN) involving Public Next Generation Networks (NGN) (December 2005) http://www.ecma-international.org/publications/files/ECMA-TR/TR-091.pdf and also Technical Report TR/92 Corporate Telecommunication Networks - Mobility for Enterprise Communications (December 2005) http://www.ecma-international.org/publications/files/ECMA-TR/TR-092.pdf The scenarios and requirements described in these two documents will not be really easy to implement with NGNs ;-) Of course they want to have best of both sides: peering with each other in all variants AND in addition to be connected to an NGN, just to be on the safe side. One could also say: the overflow traffic is for the telcos (say max 20%) Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Stafford, Matthew Gesendet: Di 07.02.2006 19:20 An: Tony Rutkowski Cc: enum@ietf.org; speermint@ietf.org Betreff: RE: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Tony- The E.164 space is a many-encumbered thing. No argument there. All the same, I see two benefits of E.164 numbers: although *some* mobile devices have QWERTY keyboards, many of them still don't. IMO a telephone number is far and away the easiest thing to punch into a cellphone keypad. That's the first one. The second one is (essentially) number portability. My SIP URI can change from sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. As long as my phone number stays the same, it can be used to obtain my current SIP URI. Best, Matt -----Original Message----- From: Tony Rutkowski [mailto:trutkowski@verisign.com] Sent: Sunday, February 05, 2006 10:42 AM To: lconroy; Stafford, Matthew; Otmar Lendl Cc: enum@ietf.org; speermint@ietf.org Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Hi Lawrence, >The first is the process issue - what group (if any) coordinates >between the different DDDS applications and their uses; this topic ... >3761bis. It seems that your proposal is purely for Carrier/ Infrastructure/ >Private ENUM; in this case, changing 3761 has unintended consequences >for Public/User ENUM applications. These are great understatements. The use of E.164 identifiers, internationally and domestically, is subject to more statutory, regulatory, national security, and industry practice requirements than any identifier space in existence - not to mention well established institutional jurisdiction. The following list is a current tabulation of E.164 resolver-directory capability requirements, parsed into three categories, currently in play in various industry NGN forums. The recently enacted EC Data Retention Directive, and the U.S. Prevent Cyberstalking law, add further complexity to the mix. ;-) best, --tony >basic resolver capability > >supplementary capability > Number Portability > Priority Access > Roaming > Quality of Service > Directory Assistance > CallerID > Disability Assistance > Language preference > Personal emergency (E112/911) > Public emergency alerts > Law enforcement assistance > DoNotCall > Payment Methods > Intercarrier Compensation > Profile Management > Presence > Availability > Location > Push Management > Digital Rights Management > Device Management > Authentication Credentials > Information verification level > >protocol feature > Authentication > Auditing > Multiple Syntax Support > Mutiple Language Support > Extensibility and Localisation Mechanisms ------_=_NextPart_001_01C62C38.4F8638E8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Enum] a suggestion re: using flags to distinguish post-ENUM = signaling f lows

Richard-

=3D=3D=3D> What I want to have is SIP URI = portability too, or in other words: I =3D=3D=3D> want to have my sip = URI sip:richard@stastny.com

=3D=3D=3D> hosted by one provider and the = possibility to port this to another.

No disagreement there. I guess I view these = portability options as complementary (i.e., both useful depending on = individual preferences).

Thanks for the document pointers.

Matt

-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny@oefeg.at= ]
Sent: Tuesday, February 07, 2006 12:50 PM
To: Stafford, Matthew
Cc: enum@ietf.org; speermint@ietf.org
Subject: Re: [Enum] a suggestion re: using flags to = distinguish post-ENUM signaling f lows

>The second one is (essentially) number = portability. My SIP URI can change from sip:mstafford@provider-A.net to = >sip:mstafford@provider-B.biz. As long as my phone number stays the = same, it can be used to obtain my current SIP URI.

What I want to have is SIP URI portability too, or in = other words: I want to have my sip URI sip:richard@stastny.com
hosted by one provider and the possibility to port = this to another.

Especially if I am a company.
 
For more information see the ECMA christmas = wish-list presented today at ETSI TISPAN:
Technical Report TR/91
Enterprise Communication in Next Generation = Corporate Networks (NGCN) involving Public Next Generation Networks = (NGN)
(December 2005)
http://www.ecma-international.org/publications/files/E= CMA-TR/TR-091.pdf
 
and also
Technical Report TR/92
Corporate Telecommunication Networks - Mobility for = Enterprise Communications
(December 2005)
http://www.ecma-international.org/publications/files/E= CMA-TR/TR-092.pdf
 
The scenarios and requirements described in these = two documents will not
be really easy to implement with NGNs ;-)
Of course they want to have best of both sides: = peering with each other in all variants
AND in addition to be connected to an NGN, just to = be on the safe side.
One could also say: the overflow traffic is for the = telcos (say max 20%)
 
Richard


________________________________

Von: enum-bounces@ietf.org im Auftrag von Stafford, = Matthew
Gesendet: Di 07.02.2006 19:20
An: Tony Rutkowski
Cc: enum@ietf.org; speermint@ietf.org
Betreff: RE: [Enum] a suggestion re: using flags to = distinguish post-ENUM signaling f lows



Tony- The E.164 space is a many-encumbered thing. No = argument there.

All the same, I see two benefits of E.164 numbers: = although *some* mobile devices have QWERTY keyboards, many of them = still don't. IMO a telephone number is far and away the easiest thing = to punch into a cellphone keypad. That's the first one. The second one = is (essentially) number portability. My SIP URI can change from = sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. As long = as my phone number stays the same, it can be used to obtain my current = SIP URI.

Best,
Matt

-----Original Message-----
From: Tony Rutkowski [mailto:trutkowski@verisign.com]
Sent: Sunday, February 05, 2006 10:42 AM
To: lconroy; Stafford, Matthew; Otmar Lendl
Cc: enum@ietf.org; speermint@ietf.org
Subject: Re: [Enum] a suggestion re: using flags to = distinguish post-ENUM signaling f lows

Hi Lawrence,

>The first is the process issue - what group (if = any) coordinates
>between the different DDDS applications and = their uses; this topic
...
>3761bis. It seems that your proposal is purely = for Carrier/ Infrastructure/
>Private ENUM; in this case, changing 3761 has = unintended consequences
>for Public/User ENUM applications.

These are great understatements.  The use of =
E.164 identifiers, internationally and
domestically, is subject to more statutory,
regulatory, national security, and industry
practice requirements than any identifier
space in existence - not to mention well
established institutional jurisdiction.

The following list is a current tabulation
of E.164 resolver-directory capability
requirements, parsed into three categories,
currently in play in various industry NGN
forums.  The recently enacted EC Data
Retention Directive, and the U.S. Prevent
Cyberstalking law, add further complexity
to the mix. ;-)

best,
--tony

>basic resolver capability
>
>supplementary capability
>         = Number Portability
>         = Priority Access
>         = Roaming
>         = Quality of Service
>         = Directory Assistance
>         = CallerID
>         = Disability Assistance
>         = Language preference
>         = Personal emergency (E112/911)
>         = Public emergency alerts
>         = Law enforcement assistance
>         = DoNotCall
>         = Payment Methods
>         = Intercarrier Compensation
>         = Profile Management
>         = Presence
>         = Availability
>         = Location
>         = Push Management
>         = Digital Rights Management
>         = Device Management
>         = Authentication Credentials
>         = Information verification level
>
>protocol feature
>         = Authentication
>         = Auditing
>         = Multiple Syntax Support
>         = Mutiple Language Support
>         = Extensibility and Localisation Mechanisms

------_=_NextPart_001_01C62C38.4F8638E8-- --===============0423387815== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0423387815==-- From enum-bounces@ietf.org Tue Feb 07 18:16:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6c4W-0003ha-LY; Tue, 07 Feb 2006 18:16:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6c4T-0003gw-Gq; Tue, 07 Feb 2006 18:16:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10597; Tue, 7 Feb 2006 18:14:36 -0500 (EST) Received: from extmail09.cingular.com ([170.35.225.24] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6cGk-0003T9-Sn; Tue, 07 Feb 2006 18:29:11 -0500 Received: from ([10.3.188.52]) by extmail09.cingular.com with ESMTP id KP-VYGZ6.56991565; Tue, 07 Feb 2006 18:15:46 -0500 Received: by s75202e004001.tdc.cingular.net with Internet Mail Service (5.5.2657.72) id <1FCBZ5AG>; Tue, 7 Feb 2006 17:19:21 -0600 Message-ID: To: Stastny Richard Subject: RE: [Enum] a suggestion re: using flags to distinguish post-ENUMs ignaling f lows Date: Tue, 7 Feb 2006 17:16:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) From: "Stafford, Matthew" X-Spam-Score: 1.3 (+) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1529074117==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1529074117== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62C3C.8517ABBE" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C62C3C.8517ABBE Content-Type: text/plain Richard- Regarding ==> I thought E2U+sip:pstn ==> is pointing to a gw service already I consulted draft-ietf-enum-pstn-03. As best I can tell from a brief reading, the E2U+pstn records are helping you to find a media gateway for PSTN interconnect. I'm looking specifically at 7.1(d) and 7.2(f) in the call processing scenarios. Maybe "g" for gateway was a bad choice in my original message. Since "s" and "p" are already defined in non-ENUM contexts in the DDDS RFCs, I was looking for another term (other than server or proxy). Unless I read the PSTN draft incorrectly (or I'm looking at the wrong document altogether), I believe that it does *not* address the following question: I've done an ENUM query and extracted the URI from the ENUM NAPTR; how should I interpret the domain portion of the URI? Also, I'm curious to see the reactions to ==> E2U+mms:mailto:mx ? ==> or mailto:a@example.com;mx=yes/no ? ==> E2U+sip:srv ==> or sip:a@example.com;srv=yes/no Appending ";mx=yes/no" (or ";srv=yes/no" in the SIP case) gives information that can just as easily live outside the ENUM context. Not true of the Enumservice approach (or, for that matter, the ENUM NAPTR flag)- both of those are tied directly to the ENUM record. A random thought: If one wanted to go with mailto:a@example.com;mx=yes/no, where would the change to the mailto: URI scheme be documented? Best, Matt -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, February 07, 2006 12:54 PM To: Richard Shockey; Stafford, Matthew Cc: enum@ietf.org; speermint@ietf.org; lconroy Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUMsignaling f lows >Something like E2U+sip:pstngw I thought E2U+sip:pstn is pointing to a gw service already >URI extentions or Enumservice definitions are the way to go E2U+mms:mailto:mx ? or mailto:a@example.com;mx=yes/no ? E2U+sip:srv or sip:a@example.com;srv=yes/no Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Richard Shockey Gesendet: Di 07.02.2006 19:36 An: Stafford, Matthew Cc: enum@ietf.org; speermint@ietf.org; lconroy Betreff: Re: [Enum] a suggestion re: using flags to distinguish post-ENUMsignaling f lows > ==> I take your point regarding the headaches w/changes to clients. > ==> However, I'm not sure I agree that this is limited to carrier/infra- > ==> ENUM, at least if we think of that in terms of traditional telcos/ > ==> cellcos. For example, does this discussion really bear no relevance > ==> to enterprise applications (e.g., I want to call into my company's > ==> IP PBX while I'm on the road?) > > It appears that the proposed 'g' flag is appropriate only for SIP use > within Carrier ENUM, so one could WELL argue that this is an issue for the > SIP URI - I don't see how it can be used for other Enumservices (like > email:mailto, for example). Perhaps adding a SIP parameter (akin to ;user=phone) > would be more appropriate, or adding a new Enumservice to run alongside the > existing SIP one (i.e. to develop a new Enumservice definition RFC to specify > a SIP Gateway service)? That would be my strong recommendation. Something like E2U+sip:pstngw > > ==> That would have a similar effect to the flag proposal, in the sense > ==> that the contents of the ENUM NAPTR offer guidance on what to do next > ==> (which is really what I'm after) > > ==> For the sake of discussion, here's a similar example using the > recently-==> standardized Enumservice mms:mailto... an 'm' flag > indicating that the ==> NAPTR recipient should now look for an MX > Resource Record. Lets not even start a discussion over using the flag field ..I do't think that will go very far. IMHO a non starter. URI extentions or Enumservice definitions are the way to go > > all the best, > Lawrence > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01C62C3C.8517ABBE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Enum] a suggestion re: using flags to distinguish = post-ENUMsignaling f lows

Richard-

Regarding
=3D=3D> I thought E2U+sip:pstn
=3D=3D> is pointing to a gw service = already

I consulted draft-ietf-enum-pstn-03. As best I can = tell from a brief reading, the E2U+pstn records are helping you to find = a media gateway for PSTN interconnect. I'm looking specifically at = 7.1(d) and 7.2(f) in the call processing scenarios.

Maybe "g" for gateway was a bad choice in = my original message. Since "s" and "p" are already = defined in non-ENUM contexts in the DDDS RFCs, I was looking for = another term (other than server or proxy). Unless I read the PSTN draft = incorrectly (or I'm looking at the wrong document altogether), I = believe that it does *not* address the following question: I've done an = ENUM query and extracted the URI from the ENUM NAPTR; how should I = interpret the domain portion of the URI?

Also, I'm curious to see the reactions to

=3D=3D> E2U+mms:mailto:mx ?
=3D=3D> or mailto:a@example.com;mx=3Dyes/= no ?

=3D=3D> E2U+sip:srv
=3D=3D> or sip:a@example.com;srv=3Dyes/no

Appending ";mx=3Dyes/no" (or = ";srv=3Dyes/no" in the SIP case) gives information that can = just as easily live outside the ENUM context. Not true of the = Enumservice approach (or, for that matter, the ENUM NAPTR flag)- both = of those are tied directly to the ENUM record.

A random thought: If one wanted to go with mailto:a@example.com;mx=3Dyes/= no, where would the change to the mailto: URI scheme be documented? =

Best,
Matt

-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny@oefeg.at= ]
Sent: Tuesday, February 07, 2006 12:54 PM
To: Richard Shockey; Stafford, Matthew
Cc: enum@ietf.org; speermint@ietf.org; = lconroy
Subject: Re: [Enum] a suggestion re: using flags to = distinguish post-ENUMsignaling f lows

>Something like E2U+sip:pstngw
 
I thought E2U+sip:pstn
is pointing to a gw service already
 
>URI extentions or Enumservice definitions are = the way to go

E2U+mms:mailto:mx ?
or mailto:a@example.com;mx=3Dyes/= no ?

E2U+sip:srv
or sip:a@example.com;srv=3Dyes/no
 
Richard


________________________________

Von: enum-bounces@ietf.org im Auftrag von Richard = Shockey
Gesendet: Di 07.02.2006 19:36
An: Stafford, Matthew
Cc: enum@ietf.org; speermint@ietf.org; = lconroy
Betreff: Re: [Enum] a suggestion re: using flags to = distinguish post-ENUMsignaling f lows





> =3D=3D> I take your point regarding the = headaches w/changes to clients.
> =3D=3D> However, I'm not sure I agree that = this is limited to carrier/infra-
> =3D=3D> ENUM, at least if we think of that = in terms of traditional telcos/
> =3D=3D> cellcos. For example, does this = discussion really bear no relevance
> =3D=3D> to enterprise applications (e.g., I = want to call into my company's
> =3D=3D> IP PBX while I'm on the = road?)
>
> It appears that the proposed 'g' flag is = appropriate only for SIP use
> within Carrier ENUM, so one could WELL argue = that this is an issue for the
> SIP URI - I don't see how it can be used for = other Enumservices (like
> email:mailto, for example). Perhaps adding a = SIP parameter (akin to ;user=3Dphone)
> would be more appropriate, or adding a new = Enumservice to run alongside the
> existing SIP one (i.e. to develop a new = Enumservice definition RFC to specify
> a SIP Gateway service)?

That would be my strong recommendation.

Something like E2U+sip:pstngw


>
> =3D=3D> That would have a similar effect to = the flag proposal, in the sense
> =3D=3D> that the contents of the ENUM NAPTR = offer guidance on what to do next
> =3D=3D> (which is really what I'm = after)
>
> =3D=3D> For the sake of discussion, here's a = similar example using the
> recently-=3D=3D> standardized Enumservice = mms:mailto... an 'm' flag
> indicating that the =3D=3D> NAPTR recipient = should now look for an MX
> Resource Record.

Lets not even start a discussion over using the flag = field ..I do't
think that will go very far. IMHO a non = starter.

URI extentions or Enumservice definitions are the way = to go


>
> all the best,
>    Lawrence
>
>
--


 >>>>>>>>>>>>>>&= gt;>>>>>>>>>>>>>>>>>&= gt;>>>>>>>>>>>>>>>>>&= gt;>>
Richard Shockey, Director - Member of Technical = Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, = VA  20166
sip:rshockey(at)iptel.org   = sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 = 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us&g= t; or
<mailto:richard.shockey(at= )neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<= ;<<<<<<<<<<<<<<<<<<= ;<<<<<<<<<<<<<<<<<<= ;<

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

------_=_NextPart_001_01C62C3C.8517ABBE-- --===============1529074117== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1529074117==-- From enum-bounces@ietf.org Tue Feb 07 18:56:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6cgi-0005pB-97; Tue, 07 Feb 2006 18:56:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6cb0-0005Hd-Jf; Tue, 07 Feb 2006 18:50:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12145; Tue, 7 Feb 2006 18:48:24 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6cnR-0004Jm-Ih; Tue, 07 Feb 2006 19:02:58 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F6caw-0000yx-Fr; Tue, 07 Feb 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 07 Feb 2006 18:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-arch-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-ietf-enum-validation-arch-01.txt Pages : 17 Date : 2006-2-7 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-validation-arch-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-validation-arch-01.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: <2006-2-7174524.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-validation-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-validation-arch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-7174524.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Tue Feb 07 20:29:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6e97-0000cT-3B; Tue, 07 Feb 2006 20:29:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6e95-0000a0-2S for enum@megatron.ietf.org; Tue, 07 Feb 2006 20:29:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27602 for ; Tue, 7 Feb 2006 20:27:41 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6eLY-00028f-S4 for enum@ietf.org; Tue, 07 Feb 2006 20:42:18 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k181TdxW015122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2006 17:29:41 -0800 Message-ID: <43E94959.6060407@shockey.us> Date: Tue, 07 Feb 2006 20:28:57 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Peterson, Jon" , Allison Mankin Subject: [Enum] ENUM Working Group Last call on ENUM Validation Architecture X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for from Feb 8 until at least Feb 28 though we can modify that if new issues come up. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-ietf-enum-validation-arch-01.txt Pages : 17 Date : 2006-2-7 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-01.txt -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 07 23:56:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6hNj-0001jc-IW; Tue, 07 Feb 2006 23:56:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6hNi-0001ih-8r for enum@megatron.ietf.org; Tue, 07 Feb 2006 23:56:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13567 for ; Tue, 7 Feb 2006 23:54:51 -0500 (EST) Message-Id: <200602080454.XAA13567@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6ha6-0003Mu-0U for enum@ietf.org; Wed, 08 Feb 2006 00:09:31 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6hNT-00002r-AO; Wed, 08 Feb 2006 04:56:27 +0000 To: Richard Shockey , paf@cisco.com Date: Tue, 07 Feb 2006 20:56:27 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: enum@ietf.org, "Peterson, Jon" , mankin@psg.com Subject: [Enum] Re: Request for Publication - draft-ietf-enum-pstn-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Rich and PAF, Could you write the PROTO questionnaire for the document and send that to iesg-secretary and us ADs as well? We're trying to have these come in consistently for all publication requests. Here's an online copy of the questionnaire, as we haven't published the PROTO doc yet (this is online for the routing area; it's a very nice copy): http://rtg.ietf.org/area/procedures/proto_wgchair_writeup I'm glad to get this pub request, and this writeup will be helpful. Thanks! Allison _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 08 01:48:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6j7Y-0003jn-Tz; Wed, 08 Feb 2006 01:48:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6j7Y-0003hc-6q; Wed, 08 Feb 2006 01:48:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21076; Wed, 8 Feb 2006 01:46:17 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6jJu-0006x7-7G; Wed, 08 Feb 2006 02:00:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUMsignaling f lows Date: Wed, 8 Feb 2006 07:51:38 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4824@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] a suggestion re: using flags to distinguish post-ENUMsignaling f lows Thread-Index: AcYsPQg6aaaJZPBaRGCTfKjW41t06QAPk35j From: "Stastny Richard" To: "Stafford, Matthew" X-Spam-Score: 0.8 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >Also, I'm curious to see the reactions to=20 >=3D=3D> E2U+mms:mailto:mx ?=20 >=3D=3D> or mailto:a@example.com;mx=3Dyes/no ?=20 >=3D=3D> E2U+sip:srv=20 >=3D=3D> or sip:a@example.com;srv=3Dyes/no=20 >Appending ";mx=3Dyes/no" (or ";srv=3Dyes/no" in the SIP case) gives = information that can just as easily live outside the ENUM >context. Not = true of the Enumservice approach (or, for that matter, the ENUM NAPTR = flag)- both of those are tied directly >to the ENUM record. Exactly, Peering with SIP URIs must work with or without ENUM, especially in User = ENUM. The reason is that the ENUM query may be done by the client and a SIP proxy may = have no idea if the SIP URI has been entered by the user direct or by derived from ENUM. OTOH, since users now do not enter mailto:a@example.com;mx=3Dyes and it = works, why should they enter SIP:a@example.com;srv=3Dyes The SRV s mandatory anyway regards Richard ________________________________ Von: Stafford, Matthew [mailto:matthew.stafford@cingular.com] Gesendet: Mi 08.02.2006 00:16 An: Stastny Richard Cc: enum@ietf.org; speermint@ietf.org Betreff: RE: [Enum] a suggestion re: using flags to distinguish = post-ENUMsignaling f lows Richard-=20 Regarding=20 =3D=3D> I thought E2U+sip:pstn=20 =3D=3D> is pointing to a gw service already=20 I consulted draft-ietf-enum-pstn-03. As best I can tell from a brief = reading, the E2U+pstn records are helping you to find a media gateway = for PSTN interconnect. I'm looking specifically at 7.1(d) and 7.2(f) in = the call processing scenarios. Maybe "g" for gateway was a bad choice in my original message. Since "s" = and "p" are already defined in non-ENUM contexts in the DDDS RFCs, I was = looking for another term (other than server or proxy). Unless I read the = PSTN draft incorrectly (or I'm looking at the wrong document = altogether), I believe that it does *not* address the following = question: I've done an ENUM query and extracted the URI from the ENUM = NAPTR; how should I interpret the domain portion of the URI?=20 Also, I'm curious to see the reactions to=20 =3D=3D> E2U+mms:mailto:mx ?=20 =3D=3D> or mailto:a@example.com;mx=3Dyes/no ?=20 =3D=3D> E2U+sip:srv=20 =3D=3D> or sip:a@example.com;srv=3Dyes/no=20 Appending ";mx=3Dyes/no" (or ";srv=3Dyes/no" in the SIP case) gives = information that can just as easily live outside the ENUM context. Not = true of the Enumservice approach (or, for that matter, the ENUM NAPTR = flag)- both of those are tied directly to the ENUM record. A random thought: If one wanted to go with = mailto:a@example.com;mx=3Dyes/no, where would the change to the mailto: = URI scheme be documented?=20 Best,=20 Matt=20 -----Original Message-----=20 From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Tuesday, February 07, 2006 12:54 PM=20 To: Richard Shockey; Stafford, Matthew=20 Cc: enum@ietf.org; speermint@ietf.org; lconroy=20 Subject: Re: [Enum] a suggestion re: using flags to distinguish = post-ENUMsignaling f lows=20 >Something like E2U+sip:pstngw=20 =20 I thought E2U+sip:pstn=20 is pointing to a gw service already=20 =20 >URI extentions or Enumservice definitions are the way to go=20 E2U+mms:mailto:mx ?=20 or mailto:a@example.com;mx=3Dyes/no ?=20 E2U+sip:srv=20 or sip:a@example.com;srv=3Dyes/no=20 =20 Richard=20 ________________________________=20 Von: enum-bounces@ietf.org im Auftrag von Richard Shockey=20 Gesendet: Di 07.02.2006 19:36=20 An: Stafford, Matthew=20 Cc: enum@ietf.org; speermint@ietf.org; lconroy=20 Betreff: Re: [Enum] a suggestion re: using flags to distinguish = post-ENUMsignaling f lows=20 > =3D=3D> I take your point regarding the headaches w/changes to = clients.=20 > =3D=3D> However, I'm not sure I agree that this is limited to = carrier/infra-=20 > =3D=3D> ENUM, at least if we think of that in terms of traditional = telcos/=20 > =3D=3D> cellcos. For example, does this discussion really bear no = relevance=20 > =3D=3D> to enterprise applications (e.g., I want to call into my = company's=20 > =3D=3D> IP PBX while I'm on the road?)=20 >=20 > It appears that the proposed 'g' flag is appropriate only for SIP use=20 > within Carrier ENUM, so one could WELL argue that this is an issue for = the=20 > SIP URI - I don't see how it can be used for other Enumservices (like=20 > email:mailto, for example). Perhaps adding a SIP parameter (akin to = ;user=3Dphone)=20 > would be more appropriate, or adding a new Enumservice to run = alongside the=20 > existing SIP one (i.e. to develop a new Enumservice definition RFC to = specify=20 > a SIP Gateway service)?=20 That would be my strong recommendation.=20 Something like E2U+sip:pstngw=20 >=20 > =3D=3D> That would have a similar effect to the flag proposal, in the = sense=20 > =3D=3D> that the contents of the ENUM NAPTR offer guidance on what to = do next=20 > =3D=3D> (which is really what I'm after)=20 >=20 > =3D=3D> For the sake of discussion, here's a similar example using the = > recently-=3D=3D> standardized Enumservice mms:mailto... an 'm' flag=20 > indicating that the =3D=3D> NAPTR recipient should now look for an MX=20 > Resource Record.=20 Lets not even start a discussion over using the flag field ..I do't=20 think that will go very far. IMHO a non starter.=20 URI extentions or Enumservice definitions are the way to go=20 >=20 > all the best,=20 > Lawrence=20 >=20 >=20 --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 Richard Shockey, Director - Member of Technical Staff=20 NeuStar Inc.=20 46000 Center Oak Plaza - Sterling, VA 20166=20 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com=20 ENUM +87810-13313-31331=20 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683=20 Fax: +1 815.333.1237=20 or=20 =20 ; =20 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<=20 _______________________________________________=20 enum mailing list=20 enum@ietf.org=20 https://www1.ietf.org/mailman/listinfo/enum=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 08 07:05:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6o4T-0008A2-4s; Wed, 08 Feb 2006 07:05:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6o4R-00089D-Hc for enum@megatron.ietf.org; Wed, 08 Feb 2006 07:05:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15717 for ; Wed, 8 Feb 2006 07:03:34 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6oGw-0001YZ-PG for enum@ietf.org; Wed, 08 Feb 2006 07:18:16 -0500 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 08 Feb 2006 13:04:33 +0100 id 0006C002.43E9DE51.000066D2 Message-ID: <43E9DE3E.8050201@enum.at> Date: Wed, 08 Feb 2006 13:04:14 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: enum@ietf.org, Bernie Hoeneisen Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] NITS review of draft-ietf-enum-validation-epp-02 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi, i've reviewed the draft, here are my comments: - The draft passes the idnits checker - good. - Abbreviations in abstract: Some (not all!) RFC have acronyms spelled out in the Abstract - i've a request pending with the RFC editors about this. - Introduction: Please move references to the first occurence (namely ENUM [4] from 3rd para to 1st para as well als EPP). There's no need to repeat references within the document, like the ENUM reference in section 4.1. - XML elements are sometimes called "elements", sometimes "field" (4.5.1, 4.5.2 eg.) Please unify the terminology regarding XML elements. - 4.4: I'd add quotes around the word "any" - that would make it clearer that this is a name, and not the word "any". In addition, i'd point out that this is the a schema element by using 'XML schema "any" element'. - Please put the element/attribute names in quotes. That makes it easier to distinguish element names. Most EPP RFCs, however, use to identify XML elements - if the Draft should fit into them, that would be an approach, too. However, putting elements between <>'s would then clash with the command identifiers, however this is already mixed in eg. 5.1.2 where there is an " command", but also an " element". That should be cleaned up. - An XML schema identifier plus namespace in the urn:ietf range is used for the validation example data section - however, there is no registration requested in the IANA section for this. - The reference to the EPP domain mapping is repeated several times in the draft. I don't think that this is neccessary. - What about including a sentence like "The number of validationInfo elements per domain instance is subject to local registry policy" somewhere. That would make it clear that you might eg. limit the number of validationInfo elements to 1 per domain (as we are doing that right now ;) - After "Figure 2": What about changing the sentence to "... successfully, an EPP response as described in the EPP domain mapping is returned"? Same after Figure 3 etc.. - Both XML schemas pass the validation at http://www.w3.org/2001/03/webdata/xsv - IANA considerations: As mentioned above, the e164valex is missing. tia, alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 08 09:57:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6qko-0001hf-Jv; Wed, 08 Feb 2006 09:57:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6qki-0001gw-Hf for enum@megatron.ietf.org; Wed, 08 Feb 2006 09:57:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29073 for ; Wed, 8 Feb 2006 09:55:12 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6qxA-0007g3-0i for enum@ietf.org; Wed, 08 Feb 2006 10:09:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Feb 2006 16:00:31 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C482A@oefeg-s04.oefeg.loc> Thread-Topic: URI Portability Thread-Index: AcYsaY52gUtbml3ZSrey35XuARR0XgATjaTL From: "Stastny Richard" To: , , X-Spam-Score: 0.8 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Content-Transfer-Encoding: quoted-printable Cc: Subject: [Enum] Re: URI Portability X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jim Baskin sent a private comment on URI Portability to Matt and me, but had no objections to comment this on the list, which I do, because I consider this relevant: >Number portability and SIP URI portability may sound like=20 >similar concepts, but there is at least one big difference.=20 >Moving sip:richard@stastny.com from one provider to another=20 >may be really simple, assuming that you own stastny.com and=20 >you have control over its nameserver. =20 Agreed =20 >However, if you are=20 >a SIP customer of acme-sip.com (e.g., sip:richard@acme-sip.com),=20 >it isn't a strictly technical issue. It is not likely that=20 >the owners of acme-sip.com would want their company name or=20 >its domain used by someone who has a different SIP service=20 >provider. The same issue is why I don't ever expect to see=20 >email address portability for somebody@aol.com or=20 >somebody-else@yahoo.com.=20 I agree in principal, but we have to distinguish between to cases here: 1. sip:richard@acme-sip.com can be compared your company extension with = DDI I have eg +43 1 79780 32 as office number, where 32 is my extension. It is obvious that if I change company I cannot take (port) this number = with me, because +43 1 79780 belongs to OeFEG. Same with acme-sip.com +43 1 79780 is public, the rest is private. In the PSTN there exists a clear distinction between what a public telephone service is and what is private (corporate) 2. On the Internet this distincion is not existing, but of course one could be found:=20 acme-sip.com is not providing a service for the public yahoo.com and aol.com is. A bored regulator could come to the conclusion at some time to foster competition and require URI portability vor public SIP URIs. First every SIP service provider would rant that this is impossible, expensive, whatever, but we had this also on the PSTN. Of course this can be implemented in the same way as it was implemented in the PSTN, with onward routing and/or redirect, with the same drawback: the donor is always involved Next step would be to standardise a DNS lookup for sip:fred@yahoo.com in something like fred.at.yahoo.com to find the current URI. of course there are a lot of problems, such as a certified from information, but this can be solved. >E.164 telephone numbers, on the other hand, don't have service=20 >provider trademark issues. In addition, number portability,=20 >if done with a database and originating or n-1 carrier dips,=20 >takes the ported-from service provider completely out of call=20 >processing for the ported number. Of course, number portability=20 >isn't "perfect" yet. There are still regulatory limits on=20 >what numbers can be ported where. =20 SIP URI portability of course must work global, an this will delay or prevent the idea for some time ;-) =20 >Oh yes, regarding Tony's statement, "The use of E.164=20 >identifiers, internationally and domestically, is subject to=20 >more statutory, regulatory, national security, and industry=20 >practice requirements than any identifier space in existence -=20 >not to mention well established institutional jurisdiction."=20 >That may be exactly why E.164 telephone numbers have been used so=20 >successfully as a nearly seamless identifier standard providing=20 >worldwide telecommunications for longer than many IETF=20 >participants can remember.=20 True, at least as long as we do not have global reachability provided by a Public User Identity in the form of a SIP AoR. =20 Richard >Jim Baskin=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Original messages:=20 Richard-=20 =3D=3D=3D> What I want to have is SIP URI portability too, or in other = words: I =3D=3D=3D> want to have my sip URI sip:richard@stastny.com=20 =3D=3D=3D> hosted by one provider and the possibility to port this to = another.=20 No disagreement there. I guess I view these portability options as = complementary (i.e., both useful depending on individual preferences).=20 Thanks for the document pointers.=20 Matt=20 -----Original Message-----=20 From: Stastny Richard [mailto:Richard.Stastny@oefeg.at = ]=20 Sent: Tuesday, February 07, 2006 12:50 PM=20 To: Stafford, Matthew=20 Cc: enum@ietf.org; speermint@ietf.org=20 Subject: Re: [Enum] a suggestion re: using flags to distinguish = post-ENUM signaling f lows=20 >The second one is (essentially) number portability. My SIP URI can = change from sip:mstafford@provider-A.net to = >sip:mstafford@provider-B.biz. As long as my phone number stays the = same, it can be used to obtain my current SIP URI.=20 What I want to have is SIP URI portability too, or in other words: I = want to have my sip URI sip:richard@stastny.com=20 hosted by one provider and the possibility to port this to another.=20 Especially if I am a company.=20 =20 For more information see the ECMA christmas wish-list presented today at = ETSI TISPAN:=20 Technical Report TR/91=20 Enterprise Communication in Next Generation Corporate Networks (NGCN) = involving Public Next Generation Networks (NGN)=20 (December 2005)=20 http://www.ecma-international.org/publications/files/ECMA-TR/TR-091.pdf = = =20 =20 and also=20 Technical Report TR/92=20 Corporate Telecommunication Networks - Mobility for Enterprise = Communications=20 (December 2005)=20 http://www.ecma-international.org/publications/files/ECMA-TR/TR-092.pdf = = =20 =20 The scenarios and requirements described in these two documents will not = be really easy to implement with NGNs ;-)=20 Of course they want to have best of both sides: peering with each other = in all variants=20 AND in addition to be connected to an NGN, just to be on the safe side.=20 One could also say: the overflow traffic is for the telcos (say max 20%) = =20 Richard=20 _______________________________=20 Von: enum-bounces@ietf.org im Auftrag von Stafford, Matthew=20 Gesendet: Di 07.02.2006 19:20=20 An: Tony Rutkowski=20 Cc: enum@ietf.org; speermint@ietf.org=20 Betreff: RE: [Enum] a suggestion re: using flags to distinguish = post-ENUM signaling f lows=20 Tony- The E.164 space is a many-encumbered thing. No argument there.=20 All the same, I see two benefits of E.164 numbers: although *some* = mobile devices have QWERTY keyboards, many of them still don't. IMO a = telephone number is far and away the easiest thing to punch into a = cellphone keypad. That's the first one. The second one is (essentially) = number portability. My SIP URI can change from = sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. As long as = my phone number stays the same, it can be used to obtain my current SIP = URI.=20 Best,=20 Matt=20 -----Original Message-----=20 From: Tony Rutkowski [mailto:trutkowski@verisign.com = ]=20 Sent: Sunday, February 05, 2006 10:42 AM=20 To: lconroy; Stafford, Matthew; Otmar Lendl=20 Cc: enum@ietf.org; speermint@ietf.org=20 Subject: Re: [Enum] a suggestion re: using flags to distinguish = post-ENUM signaling f lows=20 Hi Lawrence,=20 >The first is the process issue - what group (if any) coordinates=20 >between the different DDDS applications and their uses; this topic=20 ...=20 >3761bis. It seems that your proposal is purely for Carrier/ = Infrastructure/=20 >Private ENUM; in this case, changing 3761 has unintended consequences=20 >for Public/User ENUM applications.=20 These are great understatements. The use of=20 E.164 identifiers, internationally and=20 domestically, is subject to more statutory,=20 regulatory, national security, and industry=20 practice requirements than any identifier=20 space in existence - not to mention well=20 established institutional jurisdiction.=20 The following list is a current tabulation=20 of E.164 resolver-directory capability=20 requirements, parsed into three categories,=20 currently in play in various industry NGN=20 forums. The recently enacted EC Data=20 Retention Directive, and the U.S. Prevent=20 Cyberstalking law, add further complexity=20 to the mix. ;-)=20 best,=20 --tony=20 >basic resolver capability=20 >=20 >supplementary capability=20 > Number Portability=20 > Priority Access=20 > Roaming=20 > Quality of Service=20 > Directory Assistance=20 > CallerID=20 > Disability Assistance=20 > Language preference=20 > Personal emergency (E112/911)=20 > Public emergency alerts=20 > Law enforcement assistance=20 > DoNotCall=20 > Payment Methods=20 > Intercarrier Compensation=20 > Profile Management=20 > Presence=20 > Availability=20 > Location=20 > Push Management=20 > Digital Rights Management=20 > Device Management=20 > Authentication Credentials=20 > Information verification level=20 >=20 >protocol feature=20 > Authentication=20 > Auditing=20 > Multiple Syntax Support=20 > Mutiple Language Support=20 > Extensibility and Localisation Mechanisms 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 enum-bounces@ietf.org Wed Feb 08 10:23:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rA6-0005vG-FL; Wed, 08 Feb 2006 10:23:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rA5-0005uu-Eo for enum@megatron.ietf.org; Wed, 08 Feb 2006 10:23:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00879 for ; Wed, 8 Feb 2006 10:21:30 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6rMb-000072-QD for enum@ietf.org; Wed, 08 Feb 2006 10:36:15 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 08 Feb 2006 07:22:58 -0800 X-IronPort-AV: i="4.02,98,1139212800"; d="scan'208"; a="254263918:sNHT36851750" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k18FMuQL021586; Wed, 8 Feb 2006 07:22:58 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 10:22:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: URI Portability Date: Wed, 8 Feb 2006 10:22:55 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3010F9EAA@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] Re: URI Portability Thread-Index: AcYsaY52gUtbml3ZSrey35XuARR0XgATjaTLAAKS0kA= From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , , , X-OriginalArrivalTime: 08 Feb 2006 15:22:56.0452 (UTC) FILETIME=[898BC040:01C62CC3] X-Spam-Score: 0.8 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard, This talk of URI portability being like number portability seems dangerous. The problems with number ownership in the PSTN and domain name ownership wrt ICANN always seems a sore point. The logical conclusion is you go that route would seem to be to assign a national identity, perhaps like: john-doe456@town.state.country at birth which then begs the question can people be portable too. Should we stamp this on our passports too? Then we can create yet another DNS directory UNUM to do translations from our birth URI to our current SP URI. :( Please, don't go there. It seems to have little value. If you want to keep a business domain name, buy a long-term lease of the name and run your own DNS server. I am not an ENUM guru. Am I missing something here? Mike > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Stastny Richard > Sent: Wednesday, February 08, 2006 10:01 AM > To: james.f.baskin@verizon.com;=20 > matthew.stafford@cingular.com; enum@ietf.org > Subject: [Enum] Re: URI Portability >=20 > Jim Baskin sent a private comment on URI Portability to Matt=20 > and me, but had no objections to comment this on the list,=20 > which I do, because I consider this relevant: >=20 > >Number portability and SIP URI portability may sound like similar=20 > >concepts, but there is at least one big difference. > >Moving sip:richard@stastny.com from one provider to another may be=20 > >really simple, assuming that you own stastny.com and you=20 > have control=20 > >over its nameserver. >=20 > Agreed > =20 > >However, if you are > >a SIP customer of acme-sip.com (e.g., sip:richard@acme-sip.com), it=20 > >isn't a strictly technical issue. It is not likely that the=20 > owners of=20 > >acme-sip.com would want their company name or its domain used by=20 > >someone who has a different SIP service provider. The same issue is=20 > >why I don't ever expect to see email address portability for=20 > >somebody@aol.com or somebody-else@yahoo.com. >=20 > I agree in principal, but we have to distinguish between to=20 > cases here: >=20 >=20 > 1. sip:richard@acme-sip.com can be compared your company=20 > extension with DDI I have eg +43 1 79780 32 as office number,=20 > where 32 is my extension. > It is obvious that if I change company I cannot take (port)=20 > this number with me, because +43 1 79780 belongs to OeFEG.=20 > Same with acme-sip.com > +43 1 79780 is public, the rest is private. In the PSTN there exists > a clear distinction between what a public telephone service=20 > is and what is private (corporate) >=20 > 2. On the Internet this distincion is not existing, but of=20 > course one could be found:=20 >=20 > acme-sip.com is not providing a service for the public=20 > yahoo.com and aol.com is. >=20 > A bored regulator could come to the conclusion at some time=20 > to foster competition and require URI portability vor public SIP URIs. >=20 > First every SIP service provider would rant that this is=20 > impossible, expensive, whatever, but we had this also on the PSTN. >=20 > Of course this can be implemented in the same way as it was=20 > implemented in the PSTN, with onward routing and/or redirect,=20 > with the same drawback: the donor is always involved >=20 > Next step would be to standardise a DNS lookup for sip:fred@yahoo.com >=20 > in something like fred.at.yahoo.com to find the current URI. > of course there are a lot of problems, such as a certified=20 > from information, but this can be solved. >=20 > >E.164 telephone numbers, on the other hand, don't have=20 > service provider=20 > >trademark issues. In addition, number portability, if done with a=20 > >database and originating or n-1 carrier dips, takes the ported-from=20 > >service provider completely out of call processing for the ported=20 > >number. Of course, number portability isn't "perfect" yet. =20 > There are=20 > >still regulatory limits on what numbers can be ported where. > =20 > SIP URI portability of course must work global, an this > will delay or prevent the idea for some time ;-) =20 >=20 > >Oh yes, regarding Tony's statement, "The use of E.164 identifiers,=20 > >internationally and domestically, is subject to more statutory,=20 > >regulatory, national security, and industry practice=20 > requirements than=20 > >any identifier space in existence - not to mention well established=20 > >institutional jurisdiction." > >That may be exactly why E.164 telephone numbers have been used so=20 > >successfully as a nearly seamless identifier standard providing=20 > >worldwide telecommunications for longer than many IETF=20 > participants can=20 > >remember. >=20 > True, at least as long as we do not have global reachability=20 > provided by a Public User Identity in the form of a SIP AoR. > =20 > Richard >=20 > >Jim Baskin >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Original messages:=20 >=20 > Richard- > =3D=3D=3D> What I want to have is SIP URI portability too, or in=20 > other words: I =3D=3D=3D> want to have my sip URI=20 > sip:richard@stastny.com =3D=3D=3D> hosted by one provider and the=20 > possibility to port this to another.=20 > No disagreement there. I guess I view these portability=20 > options as complementary (i.e., both useful depending on=20 > individual preferences).=20 > Thanks for the document pointers.=20 > Matt > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at=20 > ] > Sent: Tuesday, February 07, 2006 12:50 PM > To: Stafford, Matthew > Cc: enum@ietf.org; speermint@ietf.org > Subject: Re: [Enum] a suggestion re: using flags to=20 > distinguish post-ENUM signaling f lows=20 >=20 > >The second one is (essentially) number portability. My SIP=20 > URI can change from sip:mstafford@provider-A.net to=20 > >sip:mstafford@provider-B.biz. As long as my phone number=20 > stays the same, it can be used to obtain my current SIP URI.=20 >=20 > What I want to have is SIP URI portability too, or in other=20 > words: I want to have my sip URI sip:richard@stastny.com=20 > hosted by one provider and the possibility to port this to another.=20 >=20 > Especially if I am a company.=20 > =20 > For more information see the ECMA christmas wish-list=20 > presented today at ETSI TISPAN:=20 > Technical Report TR/91 > Enterprise Communication in Next Generation Corporate=20 > Networks (NGCN) involving Public Next Generation Networks=20 > (NGN) (December 2005)=20 > http://www.ecma-international.org/publications/files/ECMA-TR/T > R-091.pdf=20 > TR-091.pdf> =20 > =20 > and also > Technical Report TR/92 > Corporate Telecommunication Networks - Mobility for=20 > Enterprise Communications (December 2005)=20 > http://www.ecma-international.org/publications/files/ECMA-TR/T > R-092.pdf=20 > TR-092.pdf> =20 > =20 > The scenarios and requirements described in these two=20 > documents will not be really easy to implement with NGNs ;-)=20 > Of course they want to have best of both sides: peering with=20 > each other in all variants AND in addition to be connected to=20 > an NGN, just to be on the safe side.=20 > One could also say: the overflow traffic is for the telcos=20 > (say max 20%)=20 > =20 > Richard > _______________________________=20 >=20 > Von: enum-bounces@ietf.org im Auftrag von Stafford, Matthew > Gesendet: Di 07.02.2006 19:20 > An: Tony Rutkowski > Cc: enum@ietf.org; speermint@ietf.org > Betreff: RE: [Enum] a suggestion re: using flags to=20 > distinguish post-ENUM signaling f lows=20 >=20 > Tony- The E.164 space is a many-encumbered thing. No argument there.=20 >=20 > All the same, I see two benefits of E.164 numbers: although=20 > *some* mobile devices have QWERTY keyboards, many of them=20 > still don't. IMO a telephone number is far and away the=20 > easiest thing to punch into a cellphone keypad. That's the=20 > first one. The second one is (essentially) number=20 > portability. My SIP URI can change from=20 > sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz.=20 > As long as my phone number stays the same, it can be used to=20 > obtain my current SIP URI.=20 >=20 > Best, > Matt=20 >=20 > -----Original Message----- > From: Tony Rutkowski [mailto:trutkowski@verisign.com=20 > ] > Sent: Sunday, February 05, 2006 10:42 AM > To: lconroy; Stafford, Matthew; Otmar Lendl > Cc: enum@ietf.org; speermint@ietf.org > Subject: Re: [Enum] a suggestion re: using flags to=20 > distinguish post-ENUM signaling f lows=20 >=20 > Hi Lawrence,=20 >=20 > >The first is the process issue - what group (if any) coordinates=20 > >between the different DDDS applications and their uses; this topic > ...=20 > >3761bis. It seems that your proposal is purely for Carrier/=20 > >Infrastructure/ Private ENUM; in this case, changing 3761 has=20 > >unintended consequences for Public/User ENUM applications. >=20 > These are great understatements. The use of > E.164 identifiers, internationally and > domestically, is subject to more statutory, regulatory,=20 > national security, and industry practice requirements than=20 > any identifier space in existence - not to mention well=20 > established institutional jurisdiction.=20 >=20 > The following list is a current tabulation of E.164=20 > resolver-directory capability requirements, parsed into three=20 > categories, currently in play in various industry NGN forums.=20 > The recently enacted EC Data Retention Directive, and the=20 > U.S. Prevent Cyberstalking law, add further complexity to the=20 > mix. ;-)=20 >=20 > best,=20 > --tony=20 >=20 > >basic resolver capability=20 > >=20 > >supplementary capability=20 > > Number Portability=20 > > Priority Access=20 > > Roaming=20 > > Quality of Service=20 > > Directory Assistance=20 > > CallerID=20 > > Disability Assistance=20 > > Language preference=20 > > Personal emergency (E112/911)=20 > > Public emergency alerts=20 > > Law enforcement assistance=20 > > DoNotCall=20 > > Payment Methods=20 > > Intercarrier Compensation=20 > > Profile Management=20 > > Presence=20 > > Availability=20 > > Location=20 > > Push Management=20 > > Digital Rights Management=20 > > Device Management=20 > > Authentication Credentials=20 > > Information verification level=20 > >=20 > >protocol feature=20 > > Authentication=20 > > Auditing=20 > > Multiple Syntax Support=20 > > Mutiple Language Support=20 > > Extensibility and Localisation Mechanisms > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 08 10:29:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rFy-0007mz-Dn; Wed, 08 Feb 2006 10:29:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rFx-0007mL-AG for enum@megatron.ietf.org; Wed, 08 Feb 2006 10:29:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01316 for ; Wed, 8 Feb 2006 10:27:38 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6rSZ-0000Ll-1w for enum@ietf.org; Wed, 08 Feb 2006 10:42:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: URI Portability Date: Wed, 8 Feb 2006 16:28:18 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C482B@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: URI Portability Thread-Index: AcYsaY52gUtbml3ZSrey35XuARR0XgATjaTLAAKS0kAAAI5CnA== From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , , , X-Spam-Score: 0.8 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Mike, =20 I agree with you. Maybe I was not perfectly clear: I do not propose this to be implemented, I just said it could be implemented if it is required. NP was also not invented by operators, it was invented by regulators. =20 IMHO "portability" of domains held by individuals or companies must be implemented, but not portability within domains held by an ISP or VoIP SP such as yahoo.com or verizon.net =20 Richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Mi 08.02.2006 16:22 An: Stastny Richard; james.f.baskin@verizon.com; = matthew.stafford@cingular.com; enum@ietf.org Betreff: RE: [Enum] Re: URI Portability Richard, This talk of URI portability being like number portability seems dangerous. The problems with number ownership in the PSTN and domain name ownership wrt ICANN always seems a sore point. The logical conclusion is you go that route would seem to be to assign a national identity, perhaps like: john-doe456@town.state.country at birth which then begs the question can people be portable too. Should we stamp this on our passports too? Then we can create yet another DNS directory UNUM to do translations from our birth URI to our current SP URI. :( Please, don't go there. It seems to have little value. If you want to keep a business domain name, buy a long-term lease of the name and run your own DNS server. I am not an ENUM guru. Am I missing something here? Mike > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > Behalf Of Stastny Richard > Sent: Wednesday, February 08, 2006 10:01 AM > To: james.f.baskin@verizon.com; > matthew.stafford@cingular.com; enum@ietf.org > Subject: [Enum] Re: URI Portability > > Jim Baskin sent a private comment on URI Portability to Matt > and me, but had no objections to comment this on the list, > which I do, because I consider this relevant: > > >Number portability and SIP URI portability may sound like similar > >concepts, but there is at least one big difference. > >Moving sip:richard@stastny.com from one provider to another may be > >really simple, assuming that you own stastny.com and you > have control > >over its nameserver. > > Agreed >=20 > >However, if you are > >a SIP customer of acme-sip.com (e.g., sip:richard@acme-sip.com), it > >isn't a strictly technical issue. It is not likely that the > owners of > >acme-sip.com would want their company name or its domain used by > >someone who has a different SIP service provider. The same issue is > >why I don't ever expect to see email address portability for > >somebody@aol.com or somebody-else@yahoo.com. > > I agree in principal, but we have to distinguish between to > cases here: > > > 1. sip:richard@acme-sip.com can be compared your company > extension with DDI I have eg +43 1 79780 32 as office number, > where 32 is my extension. > It is obvious that if I change company I cannot take (port) > this number with me, because +43 1 79780 belongs to OeFEG. > Same with acme-sip.com > +43 1 79780 is public, the rest is private. In the PSTN there exists > a clear distinction between what a public telephone service > is and what is private (corporate) > > 2. On the Internet this distincion is not existing, but of > course one could be found: > > acme-sip.com is not providing a service for the public > yahoo.com and aol.com is. > > A bored regulator could come to the conclusion at some time > to foster competition and require URI portability vor public SIP URIs. > > First every SIP service provider would rant that this is > impossible, expensive, whatever, but we had this also on the PSTN. > > Of course this can be implemented in the same way as it was > implemented in the PSTN, with onward routing and/or redirect, > with the same drawback: the donor is always involved > > Next step would be to standardise a DNS lookup for sip:fred@yahoo.com > > in something like fred.at.yahoo.com to find the current URI. > of course there are a lot of problems, such as a certified > from information, but this can be solved. > > >E.164 telephone numbers, on the other hand, don't have > service provider > >trademark issues. In addition, number portability, if done with a > >database and originating or n-1 carrier dips, takes the ported-from > >service provider completely out of call processing for the ported > >number. Of course, number portability isn't "perfect" yet.=20 > There are > >still regulatory limits on what numbers can be ported where. >=20 > SIP URI portability of course must work global, an this > will delay or prevent the idea for some time ;-) =20 > > >Oh yes, regarding Tony's statement, "The use of E.164 identifiers, > >internationally and domestically, is subject to more statutory, > >regulatory, national security, and industry practice > requirements than > >any identifier space in existence - not to mention well established > >institutional jurisdiction." > >That may be exactly why E.164 telephone numbers have been used so > >successfully as a nearly seamless identifier standard providing > >worldwide telecommunications for longer than many IETF > participants can > >remember. > > True, at least as long as we do not have global reachability > provided by a Public User Identity in the form of a SIP AoR. >=20 > Richard > > >Jim Baskin > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Original messages: > > Richard- > =3D=3D=3D> What I want to have is SIP URI portability too, or in > other words: I =3D=3D=3D> want to have my sip URI > sip:richard@stastny.com =3D=3D=3D> hosted by one provider and the > possibility to port this to another. > No disagreement there. I guess I view these portability > options as complementary (i.e., both useful depending on > individual preferences). > Thanks for the document pointers. > Matt > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at > ] > Sent: Tuesday, February 07, 2006 12:50 PM > To: Stafford, Matthew > Cc: enum@ietf.org; speermint@ietf.org > Subject: Re: [Enum] a suggestion re: using flags to > distinguish post-ENUM signaling f lows > > >The second one is (essentially) number portability. My SIP > URI can change from sip:mstafford@provider-A.net to > >sip:mstafford@provider-B.biz. As long as my phone number > stays the same, it can be used to obtain my current SIP URI. > > What I want to have is SIP URI portability too, or in other > words: I want to have my sip URI sip:richard@stastny.com > hosted by one provider and the possibility to port this to another. > > Especially if I am a company. >=20 > For more information see the ECMA christmas wish-list > presented today at ETSI TISPAN: > Technical Report TR/91 > Enterprise Communication in Next Generation Corporate > Networks (NGCN) involving Public Next Generation Networks > (NGN) (December 2005) > http://www.ecma-international.org/publications/files/ECMA-TR/T > R-091.pdf > TR-091.pdf>=20 >=20 > and also > Technical Report TR/92 > Corporate Telecommunication Networks - Mobility for > Enterprise Communications (December 2005) > http://www.ecma-international.org/publications/files/ECMA-TR/T > R-092.pdf > TR-092.pdf>=20 > =20 > The scenarios and requirements described in these two > documents will not be really easy to implement with NGNs ;-) > Of course they want to have best of both sides: peering with > each other in all variants AND in addition to be connected to > an NGN, just to be on the safe side. > One could also say: the overflow traffic is for the telcos > (say max 20%) >=20 > Richard > _______________________________ > > Von: enum-bounces@ietf.org im Auftrag von Stafford, Matthew > Gesendet: Di 07.02.2006 19:20 > An: Tony Rutkowski > Cc: enum@ietf.org; speermint@ietf.org > Betreff: RE: [Enum] a suggestion re: using flags to > distinguish post-ENUM signaling f lows > > Tony- The E.164 space is a many-encumbered thing. No argument there. > > All the same, I see two benefits of E.164 numbers: although > *some* mobile devices have QWERTY keyboards, many of them > still don't. IMO a telephone number is far and away the > easiest thing to punch into a cellphone keypad. That's the > first one. The second one is (essentially) number > portability. My SIP URI can change from > sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. > As long as my phone number stays the same, it can be used to > obtain my current SIP URI. > > Best, > Matt > > -----Original Message----- > From: Tony Rutkowski [mailto:trutkowski@verisign.com > ] > Sent: Sunday, February 05, 2006 10:42 AM > To: lconroy; Stafford, Matthew; Otmar Lendl > Cc: enum@ietf.org; speermint@ietf.org > Subject: Re: [Enum] a suggestion re: using flags to > distinguish post-ENUM signaling f lows > > Hi Lawrence, > > >The first is the process issue - what group (if any) coordinates > >between the different DDDS applications and their uses; this topic > ... > >3761bis. It seems that your proposal is purely for Carrier/ > >Infrastructure/ Private ENUM; in this case, changing 3761 has > >unintended consequences for Public/User ENUM applications. > > These are great understatements. The use of > E.164 identifiers, internationally and > domestically, is subject to more statutory, regulatory, > national security, and industry practice requirements than > any identifier space in existence - not to mention well > established institutional jurisdiction. > > The following list is a current tabulation of E.164 > resolver-directory capability requirements, parsed into three > categories, currently in play in various industry NGN forums. > The recently enacted EC Data Retention Directive, and the > U.S. Prevent Cyberstalking law, add further complexity to the > mix. ;-) > > best, > --tony > > >basic resolver capability > > > >supplementary capability > > Number Portability > > Priority Access > > Roaming > > Quality of Service > > Directory Assistance > > CallerID > > Disability Assistance > > Language preference > > Personal emergency (E112/911) > > Public emergency alerts > > Law enforcement assistance > > DoNotCall > > Payment Methods > > Intercarrier Compensation > > Profile Management > > Presence > > Availability > > Location > > Push Management > > Digital Rights Management > > Device Management > > Authentication Credentials > > Information verification level > > > >protocol feature > > Authentication > > Auditing > > Multiple Syntax Support > > Mutiple Language Support > > Extensibility and Localisation Mechanisms > 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 enum-bounces@ietf.org Wed Feb 08 10:32:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rJQ-0001Xi-OH; Wed, 08 Feb 2006 10:32:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rJN-0001X9-Do for enum@megatron.ietf.org; Wed, 08 Feb 2006 10:32:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01619 for ; Wed, 8 Feb 2006 10:31:10 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6rVz-0000Uw-L6 for enum@ietf.org; Wed, 08 Feb 2006 10:45:56 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2006 07:32:42 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,98,1139212800"; d="scan'208"; a="21439004:sNHT27721804" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k18FWDPi008950; Wed, 8 Feb 2006 10:32:39 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 10:32:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: URI Portability Date: Wed, 8 Feb 2006 10:32:34 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3010F9EC4@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] Re: URI Portability Thread-Index: AcYsaY52gUtbml3ZSrey35XuARR0XgATjaTLAAKS0kAAAI5CnAAAHKEQ From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , , , X-OriginalArrivalTime: 08 Feb 2006 15:32:35.0362 (UTC) FILETIME=[E29A6820:01C62CC4] X-Spam-Score: 0.8 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Never tell regulators something is possible, it will just become a new career opportunity. :) Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Wednesday, February 08, 2006 10:28 AM > To: Michael Hammer (mhammer); james.f.baskin@verizon.com;=20 > matthew.stafford@cingular.com; enum@ietf.org > Subject: Re: [Enum] Re: URI Portability >=20 > Mike, > =20 > I agree with you. Maybe I was not perfectly clear: I do not=20 > propose this to be implemented, I just said it could be=20 > implemented if it is required. NP was also not invented by=20 > operators, it was invented by regulators. > =20 > IMHO "portability" of domains held by individuals or=20 > companies must be implemented, but not portability within=20 > domains held by an ISP or VoIP SP such as yahoo.com or verizon.net > =20 > Richard >=20 > ________________________________ >=20 > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Gesendet: Mi 08.02.2006 16:22 > An: Stastny Richard; james.f.baskin@verizon.com;=20 > matthew.stafford@cingular.com; enum@ietf.org > Betreff: RE: [Enum] Re: URI Portability >=20 >=20 >=20 > Richard, >=20 > This talk of URI portability being like number portability=20 > seems dangerous. The problems with number ownership in the=20 > PSTN and domain name ownership wrt ICANN always seems a sore=20 > point. The logical conclusion is you go that route would=20 > seem to be to assign a national identity, perhaps like:=20 > john-doe456@town.state.country at birth which then begs the=20 > question can people be portable too. Should we stamp this on=20 > our passports too? Then we can create yet another DNS=20 > directory UNUM to do translations from our birth URI to our=20 > current SP URI. :( >=20 > Please, don't go there. It seems to have little value. If=20 > you want to keep a business domain name, buy a long-term=20 > lease of the name and run your own DNS server. >=20 > I am not an ENUM guru. Am I missing something here? >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]=20 > On Behalf=20 > > Of Stastny Richard > > Sent: Wednesday, February 08, 2006 10:01 AM > > To: james.f.baskin@verizon.com; > > matthew.stafford@cingular.com; enum@ietf.org > > Subject: [Enum] Re: URI Portability > > > > Jim Baskin sent a private comment on URI Portability to=20 > Matt and me,=20 > > but had no objections to comment this on the list, which I=20 > do, because=20 > > I consider this relevant: > > > > >Number portability and SIP URI portability may sound like similar=20 > > >concepts, but there is at least one big difference. > > >Moving sip:richard@stastny.com from one provider to another may be=20 > > >really simple, assuming that you own stastny.com and you > > have control > > >over its nameserver. > > > > Agreed > >=20 > > >However, if you are > > >a SIP customer of acme-sip.com (e.g.,=20 > sip:richard@acme-sip.com), it=20 > > >isn't a strictly technical issue. It is not likely that the > > owners of > > >acme-sip.com would want their company name or its domain used by=20 > > >someone who has a different SIP service provider. The=20 > same issue is=20 > > >why I don't ever expect to see email address portability for=20 > > >somebody@aol.com or somebody-else@yahoo.com. > > > > I agree in principal, but we have to distinguish between to cases=20 > > here: > > > > > > 1. sip:richard@acme-sip.com can be compared your company extension=20 > > with DDI I have eg +43 1 79780 32 as office number, where 32 is my=20 > > extension. > > It is obvious that if I change company I cannot take (port) this=20 > > number with me, because +43 1 79780 belongs to OeFEG. > > Same with acme-sip.com > > +43 1 79780 is public, the rest is private. In the PSTN there exists > > a clear distinction between what a public telephone service is and=20 > > what is private (corporate) > > > > 2. On the Internet this distincion is not existing, but of=20 > course one=20 > > could be found: > > > > acme-sip.com is not providing a service for the public=20 > yahoo.com and=20 > > aol.com is. > > > > A bored regulator could come to the conclusion at some time=20 > to foster=20 > > competition and require URI portability vor public SIP URIs. > > > > First every SIP service provider would rant that this is=20 > impossible,=20 > > expensive, whatever, but we had this also on the PSTN. > > > > Of course this can be implemented in the same way as it was=20 > > implemented in the PSTN, with onward routing and/or=20 > redirect, with the=20 > > same drawback: the donor is always involved > > > > Next step would be to standardise a DNS lookup for=20 > sip:fred@yahoo.com > > > > in something like fred.at.yahoo.com to find the current URI. > > of course there are a lot of problems, such as a certified from=20 > > information, but this can be solved. > > > > >E.164 telephone numbers, on the other hand, don't have > > service provider > > >trademark issues. In addition, number portability, if done with a=20 > > >database and originating or n-1 carrier dips, takes the=20 > ported-from=20 > > >service provider completely out of call processing for the ported=20 > > >number. Of course, number portability isn't "perfect" yet. > > There are > > >still regulatory limits on what numbers can be ported where. > >=20 > > SIP URI portability of course must work global, an this=20 > will delay or=20 > > prevent the idea for some time ;-) > > > > >Oh yes, regarding Tony's statement, "The use of E.164 identifiers,=20 > > >internationally and domestically, is subject to more statutory,=20 > > >regulatory, national security, and industry practice > > requirements than > > >any identifier space in existence - not to mention well=20 > established=20 > > >institutional jurisdiction." > > >That may be exactly why E.164 telephone numbers have been used so=20 > > >successfully as a nearly seamless identifier standard providing=20 > > >worldwide telecommunications for longer than many IETF > > participants can > > >remember. > > > > True, at least as long as we do not have global=20 > reachability provided=20 > > by a Public User Identity in the form of a SIP AoR. > >=20 > > Richard > > > > >Jim Baskin > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Original messages: > > > > Richard- > > =3D=3D=3D> What I want to have is SIP URI portability too, or in = other=20 > > words: I =3D=3D=3D> want to have my sip URI sip:richard@stastny.com = =3D=3D=3D>=20 > > hosted by one provider and the possibility to port this to another. > > No disagreement there. I guess I view these portability options as=20 > > complementary (i.e., both useful depending on individual=20 > preferences). > > Thanks for the document pointers. > > Matt > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at=20 > > ] > > Sent: Tuesday, February 07, 2006 12:50 PM > > To: Stafford, Matthew > > Cc: enum@ietf.org; speermint@ietf.org > > Subject: Re: [Enum] a suggestion re: using flags to distinguish=20 > > post-ENUM signaling f lows > > > > >The second one is (essentially) number portability. My SIP > > URI can change from sip:mstafford@provider-A.net to > > >sip:mstafford@provider-B.biz. As long as my phone number > > stays the same, it can be used to obtain my current SIP URI. > > > > What I want to have is SIP URI portability too, or in other > > words: I want to have my sip URI sip:richard@stastny.com=20 > hosted by one=20 > > provider and the possibility to port this to another. > > > > Especially if I am a company. > >=20 > > For more information see the ECMA christmas wish-list=20 > presented today=20 > > at ETSI TISPAN: > > Technical Report TR/91 > > Enterprise Communication in Next Generation Corporate=20 > Networks (NGCN)=20 > > involving Public Next Generation Networks > > (NGN) (December 2005) > > http://www.ecma-international.org/publications/files/ECMA-TR/T > > R-091.pdf > > > TR-091.pdf> > >=20 > > and also > > Technical Report TR/92 > > Corporate Telecommunication Networks - Mobility for Enterprise=20 > > Communications (December 2005)=20 > > http://www.ecma-international.org/publications/files/ECMA-TR/T > > R-092.pdf > > > TR-092.pdf> > > =20 > > The scenarios and requirements described in these two=20 > documents will=20 > > not be really easy to implement with NGNs ;-) Of course=20 > they want to=20 > > have best of both sides: peering with each other in all=20 > variants AND=20 > > in addition to be connected to an NGN, just to be on the safe side. > > One could also say: the overflow traffic is for the telcos (say max=20 > > 20%) > >=20 > > Richard > > _______________________________ > > > > Von: enum-bounces@ietf.org im Auftrag von Stafford, Matthew > > Gesendet: Di 07.02.2006 19:20 > > An: Tony Rutkowski > > Cc: enum@ietf.org; speermint@ietf.org > > Betreff: RE: [Enum] a suggestion re: using flags to distinguish=20 > > post-ENUM signaling f lows > > > > Tony- The E.164 space is a many-encumbered thing. No argument there. > > > > All the same, I see two benefits of E.164 numbers: although > > *some* mobile devices have QWERTY keyboards, many of them=20 > still don't.=20 > > IMO a telephone number is far and away the easiest thing to=20 > punch into=20 > > a cellphone keypad. That's the first one. The second one is=20 > > (essentially) number portability. My SIP URI can change from=20 > > sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. > > As long as my phone number stays the same, it can be used=20 > to obtain my=20 > > current SIP URI. > > > > Best, > > Matt > > > > -----Original Message----- > > From: Tony Rutkowski [mailto:trutkowski@verisign.com=20 > > ] > > Sent: Sunday, February 05, 2006 10:42 AM > > To: lconroy; Stafford, Matthew; Otmar Lendl > > Cc: enum@ietf.org; speermint@ietf.org > > Subject: Re: [Enum] a suggestion re: using flags to distinguish=20 > > post-ENUM signaling f lows > > > > Hi Lawrence, > > > > >The first is the process issue - what group (if any) coordinates=20 > > >between the different DDDS applications and their uses; this topic > > ... > > >3761bis. It seems that your proposal is purely for Carrier/=20 > > >Infrastructure/ Private ENUM; in this case, changing 3761 has=20 > > >unintended consequences for Public/User ENUM applications. > > > > These are great understatements. The use of > > E.164 identifiers, internationally and domestically, is subject to=20 > > more statutory, regulatory, national security, and industry=20 > practice=20 > > requirements than any identifier space in existence - not=20 > to mention=20 > > well established institutional jurisdiction. > > > > The following list is a current tabulation of E.164=20 > resolver-directory=20 > > capability requirements, parsed into three categories, currently in=20 > > play in various industry NGN forums. > > The recently enacted EC Data Retention Directive, and the U.S.=20 > > Prevent Cyberstalking law, add further complexity to the mix. ;-) > > > > best, > > --tony > > > > >basic resolver capability > > > > > >supplementary capability > > > Number Portability > > > Priority Access > > > Roaming > > > Quality of Service > > > Directory Assistance > > > CallerID > > > Disability Assistance > > > Language preference > > > Personal emergency (E112/911) > > > Public emergency alerts > > > Law enforcement assistance > > > DoNotCall > > > Payment Methods > > > Intercarrier Compensation > > > Profile Management > > > Presence > > > Availability > > > Location > > > Push Management > > > Digital Rights Management > > > Device Management > > > Authentication Credentials > > > Information verification level > > > > > >protocol feature > > > Authentication > > > Auditing > > > Multiple Syntax Support > > > Mutiple Language Support > > > Extensibility and Localisation Mechanisms > > 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 > > >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 08 12:06:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6sm9-0002WK-Fm; Wed, 08 Feb 2006 12:06:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6sm6-0002VX-Vd for enum@megatron.ietf.org; Wed, 08 Feb 2006 12:06:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10091 for ; Wed, 8 Feb 2006 12:04:55 -0500 (EST) From: james.f.baskin@verizon.com Received: from tpamail2.verizon.com ([192.76.82.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6syg-0004Ca-9r for enum@ietf.org; Wed, 08 Feb 2006 12:19:42 -0500 Received: from smtpftw3.verizon.com (smtpftw3.verizon.com [138.83.140.92]) by tpamail2.verizon.com (8.13.3/8.13.3) with ESMTP id k18H6HIu001106 for ; Wed, 8 Feb 2006 12:06:19 -0500 (EST) Received: from irvp1cvmma01.vzh.ent.verizon.com (irvp1cvmma01.verizon.com [138.83.34.82]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id k18H5x9m010860 for ; Wed, 8 Feb 2006 12:06:17 -0500 (EST) Received: from 138.83.34.22 by irvp1cvmma01.vzh.ent.verizon.com with ESMTP (SMTP Relay); Wed, 08 Feb 2006 12:06:01 -0500 X-Server-Uuid: 33D99CC3-91DD-4C5F-B3C4-DE0A72F86AF5 Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id k18H5xLi014723 for ; Wed, 8 Feb 2006 11:05:59 -0600 ( CST) To: "Stastny Richard" Subject: Re: [Enum] Re: URI Portability MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Wed, 8 Feb 2006 12:05:51 -0500 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.5.4HF453 | August 4, 2005) at 02/08/2006 11:05:59, Serialize complete at 02/08/2006 11:05:59 X-WSS-ID: 6FF4FB7267W439413-01-01 X-Spam-Score: 0.8 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1811698947==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multipart message in MIME format. --===============1811698947== Content-Type: multipart/alternative; boundary="=_alternative 005E1CDA8525710F_=" This is a multipart message in MIME format. --=_alternative 005E1CDA8525710F_= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Richard, I must be missing something. As far as I know, individually-owned or company-owned domain names ARE portable. I can have any service provider run a web server for my domain. I can have a separate provider handle my email. I can have lots of providers handle lots of different services for me, and I can switch any particular service from any provider to any other at any time. What kind of portability isn't already implemented? What portability functions are you looking for that aren't available today? Jim ========================== Richard Stastny wrote: IMHO "portability" of domains held by individuals or companies must be implemented, but not portability within domains held by an ISP or VoIP SP such as yahoo.com or verizon.net --=_alternative 005E1CDA8525710F_= Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Richard,

I must be missing something.  As far as I know, individually-owned
or company-owned domain names ARE portable.  I can have any service
provider run a web server for my domain.  I can have a separate
provider handle my email.  I can have lots of providers handle lots
of different services for me, and I can switch any particular
service from any provider to any other at any time.  

What kind of portability isn't already implemented?  What portability
functions are you looking for that aren't available today?

Jim

==========================
Richard Stastny wrote:

IMHO "portability" of domains held by individuals or companies
must be implemented, but not portability within domains held
by an ISP or VoIP SP such as yahoo.com or verizon.net --=_alternative 005E1CDA8525710F_=-- --===============1811698947== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1811698947==-- From enum-bounces@ietf.org Wed Feb 08 12:42:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tKx-0007WT-Vp; Wed, 08 Feb 2006 12:42:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tKp-0007Ux-1e for enum@megatron.ietf.org; Wed, 08 Feb 2006 12:42:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13883 for ; Wed, 8 Feb 2006 12:40:37 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6tXF-0005q7-6M for enum@ietf.org; Wed, 08 Feb 2006 12:55:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: URI Portability Date: Wed, 8 Feb 2006 18:41:47 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C482E@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: URI Portability Thread-Index: AcYs0olV22vs36BoR3qLegE5VgfGZgABGXrO From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org James, >I must be missing something. As far as I know, individually-owned=20 >or company-owned domain names ARE portable. I can have any service=20 >provider run a web server for my domain. I can have a separate=20 >provider handle my email. I can have lots of providers handle lots=20 >of different services for me, and I can switch any particular=20 >service from any provider to any other at any time. =20 >What kind of portability isn't already implemented? What portability=20 >functions are you looking for that aren't available today?=20 =20 you can port jamesbaskin.com and Yahoo can port yahoo.com to any = provider, but you cannot port james.baskin@yahoo.com independently to a different service provider. So if you leave yahoo.com, you loose = james.baskin@yahoo.com =20 Richard Jim=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=20 Richard Stastny wrote:=20 IMHO "portability" of domains held by individuals or companies must be implemented, but not portability within domains held by an ISP or VoIP SP such as yahoo.com or verizon.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 08 12:48:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tQv-0000It-7m; Wed, 08 Feb 2006 12:48:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tQt-0000Gm-3H for enum@megatron.ietf.org; Wed, 08 Feb 2006 12:48:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14574 for ; Wed, 8 Feb 2006 12:46:52 -0500 (EST) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6tdE-00066e-Ft for enum@ietf.org; Wed, 08 Feb 2006 13:01:37 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id A34CB1A618; Wed, 8 Feb 2006 18:48:11 +0100 (CET) Date: Wed, 8 Feb 2006 18:48:11 +0100 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] Re: URI Portability Message-ID: <20060208174811.GA6329@nic.at> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2006/02/08 18:02, james.f.baskin@verizon.com wrote: > Richard, > > I must be missing something. As far as I know, individually-owned > or company-owned domain names ARE portable. I can have any service > provider run a web server for my domain. I can have a separate > provider handle my email. I can have lots of providers handle lots > of different services for me, and I can switch any particular > service from any provider to any other at any time. > > What kind of portability isn't already implemented? What portability > functions are you looking for that aren't available today? Have you ever asked one of the new SIP based VoIP outfits (Vonage, SIPhone, Gizmo, VoIPbuster, SIPgate, ...) whether their system copes with customers wanting to use their own domain for the SIP URIs these services use? I haven't seen that yet. The protocol support ist there, no question. But in term of implementation we're at the level of email anno 1992 where most people had to use user@provider as their email address. To make things even more interesting: have a look at the the IMS and all the other NGN efforts. From what I have heard, these people don't want to rely on the public DNS for any of their call routing decisions. They can easily build their own private DNS on their GRX (or whatever) network and store the domains of the carriers in there. I can't see how such a private DNS infrastructure can ever cope with people wanting to user their own domains in an IMS or NGN setting. Either you duplicate the public DNS in your walled garden or you abandon your "never depend on the public Internet principle". So: There is a real chance that for the near future people will have no choice but use sip:user@provider as their SIP address. I thus consider it not _that_ unlikely that regulators will step in and force portability for such addresses. Summary: Right now, E.164 numbers are still the primary addressing mechanism for most SIP/VoIP services. Once that starts to change and people start to put SIP addresses on their business cards, then all providers MUST offer the option of using a customer-owned domain. Failing to support that early can spell trouble down the road. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 08 13:05:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tgi-0004ih-JP; Wed, 08 Feb 2006 13:05:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tgg-0004gg-ND for enum@megatron.ietf.org; Wed, 08 Feb 2006 13:05:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16929 for ; Wed, 8 Feb 2006 13:03:15 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6tt9-00075Q-8O for enum@ietf.org; Wed, 08 Feb 2006 13:18:00 -0500 Received: from [10.31.13.180] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k18I5LMw006542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2006 10:05:23 -0800 Message-ID: <43EA32B9.9030406@shockey.us> Date: Wed, 08 Feb 2006 13:04:41 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Peterson, Jon" , Allison Mankin Subject: [Enum] ENUM Working Group Last call on ENUM Validation Architecture X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-ietf-enum-validation-arch-01.txt Pages : 17 Date : 2006-2-7 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-01.txt The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. This document has been under discussion since early 2005. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 2 weeks or so from today Feb 8 until at least Feb 24 though we can modify that if new issues come up. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 08 13:06:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tiQ-0005GY-JS; Wed, 08 Feb 2006 13:06:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tiN-0005FA-GA for enum@megatron.ietf.org; Wed, 08 Feb 2006 13:06:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17104 for ; Wed, 8 Feb 2006 13:05:00 -0500 (EST) Received: from smtpout06-01.prod.mesa1.secureserver.net ([64.202.165.224] helo=smtpout06-03.prod.mesa1.secureserver.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6tuq-0007A7-OF for enum@ietf.org; Wed, 08 Feb 2006 13:19:45 -0500 Received: (qmail 24046 invoked from network); 8 Feb 2006 18:06:29 -0000 Received: from unknown (HELO gem-wbe06.prod.mesa1.secureserver.net) (64.202.189.38) by smtpout06-03.prod.mesa1.secureserver.net with SMTP; 8 Feb 2006 18:06:29 -0000 Received: (qmail 25510 invoked by uid 99); 8 Feb 2006 18:06:29 -0000 Date: Wed, 08 Feb 2006 11:06:29 -0700 From: Tim Ruiz Subject: RE: [Enum] Re: URI Portability To: Stastny Richard Message-ID: <20060208110629.4a871ae7d05d2c98d9abb595d392cd69.5c51fef7ac.wbe@email.email.secureserver.net> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII X-Originating-IP: 12.215.195.100 X-Spam-Score: 3.1 (+++) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Cc: james.f.baskin@verizon.com, enum@ietf.org, "Michael Hammer \(mhammer\)" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tim Ruiz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard, So you are saying sip:richard@stastny.com must be portable, but not sip:richard@acme-sip.com? If so, then you're done becaue the first example is really already portable isn't it? Tim -------- Original Message -------- Subject: Re: [Enum] Re: URI Portability From: "Stastny Richard" Date: Wed, February 08, 2006 9:28 am To: "Michael Hammer (mhammer)" , , , Mike, I agree with you. Maybe I was not perfectly clear: I do not propose this to be implemented, I just said it could be implemented if it is required. NP was also not invented by operators, it was invented by regulators. IMHO "portability" of domains held by individuals or companies must be implemented, but not portability within domains held by an ISP or VoIP SP such as yahoo.com or verizon.net Richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Mi 08.02.2006 16:22 An: Stastny Richard; james.f.baskin@verizon.com; matthew.stafford@cingular.com; enum@ietf.org Betreff: RE: [Enum] Re: URI Portability Richard, This talk of URI portability being like number portability seems dangerous. The problems with number ownership in the PSTN and domain name ownership wrt ICANN always seems a sore point. The logical conclusion is you go that route would seem to be to assign a national identity, perhaps like: john-doe456@town.state.country at birth which then begs the question can people be portable too. Should we stamp this on our passports too? Then we can create yet another DNS directory UNUM to do translations from our birth URI to our current SP URI. :( Please, don't go there. It seems to have little value. If you want to keep a business domain name, buy a long-term lease of the name and run your own DNS server. I am not an ENUM guru. Am I missing something here? Mike > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > Behalf Of Stastny Richard > Sent: Wednesday, February 08, 2006 10:01 AM > To: james.f.baskin@verizon.com; > matthew.stafford@cingular.com; enum@ietf.org > Subject: [Enum] Re: URI Portability > > Jim Baskin sent a private comment on URI Portability to Matt > and me, but had no objections to comment this on the list, > which I do, because I consider this relevant: > > >Number portability and SIP URI portability may sound like similar > >concepts, but there is at least one big difference. > >Moving sip:richard@stastny.com from one provider to another may be > >really simple, assuming that you own stastny.com and you > have control > >over its nameserver. > > Agreed > > >However, if you are > >a SIP customer of acme-sip.com (e.g., sip:richard@acme-sip.com), it > >isn't a strictly technical issue. It is not likely that the > owners of > >acme-sip.com would want their company name or its domain used by > >someone who has a different SIP service provider. The same issue is > >why I don't ever expect to see email address portability for > >somebody@aol.com or somebody-else@yahoo.com. > > I agree in principal, but we have to distinguish between to > cases here: > > > 1. sip:richard@acme-sip.com can be compared your company > extension with DDI I have eg +43 1 79780 32 as office number, > where 32 is my extension. > It is obvious that if I change company I cannot take (port) > this number with me, because +43 1 79780 belongs to OeFEG. > Same with acme-sip.com > +43 1 79780 is public, the rest is private. In the PSTN there exists > a clear distinction between what a public telephone service > is and what is private (corporate) > > 2. On the Internet this distincion is not existing, but of > course one could be found: > > acme-sip.com is not providing a service for the public > yahoo.com and aol.com is. > > A bored regulator could come to the conclusion at some time > to foster competition and require URI portability vor public SIP URIs. > > First every SIP service provider would rant that this is > impossible, expensive, whatever, but we had this also on the PSTN. > > Of course this can be implemented in the same way as it was > implemented in the PSTN, with onward routing and/or redirect, > with the same drawback: the donor is always involved > > Next step would be to standardise a DNS lookup for sip:fred@yahoo.com > > in something like fred.at.yahoo.com to find the current URI. > of course there are a lot of problems, such as a certified > from information, but this can be solved. > > >E.164 telephone numbers, on the other hand, don't have > service provider > >trademark issues. In addition, number portability, if done with a > >database and originating or n-1 carrier dips, takes the ported-from > >service provider completely out of call processing for the ported > >number. Of course, number portability isn't "perfect" yet. > There are > >still regulatory limits on what numbers can be ported where. > > SIP URI portability of course must work global, an this > will delay or prevent the idea for some time ;-) > > >Oh yes, regarding Tony's statement, "The use of E.164 identifiers, > >internationally and domestically, is subject to more statutory, > >regulatory, national security, and industry practice > requirements than > >any identifier space in existence - not to mention well established > >institutional jurisdiction." > >That may be exactly why E.164 telephone numbers have been used so > >successfully as a nearly seamless identifier standard providing > >worldwide telecommunications for longer than many IETF > participants can > >remember. > > True, at least as long as we do not have global reachability > provided by a Public User Identity in the form of a SIP AoR. > > Richard > > >Jim Baskin > > ======================================= > Original messages: > > Richard- > ===> What I want to have is SIP URI portability too, or in > other words: I ===> want to have my sip URI > sip:richard@stastny.com ===> hosted by one provider and the > possibility to port this to another. > No disagreement there. I guess I view these portability > options as complementary (i.e., both useful depending on > individual preferences). > Thanks for the document pointers. > Matt > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at > ] > Sent: Tuesday, February 07, 2006 12:50 PM > To: Stafford, Matthew > Cc: enum@ietf.org; speermint@ietf.org > Subject: Re: [Enum] a suggestion re: using flags to > distinguish post-ENUM signaling f lows > > >The second one is (essentially) number portability. My SIP > URI can change from sip:mstafford@provider-A.net to > >sip:mstafford@provider-B.biz. As long as my phone number > stays the same, it can be used to obtain my current SIP URI. > > What I want to have is SIP URI portability too, or in other > words: I want to have my sip URI sip:richard@stastny.com > hosted by one provider and the possibility to port this to another. > > Especially if I am a company. > > For more information see the ECMA christmas wish-list > presented today at ETSI TISPAN: > Technical Report TR/91 > Enterprise Communication in Next Generation Corporate > Networks (NGCN) involving Public Next Generation Networks > (NGN) (December 2005) > http://www.ecma-international.org/publications/files/ECMA-TR/T > R-091.pdf > TR-091.pdf> > > and also > Technical Report TR/92 > Corporate Telecommunication Networks - Mobility for > Enterprise Communications (December 2005) > http://www.ecma-international.org/publications/files/ECMA-TR/T > R-092.pdf > TR-092.pdf> > > The scenarios and requirements described in these two > documents will not be really easy to implement with NGNs ;-) > Of course they want to have best of both sides: peering with > each other in all variants AND in addition to be connected to > an NGN, just to be on the safe side. > One could also say: the overflow traffic is for the telcos > (say max 20%) > > Richard > _______________________________ > > Von: enum-bounces@ietf.org im Auftrag von Stafford, Matthew > Gesendet: Di 07.02.2006 19:20 > An: Tony Rutkowski > Cc: enum@ietf.org; speermint@ietf.org > Betreff: RE: [Enum] a suggestion re: using flags to > distinguish post-ENUM signaling f lows > > Tony- The E.164 space is a many-encumbered thing. No argument there. > > All the same, I see two benefits of E.164 numbers: although > *some* mobile devices have QWERTY keyboards, many of them > still don't. IMO a telephone number is far and away the > easiest thing to punch into a cellphone keypad. That's the > first one. The second one is (essentially) number > portability. My SIP URI can change from > sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. > As long as my phone number stays the same, it can be used to > obtain my current SIP URI. > > Best, > Matt > > -----Original Message----- > From: Tony Rutkowski [mailto:trutkowski@verisign.com > ] > Sent: Sunday, February 05, 2006 10:42 AM > To: lconroy; Stafford, Matthew; Otmar Lendl > Cc: enum@ietf.org; speermint@ietf.org > Subject: Re: [Enum] a suggestion re: using flags to > distinguish post-ENUM signaling f lows > > Hi Lawrence, > > >The first is the process issue - what group (if any) coordinates > >between the different DDDS applications and their uses; this topic > ... > >3761bis. It seems that your proposal is purely for Carrier/ > >Infrastructure/ Private ENUM; in this case, changing 3761 has > >unintended consequences for Public/User ENUM applications. > > These are great understatements. The use of > E.164 identifiers, internationally and > domestically, is subject to more statutory, regulatory, > national security, and industry practice requirements than > any identifier space in existence - not to mention well > established institutional jurisdiction. > > The following list is a current tabulation of E.164 > resolver-directory capability requirements, parsed into three > categories, currently in play in various industry NGN forums. > The recently enacted EC Data Retention Directive, and the > U.S. Prevent Cyberstalking law, add further complexity to the > mix. ;-) > > best, > --tony > > >basic resolver capability > > > >supplementary capability > > Number Portability > > Priority Access > > Roaming > > Quality of Service > > Directory Assistance > > CallerID > > Disability Assistance > > Language preference > > Personal emergency (E112/911) > > Public emergency alerts > > Law enforcement assistance > > DoNotCall > > Payment Methods > > Intercarrier Compensation > > Profile Management > > Presence > > Availability > > Location > > Push Management > > Digital Rights Management > > Device Management > > Authentication Credentials > > Information verification level > > > >protocol feature > > Authentication > > Auditing > > Multiple Syntax Support > > Mutiple Language Support > > Extensibility and Localisation Mechanisms > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 08 14:06:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ue3-0007PK-3E; Wed, 08 Feb 2006 14:06:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ue0-0007OS-OB for enum@megatron.ietf.org; Wed, 08 Feb 2006 14:06:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22292 for ; Wed, 8 Feb 2006 14:04:35 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6uqX-0000w5-3G for enum@ietf.org; Wed, 08 Feb 2006 14:19:21 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2006 11:06:06 -0800 X-IronPort-AV: i="4.02,98,1139212800"; d="scan'208"; a="402428776:sNHT1584796582" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k18J5ZL3005803; Wed, 8 Feb 2006 11:06:06 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 14:06:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: URI Portability Date: Wed, 8 Feb 2006 14:06:00 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3010F9FE2@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] Re: URI Portability Thread-Index: AcYs2UwDx9wqGdtiRROOqm053QP88gACNvbg From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" , X-OriginalArrivalTime: 08 Feb 2006 19:06:01.0331 (UTC) FILETIME=[B38E3430:01C62CE2] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Otmar, What do you think are the chances of my getting the mike@hammer.com, hammer.net, hammer.org, ... domain name? The problem is only shifted. Mike =20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Otmar Lendl > Sent: Wednesday, February 08, 2006 12:48 PM > To: enum@ietf.org > Subject: Re: [Enum] Re: URI Portability >=20 > On 2006/02/08 18:02, james.f.baskin@verizon.com wrote: > > Richard, > >=20 > > I must be missing something. As far as I know,=20 > individually-owned or=20 > > company-owned domain names ARE portable. I can have any service=20 > > provider run a web server for my domain. I can have a separate=20 > > provider handle my email. I can have lots of providers=20 > handle lots of=20 > > different services for me, and I can switch any particular service=20 > > from any provider to any other at any time. > >=20 > > What kind of portability isn't already implemented? What=20 > portability=20 > > functions are you looking for that aren't available today? >=20 > Have you ever asked one of the new SIP based VoIP outfits=20 > (Vonage, SIPhone, Gizmo, VoIPbuster, SIPgate, ...) whether=20 > their system copes with customers wanting to use their own=20 > domain for the SIP URIs these services use? >=20 > I haven't seen that yet.=20 >=20 > The protocol support ist there, no question. But in term of=20 > implementation we're at the level of email anno 1992 where=20 > most people had to use user@provider as their email address. >=20 > To make things even more interesting: have a look at the the=20 > IMS and all the other NGN efforts. From what I have heard,=20 > these people don't want to rely on the public DNS for any of=20 > their call routing decisions. They can easily build their own=20 > private DNS on their GRX (or whatever) network and store the=20 > domains of the carriers in there. >=20 > I can't see how such a private DNS infrastructure can ever=20 > cope with people wanting to user their own domains in an IMS=20 > or NGN setting. Either you duplicate the public DNS in your=20 > walled garden or you abandon your "never depend on the public=20 > Internet principle". >=20 > So: There is a real chance that for the near future people=20 > will have no choice but use sip:user@provider as their SIP address. >=20 > I thus consider it not _that_ unlikely that regulators will=20 > step in and force portability for such addresses. >=20 > Summary: Right now, E.164 numbers are still the primary=20 > addressing mechanism for most SIP/VoIP services. Once that=20 > starts to change and people start to put SIP addresses on=20 > their business cards, then all providers MUST offer the=20 > option of using a customer-owned domain. >=20 > Failing to support that early can spell trouble down the road. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 08 14:32:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6v3a-0003UQ-G1; Wed, 08 Feb 2006 14:32:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6v3Y-0003Tc-Ma for enum@megatron.ietf.org; Wed, 08 Feb 2006 14:32:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24545 for ; Wed, 8 Feb 2006 14:31:06 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6vGC-0001y6-3p for enum@ietf.org; Wed, 08 Feb 2006 14:45:53 -0500 Received: from [10.31.13.180] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k18JWl73018782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2006 11:32:48 -0800 Message-ID: <43EA4737.5060801@shockey.us> Date: Wed, 08 Feb 2006 14:32:07 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Enum] Re: URI Portability References: <072C5B76F7CEAB488172C6F64B30B5E3010F9FE2@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3010F9FE2@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Otmar Lendl X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Michael Hammer (mhammer) wrote: > Otmar, > > What do you think are the chances of my getting the mike@hammer.com, > hammer.net, hammer.org, ... domain name? > > The problem is only shifted. well actually mikehammer.us is available :-) > > Mike > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 08 14:38:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6v9M-0004zc-UQ; Wed, 08 Feb 2006 14:38:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6v9L-0004uB-89 for enum@megatron.ietf.org; Wed, 08 Feb 2006 14:38:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25023 for ; Wed, 8 Feb 2006 14:37:00 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6vLt-0002BE-UY for enum@ietf.org; Wed, 08 Feb 2006 14:51:47 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2006 11:38:32 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k18Jc0kD019632; Wed, 8 Feb 2006 11:38:31 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 14:38:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: URI Portability Date: Wed, 8 Feb 2006 14:38:25 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3010FA012@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] Re: URI Portability Thread-Index: AcYs5mp0timE7v9HT/WtxgETDIvXIwAAHbQg From: "Michael Hammer \(mhammer\)" To: "Richard Shockey" X-OriginalArrivalTime: 08 Feb 2006 19:38:26.0337 (UTC) FILETIME=[3ADE9110:01C62CE7] X-Spam-Score: 0.8 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, Otmar Lendl X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Maybe, but that doesn't scale globally. =20 Heck, I couldn't even get my own name within Comcast domain. My solution is to just not use letter head or print too many business cards. :) Mike =20 > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us]=20 > Sent: Wednesday, February 08, 2006 2:32 PM > To: Michael Hammer (mhammer) > Cc: Otmar Lendl; enum@ietf.org > Subject: Re: [Enum] Re: URI Portability >=20 > Michael Hammer (mhammer) wrote: > > Otmar, > >=20 > > What do you think are the chances of my getting the=20 > mike@hammer.com,=20 > > hammer.net, hammer.org, ... domain name? > >=20 > > The problem is only shifted. >=20 >=20 > well actually mikehammer.us is available :-) >=20 > >=20 > > Mike > > =20 > >=20 >=20 > --=20 >=20 >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Director - Member of Technical Staff NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > Fax: +1 815.333.1237 > or > > ; =20 > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 08 14:42:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6vDE-0006Cv-FH; Wed, 08 Feb 2006 14:42:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6vDC-0006Bh-SL for enum@megatron.ietf.org; Wed, 08 Feb 2006 14:42:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25483 for ; Wed, 8 Feb 2006 14:40:56 -0500 (EST) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6vPi-0002Nk-HJ for enum@ietf.org; Wed, 08 Feb 2006 14:55:43 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 2EE051A772; Wed, 8 Feb 2006 20:42:27 +0100 (CET) Date: Wed, 8 Feb 2006 20:42:27 +0100 From: Otmar Lendl To: Richard Shockey Subject: Re: [Enum] Re: URI Portability Message-ID: <20060208194226.GO5755@nic.at> References: <072C5B76F7CEAB488172C6F64B30B5E3010F9FE2@xmb-rtp-20b.amer.cisco.com> <43EA4737.5060801@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43EA4737.5060801@shockey.us> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: enum@ietf.org, "Michael Hammer \(mhammer\)" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2006/02/08 20:02, Richard Shockey wrote: > Michael Hammer (mhammer) wrote: > >Otmar, > > > >What do you think are the chances of my getting the mike@hammer.com, > >hammer.net, hammer.org, ... domain name? > > > >The problem is only shifted. > > > well actually mikehammer.us is available :-) > I could offer mikehammer.at. We kind of, eh, sell those domains. :-) But seriously: you have the same problem even if you use identifiers like sip:user@carrier.com: Which of the Mike Hammer's out there will get sip:mike.hammer@carrier.com? (see also http://www.sendmail.org/faq/section3.html#3.5) ------- The question wasn't how to get a nice address, the question is how to get an address that you can take with you if you switch VoIP provider. Because one way (using a customer's domain) or the other (a regulator steps in) this will be possible. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From dhcwg-bounces@ietf.org Wed Feb 08 16:13:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6wdF-0000Pq-EO; Wed, 08 Feb 2006 16:13:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6wdD-0000Ll-D0 for dhcwg@megatron.ietf.org; Wed, 08 Feb 2006 16:13:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03703 for ; Wed, 8 Feb 2006 16:12:00 -0500 (EST) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6wpq-00062z-Gb for dhcwg@ietf.org; Wed, 08 Feb 2006 16:26:49 -0500 Received: from abhaya.fugue.com (lam.fugue.com [66.93.162.226]) by toccata.fugue.com (Postfix) with ESMTP id A1D091B2099; Wed, 8 Feb 2006 14:13:21 -0700 (MST) From: Ted Lemon Organization: Nominum, Inc. To: dhcwg@ietf.org Date: Wed, 8 Feb 2006 14:13:19 -0700 User-Agent: KMail/1.8.3 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602081413.20233.Ted.Lemon@nominum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Harald@alvestrand.no, "Hartman, Sam" , namedroppers@ops.ietf.org Subject: [dhcwg] Re: DDNS IESG Issue resolution. X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I just had a conversation on the phone with Sam Hartman, which I hope will turn out to have been constructive. Basically, Sam agrees that it's unlikely that we will need to change the hash algorithm in the future, but won't go so far as to say that he's sure we won't. So what he asked us to do is to put an algorithm identifier on the DHCID, but not make any other changes (we could change to SHA-1 or SHA-256 as our initial algorithm, and that might mollify some folks; since it's basically a search and replace on the document, I think it's worth doing). The idea is that in the unlikely event that we at some future date need to change the hash, then AT THAT TIME we write a draft that tells us how to do updates in the transitional state where more than one hash might still be present in the DNS. For now, we just put the identifier there and don't change anything else. This seems like a reasonable compromise - since we're claiming that we're never going to need the additional complexity, hopefully this postpones the work to describe and implement that complexity forever; if it turns out that we're wrong, we have a path forward. I can go more into the reasons why we agreed on this particular approach if anyone's interested, but unless you are, I'll just leave it at that. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From enum-bounces@ietf.org Wed Feb 08 16:13:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6wcb-0007wm-8Q; Wed, 08 Feb 2006 16:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6wcY-0007sf-On for enum@megatron.ietf.org; Wed, 08 Feb 2006 16:13:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03646 for ; Wed, 8 Feb 2006 16:11:06 -0500 (EST) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6woz-000620-9T for enum@ietf.org; Wed, 08 Feb 2006 16:25:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] input for Enumservice registration BCP sought Date: Wed, 8 Feb 2006 16:11:58 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A1BC@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] input for Enumservice registration BCP sought Thread-Index: AcYr2gxxXxl4ZxmcSpiQj7uBhWUwcABGh9MQ From: "Livingood, Jason" To: "Alexander Mayrhofer" , X-OriginalArrivalTime: 08 Feb 2006 21:11:59.0250 (UTC) FILETIME=[4C6D1F20:01C62CF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Bernie and I are working on one - very close to issuing a -00 draft. Would you like to join in the fun of writing it with us? :-) Jason=20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Alexander Mayrhofer > Sent: Tuesday, February 07, 2006 6:09 AM > To: enum@ietf.org > Subject: [Enum] input for Enumservice registration BCP sought >=20 > All, >=20 > i'm seeking input for a BCP on Enumservice registrations.=20 > Various members of the working group have expressed their=20 > opinion that the existing registration template is=20 > suboptimal, and a BCP on registration would be welcome. >=20 > The document should ease Enumservice registrations, and help=20 > to prevent repeated discussions every time a new registration=20 > is presented to the WG (type vs. subtype, protocol vs.=20 > application types, etc. comes to my mind) >=20 > So, please speak up what you would like to see in such a=20 > document - i'm attempting to prepare a draft before Dallas. >=20 > cheers >=20 > alex >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 09 02:58:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F76hH-0006AI-Qz; Thu, 09 Feb 2006 02:58:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F76hD-00066J-S2 for enum@megatron.ietf.org; Thu, 09 Feb 2006 02:58:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26501 for ; Thu, 9 Feb 2006 02:56:30 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F76tc-0004nU-GA for enum@ietf.org; Thu, 09 Feb 2006 03:11:23 -0500 Received: from [192.168.1.206] (85-124-84-32.zollergasse.xdsl-line.inode.at [::ffff:85.124.84.32]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 09 Feb 2006 08:58:00 +0100 id 0006C002.43EAF608.0000204C Message-ID: <43EAF5F4.4070808@enum.at> Date: Thu, 09 Feb 2006 08:57:40 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Livingood, Jason" Subject: Re: [Enum] input for Enumservice registration BCP sought References: <6EEEACD9D7F52940BEE26F5467C02C7302A3A1BC@PACDCEXCMB01.cable.comcast.com> In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302A3A1BC@PACDCEXCMB01.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Livingood, Jason wrote: > Bernie and I are working on one - very close to issuing a -00 draft. > Would you like to join in the fun of writing it with us? :-) Of course! I didn't know about that, and i'd appreciate to join. cheers alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 09 04:52:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F78TY-0005W3-4z; Thu, 09 Feb 2006 04:52:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F78TI-0005QL-SM; Thu, 09 Feb 2006 04:52:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04247; Thu, 9 Feb 2006 04:50:22 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F78fq-00008T-1e; Thu, 09 Feb 2006 05:05:17 -0500 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 09 Feb 2006 10:51:43 +0100 id 0006C002.43EB10B0.00002B1F Message-ID: <43EB109F.1030804@enum.at> Date: Thu, 09 Feb 2006 10:51:27 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Robert.Shaw@itu.int Subject: Re: [Enum] RE: [Speermint] and are phone numbers a borken addressingsystem? References: <2ECA12DF5FCB7948A1CD9047C3DAF3DC010DDFA7@MAILBOX1.blue.itu.ch> In-Reply-To: <2ECA12DF5FCB7948A1CD9047C3DAF3DC010DDFA7@MAILBOX1.blue.itu.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, speermint@ietf.org, trutkowski@verisign.com, lconroy@insensate.co.uk, ppfautz@att.com, duane@e164.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Robert.Shaw@itu.int wrote: >> All neat stuff I'm sure. But it lacks the kind of universality and >> authoritativeness that are ultimately required for a system >> that's going to be more than an adjunct, however popular. > > Indeed. There are about 3.4 billion mobile + fixed subscribers > out there with most of them now *mobile* and growing fast. At > this time, provider-based URI schemes are barely a blip on this > radar screen. And, i think that phone numbers may even enjoy a renaissance as identity tokens, with "Identity 2.0" (whatever you interpret into this - schizophrenia with 1.0 being me, and 2.0 being ... ??) as one of the new internet buzzwords. I hope i'll have my ideas in a draft by Dallas - stay tuned ;) cheers alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 09 04:54:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F78Ux-0005yV-Tb; Thu, 09 Feb 2006 04:53:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F78Ur-0005xd-Vy; Thu, 09 Feb 2006 04:53:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04377; Thu, 9 Feb 2006 04:52:03 -0500 (EST) Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F78hV-0000Bd-3h; Thu, 09 Feb 2006 05:06:58 -0500 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id C1E2B721558; Thu, 9 Feb 2006 10:53:24 +0100 (CET) Message-ID: <43EB111C.40500@pernau.at> Date: Thu, 09 Feb 2006 10:53:32 +0100 From: Klaus Darilion User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Stafford, Matthew" Subject: Re: [Speermint] RE: [Enum] a suggestion re: using flags to distinguish post-ENUMs ignaling f lows References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Stastny Richard , speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stafford, Matthew wrote: > ==> E2U+mms:mailto:mx ? > ==> or mailto:a@example.com;mx=yes/no ? > > ==> E2U+sip:srv > ==> or sip:a@example.com;srv=yes/no I can't follow your discussion: Why do we need a mx=yes/no parameter? AFAIK standard SMTP applications try MX first with fallback to A. Thus, mx=no can be achieved just by not having an MX record for the domain. regards klaus _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 09 09:13:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7CY7-0001Ss-BZ; Thu, 09 Feb 2006 09:13:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7CY5-0001RC-QV for enum@megatron.ietf.org; Thu, 09 Feb 2006 09:13:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24523 for ; Thu, 9 Feb 2006 09:11:37 -0500 (EST) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F7Ckf-0000tS-NL for enum@ietf.org; Thu, 09 Feb 2006 09:26:34 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-8.tower-121.messagelabs.com!1139494335!7399859!17 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 27255 invoked from network); 9 Feb 2006 14:13:02 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-8.tower-121.messagelabs.com with SMTP; 9 Feb 2006 14:13:02 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 43CF037500336E96; Thu, 9 Feb 2006 09:13:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] ENUM Working Group Last call on ENUM Validation Architecture Date: Thu, 9 Feb 2006 09:12:57 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0C1CEFD1@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] ENUM Working Group Last call on ENUM Validation Architecture Thread-Index: AcYs2rtZ6tqak9J3SzmyfOyom/AfWQApswoA From: "Pfautz, Penn L, NEO" To: "Richard Shockey" , X-Spam-Score: 0.8 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Peterson, Jon" , Allison Mankin X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Nice summary of the validation issue. A couple of questions for = Alexander and Bernie: 1. The disjoint roles example in Section 5.2 shows the Validation Entity = in communication with the Number Assignment Entity. Is your intent that = such communication be considered a requirement of validation or merely = one way in which it may be accomplished? 2. You may want to consider the effects of number portability on the = process when the CSP is the NAE. When a number is ported, the CSP that = assigned the number may no longer be in a position to verify number = assignment. And yet the new CSP for the number is not the entity that = originally assigned the number and was delegated the range from the = NNPA. Where proper NP architectures (i.e. all-call query) have been = implemented there is a database that can, if accessible to the VE, = identify the current CSP. In other architectures different procedures = will be required. Penn -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Richard Shockey Sent: Wednesday, February 08, 2006 1:05 PM To: enum@ietf.org Cc: Patrik F=E4ltstr=F6m; Peterson,Jon; Allison Mankin Subject: [Enum] ENUM Working Group Last call on ENUM Validation = Architecture Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-ietf-enum-validation-arch-01.txt Pages : 17 Date : 2006-2-7 =09 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of = an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-01.tx= t The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. This document has been under discussion since early 2005. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 2 weeks or so from today Feb 8 until at least Feb 24 though we can modify that if new issues come up. --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 09 09:31:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7CpK-0007gD-MK; Thu, 09 Feb 2006 09:31:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7CpF-0007bn-4P; Thu, 09 Feb 2006 09:31:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26133; Thu, 9 Feb 2006 09:29:22 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7D1v-0001aQ-6D; Thu, 09 Feb 2006 09:44:20 -0500 Received: from [10.10.2.124] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k19EUwI2012326 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 9 Feb 2006 08:31:00 -0600 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4820@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4820@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D29B289-1104-4FC5-AE49-EAEE963806B9@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows Date: Thu, 9 Feb 2006 08:31:14 -0600 To: Stastny Richard X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.8 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Feb 7, 2006, at 12:50 PM, Stastny Richard wrote: >> The second one is (essentially) number portability. My SIP URI can >> change from sip:mstafford@provider-A.net to >> >sip:mstafford@provider-B.biz. As long as my phone number stays >> the same, it can be used to obtain my current SIP URI. > > What I want to have is SIP URI portability too, or in other words: > I want to have my sip URI sip:richard@stastny.com > hosted by one provider and the possibility to port this to another. > > Especially if I am a company. > It's quite easy to move stastny.com from one provider to another -- you simply change the DNS NS, A, MX, and SRV records appropriately, and you're moved. We don't even need ENUM for this, and it's not a peering problem ala speermint. Having a phone number translate to a different URI requires either a DNS record change or an delegation, depending on which portability model you're using. What is HARD to is to move sip:richard@stastny.com without also moving sip:alice@stastny.com. That's basically a 302 operation, requiring database dips at the original host, and you expect it to be painful. -- dean _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 10 16:57:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7gGm-0004DD-T3; Fri, 10 Feb 2006 16:57:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F68oa-00066Z-Tv; Mon, 06 Feb 2006 11:02:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29360; Mon, 6 Feb 2006 11:00:15 -0500 (EST) Received: from h139-142-184-176.roothosts.com ([139.142.184.176] helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F690X-00055L-2v; Mon, 06 Feb 2006 11:14:30 -0500 Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id 5567AE38; Mon, 6 Feb 2006 11:01:24 -0500 (EST) Message-ID: <43E772D3.5010801@e164.org> Date: Mon, 06 Feb 2006 11:01:23 -0500 From: Duane User-Agent: Mail/News 1.5 (X11/20060119) MIME-Version: 1.0 To: "Pfautz, Penn L, NEO" Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish post-ENUM signaling f lows References: <34DA635B184A644DA4588E260EC0A25A0C15E4BC@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0C15E4BC@ACCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 10 Feb 2006 16:57:35 -0500 Cc: enum@ietf.org, speermint@ietf.org, Otmar Lendl , Tony Rutkowski , henry@pulver.com, lconroy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Pfautz, Penn L, NEO wrote: > Right now, however, phone numbers are a little like democracy - "the > worst system imaginable except for all others" > P2P folks don't seem serious about interoperability (look at IM) and > only TNs provide reachability from the PSTN. Not entirely true, the guys from Jabber use enum lookups and resolve Jabber IDs from our zone (e164.org). Also we're currently working on plugins for thunderbird/firefox to do phone number to email/website with the idea of unification on business cards of 10 different pieces of contact information to just a phone number if people want to go that route. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 10 16:58:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7gI0-000551-UB; Fri, 10 Feb 2006 16:58:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6TW9-0007Pi-Q3; Tue, 07 Feb 2006 09:08:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28170; Tue, 7 Feb 2006 09:06:33 -0500 (EST) Received: from h139-142-184-176.roothosts.com ([139.142.184.176] helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6TiI-00019Y-CB; Tue, 07 Feb 2006 09:21:04 -0500 Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id 69A1449AF; Tue, 7 Feb 2006 09:07:54 -0500 (EST) Message-ID: <43E8A9B9.7080901@e164.org> Date: Tue, 07 Feb 2006 09:07:53 -0500 From: Duane User-Agent: Mail/News 1.5 (X11/20060119) MIME-Version: 1.0 To: Klaus Darilion Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish post-ENUM signaling f lows References: <34DA635B184A644DA4588E260EC0A25A0C15E4BC@ACCLUST02EVS1.ugd.att.com> <43E772D3.5010801@e164.org> <43E85A4C.8020207@pernau.at> In-Reply-To: <43E85A4C.8020207@pernau.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 10 Feb 2006 16:58:50 -0500 Cc: enum@ietf.org, speermint@ietf.org, lconroy , "Pfautz, Penn L, NEO" , Tony Rutkowski X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Klaus Darilion wrote: >> Also we're currently working on plugins for thunderbird/firefox to do >> phone number to email/website with the idea of unification on business >> cards of 10 different pieces of contact information to just a phone >> number if people want to go that route. > > FYI: There already exists a firefox plugin (firefox 1.0.x only). > http://falb.at/enum4firefox/enummapper-0.1.0.xpi I'm aware of that plugin but that only works on windows, and the binaries including in the plugin only link to their service. -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Using Enum.164 to interconnect asterisk servers "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 10 16:58:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7gI1-00055R-Bx; Fri, 10 Feb 2006 16:58:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6bv9-0001T2-NX; Tue, 07 Feb 2006 18:06:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09813; Tue, 7 Feb 2006 18:05:02 -0500 (EST) Received: from h139-142-184-176.roothosts.com ([139.142.184.176] helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6c7T-00037z-Ia; Tue, 07 Feb 2006 18:19:36 -0500 Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id 24E09260F; Tue, 7 Feb 2006 18:06:22 -0500 (EST) Message-ID: <43E927ED.7080205@e164.org> Date: Tue, 07 Feb 2006 18:06:21 -0500 From: Duane User-Agent: Mail/News 1.5 (X11/20060119) MIME-Version: 1.0 To: "Stafford, Matthew" Subject: Re: [Speermint] RE: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 10 Feb 2006 16:58:51 -0500 Cc: enum@ietf.org, Stastny Richard , speermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stafford, Matthew wrote: > Richard- > > ===> What I want to have is SIP URI portability too, or in other words: > I ===> want to have my sip URI sip:richard@stastny.com > > ===> hosted by one provider and the possibility to port this to another. > > No disagreement there. I guess I view these portability options as > complementary (i.e., both useful depending on individual preferences). Wouldn't that be the equivalent to an email provider doing an email forward, (or in this case a 3XX redirection) ? If that's the case, phone number portability would solve that by letting the user updates their enum record to point to the new location, or having your old provider add a 3XX redirect to their software, a lot of ISPs have taken to charging a lot of money for simple email redirects if a user moves to another ISP but still wants to collect from their old address. Of course owning your own domain would overcome this, just like it does with email redirections. Kind of a moot point as far as I can tell. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Feb 12 16:52:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8P8R-0004U7-Cl; Sun, 12 Feb 2006 16:51:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8P8P-0004Sr-Ll for enum@megatron.ietf.org; Sun, 12 Feb 2006 16:51:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16660 for ; Sun, 12 Feb 2006 16:50:10 -0500 (EST) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8PLr-0007El-N8 for enum@ietf.org; Sun, 12 Feb 2006 17:05:52 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k1CLpc326509; Sun, 12 Feb 2006 16:51:38 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006021216513408858 ; Sun, 12 Feb 2006 16:51:34 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 12 Feb 2006 16:51:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] ENUM Working Group Last call on ENUM Validation Architecture Date: Sun, 12 Feb 2006 16:51:34 -0500 Message-ID: Thread-Topic: [Enum] ENUM Working Group Last call on ENUM Validation Architecture Thread-Index: AcYs2r3R63+uZqxURPS4S+vDq4YkVQDQBbEg From: "Mowafy, Hala" To: X-OriginalArrivalTime: 12 Feb 2006 21:51:34.0496 (UTC) FILETIME=[7DD5E600:01C6301E] X-Spam-Score: 0.8 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Peterson, Jon" , Allison Mankin X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Alex and Bernie, The ENUM Validation draft looks good. This is an important topic for = ENUM. Just one clarification about the last sentence of section 3.1, where you = mention it is unlikely that all CSPs will participate in the ENUM = validation. I agree, not ALL CSPs would or could. =20 However, to be consistent with the expectations and roles outlined later = in Sec 5.2, it would be helpful to add at the end of 3.1 that: "In some = cases, the CSP may own and operate subscriber database(s) containing = service information on each working number (wireline, wireless, VoIP). = Typically, other CSPs and authorized entities are allowed to access = these databases, in real-time, under contract for the limited purposes = of billing and validation (no marketing, data mining or otherwise). It = is conceivable that the VE would negotiate such access to those = databases for fulfilling its role in validating the number assignee." I know this standard is generic for all countries involved, but I just = wanted to draw your attention to the fact that such databases exist and = have been widely used in the US and Canada for other validation purposes = long before the ENUM validation needs came up. thanks Hala -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Richard Shockey Sent: Wednesday, February 08, 2006 1:05 PM To: enum@ietf.org Cc: Patrik F=E4ltstr=F6m; Peterson, Jon; Allison Mankin Subject: [Enum] ENUM Working Group Last call on ENUM Validation = Architecture Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-ietf-enum-validation-arch-01.txt Pages : 17 Date : 2006-2-7 =09 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of = an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-01.tx= t The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. This document has been under discussion since early 2005. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 2 weeks or so from today Feb 8 until at least Feb 24 though we can modify that if new issues come up. --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 15 04:35:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9J4F-0003ln-Cf; Wed, 15 Feb 2006 04:35:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9J4D-0003k9-6f for enum@megatron.ietf.org; Wed, 15 Feb 2006 04:35:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23671 for ; Wed, 15 Feb 2006 04:33:35 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9JI2-0002At-DS for enum@ietf.org; Wed, 15 Feb 2006 04:49:49 -0500 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 15 Feb 2006 10:35:06 +0100 id 0006C0B9.43F2F5CA.00000869 Message-ID: <43F2F5B3.8000602@enum.at> Date: Wed, 15 Feb 2006 10:34:43 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Enum] "manual" I-D ACTION announcement for draft-ietf-enum-validation-token-01 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi, it seems that there was a problem with the I-D ACTION announcement for draft-ietf-enum-validation-token-01, because it's already in the archives as well as on the WG charter page, but no announcement was sent out (i think it might have been a general problem on feb 11, since not a single I-D ACTION went out on that day according to the list archive). So, here's a "manual" announcement for the group: A new version of draft-ietf-enum-validation-token is available at http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-01.txt Abstract An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 15 08:32:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MmA-0005nv-1b; Wed, 15 Feb 2006 08:32:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Mm7-0005nq-Nt for enum@megatron.ietf.org; Wed, 15 Feb 2006 08:32:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09231 for ; Wed, 15 Feb 2006 08:31:08 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9N09-0001tt-3n for enum@ietf.org; Wed, 15 Feb 2006 08:47:25 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 15 Feb 2006 05:32:45 -0800 X-IronPort-AV: i="4.02,117,1139212800"; d="scan'208"; a="405415481:sNHT40528482" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1FDWijt017722; Wed, 15 Feb 2006 05:32:44 -0800 (PST) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k1FDZn2J001655; Wed, 15 Feb 2006 05:35:50 -0800 In-Reply-To: <010342E2-E165-470E-A8A0-8734A9B1CA37@insensate.co.uk> References: <337406757.16031@cnnic.cn> <010342E2-E165-470E-A8A0-8734A9B1CA37@insensate.co.uk> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] The use of "service type" and "subtype" fieldsin ENUM record Date: Wed, 15 Feb 2006 09:26:37 +0100 To: lconroy X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=5989; t=1140010552; x=1140442752; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=paf@cisco.com; z=From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:Re=3A=20[Enum]=20The=20use=20of=20=22service=20type=22=20and=20=22subtyp e=22=20fieldsin=20ENUM=20record |To:lconroy=20; X=v=3Dmtcc.com=3B=20h=3Dsp2slQYlKCgvVc0exugstchbBLk=3D; b=kH1ALvSTGBn0i6ig7wgpZv1yZ9E47UQ9ncFdgwOYBIpw2Pws676c+dUWWfiLkRYNVKR4R4/B sXsWCcAt0BdADNYzSahBSWb82NQP+IR3JZB/d40w8a5UZy9MNZ4/nVgah++hUWrlQGCEGHlAWYE VnyxE9rMla738EQXCBAP31sY=; Authentication-Results: imail.cisco.com; header.From=paf@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 2.9 (++) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit Cc: IETF ENUM WG , Julian Rose , =?UTF-8?B?546LIOWzsA==?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Also, note that the DNS query is still for a specific owner, which imply your resolver will most certainly cash all NAPTR records even though your "ENUM resolver" will only return a subset of the NAPTR returned (given the TTL is large enough). So, if you have to issue a new query to the "ENUM resolver", that should not imply as heavy work as the previous query. paf On 16 jan 2006, at 12.36, lconroy wrote: > Hi there, > filter design depends on what you want to do. If the ENUM client > is in a > voice gateway, then it's fairly simple. > > NOTE: The following is just an "Implementation description". There are > many ways one could process the NAPTRs - this is just the way WE > did it > in the U.K. trials. > > ---- > > In our systems, we used the "simple" pattern matching scheme > mentioned in > the "Experiences" draft to handle both RFC2916-style and RFC3261- > style NAPTRs. > [Tokenise services field on '+' character, expect (and remove) > token "E2U", > then process the rest]. > > If the client has communication systems that can provide a given > teleservice > (like voice) then that will be included in the filter - IMHO, this > must be > more flexible that an explicit string match against "voice:tel". > > We sub-tokenised each Enumservice on ':' character, "cheated" by > creating a > protocol sub-token for those Enumservices where it is implicit > (H323, SIP) and > re-wrote the RFC2916-style "ldap" and "mailto" services into > "ldap:ldap" and > "email:mailto", then pattern matched the generated list of > "published services" > against the capabilities of the client. > > Our clients could handle voice, so we matched against {voice:tel, > sip:sip} > (and voice:sip, as we were using TS 102 172 as well as the IETF/ > IANA services). > > For messaging, we matched against {{email:mailto, sms:mailto, > mms:mailto, > ems:mailto} and {sms:tel, mms:tel, ems:tel} and {fax:tel}}, which > triggered > one of three external communications programs - we did not have a > program > to support ifax:mailto, so just pattern matching against {*:mailto} > would > not work. > For mobile clients with no email, SIP or fax support, we just > matched against > {voice:tel} and {sms:tel, mms:tel, ems:tel} to run the voice or > text features > of the phone. > > This worked well, but as you say it does require some processing to > get NAPTRs > and their services field into a single list of "all teleservices > supported". > The capabilities of the client devices was fixed so we could have > "hard wired" > the "local support" match lists - however, we wanted the user to be > able to > "switch off" sending an SMS/MMS/EMS message - this just consisted > of removing > those items {sms:tel,mms:tel, ems:tel} from the "locally supported" > list. > ---- > To summarise the steps: > - process the NAPTRs to generate one list of "published services" > of the form > : > > - match this against a list of "locally supported services", > ordered according > to the user's choice (e.g. voice first, then message using > mailto, then > SMS/MMS/EMS message, then fax) > > - generate a list of "successful" matches, with a pointer to the > NAPTR(s) > that held the service and to the local program that needs to be > run. > ---- > As a final note - we kept a "winning list" rather than a single > answer so > that, if the first choice failed, the ENUM client could try the > next without > re-processing. This worked as the TTLs on the NAPTRs were a few > minutes > - if the NAPTRs had very short TTLs (e.g. 1 second), this would not > have > been valid. > > I hope this helps, > Lawrence > > > On 16 Jan 2006, at 10:19, chenhui wrote: >> Hi all, >> >> We are considering how to implement ENUM resolver into current >> communication clients or service systems. >> >> Now most of current communication applications do not support ENUM >> resolution, although ENUM records can be retieved by "nslookup" or >> "dig" query "NAPTR" resource records, different clients or service >> systems can not support all returned results. That is, some >> records are useless for specific services. Also, too many useless >> records will affect service performance. >> >> Using filter is a useful method to resolve this problem. To use >> "service type" and "subtype", only valuable results can be returned. >> >> But, we are not sure how can make the ENUM resolver works more >> reasonable. Because exact "service type" and "subtype" will filter >> many results, including of old "service type". For example, there >> is an ENUM number having NAPTR records of "E2U+email:mailto", "E2U >> +sms:mailto", and "E2U+ems:mailto", if the filter is "E2U >> +sms:mailto", it just returns NAPTR records with exact "service >> type" and "subtype". Or if there is no any corresponding record, >> this call will be failed. Too much failure will affect service >> performance. >> >> Another way is to support not exact filter, like only by >> "subtype". The ENUM resolver can return all relative records of >> "E2U+email:mailto", "E2U+sms:mailto", and "E2U+ems:mailto". >> Application clients or service systems can automatically choose >> its perferred results. However, this may introduce more service >> delay. >> >> What is the best way? Do you have any suggestion on this problem? >> >> BTW, We find that IANA has published ENUM services on Jan 10th, >> 2006. The webpage is http://www.iana.org/assignments/enum-services >> _______________________________________________ >> 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 enum-bounces@ietf.org Wed Feb 15 08:33:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MmE-0005oR-Qr; Wed, 15 Feb 2006 08:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MmC-0005oM-GV for enum@megatron.ietf.org; Wed, 15 Feb 2006 08:33:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09234 for ; Wed, 15 Feb 2006 08:31:13 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9N0C-0001u1-FQ for enum@ietf.org; Wed, 15 Feb 2006 08:47:30 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 15 Feb 2006 05:32:49 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1FDWmjt017746; Wed, 15 Feb 2006 05:32:48 -0800 (PST) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k1FDZn2K001655; Wed, 15 Feb 2006 05:35:54 -0800 In-Reply-To: <43CADE5C.5060903@shockey.us> References: <32755D354E6B65498C3BD9FD496C7D462C4779@oefeg-s04.oefeg.loc> <43C85D78.5030108@shockey.us> <43C867C7.4040800@shockey.us> <43CADE5C.5060903@shockey.us> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C7F9B4D-19B8-4E67-BD6C-2630910E706E@cisco.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] CNAM on further reflection Date: Wed, 15 Feb 2006 09:54:34 +0100 To: Richard Shockey X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=886; t=1140010555; x=1140442755; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=paf@cisco.com; z=From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:Re=3A=20[Enum]=20CNAM=20on=20further=20reflection |To:Richard=20Shockey=20; X=v=3Dmtcc.com=3B=20h=3DIwAoBXHZkgqEasPhFaeq2/QQFng=3D; b=D8sZ/ucPVrMouFrCF1w5kJCyPSEe/Uqf6rdghKevUrpeU0IsKOHhu+DqknnIEEqLEss7jm5U wWfm06uiVC0G9lxm4boWPJFlDG5UkXAAT5DKZCMj54XrJ7HEGGzgQRUbfMfCYlsgH1n9Laxs/8Y Rf2AXCvvPLbzz4biwqJNnWtc=; Authentication-Results: imail.cisco.com; header.From=paf@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 2.9 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Stastny Richard , lconroy , Paul Kyzivat X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org (Sorry, but I have, even though I am a co-chair of this group, had just too much to do in my day-job(s) lately...but I hope to be on board again from now. Having me leaving IAB at the next IETF will make things easier for me.) Two reflections on the cnam draft: - Be careful when talking about storing data in the DNS. There is a big difference between storing the data itself in DNS, and storing a URI (or subset thereof) in the DNS that refer the querying party to where the data is. This is for example the preferred solution when authentication and authorization is needed. - Even if old(er) standards only can handle ASCII characters, I don't see any reason the new standards we create should not handle a larger repertoire of characters, so we can handle names of people all over the world and not only in a subset thereof. Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 15 08:33:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MmH-0005ow-DL; Wed, 15 Feb 2006 08:33:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MmF-0005oq-H1 for enum@megatron.ietf.org; Wed, 15 Feb 2006 08:33:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09237 for ; Wed, 15 Feb 2006 08:31:16 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9N0G-0001uA-Gd for enum@ietf.org; Wed, 15 Feb 2006 08:47:33 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 15 Feb 2006 05:32:53 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1FDWqWF000536; Wed, 15 Feb 2006 05:32:52 -0800 (PST) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k1FDZn2L001655; Wed, 15 Feb 2006 05:35:59 -0800 In-Reply-To: <7898FA89-F9B4-47F5-8C1F-40F9C5EFFDE2@insensate.co.uk> References: <32755D354E6B65498C3BD9FD496C7D462C480E@oefeg-s04.oefeg.loc> <43E76919.9020509@shockey.us> <7898FA89-F9B4-47F5-8C1F-40F9C5EFFDE2@insensate.co.uk> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Wed, 15 Feb 2006 10:04:05 +0100 To: lconroy X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=604; t=1140010560; x=1140442760; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=paf@cisco.com; z=From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:Re=3A=20[Enum]=20Why=20not=20re-use=20interim=20procedures=20for=20infra structure=20ENUM? |To:lconroy=20; X=v=3Dmtcc.com=3B=20h=3DlVz6MRvV8QUbW6zRVOtMN7auhUw=3D; b=kV8yvWcFnYf5l+L4eFeAXmQmBIbuER+oIhOW5hjvnZqze07uVKaeQGqPRf2tVRskahVCSjM1 a0Dwp3Hx9MXyI+66jhDGL4vUqb1J1GvsdS9x8srEwJbWTx5PPYGg18TIH9m2frkg87As84P5NDk 88nM34z1NugD7U4WRF2vkjVU=; Authentication-Results: imail.cisco.com; header.From=paf@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.7 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Stastny Richard , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 6 feb 2006, at 19.26, lconroy wrote: > (ii) People keep talking about rfc3761bis, but I think we're > talking about > different things - some folks seem to be talking about a > "traditional" > rfc3761bis (i.e. obsoleting the current RFC 3761); others > seem more > interested in an RFC3761-doppelganger (i.e. in parallel with > RFC 3761). Regardless of what path this wg is suggesting, we do need a new RFC 3761 as you (among others) have found non-clear things in RFC 3761. And, I hereby report I am taking up the pen starting writing. Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 15 08:33:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MmJ-0005pP-1I; Wed, 15 Feb 2006 08:33:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MmH-0005ov-34 for enum@megatron.ietf.org; Wed, 15 Feb 2006 08:33:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09240 for ; Wed, 15 Feb 2006 08:31:18 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9N0I-0001uA-1O for enum@ietf.org; Wed, 15 Feb 2006 08:47:35 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 15 Feb 2006 05:32:56 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1FDWtjt017796; Wed, 15 Feb 2006 05:32:55 -0800 (PST) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k1FDZn2M001655; Wed, 15 Feb 2006 05:36:02 -0800 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4819@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4819@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6DFC7452-FC74-4093-85D7-555CD5532D45@cisco.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM? Date: Wed, 15 Feb 2006 10:05:39 +0100 To: Stastny Richard X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1069; t=1140010563; x=1140442763; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=paf@cisco.com; z=From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:Re=3A=20[Enum]=20Why=20not=20re-use=20interim=20procedures=20for=20infra structure=20ENUM? |To:Stastny=20Richard=20; X=v=3Dmtcc.com=3B=20h=3D72ePa90gvQQQY92+uKgashaAt/A=3D; b=I9UExV46rIdUNukFy3Q12T/S9C2ONuBFxX9yEL9D+HR6kPap83AQ+cXCcvY7ZV3agrUY3HDk vVo5Y0bWPnASDSBCZ0kMfxFX+f7wZble6xDD3NlaPfT4YD5JfMVx5sQxPIlZOEu0pLM+37eA5pS SzMysS9VbUapiCvW3tNHv/I0=; Authentication-Results: imail.cisco.com; header.From=paf@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 2.9 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, lconroy , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 6 feb 2006, at 22.38, Stastny Richard wrote: > RFC 3761 Doppelganger proposal: > > To fullfil the requirements for Infrastructure ENUM stated in > http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum- > reqs-01.txt > especially the requirement stated in 2.6. > > Infrastructure ENUM SHALL be implemented under a TLD that can > support > reliability and performance suitable for PSTN applications. > > RFC3761 is endorsed as is with the replacement of step 4 > in section 2.4 Valid databases:with > 4. Append the string "i.e164.arpa" to the end. Example: > 8.4.1.0.6.4.9.7.0.2.4.4.i.e164.arpa > > OR > > 4. Append the string ".e164i.arpa" to the end. Example: > 8.4.1.0.6.4.9.7.0.2.4.4.e164i.arpa > > This could be placed in the requiements document itself Or (if we don't agree on which one of these or other suggestions to choose) the requirements document should really list the requirements that can be used when measuring which one of these solutions are finally chosen. Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 15 08:33:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Mmc-0005s1-HW; Wed, 15 Feb 2006 08:33:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MmZ-0005rE-3W for enum@megatron.ietf.org; Wed, 15 Feb 2006 08:33:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09281 for ; Wed, 15 Feb 2006 08:31:36 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9N0b-0001vE-2v for enum@ietf.org; Wed, 15 Feb 2006 08:47:53 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 15 Feb 2006 05:33:13 -0800 X-IronPort-AV: i="4.02,117,1139212800"; d="scan'208"; a="405415559:sNHT31469822" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1FDXDjt017911; Wed, 15 Feb 2006 05:33:13 -0800 (PST) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k1FDZn2O001655; Wed, 15 Feb 2006 05:36:20 -0800 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C482E@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C482E@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Re: URI Portability Date: Wed, 15 Feb 2006 10:15:05 +0100 To: Stastny Richard X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=637; t=1140010581; x=1140442781; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=paf@cisco.com; z=From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:Re=3A=20[Enum]=20Re=3A=20URI=20Portability |To:Stastny=20Richard=20; X=v=3Dmtcc.com=3B=20h=3DV83wIIHG3XMNkrOIuqAYmd046i0=3D; b=d14VMljBknpwKd/7TBHSQkcbxwwFAbfl3OlRKezfpip0QbyskhP75nei9RgH+3JrA7sm7p29 qughN9MzyX4WsxQ8Q7LQz0rdRCfcTR6vpHMKMzOMKsiyw2auyum0c6jr4ip1vS5hKvavLPjPpUn gOe2fO7GhvOEkiK7DK0WWAPo=; Authentication-Results: imail.cisco.com; header.From=paf@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 2.9 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: james.f.baskin@verizon.com, enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 8 feb 2006, at 18.41, Stastny Richard wrote: > you can port jamesbaskin.com and Yahoo can port yahoo.com to any > provider, > but you cannot port james.baskin@yahoo.com independently to a > different > service provider. So if you leave yahoo.com, you loose > james.baskin@yahoo.com The real problem is that if you have foo@example.com and bar@example.com, then those two adresses can not be ported or moved between organisations INDEPENDENTLY from each other. So, sure, james.baskin@yahoo.com can be moved to some other provider, but you will get all other @yahoo.com addresses with you. Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 15 08:33:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Mmc-0005sQ-W6; Wed, 15 Feb 2006 08:33:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MmX-0005qU-OO for enum@megatron.ietf.org; Wed, 15 Feb 2006 08:33:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09278 for ; Wed, 15 Feb 2006 08:31:34 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9N0Z-0001v4-6r for enum@ietf.org; Wed, 15 Feb 2006 08:47:51 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 15 Feb 2006 05:33:12 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1FDXBjt017899; Wed, 15 Feb 2006 05:33:11 -0800 (PST) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k1FDZn2N001655; Wed, 15 Feb 2006 05:36:18 -0800 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C482A@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C482A@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <42FD31FC-B6E5-45CA-BD96-E56EA76BB327@cisco.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Re: URI Portability Date: Wed, 15 Feb 2006 10:13:17 +0100 To: Stastny Richard X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=10144; t=1140010579; x=1140442779; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=paf@cisco.com; z=From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:Re=3A=20[Enum]=20Re=3A=20URI=20Portability |To:Stastny=20Richard=20; X=v=3Dmtcc.com=3B=20h=3Do1ucFc0FoKoMUekVoDAZFHBDi6M=3D; b=DwIJg05LQw36WwTvpzo6eqeCR1CcNGxfeyQI0vf49SMHfiCc+JbivvsvqIvu1ewDfX9KOpsa PqAiM5g1M/l11PmvI7vpcbdu1ySBap0A9nY4Z5YiACSp9Hsvlv+gb3xcCwdnSjR1HJMpqg2axqB UTWNjE0c6Ukl3kZ0Iak0PQX0=; Authentication-Results: imail.cisco.com; header.From=paf@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 3.7 (+++) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Content-Transfer-Encoding: 7bit Cc: james.f.baskin@verizon.com, enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org There is absolutely no difference between SIP and email and other services. Either the end user get a domain name he own (as a registrant) and ask the provider of whatever services he buy to use that domain for the services. Or, he uses the default domain the provider has, but that domain name belongs to the service provider, and is because of that not portable. So, domain names are portable, you have to (only) make sure you have one. paf On 8 feb 2006, at 16.00, Stastny Richard wrote: > Jim Baskin sent a private comment on URI Portability to Matt and me, > but had no objections to comment this on the list, which I do, because > I consider this relevant: > >> Number portability and SIP URI portability may sound like >> similar concepts, but there is at least one big difference. >> Moving sip:richard@stastny.com from one provider to another >> may be really simple, assuming that you own stastny.com and >> you have control over its nameserver. > > Agreed > >> However, if you are >> a SIP customer of acme-sip.com (e.g., sip:richard@acme-sip.com), >> it isn't a strictly technical issue. It is not likely that >> the owners of acme-sip.com would want their company name or >> its domain used by someone who has a different SIP service >> provider. The same issue is why I don't ever expect to see >> email address portability for somebody@aol.com or >> somebody-else@yahoo.com. > > I agree in principal, but we have to distinguish between to cases > here: > > > 1. sip:richard@acme-sip.com can be compared your company extension > with DDI > I have eg +43 1 79780 32 as office number, where 32 is my extension. > It is obvious that if I change company I cannot take (port) this > number with > me, because +43 1 79780 belongs to OeFEG. Same with acme-sip.com > +43 1 79780 is public, the rest is private. In the PSTN there exists > a clear distinction between what a public telephone service is and > what is private (corporate) > > 2. On the Internet this distincion is not existing, but of course > one could be found: > > acme-sip.com is not providing a service for the public > yahoo.com and aol.com is. > > A bored regulator could come to the conclusion at some time to > foster competition and require URI portability vor public > SIP URIs. > > First every SIP service provider would rant that this is > impossible, expensive, whatever, but we had this also on the > PSTN. > > Of course this can be implemented in the same way as > it was implemented in the PSTN, with onward routing and/or > redirect, with the same drawback: the donor is always involved > > Next step would be to standardise a DNS lookup for sip:fred@yahoo.com > > in something like fred.at.yahoo.com to find the current URI. > of course there are a lot of problems, such as a certified > from information, but this can be solved. > >> E.164 telephone numbers, on the other hand, don't have service >> provider trademark issues. In addition, number portability, >> if done with a database and originating or n-1 carrier dips, >> takes the ported-from service provider completely out of call >> processing for the ported number. Of course, number portability >> isn't "perfect" yet. There are still regulatory limits on >> what numbers can be ported where. > > SIP URI portability of course must work global, an this > will delay or prevent the idea for some time ;-) > >> Oh yes, regarding Tony's statement, "The use of E.164 >> identifiers, internationally and domestically, is subject to >> more statutory, regulatory, national security, and industry >> practice requirements than any identifier space in existence - >> not to mention well established institutional jurisdiction." >> That may be exactly why E.164 telephone numbers have been used so >> successfully as a nearly seamless identifier standard providing >> worldwide telecommunications for longer than many IETF >> participants can remember. > > True, at least as long as we do not have global reachability > provided by a Public User Identity in the form of a SIP AoR. > > Richard > >> Jim Baskin > > ======================================= > Original messages: > > Richard- > ===> What I want to have is SIP URI portability too, or in other > words: I ===> want to have my sip URI sip:richard@stastny.com > ===> hosted by one provider and the possibility to port this to > another. > No disagreement there. I guess I view these portability options as > complementary (i.e., both useful depending on individual preferences). > Thanks for the document pointers. > Matt > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at > ] > Sent: Tuesday, February 07, 2006 12:50 PM > To: Stafford, Matthew > Cc: enum@ietf.org; speermint@ietf.org > Subject: Re: [Enum] a suggestion re: using flags to distinguish > post-ENUM signaling f lows > >> The second one is (essentially) number portability. My SIP URI can >> change from sip:mstafford@provider-A.net to >> >sip:mstafford@provider-B.biz. As long as my phone number stays >> the same, it can be used to obtain my current SIP URI. > > What I want to have is SIP URI portability too, or in other words: > I want to have my sip URI sip:richard@stastny.com > hosted by one provider and the possibility to port this to another. > > Especially if I am a company. > > For more information see the ECMA christmas wish-list presented > today at ETSI TISPAN: > Technical Report TR/91 > Enterprise Communication in Next Generation Corporate Networks > (NGCN) involving Public Next Generation Networks (NGN) > (December 2005) > http://www.ecma-international.org/publications/files/ECMA-TR/ > TR-091.pdf ECMA-TR/TR-091.pdf> > > and also > Technical Report TR/92 > Corporate Telecommunication Networks - Mobility for Enterprise > Communications > (December 2005) > http://www.ecma-international.org/publications/files/ECMA-TR/ > TR-092.pdf ECMA-TR/TR-092.pdf> > > The scenarios and requirements described in these two documents > will not > be really easy to implement with NGNs ;-) > Of course they want to have best of both sides: peering with each > other in all variants > AND in addition to be connected to an NGN, just to be on the safe > side. > One could also say: the overflow traffic is for the telcos (say max > 20%) > > Richard > _______________________________ > > Von: enum-bounces@ietf.org im Auftrag von Stafford, Matthew > Gesendet: Di 07.02.2006 19:20 > An: Tony Rutkowski > Cc: enum@ietf.org; speermint@ietf.org > Betreff: RE: [Enum] a suggestion re: using flags to distinguish > post-ENUM signaling f lows > > Tony- The E.164 space is a many-encumbered thing. No argument there. > > All the same, I see two benefits of E.164 numbers: although *some* > mobile devices have QWERTY keyboards, many of them still don't. IMO > a telephone number is far and away the easiest thing to punch into > a cellphone keypad. That's the first one. The second one is > (essentially) number portability. My SIP URI can change from > sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. As > long as my phone number stays the same, it can be used to obtain my > current SIP URI. > > Best, > Matt > > -----Original Message----- > From: Tony Rutkowski [mailto:trutkowski@verisign.com > ] > Sent: Sunday, February 05, 2006 10:42 AM > To: lconroy; Stafford, Matthew; Otmar Lendl > Cc: enum@ietf.org; speermint@ietf.org > Subject: Re: [Enum] a suggestion re: using flags to distinguish > post-ENUM signaling f lows > > Hi Lawrence, > >> The first is the process issue - what group (if any) coordinates >> between the different DDDS applications and their uses; this topic > ... >> 3761bis. It seems that your proposal is purely for Carrier/ >> Infrastructure/ >> Private ENUM; in this case, changing 3761 has unintended consequences >> for Public/User ENUM applications. > > These are great understatements. The use of > E.164 identifiers, internationally and > domestically, is subject to more statutory, > regulatory, national security, and industry > practice requirements than any identifier > space in existence - not to mention well > established institutional jurisdiction. > > The following list is a current tabulation > of E.164 resolver-directory capability > requirements, parsed into three categories, > currently in play in various industry NGN > forums. The recently enacted EC Data > Retention Directive, and the U.S. Prevent > Cyberstalking law, add further complexity > to the mix. ;-) > > best, > --tony > >> basic resolver capability >> >> supplementary capability >> Number Portability >> Priority Access >> Roaming >> Quality of Service >> Directory Assistance >> CallerID >> Disability Assistance >> Language preference >> Personal emergency (E112/911) >> Public emergency alerts >> Law enforcement assistance >> DoNotCall >> Payment Methods >> Intercarrier Compensation >> Profile Management >> Presence >> Availability >> Location >> Push Management >> Digital Rights Management >> Device Management >> Authentication Credentials >> Information verification level >> >> protocol feature >> Authentication >> Auditing >> Multiple Syntax Support >> Mutiple Language Support >> Extensibility and Localisation Mechanisms > 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 enum-bounces@ietf.org Wed Feb 15 10:50:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9OvE-0002Nf-7t; Wed, 15 Feb 2006 10:50:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Ouz-0002IC-KJ; Wed, 15 Feb 2006 10:50:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20045; Wed, 15 Feb 2006 10:48:26 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9P90-0007Pf-GU; Wed, 15 Feb 2006 11:04:43 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k1FFo2BX003433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2006 15:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1F9Ouo-0004tn-4d; Wed, 15 Feb 2006 10:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 15 Feb 2006 10:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-token-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Validation Token Format Definition Author(s) : O. Lendl Filename : draft-ietf-enum-validation-token-01.txt Pages : 16 Date : 2006-2-13 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-validation-token-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-validation-token-01.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: <2006-2-13151925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-validation-token-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-validation-token-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-13151925.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Wed Feb 15 11:00:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9P4g-0005PX-6C; Wed, 15 Feb 2006 11:00:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9P4d-0005PC-Cs for enum@megatron.ietf.org; Wed, 15 Feb 2006 11:00:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22406 for ; Wed, 15 Feb 2006 10:58:25 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9PId-0008PJ-Rn for enum@ietf.org; Wed, 15 Feb 2006 11:14:42 -0500 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 15 Feb 2006 17:00:05 +0100 id 0006C001.43F35005.00004097 Message-ID: <43F34FEC.2070007@enum.at> Date: Wed, 15 Feb 2006 16:59:40 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: enum@ietf.org, shollenbeck@verisign.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] RFC4114 example breaks RFC3731? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi, i'm currently looking at RFC4114 to see how it fits potential infrastructure ENUM applications. In section 3.2.5, there is the following example of an : C: C: C: C: C: C: 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa C: C: C: ... (remaining lines removed) ... Clearly, this request uses the domain mapping specified in RFC3731. Section 3.2.5 of RFC3731 says: ----- The element contains the following child elements: - A element that contains the fully qualified name of the domain object to be updated. - An OPTIONAL element that contains attribute values to be added to the object. - An OPTIONAL element that contains attribute values to be removed from the object. - An OPTIONAL element that contains object attribute values to be changed. At least one , , or element MUST be provided. The and elements contain the following child elements: ----- However, the example above does not contain such an element required by the last sentence. It passes the schema, though, because the above requirement cannot be easily expressed there. So, my question is: - is the example in RFC4114 broken? Or - is it ok to use RFC3731 schemas without being RFC3731 compliant? Or - is the example not considered normative? ;) (BTW, i don't see any reason for the mandatory elements in a RFC4114 scenario though, so i'd actually prefer to implement it the way it is outlined in the example) Any comments appreciated. Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 15 16:57:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9UeQ-0003nR-O3; Wed, 15 Feb 2006 16:57:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9UeO-0003io-Ak for enum@megatron.ietf.org; Wed, 15 Feb 2006 16:57:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10761 for ; Wed, 15 Feb 2006 16:55:42 -0500 (EST) Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9UsP-00041W-W4 for enum@ietf.org; Wed, 15 Feb 2006 17:12:02 -0500 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1F9Ue8-0006dL-00; Wed, 15 Feb 2006 22:57:12 +0100 Date: Wed, 15 Feb 2006 22:57:01 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: Alexander Mayrhofer Subject: Re: [Enum] RFC4114 example breaks RFC3731? In-Reply-To: <43F34FEC.2070007@enum.at> Message-ID: References: <43F34FEC.2070007@enum.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: enum@ietf.org, shollenbeck@verisign.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Ciao Axel! RFC 3731 (as well as the other EPP RFCs) is currently being revised. See below Scott's email concerning this sent to the PROVREG mailing list. cheers, Bernie --- BEGIN --- Date: Fri, 9 Sep 2005 14:27:45 -0400 From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: [ietf-provreg] 3731bis Submitted I just sent the -00 version of 3731bis to the I-D administrator for publication. Here's the list of changes copied from Appendix A: [...] 3. Changed text in Section 3.2.1.4 from "At least one , , or element MUST be provided." to "At least one , , or element MUST be provided if the command is not being extended. All of these elements MAY be omitted if an extension is present.". [...] --- END -- On Wed, 15 Feb 2006, Alexander Mayrhofer wrote: > Hi, > > i'm currently looking at RFC4114 to see how it fits potential infrastructure > ENUM applications. In section 3.2.5, there is the following example of an > : > > C: > C: C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 > C: epp-1.0.xsd"> > C: > C: > C: C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" > C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 > C: domain-1.0.xsd"> > C: 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa > C: > C: > C: > ... (remaining lines removed) ... > > Clearly, this request uses the domain mapping specified in RFC3731. Section > 3.2.5 of RFC3731 says: > > ----- > The element contains the following child elements: > > - A element that contains the fully qualified name of > the domain object to be updated. > > - An OPTIONAL element that contains attribute values to > be added to the object. > > - An OPTIONAL element that contains attribute values to > be removed from the object. > > - An OPTIONAL element that contains object attribute > values to be changed. > > At least one , , or element MUST > be provided. The and elements contain the > following child elements: > ----- > > However, the example above does not contain such an element required by the > last sentence. It passes the schema, though, because the above requirement > cannot be easily expressed there. > > So, my question is: > > - is the example in RFC4114 broken? Or > - is it ok to use RFC3731 schemas without being RFC3731 compliant? Or > - is the example not considered normative? ;) > > (BTW, i don't see any reason for the mandatory elements in a RFC4114 scenario > though, so i'd actually prefer to implement it the way it is outlined in the > example) > > Any comments appreciated. > > Alex > > _______________________________________________ > 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 enum-bounces@ietf.org Wed Feb 15 17:04:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Ukk-0000Xf-Sh; Wed, 15 Feb 2006 17:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Uki-0000VG-Dc for enum@megatron.ietf.org; Wed, 15 Feb 2006 17:04:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11183 for ; Wed, 15 Feb 2006 17:02:14 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Uyj-0004GI-Uq for enum@ietf.org; Wed, 15 Feb 2006 17:18:34 -0500 Received: from [192.168.1.206] (85-124-86-220.dynamic.xdsl-line.inode.at [::ffff:85.124.86.220]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 15 Feb 2006 23:03:50 +0100 id 0006C117.43F3A546.000005F7 Message-ID: <43F3A52F.5000706@enum.at> Date: Wed, 15 Feb 2006 23:03:27 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Bernie Hoeneisen Subject: Re: [Enum] RFC4114 example breaks RFC3731? References: <43F34FEC.2070007@enum.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, shollenbeck@verisign.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Bernie Hoeneisen wrote: > Ciao Axel! > > RFC 3731 (as well as the other EPP RFCs) is currently being revised. > See below Scott's email concerning this sent to the PROVREG mailing list. Bernie, thanks for pointing that out - i've unsubscribed from the provreg list when the set of RFCs was published :-/ cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 15 18:50:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9WPo-0002Om-Gb; Wed, 15 Feb 2006 18:50:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9WPV-000269-S4; Wed, 15 Feb 2006 18:50:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18898; Wed, 15 Feb 2006 18:48:26 -0500 (EST) Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Wda-0007aU-1u; Wed, 15 Feb 2006 19:04:48 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k1FNo1vP010597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Feb 2006 23:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1F9WPJ-0001Un-GX; Wed, 15 Feb 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 15 Feb 2006 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-epp-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author(s) : B. Hoeneisen Filename : draft-ietf-enum-validation-epp-03.txt Pages : 26 Date : 2006-2-15 This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the E.164 Number Mapping (ENUM) domain name is based on. Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-epp-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-validation-epp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-validation-epp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-15160608.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-validation-epp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-validation-epp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-15160608.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Wed Feb 15 19:59:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9XUe-00052b-Cp; Wed, 15 Feb 2006 19:59:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9XUc-000514-6a for enum@megatron.ietf.org; Wed, 15 Feb 2006 19:59:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00654 for ; Wed, 15 Feb 2006 19:57:47 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Xij-0003mg-0u for enum@ietf.org; Wed, 15 Feb 2006 20:14:10 -0500 Received: from [10.31.13.103] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1G0xuPX008640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Feb 2006 16:59:57 -0800 Message-ID: <43F3CE64.20802@shockey.us> Date: Wed, 15 Feb 2006 19:59:16 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------010802090204010505000107" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Subject: [Enum] [Fwd: I-D ACTION:draft-reichinger-enum-foaf-00.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------010802090204010505000107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: I-D ACTION:draft-reichinger-enum-foaf-00.txt Date: Wed, 15 Feb 2006 18:50:01 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Registration for Enumservice foaf Author(s) : K. Reichinger Filename : draft-reichinger-enum-foaf-00.txt Pages : 9 Date : 2006-2-15 This memo registers the Enumservice "foaf" using the URI schemes "http" and "https" according to the IANA Enumservice registration process defined in RFC3671. The Enumservice "foaf" is to be used to refer from an ENUM domain name to the location of a FOAF RDF file using the corresponding E.164 telephone number. Clients may use data retrieved from a FOAF RDF file to provide caller or callee with information available within the Friend-Of-A-Friend (FOAF) Semantic Web application. For example, the caller might be presented with personal information on the callee (e.g. name, gender and various online attributes) as well as information on the callee's social context (e.g. relations to friends or colleagues). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-reichinger-enum-foaf-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-reichinger-enum-foaf-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-reichinger-enum-foaf-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. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------010802090204010505000107 Content-Type: Message/External-body; name="draft-reichinger-enum-foaf-00.txt" Content-Disposition: inline; filename="draft-reichinger-enum-foaf-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2006-2-15152532.I-D@ietf.org> --------------010802090204010505000107 Content-Type: text/plain; name*0="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename*0="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------010802090204010505000107 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------010802090204010505000107-- From enum-bounces@ietf.org Wed Feb 15 21:37:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Z1l-0004Gp-42; Wed, 15 Feb 2006 21:37:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Z1j-0004Fa-1U for enum@megatron.ietf.org; Wed, 15 Feb 2006 21:37:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07802 for ; Wed, 15 Feb 2006 21:36:02 -0500 (EST) Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F9ZFV-0007bc-OC for enum@ietf.org; Wed, 15 Feb 2006 21:52:27 -0500 Received: (eyou send program); Thu, 16 Feb 2006 10:37:04 +0800 Message-ID: <340057424.29737@cnnic.cn> X-EYOUMAIL-SMTPAUTH: chenhui@cnnic.cn Received: from unknown (HELO cnnicchenh) (159.226.6.99) by 159.226.7.151 with SMTP; Thu, 16 Feb 2006 10:37:04 +0800 Message-ID: <004e01c632a1$e394a190$6306e29f@cnnicchenh> From: "chenhui" To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , "lconroy" References: <337406757.16031@cnnic.cn> <010342E2-E165-470E-A8A0-8734A9B1CA37@insensate.co.uk> <340010362.05978@cnnic.cn> Subject: Re: [Enum] The use of "service type" and "subtype" fieldsin ENUM record Date: Thu, 16 Feb 2006 10:37:11 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: IETF ENUM WG , =?UTF-8?B?546LIOWzsA==?= , Julian Rose X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0495855769==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0495855769== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 V2UgYWdyZWUgdGhlIHR3byBpc3N1ZXMgYWJvdXQgRU5VTSByZXNvbHZlciwgdGhlIGZpcnN0IGlz IEVOVU0gcmVzb2x2ZXIganVzdCByZXR1cm5zIHNvbWUgc3BlY2lhbCByZXN1bHRzIHRvIHRoZSB0 ZXJtaW5hbCBhcyBuZWVkZWQgYW5kIHRoaXMgZnVuY3Rpb24gc2hvdWxkIGJlIGltcGxlbWVudGVk IGluIGEgc2ltcGxlIHdheSwgYW5kIHRoZSBzZWNvbmQgaXMgRU5VTSByZXNvbHZlciBuZWVkcyBu byBjYWNoZSBiZWNhdXNlIGxvY2FsIEROUyByZXNvbHZlciBjYW4gY2FjaGUgdGhlIHJlY29yZHMu DQoNCkFuZCBpdCBpcyBqdXN0IHRoZSBydWxlIHdlIGFiaWRlIGJ5IGluIENoaW5hIEVOVU0gdHJp YWwuDQoNCmNoZW5odWkNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJQ YXRyaWsgRsOkbHRzdHLDtm0iIDxwYWZAY2lzY28uY29tPg0KVG86ICJsY29ucm95IiA8bGNvbnJv eUBpbnNlbnNhdGUuY28udWs+DQpDYzogImNoZW5odWkiIDxjaGVuaHVpQGNubmljLmNuPjsgIklF VEYgRU5VTSBXRyIgPGVudW1AaWV0Zi5vcmc+OyAi546LIOWzsCIgPGZlbmd3QGNubmljLmNuPjsg Ikp1bGlhbiBSb3NlIiA8anJvc2VAdGVsbmljLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh cnkgMTUsIDIwMDYgNDoyNiBQTQ0KU3ViamVjdDogUmU6IFtFbnVtXSBUaGUgdXNlIG9mICJzZXJ2 aWNlIHR5cGUiIGFuZCAic3VidHlwZSIgZmllbGRzaW4gRU5VTSByZWNvcmQNCg0KDQo+IEFsc28s IG5vdGUgdGhhdCB0aGUgRE5TIHF1ZXJ5IGlzIHN0aWxsIGZvciBhIHNwZWNpZmljIG93bmVyLCB3 aGljaCAgDQo+IGltcGx5IHlvdXIgcmVzb2x2ZXIgd2lsbCBtb3N0IGNlcnRhaW5seSBjYXNoIGFs bCBOQVBUUiByZWNvcmRzIGV2ZW4gIA0KPiB0aG91Z2ggeW91ciAiRU5VTSByZXNvbHZlciIgd2ls bCBvbmx5IHJldHVybiBhIHN1YnNldCBvZiB0aGUgTkFQVFIgIA0KPiByZXR1cm5lZCAoZ2l2ZW4g dGhlIFRUTCBpcyBsYXJnZSBlbm91Z2gpLg0KPiANCj4gU28sIGlmIHlvdSBoYXZlIHRvIGlzc3Vl IGEgbmV3IHF1ZXJ5IHRvIHRoZSAiRU5VTSByZXNvbHZlciIsIHRoYXQgIA0KPiBzaG91bGQgbm90 IGltcGx5IGFzIGhlYXZ5IHdvcmsgYXMgdGhlIHByZXZpb3VzIHF1ZXJ5Lg0KPiANCj4gICAgcGFm DQo+IA0KPiBPbiAxNiBqYW4gMjAwNiwgYXQgMTIuMzYsIGxjb25yb3kgd3JvdGU6DQo+IA0KPj4g SGkgdGhlcmUsDQo+PiAgZmlsdGVyIGRlc2lnbiBkZXBlbmRzIG9uIHdoYXQgeW91IHdhbnQgdG8g ZG8uIElmIHRoZSBFTlVNIGNsaWVudCAgDQo+PiBpcyBpbiBhDQo+PiB2b2ljZSBnYXRld2F5LCB0 aGVuIGl0J3MgZmFpcmx5IHNpbXBsZS4NCj4+DQo+PiBOT1RFOiBUaGUgZm9sbG93aW5nIGlzIGp1 c3QgYW4gIkltcGxlbWVudGF0aW9uIGRlc2NyaXB0aW9uIi4gVGhlcmUgYXJlDQo+PiBtYW55IHdh eXMgb25lIGNvdWxkIHByb2Nlc3MgdGhlIE5BUFRScyAtIHRoaXMgaXMganVzdCB0aGUgd2F5IFdF ICANCj4+IGRpZCBpdA0KPj4gaW4gdGhlIFUuSy4gdHJpYWxzLg0KPj4NCj4+IC0tLS0NCj4+DQo+ PiBJbiBvdXIgc3lzdGVtcywgd2UgdXNlZCB0aGUgInNpbXBsZSIgcGF0dGVybiBtYXRjaGluZyBz Y2hlbWUgIA0KPj4gbWVudGlvbmVkIGluDQo+PiB0aGUgIkV4cGVyaWVuY2VzIiBkcmFmdCB0byBo YW5kbGUgYm90aCBSRkMyOTE2LXN0eWxlIGFuZCBSRkMzMjYxLSANCj4+IHN0eWxlIE5BUFRScy4N Cj4+IFtUb2tlbmlzZSBzZXJ2aWNlcyBmaWVsZCBvbiAnKycgY2hhcmFjdGVyLCBleHBlY3QgKGFu ZCByZW1vdmUpICANCj4+IHRva2VuICJFMlUiLA0KPj4gdGhlbiBwcm9jZXNzIHRoZSByZXN0XS4N Cj4+DQo+PiBJZiB0aGUgY2xpZW50IGhhcyBjb21tdW5pY2F0aW9uIHN5c3RlbXMgdGhhdCBjYW4g cHJvdmlkZSBhIGdpdmVuICANCj4+IHRlbGVzZXJ2aWNlDQo+PiAobGlrZSB2b2ljZSkgdGhlbiB0 aGF0IHdpbGwgYmUgaW5jbHVkZWQgaW4gdGhlIGZpbHRlciAtIElNSE8sIHRoaXMgIA0KPj4gbXVz dCBiZQ0KPj4gbW9yZSBmbGV4aWJsZSB0aGF0IGFuIGV4cGxpY2l0IHN0cmluZyBtYXRjaCBhZ2Fp bnN0ICJ2b2ljZTp0ZWwiLg0KPj4NCj4+IFdlIHN1Yi10b2tlbmlzZWQgZWFjaCBFbnVtc2Vydmlj ZSBvbiAnOicgY2hhcmFjdGVyLCAiY2hlYXRlZCIgYnkgIA0KPj4gY3JlYXRpbmcgYQ0KPj4gcHJv dG9jb2wgc3ViLXRva2VuIGZvciB0aG9zZSBFbnVtc2VydmljZXMgd2hlcmUgaXQgaXMgaW1wbGlj aXQgIA0KPj4gKEgzMjMsIFNJUCkgYW5kDQo+PiByZS13cm90ZSB0aGUgUkZDMjkxNi1zdHlsZSAi bGRhcCIgYW5kICJtYWlsdG8iIHNlcnZpY2VzIGludG8gIA0KPj4gImxkYXA6bGRhcCIgYW5kDQo+ PiAiZW1haWw6bWFpbHRvIiwgdGhlbiBwYXR0ZXJuIG1hdGNoZWQgdGhlIGdlbmVyYXRlZCBsaXN0 IG9mICANCj4+ICJwdWJsaXNoZWQgc2VydmljZXMiDQo+PiBhZ2FpbnN0IHRoZSBjYXBhYmlsaXRp ZXMgb2YgdGhlIGNsaWVudC4NCj4+DQo+PiBPdXIgY2xpZW50cyBjb3VsZCBoYW5kbGUgdm9pY2Us IHNvIHdlIG1hdGNoZWQgYWdhaW5zdCB7dm9pY2U6dGVsLCAgDQo+PiBzaXA6c2lwfQ0KPj4gKGFu ZCB2b2ljZTpzaXAsIGFzIHdlIHdlcmUgdXNpbmcgVFMgMTAyIDE3MiBhcyB3ZWxsIGFzIHRoZSBJ RVRGLyANCj4+IElBTkEgc2VydmljZXMpLg0KPj4NCj4+IEZvciBtZXNzYWdpbmcsIHdlIG1hdGNo ZWQgYWdhaW5zdCB7e2VtYWlsOm1haWx0bywgc21zOm1haWx0bywgIA0KPj4gbW1zOm1haWx0bywN Cj4+IGVtczptYWlsdG99IGFuZCB7c21zOnRlbCwgbW1zOnRlbCwgZW1zOnRlbH0gYW5kIHtmYXg6 dGVsfX0sIHdoaWNoICANCj4+IHRyaWdnZXJlZA0KPj4gb25lIG9mIHRocmVlIGV4dGVybmFsIGNv bW11bmljYXRpb25zIHByb2dyYW1zIC0gd2UgZGlkIG5vdCBoYXZlIGEgIA0KPj4gcHJvZ3JhbQ0K Pj4gdG8gc3VwcG9ydCBpZmF4Om1haWx0bywgc28ganVzdCBwYXR0ZXJuIG1hdGNoaW5nIGFnYWlu c3Qgeyo6bWFpbHRvfSAgDQo+PiB3b3VsZA0KPj4gbm90IHdvcmsuDQo+PiBGb3IgbW9iaWxlIGNs aWVudHMgd2l0aCBubyBlbWFpbCwgU0lQIG9yIGZheCBzdXBwb3J0LCB3ZSBqdXN0ICANCj4+IG1h dGNoZWQgYWdhaW5zdA0KPj4ge3ZvaWNlOnRlbH0gYW5kIHtzbXM6dGVsLCBtbXM6dGVsLCBlbXM6 dGVsfSB0byBydW4gdGhlIHZvaWNlIG9yICANCj4+IHRleHQgZmVhdHVyZXMNCj4+IG9mIHRoZSBw aG9uZS4NCj4+DQo+PiBUaGlzIHdvcmtlZCB3ZWxsLCBidXQgYXMgeW91IHNheSBpdCBkb2VzIHJl cXVpcmUgc29tZSBwcm9jZXNzaW5nIHRvICANCj4+IGdldCBOQVBUUnMNCj4+IGFuZCB0aGVpciBz ZXJ2aWNlcyBmaWVsZCBpbnRvIGEgc2luZ2xlIGxpc3Qgb2YgImFsbCB0ZWxlc2VydmljZXMgIA0K Pj4gc3VwcG9ydGVkIi4NCj4+IFRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlIGNsaWVudCBkZXZpY2Vz IHdhcyBmaXhlZCBzbyB3ZSBjb3VsZCBoYXZlICANCj4+ICJoYXJkIHdpcmVkIg0KPj4gdGhlICJs b2NhbCBzdXBwb3J0IiBtYXRjaCBsaXN0cyAtIGhvd2V2ZXIsIHdlIHdhbnRlZCB0aGUgdXNlciB0 byBiZSAgDQo+PiBhYmxlIHRvDQo+PiAic3dpdGNoIG9mZiIgc2VuZGluZyBhbiBTTVMvTU1TL0VN UyBtZXNzYWdlIC0gdGhpcyBqdXN0IGNvbnNpc3RlZCAgDQo+PiBvZiByZW1vdmluZw0KPj4gdGhv c2UgaXRlbXMge3Ntczp0ZWwsbW1zOnRlbCwgZW1zOnRlbH0gZnJvbSB0aGUgImxvY2FsbHkgc3Vw cG9ydGVkIiAgDQo+PiBsaXN0Lg0KPj4gLS0tLQ0KPj4gVG8gc3VtbWFyaXNlIHRoZSBzdGVwczoN Cj4+IC0gIHByb2Nlc3MgdGhlIE5BUFRScyB0byBnZW5lcmF0ZSBvbmUgbGlzdCBvZiAicHVibGlz aGVkIHNlcnZpY2VzIiAgDQo+PiBvZiB0aGUgZm9ybQ0KPj4gICAgPHRlbGVzZXJ2aWNlPjo8cHJv dG9jb2w+DQo+Pg0KPj4gLSAgbWF0Y2ggdGhpcyBhZ2FpbnN0IGEgbGlzdCBvZiAibG9jYWxseSBz dXBwb3J0ZWQgc2VydmljZXMiLCAgDQo+PiBvcmRlcmVkIGFjY29yZGluZw0KPj4gICAgdG8gdGhl IHVzZXIncyBjaG9pY2UgKGUuZy4gdm9pY2UgZmlyc3QsIHRoZW4gbWVzc2FnZSB1c2luZyAgDQo+ PiBtYWlsdG8sIHRoZW4NCj4+ICAgIFNNUy9NTVMvRU1TIG1lc3NhZ2UsIHRoZW4gZmF4KQ0KPj4N Cj4+IC0gIGdlbmVyYXRlIGEgbGlzdCBvZiAic3VjY2Vzc2Z1bCIgbWF0Y2hlcywgd2l0aCBhIHBv aW50ZXIgdG8gdGhlICANCj4+IE5BUFRSKHMpDQo+PiAgICB0aGF0IGhlbGQgdGhlIHNlcnZpY2Ug YW5kIHRvIHRoZSBsb2NhbCBwcm9ncmFtIHRoYXQgbmVlZHMgdG8gYmUgIA0KPj4gcnVuLg0KPj4g LS0tLQ0KPj4gQXMgYSBmaW5hbCBub3RlIC0gd2Uga2VwdCBhICJ3aW5uaW5nIGxpc3QiIHJhdGhl ciB0aGFuIGEgc2luZ2xlICANCj4+IGFuc3dlciBzbw0KPj4gdGhhdCwgaWYgdGhlIGZpcnN0IGNo b2ljZSBmYWlsZWQsIHRoZSBFTlVNIGNsaWVudCBjb3VsZCB0cnkgdGhlICANCj4+IG5leHQgd2l0 aG91dA0KPj4gcmUtcHJvY2Vzc2luZy4gVGhpcyB3b3JrZWQgYXMgdGhlIFRUTHMgb24gdGhlIE5B UFRScyB3ZXJlIGEgZmV3ICANCj4+IG1pbnV0ZXMNCj4+IC0gaWYgdGhlIE5BUFRScyBoYWQgdmVy eSBzaG9ydCBUVExzIChlLmcuIDEgc2Vjb25kKSwgdGhpcyB3b3VsZCBub3QgIA0KPj4gaGF2ZQ0K Pj4gYmVlbiB2YWxpZC4NCj4+DQo+PiBJIGhvcGUgdGhpcyBoZWxwcywNCj4+ICAgTGF3cmVuY2UN Cj4+DQo+Pg0KPj4gT24gMTYgSmFuIDIwMDYsIGF0IDEwOjE5LCBjaGVuaHVpIHdyb3RlOg0KPj4+ IEhpIGFsbCwNCj4+Pg0KPj4+IFdlIGFyZSBjb25zaWRlcmluZyBob3cgdG8gaW1wbGVtZW50IEVO VU0gcmVzb2x2ZXIgaW50byBjdXJyZW50ICANCj4+PiBjb21tdW5pY2F0aW9uIGNsaWVudHMgb3Ig c2VydmljZSBzeXN0ZW1zLg0KPj4+DQo+Pj4gTm93IG1vc3Qgb2YgY3VycmVudCBjb21tdW5pY2F0 aW9uIGFwcGxpY2F0aW9ucyBkbyBub3Qgc3VwcG9ydCBFTlVNICANCj4+PiByZXNvbHV0aW9uLCBh bHRob3VnaCBFTlVNIHJlY29yZHMgY2FuIGJlIHJldGlldmVkIGJ5ICJuc2xvb2t1cCIgb3IgIA0K Pj4+ICJkaWciIHF1ZXJ5ICJOQVBUUiIgcmVzb3VyY2UgcmVjb3JkcywgZGlmZmVyZW50IGNsaWVu dHMgb3Igc2VydmljZSAgDQo+Pj4gc3lzdGVtcyBjYW4gbm90IHN1cHBvcnQgYWxsIHJldHVybmVk IHJlc3VsdHMuIFRoYXQgaXMsIHNvbWUgIA0KPj4+IHJlY29yZHMgYXJlIHVzZWxlc3MgZm9yIHNw ZWNpZmljIHNlcnZpY2VzLiBBbHNvLCB0b28gbWFueSB1c2VsZXNzICANCj4+PiByZWNvcmRzIHdp bGwgYWZmZWN0IHNlcnZpY2UgcGVyZm9ybWFuY2UuDQo+Pj4NCj4+PiBVc2luZyBmaWx0ZXIgaXMg YSB1c2VmdWwgbWV0aG9kIHRvIHJlc29sdmUgdGhpcyBwcm9ibGVtLiBUbyB1c2UgIA0KPj4+ICJz ZXJ2aWNlIHR5cGUiIGFuZCAic3VidHlwZSIsIG9ubHkgdmFsdWFibGUgcmVzdWx0cyBjYW4gYmUg cmV0dXJuZWQuDQo+Pj4NCj4+PiBCdXQsIHdlIGFyZSBub3Qgc3VyZSBob3cgY2FuIG1ha2UgdGhl IEVOVU0gcmVzb2x2ZXIgd29ya3MgbW9yZSAgDQo+Pj4gcmVhc29uYWJsZS4gQmVjYXVzZSBleGFj dCAic2VydmljZSB0eXBlIiBhbmQgInN1YnR5cGUiIHdpbGwgZmlsdGVyICANCj4+PiBtYW55IHJl c3VsdHMsIGluY2x1ZGluZyBvZiBvbGQgInNlcnZpY2UgdHlwZSIuIEZvciBleGFtcGxlLCB0aGVy ZSAgDQo+Pj4gaXMgYW4gRU5VTSBudW1iZXIgaGF2aW5nIE5BUFRSIHJlY29yZHMgb2YgIkUyVStl bWFpbDptYWlsdG8iLCAiRTJVIA0KPj4+ICtzbXM6bWFpbHRvIiwgYW5kICJFMlUrZW1zOm1haWx0 byIsIGlmIHRoZSBmaWx0ZXIgaXMgIkUyVSANCj4+PiArc21zOm1haWx0byIsIGl0IGp1c3QgcmV0 dXJucyBOQVBUUiByZWNvcmRzIHdpdGggZXhhY3QgInNlcnZpY2UgIA0KPj4+IHR5cGUiIGFuZCAi c3VidHlwZSIuIE9yIGlmIHRoZXJlIGlzIG5vIGFueSBjb3JyZXNwb25kaW5nIHJlY29yZCwgIA0K Pj4+IHRoaXMgY2FsbCB3aWxsIGJlIGZhaWxlZC4gVG9vIG11Y2ggZmFpbHVyZSB3aWxsIGFmZmVj dCBzZXJ2aWNlICANCj4+PiBwZXJmb3JtYW5jZS4NCj4+Pg0KPj4+IEFub3RoZXIgd2F5IGlzIHRv IHN1cHBvcnQgbm90IGV4YWN0IGZpbHRlciwgbGlrZSBvbmx5IGJ5ICANCj4+PiAic3VidHlwZSIu IFRoZSBFTlVNIHJlc29sdmVyIGNhbiByZXR1cm4gYWxsIHJlbGF0aXZlIHJlY29yZHMgb2YgIA0K Pj4+ICJFMlUrZW1haWw6bWFpbHRvIiwgIkUyVStzbXM6bWFpbHRvIiwgYW5kICJFMlUrZW1zOm1h aWx0byIuICANCj4+PiBBcHBsaWNhdGlvbiBjbGllbnRzIG9yIHNlcnZpY2Ugc3lzdGVtcyBjYW4g YXV0b21hdGljYWxseSBjaG9vc2UgIA0KPj4+IGl0cyBwZXJmZXJyZWQgcmVzdWx0cy4gSG93ZXZl ciwgdGhpcyBtYXkgaW50cm9kdWNlIG1vcmUgc2VydmljZSAgDQo+Pj4gZGVsYXkuDQo+Pj4NCj4+ PiBXaGF0IGlzIHRoZSBiZXN0IHdheT8gRG8geW91IGhhdmUgYW55IHN1Z2dlc3Rpb24gb24gdGhp cyBwcm9ibGVtPw0KPj4+DQo+Pj4gQlRXLCBXZSBmaW5kIHRoYXQgSUFOQSBoYXMgcHVibGlzaGVk IEVOVU0gc2VydmljZXMgb24gSmFuIDEwdGgsIA0KPj4+IDIwMDYuIFRoZSB3ZWJwYWdlIGlzIGh0 dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvZW51bS1zZXJ2aWNlcw0KPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gZW51bSBtYWlsaW5n IGxpc3QNCj4+PiBlbnVtQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZW51bQ0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gZW51bSBtYWlsaW5nIGxpc3QNCj4+IGVudW1AaWV0Zi5v cmcNCj4+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VudW0NCj4= --===============0495855769== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0495855769==-- From enum-bounces@ietf.org Thu Feb 16 02:31:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9dbV-00023n-Jh; Thu, 16 Feb 2006 02:31:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9daO-0001Z6-Bh for enum@megatron.ietf.org; Thu, 16 Feb 2006 02:29:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24732 for ; Thu, 16 Feb 2006 02:28:08 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9doV-0008Vt-Nu for enum@ietf.org; Thu, 16 Feb 2006 02:44:36 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 15 Feb 2006 23:29:43 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1G7Tgjt025540; Wed, 15 Feb 2006 23:29:42 -0800 (PST) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k1G7V1t5009327; Wed, 15 Feb 2006 23:32:45 -0800 In-Reply-To: <340057424.29737@cnnic.cn> References: <337406757.16031@cnnic.cn> <010342E2-E165-470E-A8A0-8734A9B1CA37@insensate.co.uk> <340010362.05978@cnnic.cn> <340057424.29737@cnnic.cn> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] The use of "service type" and "subtype" fieldsin ENUM record Date: Thu, 16 Feb 2006 08:29:32 +0100 To: chenhui X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=269; t=1140075166; x=1140507366; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=paf@cisco.com; z=From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:Re=3A=20[Enum]=20The=20use=20of=20=22service=20type=22=20and=20=22subtyp e=22=20fieldsin=20ENUM=20record |To:chenhui=20; X=v=3Dmtcc.com=3B=20h=3Dd/yD96dYDVuUd68UtYvlLVITHqs=3D; b=gpQedN6OvtswoYT/zkapqgVIY4SGWxgtJQhzH9Yojm18mQ3hmpHuipFgjt2CzR1b/rnrSlV0 lxOKfsE/Wh8hZLWFge1o4yXMrAGIif7sHBDcxbxa0ucuBtWtbvJfISCeVeorh2cEZbHjkFtL5N4 2yduOCJhPi1VOq4ST/zGceGE=; Authentication-Results: imail.cisco.com; header.From=paf@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 2.2 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: IETF ENUM WG , lconroy , =?UTF-8?B?546LIOWzsA==?= , Julian Rose X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 16 feb 2006, at 03.37, chenhui wrote: > and the second is ENUM resolver needs no cache because local DNS > resolver can cache the records But IF it is caching, it definitely (like any receiver of DNS data) must look at the TTL on the data. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 16 06:58:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9hmM-0001U7-76; Thu, 16 Feb 2006 06:58:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9hmK-0001Rh-Af for enum@megatron.ietf.org; Thu, 16 Feb 2006 06:58:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14948 for ; Thu, 16 Feb 2006 06:56:45 -0500 (EST) Received: from [213.152.49.123] (helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9i0D-0001Qm-ND for enum@ietf.org; Thu, 16 Feb 2006 07:13:14 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 413077CDA9; Thu, 16 Feb 2006 11:58:00 +0000 (GMT) In-Reply-To: References: <337406757.16031@cnnic.cn> <010342E2-E165-470E-A8A0-8734A9B1CA37@insensate.co.uk> <340010362.05978@cnnic.cn> <340057424.29737@cnnic.cn> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <72B44F3D-FAB2-42CB-A6AC-EE7C550BE3D9@insensate.co.uk> Content-Transfer-Encoding: quoted-printable From: lconroy Subject: Re: [Enum] The use of "service type" and "subtype" fieldsin ENUM record Date: Thu, 16 Feb 2006 11:57:59 +0000 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: IETF ENUM WG , Julian Rose , =?UTF-8?B?546LIOWzsA==?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Patrik, chenhui, folks, Agreed that the DNS resolver will cache results, so a subsequent =20 DNS query for the same domain/owner will be MUCH quicker. However, **in our client**, we did not perform a second ENUM query if =20= the "winning" URI fails (e.g. a telephone number returns busy). =20 Carrying out another query would just return the same winner - the =20 telephone number that was just busy. Instead, **in our client**, we keep an ordered list of winners, and =20 try the "next one" in the list if the first one fails. This is just the scheme we used in our client in the UK trial - it is =20= in no way part of the ENUM standard, and it may not always be =20 appropriate behaviour. It worked in our case as the TTLs on the NAPTRs was long, so the =20 "winners list" was still valid when we tried the next contact all the best, Lawrence On 16 Feb 2006, at 07:29, Patrik F=E4ltstr=F6m wrote: > On 16 feb 2006, at 03.37, chenhui wrote: >> and the second is ENUM resolver needs no cache because local DNS =20 >> resolver can cache the records > But IF it is caching, it definitely (like any receiver of DNS data) =20= > must look at the TTL on the data. > > paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 16 07:10:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9hyL-00068r-Fh; Thu, 16 Feb 2006 07:10:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9hyJ-000662-DS for enum@megatron.ietf.org; Thu, 16 Feb 2006 07:10:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15971 for ; Thu, 16 Feb 2006 07:09:08 -0500 (EST) Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9iCS-0001vG-0Y for enum@ietf.org; Thu, 16 Feb 2006 07:25:37 -0500 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.1/8.13.4) with ESMTP id k1GCEsmY002276; Thu, 16 Feb 2006 07:14:54 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 07:10:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Feb 2006 07:10:50 -0500 Message-ID: <046F43A8D79C794FA4733814869CDF070128BCB1@dul1wnexmb01.vcorp.ad.vrsn.com> Thread-Topic: RFC4114 example breaks RFC3731? Thread-Index: AcYySOihdSboj9qVTgeXs2c3g5fOTQAqIx3w From: "Hollenbeck, Scott" To: "Alexander Mayrhofer" , X-OriginalArrivalTime: 16 Feb 2006 12:10:39.0278 (UTC) FILETIME=[0028B4E0:01C632F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: Subject: [Enum] RE: RFC4114 example breaks RFC3731? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Alex, If you look at the schema in 3731 you'll see that it explicitly allows the use of elements as described in 4114. The problem is that the text in 3731 is incorrect because it neglects to say that those elements can be absent if an appropriate replacement is found in an extension. That's being corrected in 3731bis: https://datatracker.ietf.org/public/idindex.cgi?command=3Did_detail&id=3D= 136 49 -Scott- > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at]=20 > Sent: Wednesday, February 15, 2006 11:00 AM > To: enum@ietf.org; Hollenbeck, Scott > Subject: RFC4114 example breaks RFC3731? >=20 > Hi, >=20 > i'm currently looking at RFC4114 to see how it fits potential=20 > infrastructure=20 > ENUM applications. In section 3.2.5, there is the following=20 > example of an=20 > : >=20 > C: > C: C: xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > C: xsi:schemaLocation=3D"urn:ietf:params:xml:ns:epp-1.0 > C: epp-1.0.xsd"> > C: > C: > C: C: xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0" > C: xsi:schemaLocation=3D"urn:ietf:params:xml:ns:domain-1.0 > C: domain-1.0.xsd"> > C: 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa > C: > C: > C: > ... (remaining lines removed) ... >=20 > Clearly, this request uses the domain mapping specified in=20 > RFC3731. Section=20 > 3.2.5 of RFC3731 says: >=20 > ----- > The element contains the following child elements: >=20 > - A element that contains the fully=20 > qualified name of > the domain object to be updated. >=20 > - An OPTIONAL element that contains=20 > attribute values to > be added to the object. >=20 > - An OPTIONAL element that contains=20 > attribute values to > be removed from the object. >=20 > - An OPTIONAL element that contains object attribute > values to be changed. >=20 > At least one , , or =20 > element MUST > be provided. The and elements=20 > contain the > following child elements: > ----- >=20 > However, the example above does not contain such an element=20 > required by the=20 > last sentence. It passes the schema, though, because the=20 > above requirement=20 > cannot be easily expressed there. >=20 > So, my question is: >=20 > - is the example in RFC4114 broken? Or > - is it ok to use RFC3731 schemas without being RFC3731 compliant? Or > - is the example not considered normative? ;) >=20 > (BTW, i don't see any reason for the mandatory elements in a RFC4114=20 > scenario though, so i'd actually prefer to implement it the way it is=20 > outlined in the example) >=20 > Any comments appreciated. >=20 > Alex >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 16 09:17:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9jwj-0003XC-AP; Thu, 16 Feb 2006 09:17:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9jwh-0003Wz-Ta for enum@megatron.ietf.org; Thu, 16 Feb 2006 09:17:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27029 for ; Thu, 16 Feb 2006 09:15:35 -0500 (EST) Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9kAs-00074e-7Z for enum@ietf.org; Thu, 16 Feb 2006 09:32:06 -0500 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.1/8.13.4) with ESMTP id k1GEL8de007314; Thu, 16 Feb 2006 09:21:14 -0500 Received: from dul1trutkow-l1.verisign.com ([10.169.64.186]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 09:16:52 -0500 Message-Id: <7.0.1.0.2.20060216150317.02a9df20@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 16 Feb 2006 15:16:44 +0100 To: Otmar Lendl , enum@ietf.org From: Tony Rutkowski In-Reply-To: <20060208174811.GA6329@nic.at> References: <20060208174811.GA6329@nic.at> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_65015797==_" X-OriginalArrivalTime: 16 Feb 2006 14:16:52.0919 (UTC) FILETIME=[A2669C70:01C63303] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: Subject: [Enum] draft-ietf-enum-validation-token-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --=====================_65015797==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Otmar, Your very useful token contribution can be usefully implemented within what seems the universal global architecture and process requirement for public ENUM. Whoever is running the ENUM EPP bluebox will generally require four tokens. best, tony --=====================_65015797==_ Content-Type: application/pdf; name="ENUM Authentication Architecture.pdf" Content-Disposition: attachment; filename="ENUM Authentication Architecture.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjIwIDAgb2JqIDw8L0xpbmVhcml6ZWQgMS9MIDEzNjI5L08gMjIvRSA3 Nzk5L04gMS9UIDEzMTgyL0ggWyA1NTYgMTkxXT4+DWVuZG9iag0gICAgICAgICAgICAgICAgICAg DQp4cmVmDQoyMCAxMw0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwOTEzIDAwMDAwIG4NCjAw MDAwMDExODIgMDAwMDAgbg0KMDAwMDAwMTQyNyAwMDAwMCBuDQowMDAwMDAxODQwIDAwMDAwIG4N CjAwMDAwMDIyNDQgMDAwMDAgbg0KMDAwMDAwMjI3OCAwMDAwMCBuDQowMDAwMDA0NjIyIDAwMDAw IG4NCjAwMDAwMDcyOTEgMDAwMDAgbg0KMDAwMDAwNzUxMiAwMDAwMCBuDQowMDAwMDA3NzIzIDAw MDAwIG4NCjAwMDAwMDA3NDcgMDAwMDAgbg0KMDAwMDAwMDU1NiAwMDAwMCBuDQp0cmFpbGVyDQo8 PC9TaXplIDMzL1ByZXYgMTMxNzEvWFJlZlN0bSA3NDcvUm9vdCAyMSAwIFIvSW5mbyA4IDAgUi9J RFs8NDFFMzU5OTIyOUI2RkMxMjU3QjQzN0NENDA4NDE5MzM+PDk1NTQxQkM4ODNGRENENDQ5RTg2 MUZBNTczNTA5MDU1Pl0+Pg0Kc3RhcnR4cmVmDQowDQolJUVPRg0KICANCjMyIDAgb2JqPDwvTGVu Z3RoIDk2L0MgMTExL0ZpbHRlci9GbGF0ZURlY29kZS9JIDEzMy9MIDk1L08gNzkvUyAzOT4+c3Ry ZWFtDQp42mJgYOBkYGC+zwAEkjcZUAETELMwcBxAEeSEYgYGJQYeXsNqcQWGCVne3Bs2Mi0AizIy MMjugGq+DDaAQeEtlG8BxMwMDHLdEHVMSXBTORgYDAshoozOAAEGAIUFDCUNCmVuZHN0cmVhbQ1l bmRvYmoNMzEgMCBvYmo8PC9MZW5ndGggMjAvRmlsdGVyL0ZsYXRlRGVjb2RlL1dbMSAxIDFdL0lu ZGV4WzkgMTFdL0RlY29kZVBhcm1zPDwvQ29sdW1ucyAzL1ByZWRpY3RvciAxMj4+L1NpemUgMjAv VHlwZS9YUmVmPj5zdHJlYW0NCnjaYmJiZmBiYGAkBgMEGAADzgAmDQplbmRzdHJlYW0NZW5kb2Jq DTIxIDAgb2JqPDwvTWFya0luZm88PC9MZXR0ZXJzcGFjZUZsYWdzIDAvTWFya2VkIHRydWU+Pi9P dXRsaW5lcyAxIDAgUi9NZXRhZGF0YSA3IDAgUi9QaWVjZUluZm88PC9NYXJrZWRQREY8PC9MYXN0 TW9kaWZpZWQoRDoyMDA2MDIxNjE1MTYwMCk+Pj4+L1BhZ2VzIDYgMCBSL1BhZ2VMYXlvdXQvU2lu Z2xlUGFnZS9TdHJ1Y3RUcmVlUm9vdCA5IDAgUi9UeXBlL0NhdGFsb2cvTGFzdE1vZGlmaWVkKEQ6 MjAwNjAyMTYxNTE2MDApL1BhZ2VMYWJlbHMgNCAwIFI+Pg1lbmRvYmoNMjIgMCBvYmo8PC9Dcm9w Qm94WzM3IDM3IDU3NSA3NTVdL1BhcmVudCA2IDAgUi9TdHJ1Y3RQYXJlbnRzIDAvQ29udGVudHMg MjYgMCBSL1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzPDwvQ29sb3JT cGFjZTw8L0NTMCAyNSAwIFI+Pi9Gb250PDwvVFQwIDIzIDAgUi9UVDEgMjQgMCBSPj4vUHJvY1Nl dFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMCAzMCAwIFI+Pj4+L1R5cGUvUGFnZT4+DWVuZG9i ag0yMyAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMjggMCBSL0xhc3RD aGFyIDEyMS9XaWR0aHNbMjc4IDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMjc4IDAgMjc4IDI3 OCAwIDU1NiA1NTYgMCA1NTYgMCA1NTYgMCAwIDU1NiAwIDAgMCAwIDAgMCAwIDY2NyAwIDAgNzIy IDY2NyA2MTEgMCAwIDI3OCAwIDAgMCA4MzMgNzIyIDAgNjY3IDAgNzIyIDY2NyAwIDcyMiAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgNTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMCA1 MDAgMjIyIDgzMyA1NTYgNTU2IDU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCAwIDAgNTAwXS9C YXNlRm9udC9BcmlhbE1UL0ZpcnN0Q2hhciAzMi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlw ZS9Gb250Pj4NZW5kb2JqDTI0IDAgb2JqPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRv ciAyOSAwIFIvTGFzdENoYXIgMTIxL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAyNzggMCAwIDU1NiAwIDAgNTU2IDU1NiA1NTYgMCAwIDAgMCAwIDAgMCAwIDAgMCA3MjIgMCAw IDcyMiA2NjcgMCAwIDAgMjc4IDAgMCAwIDgzMyA3MjIgMCA2NjcgMCA3MjIgNjY3IDAgNzIyIDAg MCAwIDAgMCAzMzMgMCAzMzMgMCAwIDAgNTU2IDYxMSA1NTYgNjExIDU1NiAzMzMgNjExIDYxMSAy NzggMCAwIDI3OCA4ODkgNjExIDYxMSA2MTEgMCAzODkgNTU2IDMzMyA2MTEgNTU2IDAgMCA1NTZd L0Jhc2VGb250L0FyaWFsLEJvbGQvRmlyc3RDaGFyIDMyL0VuY29kaW5nL1dpbkFuc2lFbmNvZGlu Zy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMjUgMCBvYmpbL0lDQ0Jhc2VkIDI3IDAgUl0NZW5kb2JqDTI2 IDAgb2JqPDwvTGVuZ3RoIDIyNzQvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJtFdbT+S4 En7vX+HH5Gg6xNc40molFjhHsxII0c0Ty0NfMpA9TZpN0ow4v/5UlZ0bJD090q4QndguV8rf57qd 3bJffjm7vvh6yWL266+/XV6w2dnFImabCibwj1WbYsZZDvP/gfmnavbbcna2XMaMs+W3WRzFcSzY csPm9KrZ8jvuWlaMx/j8H4yWJfwIxebwHzOrIyMY53GUsOXLLLg9rHf5hl3d3F+z80P9nBV1vlnV +b5g5+XmOa+zTX0oM7Yqtuy23G+yqgqXf86ulrOrazR38bx6zdpj8OYYcWRlyuIoFRp/pfRH0TwC g5V7SAnngGeZzfAsinZo2qHbHcpGqWXKPT7sSEAKvpRY/E2bT8SgPx6KjtkqWls7qB26vIeuRXRj hyu3bA7/gKZNI2GYSlSkLMGI+CEujgdJlPCIc/wFgraz4C6r9rsDAtvJcVIeaZ10cgDyW77Nyg/a 4IDwglI4BrmH7PX18QgVsjkebyFKDB/QYBL6NYzLFlIDcoqkZSvtsDeKfnvSpJnhnhZ5WO5LjBmm foQ7nZp7bOD8yqNv0Nq5e+AwhY8nFr5OBETcKHZzeFn3oeuxF8XaECdwCMDvITjfvuRFHs5VUNXl qt6X4ePy91nHC0BkjUNcuB13WWiCpxzFnfAE9PoI9ELqn4BeSHES9EKqU6A3fw/0wshITUMf90C3 hk9BWNTHMEyOYCjFz2AoxWkYSnEShvY0DEWLoR7FUGrE0IK1PQwXWfmWbzIPIuJnuOrhFywO62pT 5h7oCejSI9CpOP0J6FRsToJOxfYU6Hh8GnamxS4dxU6JBL6eCsgVbfBl93dfW78H0JorCGOhec/x 4Qp+y8qs2GTbLk6kzRfpwiPgkIX699Yzw3x0DnVwNALwfiIETBsmnLMmFH2FTj+T4AhoqHDihsKv 0OYjC8iBY8LrBdfU9sc0/DDzORAbTAT3LEg0YO4e8Kk0hXsFwQAMcEkQ64d9mddQPrxljK70J4i1 0o6MhMi4zEsoMPblO3sAea4f2bHqostpliBESuciAtaEknhgnhBWOP8ye4YhBQooLCKa4dbVBjt4 ozvtV3aAlACHHFMpdNxXKVQyUCm08Co9QT2V4EejKqUeWCn10EppGiul+Wglvo6pVNL0VSopByqV tF6lUuLjwe0HleAueG470CgsacTju3NbS5cNzp2SRr9C5+YkK9PYa+S4ggfnhCUu0MEbOUXuPS5K awNp+o4/Pf70pb11rbSaUqyGWjHSTYua6KN0OmmDX+tLYwwfVQwLAzk7bYNb60sLPm2DWxtImwnF sNCXk/G0DW5tIC2nbXBrA2k7pdjLxUPfkrzxLck/+pa/nrhMKufNrU1dg+FumL+bKvaW463F27dr 7rNf6d1arZvj26RnI073bDQy6Ww0ynY2+pXdVPBty99BJ9f2b12zMYy2GMo0xFwTCRds6/1/s8JV CnMdcdh6OZxMokR8ngUtSTqcbaNt145yPW0ll21iUKOmyphHKoV+TENCAlOh6sMq+45tnlfFU3Y0 b5quduG9zgLqCyxxFdQmEJIAaO3z29nFImYXC+Yz2eLiBttCzb5jsXENOv6E/9/Zw2PMtow6Ge1D GucJE1xFicJ0gAOBrNGnBAmAsLR+ejFubjKZSfuIScp99KqaatC5mXvAEN2bzgjFl8PsqgrnSVCv 1ru8es62bP3OwrkJihW2kKsdIxhJJ3SPjXqROPVNuXMJispwboPs6YC7d9Dn4JPm3sO5DNiKFiBx t/N5/f6FZdETTkQk03VGqv0U5vzvbPkv+MLN+c1tmIIqqO2hqQqToMAKP1TBqob5/fFSyY5TnmKy MSOUC8hgEEIg1AtyaShUBCwDbjs3UJTgaT9GAeyhkEeanuAxPYlH1Z1ejdII5SLRqExL4yWymIU8 qLNwjlUjDF/QHfLiOKndt2QL9DEqxSSVndI+fa3SAxSzVSjpuQrnPNjt3tmKVb4X0QF7xaIXuYVB dpRMEY+SqYyBTnDChZVWEUdCU/BNKFUg0KEs5/jYtWNyw0YROaiGUAwh6JiDCn4SsbFpcUnsKLMq SQbe6foAwoPt4fEtBPwr6guoT+gR2fGoWsyrw+vrnu5CDbdgRbSRp93j3B3+fHWeByt50VMn5bA5 InVXNyh3jz/XtO0uq/aHEsdgy1222Zfbo7SJUdpkMvDBWGKwJM6k0eh9yFmCNYy04HdQ+GAspXdy NrcffVDxH/qgkKf5YBfsZDJKlbSfnHBxWFcb9AeCPF93rsieVxCu3vLiCaf6rmK7K2FaoDfIdVGj MxTwdmhentBN/GK537H9W2jxanT6VKdPdvrqZ98nseIAql4ay9pt3EyXBFjCaCBHoktgSfDXISvf j/RPQo2HWvA+bdIIrFBIs0DciGYONb2BfkBiOgSCtNSuWqKBkbhl5/fTAMSM6FYmmNYnMQ3xoUVM jGdNoZDptsy4pPCIgdb0Am22heBo0mCN0y5Q+nhLYfSfiLmsG/WvQC8UdL6bF0i5zw6tYRoMcxej dxe6G9mLJC5M92I0nLisjnp7W2TFkYV4h1cBn87nU6pvdUpMGwOXzsfpOFIghLfGvXlx6lC1q7OH 4l5zIwgXKVUDkVHjpksq/iliEyrJqHMooaOEPhkpVzCfH4ClMq8B4jfwupv7a3SVeRNKfUlLyqIE tFINBcq3s+AyL7NNvS/f2QOQwvUjO+ZlbUGjRDLsKCB4w8GVUP2OAps1lLK+X8KODJGCbCdd6+FW sKMY+K2OdWRcW6UpvHLoelx4hh4EtEgbRxwTJZS5KAiezdF7m7GkQaMFrdHa+ukJ1z2xUOoKXjle 8GoO9KDpbYympJf9dQCot+g9bNJf0bVahyTvc6nUyfb8TQ1YJXdZHchVffTPMT6Au9Y0xV6yrGb1 +ysOaGnjPbHng7JzQt7FCGf3C9YDRV2xP4LigIM1pADI8zWkmNU6332oxnSnS3a67jFqLDCL/xs/ /oXyOefiLOUc/PsLnf/GCcng6hZKdVc+yIBSHFXsf4SDAPB/AQYAeZhTkQ0KZW5kc3RyZWFtDWVu ZG9iag0yNyAwIG9iajw8L0xlbmd0aCAyNTc1L0ZpbHRlci9GbGF0ZURlY29kZS9OIDMvQWx0ZXJu YXRlL0RldmljZVJHQj4+c3RyZWFtDQpIiZyWeVRTdxbHf2/JnpCVsMNjDVuAsAaQNWxhkR0EUQhJ CAESQkjYBUFEBRRFRISqlTLWbXRGT0WdLq5jrQ7WferSA/Uw6ug4tBbXjp0XOEedTmem0+8f7/c5 93fv793fvfed8wCgJ6WqtdUwCwCN1qDPSozFFhUUYqQJAAMKIAIRADJ5rS4tOyEH4JLGS7Ba3An8 i55eB5BpvSJMysAw8P+JLdfpDQBAGTgHKJS1cpw7ca6qN+hM9hmceaWVJoZRE+vxBHG2NLFqnr3n fOY52sQKjVaBsylnnUKjMPFpnFfXGZU4I6k4d9WplfU4X8XZpcqoUeP83BSrUcpqAUDpJrtBKS/H 2Q9nuj4nS4LzAgDIdNU7XPoOG5QNBtOlJNW6Rr1aVW7A3OUemCg0VIwlKeurlAaDMEMmr5TpFZik WqOTaRsBmL/znDim2mJ4kYNFocHBQn8f0TuF+q+bv1Cm3s7Tk8y5nkH8C29tP+dXPQqAeBavzfq3 ttItAIyvBMDy5luby/sAMPG+Hb74zn34pnkpNxh0Yb6+9fX1Pmql3MdU0Df6nw6/QO+8z8d03Jvy YHHKMpmxyoCZ6iavrqo26rFanUyuxIQ/HeJfHfjzeXhnKcuUeqUWj8jDp0ytVeHt1irUBnW1FlNr /1MTf2XYTzQ/17i4Y68Br9gHsC7yAPK3CwDl0gBStA3fgd70LZWSBzLwNd/h3vzczwn691PhPtOj Vq2ai5Nk5WByo75ufs/0WQICoAIm4AErYA+cgTsQAn8QAsJBNIgHySAd5IACsBTIQTnQAD2oBy2g HXSBHrAebALDYDsYA7vBfnAQjIOPwQnwR3AefAmugVtgEkyDh2AGPAWvIAgiQQyIC1lBDpAr5AX5 Q2IoEoqHUqEsqAAqgVSQFjJCLdAKqAfqh4ahHdBu6PfQUegEdA66BH0FTUEPoO+glzAC02EebAe7 wb6wGI6BU+AceAmsgmvgJrgTXgcPwaPwPvgwfAI+D1+DJ+GH8CwCEBrCRxwRISJGJEg6UoiUIXqk FelGBpFRZD9yDDmLXEEmkUfIC5SIclEMFaLhaBKai8rRGrQV7UWH0V3oYfQ0egWdQmfQ1wQGwZbg RQgjSAmLCCpCPaGLMEjYSfiIcIZwjTBNeEokEvlEATGEmEQsIFYQm4m9xK3EA8TjxEvEu8RZEolk RfIiRZDSSTKSgdRF2kLaR/qMdJk0TXpOppEdyP7kBHIhWUvuIA+S95A/JV8m3yO/orAorpQwSjpF QWmk9FHGKMcoFynTlFdUNlVAjaDmUCuo7dQh6n7qGept6hMajeZEC6Vl0tS05bQh2u9on9OmaC/o HLonXUIvohvp6+gf0o/Tv6I/YTAYboxoRiHDwFjH2M04xfia8dyMa+ZjJjVTmLWZjZgdNrts9phJ YboyY5hLmU3MQeYh5kXmIxaF5caSsGSsVtYI6yjrBmuWzWWL2OlsDbuXvYd9jn2fQ+K4ceI5Ck4n 5wPOKc5dLsJ15kq4cu4K7hj3DHeaR+QJeFJeBa+H91veBG/GnGMeaJ5n3mA+Yv6J+SQf4bvxpfwq fh//IP86/6WFnUWMhdJijcV+i8sWzyxtLKMtlZbdlgcsr1m+tMKs4q0qrTZYjVvdsUatPa0zreut t1mfsX5kw7MJt5HbdNsctLlpC9t62mbZNtt+YHvBdtbO3i7RTme3xe6U3SN7vn20fYX9gP2n9g8c uA6RDmqHAYfPHP6KmWMxWBU2hJ3GZhxtHZMcjY47HCccXzkJnHKdOpwOON1xpjqLncucB5xPOs+4 OLikubS47HW56UpxFbuWu252Pev6zE3glu+2ym3c7b7AUiAVNAn2Cm67M9yj3GvcR92vehA9xB6V Hls9vvSEPYM8yz1HPC96wV7BXmqvrV6XvAneod5a71HvG0K6MEZYJ9wrnPLh+6T6dPiM+zz2dfEt 9N3ge9b3tV+QX5XfmN8tEUeULOoQHRN95+/pL/cf8b8awAhICGgLOBLwbaBXoDJwW+Cfg7hBaUGr gk4G/SM4JFgfvD/4QYhLSEnIeyE3xDxxhrhX/HkoITQ2tC3049AXYcFhhrCDYX8PF4ZXhu8Jv79A sEC5YGzB3QinCFnEjojJSCyyJPL9yMkoxyhZ1GjUN9HO0YrondH3YjxiKmL2xTyO9YvVx34U+0wS JlkmOR6HxCXGdcdNxHPic+OH479OcEpQJexNmEkMSmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5KXJZ9O oadkpwynfJPqmapPPZYGpyWnbUy7vdB1oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9ZoqyWrLPZ 3Ozi7D3ZT3Nic/pybuW65xpzT+Yx84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4WkwrzCnYWzi+MX b1o8XRRU1FV0fYlgScOSc0utl1Yt/aSYWSwrPlRCKMkv2VPygyxdNiqbLZWWvlc6I5fIN8sfKqIV A4oHyghlv/JeWURZf9l9VYRqo+pBeVT5YPkjtUQ9rP62Iqlie8WzyvTKDyt/rMqvOqAha0o0R7Uc baX2dLV9dUP1JZ2Xrks3WRNWs6lmRp+i31kL1S6pPWLg4T9TF4zuxpXGqbrIupG65/V59Yca2A3a hguNno1rGu81JTT9phltljefbHFsaW+ZWhazbEcr1FraerLNua2zbXp54vJd7dT2yvY/dfh19Hd8 vyJ/xbFOu87lnXdXJq7c22XWpe+6sSp81fbV6Gr16ok1AWu2rHndrej+osevZ7Dnh1557xdrRWuH 1v64rmzdRF9w37b1xPXa9dc3RG3Y1c/ub+q/uzFt4+EBbKB74PtNxZvODQYObt9M3WzcPDmU+k8A pAFb/pi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj 5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1 sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++ Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2 zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHa dtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG 6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5 OPnH+lf65/t3/Af8mP0p/br+S/7c/23//wIMAPeE8/sKDQplbmRzdHJlYW0NZW5kb2JqDTI4IDAg b2JqPDwvU3RlbVYgODgvRm9udE5hbWUvQXJpYWxNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdl aWdodCA0MDAvRmxhZ3MgMzIvRGVzY2VudCAtMjExL0ZvbnRCQm94Wy02NjUgLTMyNSAyMDAwIDEw MDZdL0FzY2VudCA5MDUvRm9udEZhbWlseShBcmlhbCkvQ2FwSGVpZ2h0IDcxOC9YSGVpZ2h0IDUx NS9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMjkgMCBvYmo8PC9T dGVtViAxMzgvRm9udE5hbWUvQXJpYWwsQm9sZC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdo dCA3MDAvRmxhZ3MgMzIvRGVzY2VudCAtMjExL0ZvbnRCQm94Wy02MjggLTM3NiAyMDAwIDEwMTBd L0FzY2VudCA5MDUvRm9udEZhbWlseShBcmlhbCkvQ2FwSGVpZ2h0IDAvVHlwZS9Gb250RGVzY3Jp cHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTMwIDAgb2JqPDwvT1BNIDEvT1AgZmFsc2Uvb3Ag ZmFsc2UvVHlwZS9FeHRHU3RhdGUvU0EgZmFsc2UvU00gMC4wMj4+DWVuZG9iag0xIDAgb2JqPDwv Rmlyc3QgMiAwIFIvQ291bnQgMS9MYXN0IDIgMCBSPj4NZW5kb2JqDTIgMCBvYmo8PC9QYXJlbnQg MSAwIFIvRGVzdFsyMiAwIFIvRml0XS9UaXRsZSj+/wBQAHUAYgBsAGkAYwAgAEUATgBVAE0AIABB AHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4AIABBAHIAYwBoAGkAdABlAGMAdAB1AHIAZQAgAGEA bgBkACAAUAByAG8AYwBlAHMAcyk+Pg1lbmRvYmoNMyAwIG9iajw8L0ZpcnN0IDc0L0xlbmd0aCA1 MTYvRmlsdGVyL0ZsYXRlRGVjb2RlL04gMTEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KeNq8VMtu2zAQ 5L0/scf2UC1Jk6JUBALsNkULPyrYTnsQfFBtwhWiSAYjB/bPp11SdhMfcgnQwrBI7Q52yJmBUuAg OCQxCAFCpvQHoRIQA5CcigqUMCA0aE39GIwmiIEkVSASSCVBqMClgqsrHPtRHOaYl8423dJZ68de Vmb20I3tEQTO29pOy52n9JDlcWdx0bn9OuDmbdtlmZ9aEAUBPG9YtF9WmEMo4wIXdt1DZ/u7+4L7 w3tEKH2nXuvwc7XdO4tLIh+1B/xUPeAX4nN11dzixD8Wv0ri73FZVtDNn8j+6RL/H6IViTEs6OE1 GNbVtsGPZIl1+A0n5bHdd/jDVV3VbKftxuLELX8G6NdmQzB4P+ARx+tmc3qPk8hosqt0Z4RRUSx1 lq0oB5zcEWd7csy3IIPJwZKhj45vkbMgYQAKNFC0gALlExSS6E0kD0gdn7/ET5McpPCDJIVTgdRA 8ZMGZAIy9Xk4pW9x8vIvKw7r7u3jb7Zklh1Yx4CNWEu7D7S7ZjN2w6bsDZtT957qNdsTpqJdQ9Wc Odo90PuG+o4qBa07+q0Ye9ff51LVoMnrRBUijoS8lFUPVMR7VYX2lzQvyDo+Rem5EKe8h35el2t7 RyNxVLfr26cTPjNVRWZwwd5XRjSjEDwcri/R9yCNEqPBSBNJszqfQL14gj8CDADakBliDQplbmRz dHJlYW0NZW5kb2JqDTQgMCBvYmo8PC9OdW1zWzAgNSAwIFJdPj4NZW5kb2JqDTUgMCBvYmo8PC9T L0Q+Pg1lbmRvYmoNNiAwIG9iajw8L0NvdW50IDEvVHlwZS9QYWdlcy9LaWRzWzIyIDAgUl0+Pg1l bmRvYmoNNyAwIG9iajw8L1N1YnR5cGUvWE1ML0xlbmd0aCA0MDQ1L1R5cGUvTWV0YWRhdGE+PnN0 cmVhbQ0KPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQi Pz4KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iMy4xLTcwMSI+ CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYt c3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAg ICAgIHhtbG5zOnBkZj0iaHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLyI+CiAgICAgICAgIDxw ZGY6UHJvZHVjZXI+QWNyb2JhdCBEaXN0aWxsZXIgNy4wLjUgKFdpbmRvd3MpPC9wZGY6UHJvZHVj ZXI+CiAgICAgICAgIDxwZGY6S2V5d29yZHMvPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAg ICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eGFwPSJo dHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHhhcDpDcmVhdG9yVG9vbD5B Y3JvYmF0IFBERk1ha2VyIDcuMC41IGZvciBQb3dlclBvaW50PC94YXA6Q3JlYXRvclRvb2w+CiAg ICAgICAgIDx4YXA6TW9kaWZ5RGF0ZT4yMDA2LTAyLTE2VDE1OjE2KzAxOjAwPC94YXA6TW9kaWZ5 RGF0ZT4KICAgICAgICAgPHhhcDpDcmVhdGVEYXRlPjIwMDYtMDItMTZUMTU6MTU6NTkrMDE6MDA8 L3hhcDpDcmVhdGVEYXRlPgogICAgICAgICA8eGFwOk1ldGFkYXRhRGF0ZT4yMDA2LTAyLTE2VDE1 OjE2KzAxOjAwPC94YXA6TWV0YWRhdGFEYXRlPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAg ICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBs aWNhdGlvbi9wZGY8L2RjOmZvcm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8 cmRmOkFsdD4KICAgICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5FTlVN IEF1dGhlbnRpY2F0aW9uIEFyY2hpdGVjdHVyZTwvcmRmOmxpPgogICAgICAgICAgICA8L3JkZjpB bHQ+CiAgICAgICAgIDwvZGM6dGl0bGU+CiAgICAgICAgIDxkYzpjcmVhdG9yPgogICAgICAgICAg ICA8cmRmOlNlcT4KICAgICAgICAgICAgICAgPHJkZjpsaT5Ub255IFJ1dGtvd3NraTwvcmRmOmxp PgogICAgICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAgIDwvZGM6Y3JlYXRvcj4KICAgICAgICAg PGRjOmRlc2NyaXB0aW9uPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAgICAgICAgICAgPHJk ZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ii8+CiAgICAgICAgICAgIDwvcmRmOkFsdD4KICAgICAg ICAgPC9kYzpkZXNjcmlwdGlvbj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnhhcE1NPSJodHRwOi8v bnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIj4KICAgICAgICAgPHhhcE1NOkRvY3VtZW50SUQ+dXVp ZDo0YjQxYWM5Ni04NGRiLTRkYTgtYWExYy00ZWI4OWFhNjIzOTM8L3hhcE1NOkRvY3VtZW50SUQ+ CiAgICAgICAgIDx4YXBNTTpJbnN0YW5jZUlEPnV1aWQ6N2EyMWM4MGEtMjlkYy00ZDlhLWExYjEt MzIwMWE5YTAxODU3PC94YXBNTTpJbnN0YW5jZUlEPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4K ICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6cGRm eD0iaHR0cDovL25zLmFkb2JlLmNvbS9wZGZ4LzEuMy8iPgogICAgICAgICA8cGRmeDpNYW5hZ2Vy Lz4KICAgICAgICAgPHBkZng6Q29tcGFueT5WZXJpU2lnbiwgSW5jLjwvcGRmeDpDb21wYW55Pgog ICAgICAgICA8cGRmeDpDb21tZW50cy8+CiAgICAgICAgIDxwZGZ4OkNhdGVnb3J5Lz4KICAgICAg PC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0i dyI/Pg0KZW5kc3RyZWFtDWVuZG9iag04IDAgb2JqPDwvQ3JlYXRpb25EYXRlKEQ6MjAwNjAyMTYx NTE1NTkrMDEnMDAnKS9TdWJqZWN0KCkvQXV0aG9yKFRvbnkgUnV0a293c2tpKS9DcmVhdG9yKEFj cm9iYXQgUERGTWFrZXIgNy4wLjUgZm9yIFBvd2VyUG9pbnQpL0tleXdvcmRzKCkvUHJvZHVjZXIo QWNyb2JhdCBEaXN0aWxsZXIgNy4wLjUgXChXaW5kb3dzXCkpL01vZERhdGUoRDoyMDA2MDIxNjE1 MTYwMCswMScwMCcpL0NvbXBhbnkoVmVyaVNpZ24sIEluYy4pL0NvbW1lbnRzKCkvTWFuYWdlcigp L0NhdGVnb3J5KCkvVGl0bGUoRU5VTSBBdXRoZW50aWNhdGlvbiBBcmNoaXRlY3R1cmUpPj4NZW5k b2JqDXhyZWYNCjAgMjANCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwNzc5OSAwMDAwMCBuDQow MDAwMDA3ODQ5IDAwMDAwIG4NCjAwMDAwMDgwMTAgMDAwMDAgbg0KMDAwMDAwODYyMCAwMDAwMCBu DQowMDAwMDA4NjUzIDAwMDAwIG4NCjAwMDAwMDg2NzYgMDAwMDAgbg0KMDAwMDAwODcyNyAwMDAw MCBuDQowMDAwMDEyODQ4IDAwMDAwIG4NCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQp0cmFpbGVyDQo8PC9TaXplIDIwPj4NCnN0YXJ0eHJlZg0KMTE2DQol JUVPRg0K --=====================_65015797==_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --=====================_65015797==_-- From enum-bounces@ietf.org Thu Feb 16 14:33:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9osQ-0005ef-Dc; Thu, 16 Feb 2006 14:33:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9osO-0005dU-Oy for enum@megatron.ietf.org; Thu, 16 Feb 2006 14:33:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24884 for ; Thu, 16 Feb 2006 14:31:29 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9p6c-0002Fo-7p for enum@ietf.org; Thu, 16 Feb 2006 14:48:02 -0500 Received: from [10.31.13.174] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1GJXJVt018857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2006 11:33:20 -0800 Message-ID: <43F4D354.4050909@shockey.us> Date: Thu, 16 Feb 2006 14:32:36 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6?= =?ISO-8859-1?Q?m?= Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] Reminder .. Agenda items for Dallas ... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I've received several requests already for slots but I'd like to firm up what to expect. so far I have. draft-ietf-enum-infrastructure-reqs-00.txt draft-shockey-enum-cnam-00.txt draft-reichinger-enum-foaf-00.txt draft-ietf-enum-enumservices-guide-00 ( forthcoming ) The Validation drafts are now going through NITS review to WGLC so I see no reason to discuss them further unless someone thinks its necessary. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 16 16:28:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qfS-0005l3-Lo; Thu, 16 Feb 2006 16:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qfR-0005jm-LU for enum@megatron.ietf.org; Thu, 16 Feb 2006 16:28:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11878 for ; Thu, 16 Feb 2006 16:26:13 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F9qtb-00045g-QW for enum@ietf.org; Thu, 16 Feb 2006 16:42:48 -0500 Content-class: urn:content-classes:message Subject: Re: [Enum] Reminder .. Agenda items for Dallas ... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Feb 2006 22:31:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4866@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Reminder .. Agenda items for Dallas ... Thread-Index: AcYzMJvZZ1WtwMKySJSCm7xQKPQHaAADs3xJ From: "Stastny Richard" To: "Richard Shockey" , , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Spam-Score: 0.8 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Michael and I will forward an up-issue of draft-haberler-carrier-eAfter the presentationsnum-02 next week and=20 request a slot =20 After the presentation of this draft also a discussion regarding the potential ways forward concerning Infrastructure ENUM in e164.arpa and potential involvement of IAB, RIPE and eventually ITU-T may=20 be useful. =20 I also propose to start immediate discussion of draft-ietf-enum-infrastructure-reqs-00.txt on the list to be eventually able to finalize this document before or at least during the IETF =20 regards Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Richard Shockey Gesendet: Do 16.02.2006 20:32 An: 'enum@ietf.org'; Patrik F=E4ltstr=F6m Betreff: [Enum] Reminder .. Agenda items for Dallas ... I've received several requests already for slots but I'd like to firm up what to expect. so far I have. draft-ietf-enum-infrastructure-reqs-00.txt draft-shockey-enum-cnam-00.txt draft-reichinger-enum-foaf-00.txt draft-ietf-enum-enumservices-guide-00 ( forthcoming ) The Validation drafts are now going through NITS review to WGLC so I see no reason to discuss them further unless someone thinks its necessary. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 16 16:40:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qrJ-0002jN-El; Thu, 16 Feb 2006 16:40:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qrI-0002ia-7n for enum@megatron.ietf.org; Thu, 16 Feb 2006 16:40:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13250 for ; Thu, 16 Feb 2006 16:38:27 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9r5Y-0004r1-Dn for enum@ietf.org; Thu, 16 Feb 2006 16:55:03 -0500 Received: from [10.31.13.174] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1GLeS0R002570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2006 13:40:29 -0800 Message-ID: <43F4F124.8060209@shockey.us> Date: Thu, 16 Feb 2006 16:39:48 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] Reminder .. Agenda items for Dallas ... References: <32755D354E6B65498C3BD9FD496C7D462C4866@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4866@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: > Michael and I will forward an up-issue of > draft-haberler-carrier-eAfter the presentationsnum-02 next week and > request a slot > > After the presentation of this draft also a discussion > regarding the potential ways forward concerning > Infrastructure ENUM in e164.arpa and potential > involvement of IAB, RIPE and eventually ITU-T may > be useful. OK ... so you need an hour and 1/2 ? :-) > > I also propose to start immediate discussion of > draft-ietf-enum-infrastructure-reqs-00.txt > on the list to be eventually able to finalize > this document before or at least during the IETF > > regards > Richard > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 16 16:50:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9r1I-0004tj-Co; Thu, 16 Feb 2006 16:50:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9r1H-0004tD-Lc for enum@megatron.ietf.org; Thu, 16 Feb 2006 16:50:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15000 for ; Thu, 16 Feb 2006 16:48:47 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F9rFX-0005on-Ee for enum@ietf.org; Thu, 16 Feb 2006 17:05:22 -0500 Content-class: urn:content-classes:message Subject: Re: [Enum] Reminder .. Agenda items for Dallas ... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Feb 2006 22:51:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C486B@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Reminder .. Agenda items for Dallas ... Thread-Index: AcYzQiJssSucM1PATpyzt462lWXNFQAAQ/4g From: "Stastny Richard" To: "Richard Shockey" X-Spam-Score: 0.8 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org ;-) Not really, we will only present the changes, which will not be so much: 10 min should be sufficient =20 It is up to you what you think we will need for the general discussion This also depends on the stability and unresloved issues of the = requirements draft =20 Richard ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Do 16.02.2006 22:39 An: Stastny Richard Cc: enum@ietf.org; Patrik F=E4ltstr=F6m Betreff: Re: [Enum] Reminder .. Agenda items for Dallas ... Stastny Richard wrote: > Michael and I will forward an up-issue of > draft-haberler-carrier-eAfter the presentationsnum-02 next week and > request a slot >=20 > After the presentation of this draft also a discussion > regarding the potential ways forward concerning > Infrastructure ENUM in e164.arpa and potential > involvement of IAB, RIPE and eventually ITU-T may > be useful. OK ... so you need an hour and 1/2 ? :-) >=20 > I also propose to start immediate discussion of > draft-ietf-enum-infrastructure-reqs-00.txt > on the list to be eventually able to finalize > this document before or at least during the IETF >=20 > regards > Richard > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 17 09:40:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6mL-0006YD-KA; Fri, 17 Feb 2006 09:40:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6kw-0005ao-6C for enum@megatron.ietf.org; Fri, 17 Feb 2006 09:38:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01131 for ; Fri, 17 Feb 2006 09:00:25 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA1U2-00034Q-Gc for enum@ietf.org; Fri, 17 Feb 2006 04:01:15 -0500 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Fri, 17 Feb 2006 09:46:01 +0100 id 0006C0B9.43F58D49.00003858 Message-ID: <43F58D2F.5080305@enum.at> Date: Fri, 17 Feb 2006 09:45:35 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Richard Shockey Subject: Re: [Enum] Reminder .. Agenda items for Dallas ... References: <43F4D354.4050909@shockey.us> In-Reply-To: <43F4D354.4050909@shockey.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: "'enum@ietf.org'" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6?= =?ISO-8859-1?Q?m?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard Shockey wrote: > > I've received several requests already for slots but I'd like to firm up > what to expect. > > so far I have. Please reserve 10 minutes for the upcoming draft draft-mayrhofer-enum-domainkeys-00 I hope i'll get it done early next week. cheers alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 17 09:51:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6xA-0002K6-2F; Fri, 17 Feb 2006 09:51:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6ul-00017g-3j for enum@megatron.ietf.org; Fri, 17 Feb 2006 09:48:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09357 for ; Fri, 17 Feb 2006 09:20:57 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9uAn-0003cG-Lc for enum@ietf.org; Thu, 16 Feb 2006 20:12:38 -0500 Received: from [10.31.13.177] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1H0wDak025703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2006 16:58:16 -0800 Message-ID: <43F51F7D.3040001@shockey.us> Date: Thu, 16 Feb 2006 19:57:33 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] Reminder .. Agenda items for Dallas ... References: <32755D354E6B65498C3BD9FD496C7D462C486B@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C486B@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id k1H0wDak025703 X-Spam-Score: 0.8 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: > ;-) >=20 > Not really, we will only present the changes, which will not be so much= : > 10 min should be sufficient Sure .. :-) > It is up to you what you think we will need for the general discussion > This also depends on the stability and unresloved issues of the require= ments draft My personal thinking is to put all other WG issues first on the agenda=20 and then leave the remainder of the alloted time to the Requirements=20 document and your proposal on next steps for Infrastructure. I think we are all well aware that one can present the changes in what=20 may or may not be the apex of Infrastructure ENUM in about 60 seconds=20 but the implications of that could be debated for the rest of the week. > =20 > Richard >=20 > ________________________________ >=20 > Von: Richard Shockey [mailto:richard@shockey.us] > Gesendet: Do 16.02.2006 22:39 > An: Stastny Richard > Cc: enum@ietf.org; Patrik F=E4ltstr=F6m > Betreff: Re: [Enum] Reminder .. Agenda items for Dallas ... >=20 >=20 >=20 > Stastny Richard wrote: >> Michael and I will forward an up-issue of >> draft-haberler-carrier-eAfter the presentationsnum-02 next week and >> request a slot >> >> After the presentation of this draft also a discussion >> regarding the potential ways forward concerning >> Infrastructure ENUM in e164.arpa and potential >> involvement of IAB, RIPE and eventually ITU-T may >> be useful. >=20 > OK ... so you need an hour and 1/2 ? :-) >=20 >> I also propose to start immediate discussion of >> draft-ietf-enum-infrastructure-reqs-00.txt >> on the list to be eventually able to finalize >> this document before or at least during the IETF >> >> regards >> Richard >> >=20 >=20 >=20 > -- >=20 >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Director - Member of Technical Staff > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > Fax: +1 815.333.1237 > or > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >=20 >=20 >=20 --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 17 10:27:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7Vn-0005tT-8R; Fri, 17 Feb 2006 10:27:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7Vl-0005st-Iu for enum@megatron.ietf.org; Fri, 17 Feb 2006 10:27:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24564 for ; Fri, 17 Feb 2006 10:25:20 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA7kB-0006oY-HK for enum@ietf.org; Fri, 17 Feb 2006 10:42:06 -0500 Received: from [10.31.32.171] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1HFROLm029175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Feb 2006 07:27:25 -0800 Message-ID: <43F5EB2B.9060900@shockey.us> Date: Fri, 17 Feb 2006 10:26:35 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Subject: [Enum] [Fwd: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org -------- Original Message -------- Subject: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA Date: Fri, 17 Feb 2006 00:00:01 -0500 From: ietf-secretariat@ietf.org To: ietf-announce@ietf.org There are two (2) Internet-Draft cutoff dates for the 65th IETF Meeting in Dallas, TX, USA: February 27th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, February 27th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, February 20th at 9:00 AM ET. March 6th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, March 6th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, March 20th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 65th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_65.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Feb 19 13:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAtZ7-0005ay-Cn; Sun, 19 Feb 2006 13:45:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAtZ6-0005at-Fw for enum@ietf.org; Sun, 19 Feb 2006 13:45:48 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAtZ2-0001TT-5J for enum@ietf.org; Sun, 19 Feb 2006 13:45:48 -0500 Received: from [192.168.1.206] (85-124-83-148.dynamic.xdsl-line.inode.at [::ffff:85.124.83.148]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Sun, 19 Feb 2006 19:45:39 +0100 id 0006C0B9.43F8BCD3.0000674B Message-ID: <43F8BCB7.4020309@enum.at> Date: Sun, 19 Feb 2006 19:45:11 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Enum] fyi - IETF65 enum session draft schedule X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org According to the draft agenda, the ENUM WG session is scheduled for monday morning. It collides with other sessions as follows: MONDAY, March 20, 2006 0800-1800 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Session I - 2.5 hour APP apparea Applications Area Open Meeting INT dna Detecting Network Attachment WG OPS netconf Network Configuration WG RAI enum Telephone Number Mapping WG RAI mmusic Multiparty Multimedia Session Control WG RTG mpls Multiprotocol Label Switching WG SEC krb-wg Kerberos WG So, we'll have a full week for followup discussions ;) cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 20 11:12:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBDdm-0008OP-Jc; Mon, 20 Feb 2006 11:11:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBDdS-0008Mi-3g for enum@ietf.org; Mon, 20 Feb 2006 11:11:38 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBDdQ-0003Ll-M4 for enum@ietf.org; Mon, 20 Feb 2006 11:11:38 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1KGC28R021127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Feb 2006 08:12:09 -0800 Message-ID: <43F9EA29.10009@shockey.us> Date: Mon, 20 Feb 2006 11:11:21 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Enum] Preliminary Agenda IETF 65 Dallas - ENUM WG IETF Meeting Materials page X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org http://www3.ietf.org/proceedings/06mar/agenda/enum.txt Keep me posted on additions and changes. In addition once again the chairs want copies of any presentation materials sent to us or the WG Secretary IN ADVANCE of the meeting. We will then use the WG Chairs Tools to post them to the Meeting Materials Page. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 21 04:24:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBTkj-0001bZ-9k; Tue, 21 Feb 2006 04:24:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBTki-0001bU-Gu for enum@ietf.org; Tue, 21 Feb 2006 04:24:12 -0500 Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FBTkf-00020U-DL for enum@ietf.org; Tue, 21 Feb 2006 04:24:12 -0500 Received: (eyou send program); Tue, 21 Feb 2006 17:23:59 +0800 Message-ID: <340513839.14945@cnnic.cn> X-EYOUMAIL-SMTPAUTH: chenhui@cnnic.cn Received: from unknown (HELO cnnicchenh) (159.226.6.99) by 159.226.7.151 with SMTP; Tue, 21 Feb 2006 17:23:59 +0800 Message-ID: <01a601c636c8$8ab33fc0$6306e29f@cnnicchenh> From: "chenhui" To: Date: Tue, 21 Feb 2006 17:23:57 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: =?gb2312?B?J831ILflJw==?= Subject: [Enum] ENUM toolbar for Firefox X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2112330040==" Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============2112330040== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A3_01C6370B.98B75F00" This is a multi-part message in MIME format. ------=_NextPart_000_01A3_01C6370B.98B75F00 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpIZXJlIGlzIGFuIEVOVU0gdG9vbGJhciBmb3IgRmlyZWZveCB2ZXJzaW9uIDEu NSsgZnJlZSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5lbnVtLmNuL0VudW0vRW51bVJlZy9FbnVt QmFyL2VudW1maXJlZm94dG9vbGJhcjEuMS54cGkgLg0KDQpUaGUgdG9vbGJhciBjYW4gYmUgdXNl ZCB0byByZXNvbHZlIGFueSByZWdpc3RlcmVkIEVOVU0gbnVtYmVycyB1bmRlciAnZTE2NC5hcnBh JyBkb21haW4gYW5kIHN1cHBvcnRzIHRoZSBsYXRlc3QgSUFOQSBSZWdpc3RyYXRpb25zIEVOVU1z ZXJ2aWNlLg0KDQpZb3UgY2FuIGdldCB0aGUgTkFQVFIgcmVjb3JkcyByZWxhdGl2ZSB0byB0aGUg RU5VTSBudW1iZXIsIGRpcmVjdGx5IGxpbmsgdG8gdGhlIGhpZ2hlc3QgcHJpb3JpdHkgd2VicGFn ZSBhbmQgc2VuZCBFbWFpbCB0byB0aGUgaGlnaGVzdCBwcmlvcml0eSBlbWFpbCBhZGRyZXNzIGV0 Yy4NCg0KV2VsY29tZSB0byB0ZXN0IGFuZCB1c2UuIElmIGFueSBwcm9ibGVtLCBQbGVhc2Ugc2Vu ZCBtYWlsIHRvIGVudW1AY25uaWMuY24uDQoNCkNoZW5odWk= ------=_NextPart_000_01A3_01C6370B.98B75F00 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI4MDIiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBzaXplPTM+SGkg QWxsLDxCUj48QlI+SGVyZSBpcyBhbiBFTlVNIHRvb2xiYXIgZm9yIA0KRmlyZWZveCB2ZXJzaW9u IDEuNSsgZnJlZSBhdmFpbGFibGUgYXQgPC9GT05UPjxBIGhyZWY9IiI+PEZPTlQgDQpzaXplPTM+ aHR0cDovL3d3dy5lbnVtLmNuL0VudW0vRW51bVJlZy9FbnVtQmFyL2VudW1maXJlZm94dG9vbGJh cjEuMS54cGk8L0ZPTlQ+PC9BPjxGT05UIA0Kc2l6ZT0zPiAuPEJSPjxCUj5UaGUgdG9vbGJhciBj YW4gYmUgdXNlZCB0byByZXNvbHZlIGFueSByZWdpc3RlcmVkIEVOVU0gbnVtYmVycyANCnVuZGVy ICdlMTY0LmFycGEnIGRvbWFpbiBhbmQgc3VwcG9ydHMgdGhlIGxhdGVzdCBJQU5BIFJlZ2lzdHJh dGlvbnMgDQpFTlVNc2VydmljZS48QlI+PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPjxGT05UIHNpemU9Mz5Zb3UgY2FuIGdldCB0aGUgTkFQVFIgcmVjb3JkcyZuYnNwO3Jl bGF0aXZlIHRvIA0KdGhlIEVOVU0gbnVtYmVyLCBkaXJlY3RseSBsaW5rIHRvIHRoZSBoaWdoZXN0 IHByaW9yaXR5IHdlYnBhZ2UgYW5kIHNlbmQgRW1haWwgdG8gDQp0aGUgaGlnaGVzdCBwcmlvcml0 eSBlbWFpbCBhZGRyZXNzIGV0Yy48QlI+PEJSPldlbGNvbWUgdG8gdGVzdCBhbmQgdXNlLiBJZiBh bnkgDQpwcm9ibGVtLCBQbGVhc2Ugc2VuZCBtYWlsIHRvIDwvRk9OVD48QSBocmVmPSIiPjxGT05U IA0Kc2l6ZT0zPmVudW1AY25uaWMuY248L0ZPTlQ+PC9BPjxGT05UIHNpemU9Mz4uPC9GT05UPjxC Uj48L0RJVj48L0ZPTlQ+DQo8RElWPjxGT05UIHNpemU9Mj5DaGVuaHVpPC9GT05UPjwvRElWPjwv Qk9EWT48L0hUTUw+DQo= ------=_NextPart_000_01A3_01C6370B.98B75F00-- --===============2112330040== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============2112330040==-- From enum-bounces@ietf.org Tue Feb 21 09:30:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBYWc-0000VV-69; Tue, 21 Feb 2006 09:29:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBYWa-0000VN-Hq for enum@ietf.org; Tue, 21 Feb 2006 09:29:56 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBYWa-0004U7-4w for enum@ietf.org; Tue, 21 Feb 2006 09:29:56 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id BED0C1A487; Tue, 21 Feb 2006 15:29:53 +0100 (CET) Date: Tue, 21 Feb 2006 15:29:53 +0100 From: Otmar Lendl To: Tony Rutkowski Message-ID: <20060221142953.GG5755@nic.at> References: <20060208174811.GA6329@nic.at> <7.0.1.0.2.20060216150317.02a9df20@verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20060216150317.02a9df20@verisign.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: enum@ietf.org Subject: [Enum] Re: draft-ietf-enum-validation-token-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Tony, On 2006/02/16 15:02, Tony Rutkowski wrote: > > Your very useful token contribution can be > usefully implemented within what seems the > universal global architecture and process > requirement for public ENUM. > > Whoever is running the ENUM EPP bluebox > will generally require four tokens. Thank you for sharing your Authentication Architecture diagram. Some comments/questions: * Is this for User-ENUM? * As I read the diagram, you plan to hold NAPTR records in your Tier1(b) registry. You don't plan to do "normal" delegations based on NS records? * You're planning to use the data from the ENUM validation to feed the E.115 DBs? Here in .at we had long discussions about that as well, and we decided against it. In our model, a new ENUM delegations contains o The ENUM Token which documents the ownership of the number and optionally o a domain/number owner contact object which can be set by the registrar. If we were to feed our data into a directory assistance DB, we'd use the contact object and not the info from the Token. For private persons that distinction may be unnecessary. For companies this can be an essential feature. E.g. if the numbers of all branch offices are managed from the headquarter: Validation is done through them, but you still want the local address in the phonebook. Or consider a holding with various brands. * I have some difficulties understanding the roles on the left side of your diagram. Could you elaborate a bit on them? * Concerning the Token from the "E.164 Service Subscriber": Is that one digitally signed? If yes, you need some sort of PKI. Who will act as the CA in that system? * About the "referenced service provider": Are you sure you need a proactive agreement from that role? Nobody is doing that in the email space. I can point my MX records to whomever I want to. I can install email forwards without permission from the destination. I can do SIP redirects without a token from the destination. How much will this also introduce restriction on the SIP service hosters? Can a Texan use a SIP provider based in Australia which doesn't know a thing about your system? My plan was to get the token draft into WGLC as soon as possible as all changes in the last 6 months were mostly cosmentic. I'd really like to accomodate any changes you might need. So: what are your requirements for the Token specs? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 21 10:37:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZaA-0004uq-32; Tue, 21 Feb 2006 10:37:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZa8-0004uj-Eo for enum@ietf.org; Tue, 21 Feb 2006 10:37:40 -0500 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBZa8-0000KM-8B for enum@ietf.org; Tue, 21 Feb 2006 10:37:40 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.13.4) with ESMTP id k1LFhrIl019773; Tue, 21 Feb 2006 10:43:53 -0500 Received: from trutkowski-desk.verisign.com ([10.169.64.229]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Feb 2006 10:37:39 -0500 Message-Id: <7.0.1.0.2.20060221101423.036997a8@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 21 Feb 2006 10:37:38 -0500 To: Otmar Lendl From: Tony Rutkowski In-Reply-To: <20060221142953.GG5755@nic.at> References: <20060208174811.GA6329@nic.at> <7.0.1.0.2.20060216150317.02a9df20@verisign.com> <20060221142953.GG5755@nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Feb 2006 15:37:39.0357 (UTC) FILETIME=[BF2B1CD0:01C636FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: enum@ietf.org Subject: [Enum] Re: draft-ietf-enum-validation-token-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Otmar, >Thank you for sharing your Authentication Architecture diagram. >Some comments/questions: > >* Is this for User-ENUM? The relationships are applicable wherever an E.164 number is used in providing services to the public. Thus it would apply to most of the various ENUM categories. >* As I read the diagram, you plan to hold NAPTR records in your > Tier1(b) registry. You don't plan to do "normal" delegations > based on NS records? My apologies for the confusion. The architecture was intended to apply at all registry tiers, although for the upper tiers, some token functions would be null. There was no intent in the diagram to constrain the hierarchical structures. I should also underscore that this is just a "thought piece" based on an array of current developments in different industry, security, justice, and regulatory forums worldwide. >* You're planning to use the data from the ENUM validation to > feed the E.115 DBs? Yes. This would be necessary, for example, where E.164 number blocks are allocated directly to ISPs. It also gets a little tricky with number portability. You need some kind of authoritative E.164 directory and arguably the protocol of choice is E.115v2 because of its nice feature set and span of legacy and IP/NGN platforms. > decided against it. In our model, a new ENUM delegations contains > o The ENUM Token which documents the ownership of the number > and optionally > o a domain/number owner contact object which can be set by the registrar. > If we were to feed our data into a directory assistance DB, we'd > use the contact object and not the info from the Token. I think you could do it either way, as long as the necessary contractual agreements were put in place, and it was acceptable by national authorities (regulatory, justice, security), including telecom operators. :-) >* I have some difficulties understanding the roles on the left side > of your diagram. Could you elaborate a bit on them? You raise good questions, and I owe more narrative on the diagram. Again, it was largely to sort out options for your very attractive token approach. > Nobody is doing that in the email space. I can point my MX records > to whomever I want to. I can install email forwards without > permission from the destination. I can do SIP redirects without > a token from the destination. The new European Union Data Retention Directive will likely alter the practices. > How much will this also introduce restriction on the SIP service > hosters? Can a Texan use a SIP provider based in Australia which > doesn't know a thing about your system? I raised this issue in my presentation on the Directive at ETSI three weeks ago. >So: what are your requirements for the Token specs? Forthcoming... --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 21 18:33:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBh0y-0002Iz-EW; Tue, 21 Feb 2006 18:33:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBh0w-0002Io-Ru for enum@ietf.org; Tue, 21 Feb 2006 18:33:51 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FBh0u-00083f-Ea for enum@ietf.org; Tue, 21 Feb 2006 18:33:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] ENUM toolbar for Firefox Date: Wed, 22 Feb 2006 00:37:45 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4886@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] ENUM toolbar for Firefox Thread-Index: AcY2yWSf4vIoDvh4SSiW9PpfuZhh3wAdCD4R From: "Stastny Richard" To: "chenhui" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ? ? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Chenhui, folks, =20 I tried your toolbar, nice tool, but it curiously does not work for all = numbers. =20 BTW, I would like to point to the webpage of our esteemed secretary http://nona.net/features/enum/ =20 This page offers an ENUM query and also a possibility to integrate an ENUM query in the firefox searchbar (which I consider more elegant, because it is not using up toolbar space) =20 Both queries use a similar approach to the multithreaded query and xml = response from SIPBroker.com: =20 http://www.sipbroker.com/sipbroker/action/enumService?number=3D4319793321= showing responses from multiple trees =20 regards =20 Richard ________________________________ Von: chenhui [mailto:chenhui@cnnic.cn] Gesendet: Di 21.02.2006 10:23 An: enum@ietf.org Cc: '? ?' Betreff: [Enum] ENUM toolbar for Firefox Hi All, Here is an ENUM toolbar for Firefox version 1.5+ free available at = http://www.enum.cn/Enum/EnumReg/EnumBar/enumfirefoxtoolbar1.1.xpi . The toolbar can be used to resolve any registered ENUM numbers under = 'e164.arpa' domain and supports the latest IANA Registrations = ENUMservice. You can get the NAPTR records relative to the ENUM number, directly link = to the highest priority webpage and send Email to the highest priority = email address etc. Welcome to test and use. If any problem, Please send mail to = enum@cnnic.cn. Chenhui _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 22 15:50:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0w8-00056L-1t; Wed, 22 Feb 2006 15:50:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0vz-00051Z-9h; Wed, 22 Feb 2006 15:50:03 -0500 Received: from [156.154.16.129] (helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0vy-00070d-Fy; Wed, 22 Feb 2006 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1MKo20e014627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FC0vy-0004Qe-0K; Wed, 22 Feb 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Feb 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-iax-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for IAX Enumservice Author(s) : E. Guy Filename : draft-ietf-enum-iax-00.txt Pages : 13 Date : 2006-2-22 This document registers the IAX2 (Inter-Asterisk eXchange Version 2) Enumservice using the URI scheme 'iax2:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-iax-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-iax-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-iax-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: <2006-2-22130222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-iax-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-iax-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-22130222.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Wed Feb 22 20:58:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC5kf-0001N1-8Q; Wed, 22 Feb 2006 20:58:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC5kd-0001Mt-MX for enum@ietf.org; Wed, 22 Feb 2006 20:58:39 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC5kc-0007YL-99 for enum@ietf.org; Wed, 22 Feb 2006 20:58:39 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1N1x7sk013865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Feb 2006 17:59:10 -0800 Message-ID: <43FD16C4.9050203@shockey.us> Date: Wed, 22 Feb 2006 20:58:28 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------060200080600080409080007" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [Enum] [Fwd: I-D ACTION:draft-mahy-enum-im-service-00.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------060200080600080409080007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-mahy-enum-im-service-00.txt Date: Wed, 22 Feb 2006 15:50:02 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services Author(s) : R. Mahy Filename : draft-mahy-enum-im-service-00.txt Pages : 5 Date : 2006-2-22 This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning im: URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-enum-im-service-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mahy-enum-im-service-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-mahy-enum-im-service-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. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------060200080600080409080007 Content-Type: Message/External-body; name="draft-mahy-enum-im-service-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-mahy-enum-im-service-00.txt" Content-Type: text/plain Content-ID: <2006-2-22134223.I-D@ietf.org> --------------060200080600080409080007 Content-Type: text/plain; name*0="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------060200080600080409080007 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------060200080600080409080007-- From enum-bounces@ietf.org Thu Feb 23 04:01:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCCM1-0004BJ-CK; Thu, 23 Feb 2006 04:01:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCCM0-0004BB-DE for enum@ietf.org; Thu, 23 Feb 2006 04:01:40 -0500 Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCCLz-00082T-1f for enum@ietf.org; Thu, 23 Feb 2006 04:01:40 -0500 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1FCCLx-0004nf-00; Thu, 23 Feb 2006 10:01:37 +0100 Date: Thu, 23 Feb 2006 10:01:33 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: enum@ietf.org In-Reply-To: <43FD16C4.9050203@shockey.us> Message-ID: References: <43FD16C4.9050203@shockey.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: rohan@ekabal.com Subject: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Rohan! I had exactly the same idea mapping E.164 numbers to IM addresses and was about to write up an I-D about this... One of my motivations for having such a mechanism in place is to help in keeping track of all different IM Identities (Jabber, AIM, ICQ, MSN, SIMPLE, ...) a person is using. Especially useful this can be for all-in-one clients, such as Gaim (type in E.164 number, get all IM IDs of your buddy). Another area this could be used is Instant Messaging on Mobile Phones, where you anyway have the E.164 number as main identifier. What is not so clear to me is, whether for privacy reasons this should be rather done by means of RFC 3953 (indirection), i.e. provide an IM-URI (or even re-use the presence URI), where the details (the actual IM Identities) can be fetched from. So there would be some means of access control in place, unlike in the DNS. What do you think about? cheers, Bernie > -------- Original Message -------- > Subject: I-D ACTION:draft-mahy-enum-im-service-00.txt > Date: Wed, 22 Feb 2006 15:50:02 -0500 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A Telephone Number Mapping (ENUM) Service > Registration for Instant Messaging (IM) Services > > Author(s) : R. Mahy > Filename : draft-mahy-enum-im-service-00.txt > Pages : 5 > Date : 2006-2-22 > This document registers a Telephone Number Mapping (ENUM) service for > Instant Messaging (IM). Specifically, this document focuses on > provisioning im: URIs in ENUM. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mahy-enum-im-service-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-mahy-enum-im-service-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-mahy-enum-im-service-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. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 23 18:38:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQ2b-0000AT-DJ; Thu, 23 Feb 2006 18:38:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQ2a-00008t-Je for enum@ietf.org; Thu, 23 Feb 2006 18:38:32 -0500 Received: from [213.152.49.123] (helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCQ2Z-0002QB-PV for enum@ietf.org; Thu, 23 Feb 2006 18:38:32 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 0B29C7D844; Thu, 23 Feb 2006 23:38:27 +0000 (GMT) In-Reply-To: References: <43FD16C4.9050203@shockey.us> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <745C2A73-3F6F-4C79-9D19-9EF6A8022AFE@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt Date: Thu, 23 Feb 2006 23:38:26 +0000 To: Bernie Hoeneisen X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: enum@ietf.org, rohan@ekabal.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Bernie, Rohan, folks, first - I've looked at Rohan's draft - good stuff, and exactly what I had in mind. (it's succinct and to the point, so probably better than I had in mind :). Bernie - I think that RFC 3953 is about as indirect as one can get without looking out at the back of one's head. However, a whole authenticated exchange with a "presence protocol" before a client can find out *if* there is an appropriate IM cloud (i.e. one in which he or she has an account that can be used to send an IM, and in which the registrant has an account) is a long long long route. It's also one that requires a end user to have a program that supports that presence protocol as well as the IM one he or she ends up using (if they eventually find that a matching one exists). There's definitely room for another draft to cover the steps in that indirect exchange as it would cover quite a different use case, but please not this one. If a registrant has an AIM ID, it doesn't mean that I as a client can send an IM, even *if* I have Adium running on my machine. The security section in Rohan's draft spells that out nicely. I like Rohan's draft as it is, and hope that it can progress quickly on the standard track. It's certainly going to be in a race with reality. (we have been using X-IM, but will be happy to change). all the best, Lawrence On 23 Feb 2006, at 09:01, Bernie Hoeneisen wrote: > Hi Rohan! > > I had exactly the same idea mapping E.164 numbers to IM addresses > and was about to write up an I-D about this... > > One of my motivations for having such a mechanism in place > is to help in keeping track of all different IM Identities (Jabber, > AIM, ICQ, MSN, SIMPLE, ...) a person is using. Especially useful > this can be for all-in-one clients, such as Gaim (type in E.164 > number, get all IM IDs of your buddy). > > Another area this could be used is Instant Messaging on Mobile > Phones, where you anyway have the E.164 number as main identifier. > > What is not so clear to me is, whether for privacy reasons this > should be rather done by means of RFC 3953 (indirection), i.e. > provide an IM-URI (or even re-use the presence URI), where the > details (the actual IM Identities) can be fetched from. So there > would be some means of access control in place, unlike in the DNS. > > What do you think about? > > cheers, > Bernie > > >> -------- Original Message -------- >> Subject: I-D ACTION:draft-mahy-enum-im-service-00.txt >> Date: Wed, 22 Feb 2006 15:50:02 -0500 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : A Telephone Number Mapping (ENUM) Service Registration >> for Instant Messaging (IM) Services >> >> Author(s) : R. Mahy >> Filename : draft-mahy-enum-im-service-00.txt >> Pages : 5 >> Date : 2006-2-22 >> This document registers a Telephone Number Mapping (ENUM) service >> for >> Instant Messaging (IM). Specifically, this document focuses on >> provisioning im: URIs in ENUM. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-mahy-enum-im-service-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> >> 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-mahy-enum-im-service-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-mahy-enum-im-service-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. > > _______________________________________________ > 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 enum-bounces@ietf.org Thu Feb 23 18:50:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQE6-00078B-5k; Thu, 23 Feb 2006 18:50:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQDj-0006Fn-4m; Thu, 23 Feb 2006 18:50:03 -0500 Received: from [156.154.16.129] (helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCQDi-0002aS-Ln; Thu, 23 Feb 2006 18:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1NNo20e029089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FCQDi-0001Q0-7K; Thu, 23 Feb 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 23 Feb 2006 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-arch-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-ietf-enum-validation-arch-02.txt Pages : 18 Date : 2006-2-23 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-validation-arch-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-enum-validation-arch-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. --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: <2006-2-23164514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-validation-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-validation-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-23164514.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Thu Feb 23 20:38:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCRu1-0002qg-J0; Thu, 23 Feb 2006 20:37:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCRu0-0002qV-9d for enum@ietf.org; Thu, 23 Feb 2006 20:37:48 -0500 Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FCRtw-0006hr-MV for enum@ietf.org; Thu, 23 Feb 2006 20:37:48 -0500 Received: (eyou send program); Fri, 24 Feb 2006 09:37:28 +0800 Message-ID: <340745048.28264@cnnic.cn> X-EYOUMAIL-SMTPAUTH: chenhui@cnnic.cn Received: from unknown (HELO cnnicchenh) (159.226.6.99) by 159.226.7.151 with SMTP; Fri, 24 Feb 2006 09:37:28 +0800 Message-ID: <006c01c638e2$e5315e20$6306e29f@cnnicchenh> From: "chenhui" To: References: <43FD16C4.9050203@shockey.us> <340698409.05165@cnnic.cn> Subject: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt Date: Fri, 24 Feb 2006 09:37:38 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1206649556==" Errors-To: enum-bounces@ietf.org --===============1206649556== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGkgUm9oYW4sDQoNClRoZSBkcmFmdCBpcyBhIGdyZWF0IHByb2dyZXNzIHRvIHB1c2ggRU5VTSBJ TSBzZXJ2aWNlLg0KDQpXZSBoYXZlIGFsc28gYmVlbiBjb25zaWRlcmluZyB0aGUgRU5VTS1JTSBz ZXJ2aWNlIGFuZCBkZXZlbG9waW5nIHNvbWUgRU5VTS1JTSBhcHBsaWNhdGlvbi4NCkFzIHdlIGtu b3csIHRoZXJlIGFyZSBzbyBtYW55IGtpbmRzIG9mIElNIGNsaWVudHMgYW5kIGRpZmZlcmVudCBJ TSBwcm90b2NvbHMsIHNvIGhvdyB0byBpbnRlcmNvbW11bmljYXRpb24gYmV0d2VlbiBkaWZmZXJl bnQgY2xpZW50cyBpcyBhIHByb2JsZW0uDQoNCiJTZXJ2aWNlIFR5cGUiIGZpZWxkIGlzIHVzZWQg dG8gbWFyayB0aGUgcmVnaXN0cmF0aW9uIG9mIElNIHNlcnZpY2UsIGJ1dCBpdCBzZWVtcyBsaW1p dGVkIHRvIHByZXNlbnQgdGhlIGluZm9ybWF0aW9uIG9mIElNLiBUaGVyZWZvcmUsIHdlIHN1Z2dl c3QgdG8gYWRkIHRoZSAic3VidHlwZSIgZmllbGQuIA0KDQpSZWdhcmRzIQ0KQ2hlbmh1aQ0KDQo+ PiAtLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQo+PiBTdWJqZWN0OiBJLUQgQUNU SU9OOmRyYWZ0LW1haHktZW51bS1pbS1zZXJ2aWNlLTAwLnR4dA0KPj4gRGF0ZTogV2VkLCAyMiBG ZWIgMjAwNiAxNTo1MDowMiAtMDUwMA0KPj4gRnJvbTogSW50ZXJuZXQtRHJhZnRzQGlldGYub3Jn DQo+PiBSZXBseS1UbzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+PiBUbzogaS1kLWFubm91 bmNlQGlldGYub3JnDQo+Pg0KPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy b20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KPj4gZGlyZWN0b3JpZXMuDQo+Pg0KPj4N Cj4+IFRpdGxlIDogQSBUZWxlcGhvbmUgTnVtYmVyIE1hcHBpbmcgKEVOVU0pIFNlcnZpY2UgDQo+ PiBSZWdpc3RyYXRpb24gZm9yIEluc3RhbnQgTWVzc2FnaW5nIChJTSkgU2VydmljZXMNCj4+DQo+ PiBBdXRob3IocykgOiBSLiBNYWh5DQo+PiBGaWxlbmFtZSA6IGRyYWZ0LW1haHktZW51bS1pbS1z ZXJ2aWNlLTAwLnR4dA0KPj4gUGFnZXMgOiA1DQo+PiBEYXRlIDogMjAwNi0yLTIyDQo+PiBUaGlz IGRvY3VtZW50IHJlZ2lzdGVycyBhIFRlbGVwaG9uZSBOdW1iZXIgTWFwcGluZyAoRU5VTSkgc2Vy dmljZSBmb3INCj4+IEluc3RhbnQgTWVzc2FnaW5nIChJTSkuICBTcGVjaWZpY2FsbHksIHRoaXMg ZG9jdW1lbnQgZm9jdXNlcyBvbg0KPj4gcHJvdmlzaW9uaW5nIGltOiBVUklzIGluIEVOVU0uDQo+ Pg0KPj4NCj4+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPj4gaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWFoeS1lbnVtLWltLXNlcnZpY2UtMDAu dHh0DQo+Pg0KPj4gVG8gcmVtb3ZlIHlvdXJzZWxmIGZyb20gdGhlIEktRCBBbm5vdW5jZW1lbnQg bGlzdCwgc2VuZCBhIG1lc3NhZ2UgdG8NCj4+IGktZC1hbm5vdW5jZS1yZXF1ZXN0QGlldGYub3Jn IHdpdGggdGhlIHdvcmQgdW5zdWJzY3JpYmUgaW4gdGhlIGJvZHkgb2YgdGhlIA0KPj4gbWVzc2Fn ZS4NCj4+IFlvdSBjYW4gYWxzbyB2aXNpdCBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9JLUQtYW5ub3VuY2UNCj4+IHRvIGNoYW5nZSB5b3VyIHN1YnNjcmlwdGlvbiBzZXR0 aW5ncy4NCj4+DQo+Pg0KPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQLiBMb2dpbiB3aXRoIHRoZSB1c2VybmFtZQ0KPj4gImFub255bW91cyIgYW5k IGEgcGFzc3dvcmQgb2YgeW91ciBlLW1haWwgYWRkcmVzcy4gQWZ0ZXIgbG9nZ2luZyBpbiwNCj4+ IHR5cGUgImNkIGludGVybmV0LWRyYWZ0cyIgYW5kIHRoZW4NCj4+ICJnZXQgZHJhZnQtbWFoeS1l bnVtLWltLXNlcnZpY2UtMDAudHh0Ii4NCj4+DQo+PiBBIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnRz IGRpcmVjdG9yaWVzIGNhbiBiZSBmb3VuZCBpbg0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFk b3cuaHRtbA0KPj4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQN Cj4+DQo+Pg0KPj4gSW50ZXJuZXQtRHJhZnRzIGNhbiBhbHNvIGJlIG9idGFpbmVkIGJ5IGUtbWFp bC4NCj4+DQo+PiBTZW5kIGEgbWVzc2FnZSB0bzoNCj4+IG1haWxzZXJ2QGlldGYub3JnLg0KPj4g SW4gdGhlIGJvZHkgdHlwZToNCj4+ICJGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWFoeS1l bnVtLWltLXNlcnZpY2UtMDAudHh0Ii4NCj4+IE5PVEU6IFRoZSBtYWlsIHNlcnZlciBhdCBpZXRm Lm9yZyBjYW4gcmV0dXJuIHRoZSBkb2N1bWVudCBpbg0KPj4gTUlNRS1lbmNvZGVkIGZvcm0gYnkg dXNpbmcgdGhlICJtcGFjayIgdXRpbGl0eS4gIFRvIHVzZSB0aGlzDQo+PiBmZWF0dXJlLCBpbnNl cnQgdGhlIGNvbW1hbmQgIkVOQ09ESU5HIG1pbWUiIGJlZm9yZSB0aGUgIkZJTEUiDQo+PiBjb21t YW5kLiAgVG8gZGVjb2RlIHRoZSByZXNwb25zZShzKSwgeW91IHdpbGwgbmVlZCAibXVucGFjayIg b3INCj4+IGEgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXIuICBEaWZmZXJlbnQgTUlNRS1jb21w bGlhbnQgbWFpbCByZWFkZXJzDQo+PiBleGhpYml0IGRpZmZlcmVudCBiZWhhdmlvciwgZXNwZWNp YWxseSB3aGVuIGRlYWxpbmcgd2l0aA0KPj4gIm11bHRpcGFydCIgTUlNRSBtZXNzYWdlcyAoaS5l LiBkb2N1bWVudHMgd2hpY2ggaGF2ZSBiZWVuIHNwbGl0DQo+PiB1cCBpbnRvIG11bHRpcGxlIG1l c3NhZ2VzKSwgc28gY2hlY2sgeW91ciBsb2NhbCBkb2N1bWVudGF0aW9uIG9uDQo+PiBob3cgdG8g bWFuaXB1bGF0ZSB0aGVzZSBtZXNzYWdlcy4NCj4+IEJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdp bGwgZW5hYmxlIGEgTUlNRSANCj4+IGNvbXBsaWFudCBtYWlsIHJlYWRlcg0KPj4gaW1wbGVtZW50 YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGUN Cj4+IEludGVybmV0LURyYWZ0Lg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gZW51bSBtYWlsaW5nIGxpc3QNCj4gZW51bUBpZXRmLm9yZw0K PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbnVtDQo+ --===============1206649556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1206649556==-- From enum-bounces@ietf.org Thu Feb 23 20:55:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCSBG-0000ac-9g; Thu, 23 Feb 2006 20:55:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCSBE-0000aQ-Ng for enum@ietf.org; Thu, 23 Feb 2006 20:55:36 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCSBD-0007Av-AI for enum@ietf.org; Thu, 23 Feb 2006 20:55:36 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1O1u14H020837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Feb 2006 17:56:03 -0800 Message-ID: <43FE678B.4030809@shockey.us> Date: Thu, 23 Feb 2006 20:55:23 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [Enum] [Fwd: I-D ACTION:draft-mayrhofer-enum-domainkeys-00.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org -------- Original Message -------- Subject: I-D ACTION:draft-mayrhofer-enum-domainkeys-00.txt Date: Thu, 23 Feb 2006 18:50:02 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Telephone Number Mapping and Domain Keys as a Distributed Identity Infrastructure Author(s) : A. Mayrhofer Filename : draft-mayrhofer-enum-domainkeys-00.txt Pages : 10 Date : 2006-2-23 This document creates a decentralized indentity infrastructure by combining technology from E.164 Number Mapping (ENUM) and DomainKeys Identified Mail (DKIM). This infrastructure uses E.164 numbers as identities, ENUM DNS for key distribution, and leverages the trust relations from ENUM validation to actual messages signed by the number holder. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-domainkeys-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mayrhofer-enum-domainkeys-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-mayrhofer-enum-domainkeys-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. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 23 20:58:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCSEJ-0002hA-NS; Thu, 23 Feb 2006 20:58:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCSEI-0002h2-Ce for enum@ietf.org; Thu, 23 Feb 2006 20:58:46 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCSEH-0007GZ-Vg for enum@ietf.org; Thu, 23 Feb 2006 20:58:46 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1O1xGsA021270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Feb 2006 17:59:17 -0800 Message-ID: <43FE684E.3080401@shockey.us> Date: Thu, 23 Feb 2006 20:58:38 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Enum] [Fwd: I-D ACTION:draft-mahy-enum-calendar-service-00.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org -------- Original Message -------- Subject: I-D ACTION:draft-mahy-enum-calendar-service-00.txt Date: Thu, 23 Feb 2006 18:50:02 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services Author(s) : R. Mahy Filename : draft-mahy-enum-calendar-service-00.txt Pages : 5 Date : 2006-2-23 This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning mailto: (iMIP) and http: (CalDAV) URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-enum-calendar-service-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mahy-enum-calendar-service-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-mahy-enum-calendar-service-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. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 23 21:09:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCSOG-0001LE-8P; Thu, 23 Feb 2006 21:09:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCSOE-0001KC-E9 for enum@ietf.org; Thu, 23 Feb 2006 21:09:02 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCSOD-0007gV-0E for enum@ietf.org; Thu, 23 Feb 2006 21:09:02 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1O29Z12022618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Feb 2006 18:09:36 -0800 Message-ID: <43FE6AB9.9070700@shockey.us> Date: Thu, 23 Feb 2006 21:08:57 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'enum@ietf.org'" Subject: [Enum] Updated Preliminary Agenda IETF 65 Dallas - ENUM WG IETF Meeting Materials page Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org http://www3.ietf.org/proceedings/06mar/agenda/enum.txt Keep me posted on additions and changes. Its starting to seem we will use the full 2 1/2 hours. Once again the chairs want copies of any presentation materials sent to us or the WG Secretary IN ADVANCE of the meeting. The sooner you give us your powerpoints the better. I know that is a stretch but every little bit helps us in our administrative duties. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 24 06:13:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCasd-0001oL-37; Fri, 24 Feb 2006 06:12:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCasc-0001nq-89 for enum@ietf.org; Fri, 24 Feb 2006 06:12:58 -0500 Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCasa-0007J6-Vi for enum@ietf.org; Fri, 24 Feb 2006 06:12:58 -0500 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1FCasZ-0005Nn-00; Fri, 24 Feb 2006 12:12:55 +0100 Date: Fri, 24 Feb 2006 12:12:50 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: lconroy Subject: Re: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt In-Reply-To: <745C2A73-3F6F-4C79-9D19-9EF6A8022AFE@insensate.co.uk> Message-ID: References: <43FD16C4.9050203@shockey.us> <745C2A73-3F6F-4C79-9D19-9EF6A8022AFE@insensate.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: enum@ietf.org, rohan@ekabal.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Lawrence On Thu, 23 Feb 2006, lconroy wrote: > Bernie - I think that RFC 3953 is about as indirect as one can get > without looking out at the back of one's head. I had not doubt about RFC 3953 and indirection, but kind of misunderstood the proposed mechanism in Rohan's I-D. After Rohan has clarified the intension of his draft, I am aware of my misunderstanding, so the issue can be settled. > I like Rohan's draft as it is, and hope that it can progress quickly on > the standard track. It's certainly going to be in a race with reality. > (we have been using X-IM, but will be happy to change). I also like Rohan's draft. However I see room for adding further clarifications. I will think about and make concrete proposals at some later time. cheers, Bernie _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 24 08:31:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCd28-0003Gz-Om; Fri, 24 Feb 2006 08:30:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCd27-0003Gu-FY for enum@ietf.org; Fri, 24 Feb 2006 08:30:55 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FCd25-0002jz-LM for enum@ietf.org; Fri, 24 Feb 2006 08:30:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Feb 2006 14:34:37 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4DC7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 4415 IANA Registration for Enumservice voice Thread-Index: AcY5Rw5V2iG5IhFYQzWjtrTfSBhvOQ== From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Enum] RFC 4415 IANA Registration for Enumservice voice X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Folks, I am not sure if I missed the official announcement or if it was not made yet, but RFC 4415 is available since some time: http://www.ietf.org/rfc/rfc4415.txt Abstract This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in the ENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call. Regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 24 09:23:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCdqg-0001Yr-QJ; Fri, 24 Feb 2006 09:23:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCdqe-0001Yg-VO for enum@ietf.org; Fri, 24 Feb 2006 09:23:08 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FCdqd-0004Uz-IK for enum@ietf.org; Fri, 24 Feb 2006 09:23:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Feb 2006 15:27:03 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4DCB@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: General question on Enumservices Thread-Index: AcY5TmHYXgYCZShoTJ2fQcq69q+l2g== From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Enum] General question on Enumservices X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Folks, I have a general question concerning Enumservices Considering the bunch of the different Enumservices popping up recently I ask myself if we are not overdoing it On one hand a lot of people seem to have very creative ideas on what kind information one may link to a communication identifier such as an E.164 number So we are back to the original idea of the electronic business card. Bernie mentioned in context with the IM service that one my put all is Yahoo, aol, icq, jabber etc ID into ENUM and somebody else may try to find out which is matching his service. If I add now to this the webpage, email, vcard, calendar, eventually the old idea we had in TS 102 172 with=20 location (loc), and the public KEY (eh domainkey?), ... I see ENUM domains coming up with 20 and more entries. Most of this information could be put into vcard If not, we may consider one or two general pointers containing all the required information, e.g. publicinfo and privateinfo and define the template This would allow on one hand sceened access with policies and on the other hand more flexibility in data provisioning Thoughts? Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 24 12:57:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChBw-0004Xz-Cx; Fri, 24 Feb 2006 12:57:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChBv-0004Xh-4r for enum@ietf.org; Fri, 24 Feb 2006 12:57:19 -0500 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FChBt-0003e2-Uf for enum@ietf.org; Fri, 24 Feb 2006 12:57:19 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.13.4) with ESMTP id k1OI4D1X025961; Fri, 24 Feb 2006 13:04:14 -0500 Received: from trutkowski-desk.verisign.com ([10.169.64.229]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 12:57:16 -0500 Message-Id: <7.0.1.0.2.20060224124915.03cd1768@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 24 Feb 2006 12:57:15 -0500 To: "Stastny Richard" , From: Tony Rutkowski Subject: Re: [Enum] General question on Enumservices In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4DCB@oefeg-s04.oefeg.loc > References: <32755D354E6B65498C3BD9FD496C7D463C4DCB@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 24 Feb 2006 17:57:16.0915 (UTC) FILETIME=[BFD24430:01C6396B] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, >On one hand a lot of people seem to have very creative >ideas on what kind information one may link to a >communication identifier such as an E.164 number Sage advice. Creative ideas on bindings are easy. Any creative ideas on how providers are going to make money? What capabilities in the protocols allow for billing and accounting? Could be useful. :-) cheers, tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 24 13:51:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCi2e-0007a0-KI; Fri, 24 Feb 2006 13:51:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCi2d-0007UX-MY for enum@ietf.org; Fri, 24 Feb 2006 13:51:47 -0500 Received: from bay103-f20.bay103.hotmail.com ([65.54.174.30] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCi2c-0005Pr-Am for enum@ietf.org; Fri, 24 Feb 2006 13:51:47 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 24 Feb 2006 10:51:43 -0800 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Fri, 24 Feb 2006 18:51:41 GMT X-Originating-IP: [67.97.95.201] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <7.0.1.0.2.20060224124915.03cd1768@verisign.com> From: "Peter Williams" To: enum@ietf.org Bcc: Subject: Re: [Enum] General question on Enumservices Date: Fri, 24 Feb 2006 10:51:41 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 24 Feb 2006 18:51:43.0666 (UTC) FILETIME=[5AF4E920:01C63973] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org IETF needs to modify its mission statement: the forum for creating commercial opportunities to make money out of Internet protocols. Lets be honest: thats all we are, now. >From: Tony Rutkowski >To: "Stastny Richard" , >Subject: Re: [Enum] General question on Enumservices >Date: Fri, 24 Feb 2006 12:57:15 -0500 > >Hi Richard, > >>On one hand a lot of people seem to have very creative >>ideas on what kind information one may link to a >>communication identifier such as an E.164 number > >Sage advice. Creative ideas on bindings are easy. > >Any creative ideas on how providers are going to >make money? What capabilities in the protocols >allow for billing and accounting? > >Could be useful. :-) > >cheers, >tony > > >_______________________________________________ >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 enum-bounces@ietf.org Fri Feb 24 14:45:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCisN-0000Vk-MZ; Fri, 24 Feb 2006 14:45:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCisM-0000V3-IE for enum@ietf.org; Fri, 24 Feb 2006 14:45:14 -0500 Received: from 2-1-3-18a.spa.sth.bostream.se ([82.182.146.229] helo=aptop.autonomica.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCisK-0006on-1n for enum@ietf.org; Fri, 24 Feb 2006 14:45:14 -0500 Received: from aptop.autonomica.net (aptop.autonomica.net [127.0.0.1]) by aptop.autonomica.net (8.13.4/8.13.4) with ESMTP id k1OJj7Oj006232 for ; Fri, 24 Feb 2006 20:45:07 +0100 (MET) To: enum@ietf.org From: Lars-Johan Liman Date: 24 Feb 2006 20:45:07 +0100 Message-ID: <22y800h77g.fsf@aptop.autonomica.net> Lines: 27 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Enum] No "Sender:"?? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Since about February 20, the messages sent to the list seem to arrive without the Sender: enum-bounces@ietf.org header field, which was quite useful for sorting the messages into the apropriate folder. This makes them end up in the wrong folder for me. Does anyone know what happened, and why this standardized header was removed? (And yes, I know there are other fields for me to investigate. The advantage of "Sender:" is that it covers a several scenarios with the same string (bounces etc.), where the other fields may not. This doesn't answer my question, though.) Cheers, /Liman #---------------------------------------------------------------------- # There are 10 kinds of people in the world. Those who understand # binary numbers, and those who don't. #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail: liman@autonomica.se # Senior Systems Specialist ! HTTP : //www.autonomica.se/ # Autonomica AB, Stockholm ! Voice : +46 8 - 615 85 72 #---------------------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 24 15:07:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCjDc-0007XK-KR; Fri, 24 Feb 2006 15:07:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCjDa-0007XF-U0 for enum@ietf.org; Fri, 24 Feb 2006 15:07:10 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCjDY-0007WF-Jc for enum@ietf.org; Fri, 24 Feb 2006 15:07:10 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1OK6xL25910; Fri, 24 Feb 2006 15:06:59 -0500 (EST) Received: from [127.0.0.1] ([47.130.17.248] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 15:06:59 -0500 Message-ID: <43FF675F.1040206@nortel.com> Date: Fri, 24 Feb 2006 15:06:55 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lars-Johan Liman Subject: Re: [Enum] No "Sender:"?? References: <22y800h77g.fsf@aptop.autonomica.net> In-Reply-To: <22y800h77g.fsf@aptop.autonomica.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2006 20:06:59.0500 (UTC) FILETIME=[DE9A7EC0:01C6397D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org The IETF reorganized its servers last weekend. Maybe they reconfigured at that time. Lars-Johan Liman wrote: > Since about February 20, the messages sent to the list > seem to arrive without the > > Sender: enum-bounces@ietf.org > > header field, which was quite useful for sorting the messages into > the apropriate folder. This makes them end up in the wrong folder for > me. > > Does anyone know what happened, and why this standardized header was > removed? > > (And yes, I know there are other fields for me to investigate. The > advantage of "Sender:" is that it covers a several scenarios with the > same string (bounces etc.), where the other fields may not. This > doesn't answer my question, though.) > > Cheers, > /Liman > #---------------------------------------------------------------------- > # There are 10 kinds of people in the world. Those who understand > # binary numbers, and those who don't. > #---------------------------------------------------------------------- > # Lars-Johan Liman, M.Sc. ! E-mail: liman@autonomica.se > # Senior Systems Specialist ! HTTP : //www.autonomica.se/ > # Autonomica AB, Stockholm ! Voice : +46 8 - 615 85 72 > #---------------------------------------------------------------------- > > _______________________________________________ > 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 enum-bounces@ietf.org Fri Feb 24 16:41:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCkgO-0003n5-UT; Fri, 24 Feb 2006 16:41:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCkgN-0003mm-EA for enum@ietf.org; Fri, 24 Feb 2006 16:40:59 -0500 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCkgM-00036w-2e for enum@ietf.org; Fri, 24 Feb 2006 16:40:59 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1OLerE26312; Fri, 24 Feb 2006 16:40:53 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] General question on Enumservices Date: Fri, 24 Feb 2006 16:40:52 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] General question on Enumservices Thread-Index: AcY5TmHYXgYCZShoTJ2fQcq69q+l2gAO59BA From: "James McEachern" To: "Stastny Richard" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard, I have been having a similar nagging concern for some time now. I = believe the original intent of ENUM was to facilitate the smooth = transition from E.164 numbers to SIP URIs. But with all these = Enumservices, we may achieve exactly the opposite effect, by making = E.164 numbers indispensable. =20 I assume this is not our intent. Your proposal may be one way around this. Other thoughts? Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Friday, February 24, 2006 9:27 AM To: enum@ietf.org Subject: [Enum] General question on Enumservices Folks, I have a general question concerning Enumservices Considering the bunch of the different Enumservices popping up recently I ask myself if we are not overdoing it On one hand a lot of people seem to have very creative ideas on what kind information one may link to a communication identifier such as an E.164 number So we are back to the original idea of the electronic business card. Bernie mentioned in context with the IM service that one my put all is Yahoo, aol, icq, jabber etc ID into ENUM and somebody else may try to find out which is matching his service. If I add now to this the webpage, email, vcard, calendar, eventually the old idea we had in TS 102 172 with=20 location (loc), and the public KEY (eh domainkey?), ... I see ENUM domains coming up with 20 and more entries. Most of this information could be put into vcard If not, we may consider one or two general pointers containing all the required information, e.g. publicinfo and privateinfo and define the template This would allow on one hand sceened access with policies and on the other hand more flexibility in data provisioning Thoughts? Richard _______________________________________________ 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 enum-bounces@ietf.org Fri Feb 24 16:48:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCknx-0000uu-Vk; Fri, 24 Feb 2006 16:48:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCknw-0000up-Ko for enum@ietf.org; Fri, 24 Feb 2006 16:48:48 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FCknv-0003F8-9W for enum@ietf.org; Fri, 24 Feb 2006 16:48:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] General question on Enumservices Date: Fri, 24 Feb 2006 22:52:44 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C488A@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] General question on Enumservices Thread-Index: AcY5bFB1gOvQ/7y9RRSeXN1oXK2o1wAHn/9n From: "Stastny Richard" To: "Tony Rutkowski" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Tony, >>On one hand a lot of people seem to have very creative >>ideas on what kind information one may link to a >>communication identifier such as an E.164 number > >Sage advice. Creative ideas on bindings are easy. >Any creative ideas on how providers are going to >make money? What capabilities in the protocols >allow for billing and accounting? >Could be useful. :-) Either my view of the worls or yours is wrong 1. Providers =3D service providers are serving the customer (serving is derived from latin servus=3Dslave) by providing a service to the customer he is willing to pay for (customer value) =20 2. USER ENUM is for the End User =3D Customer The service is providing him a domain in ENUM He is willing to pay for this only if it gives him some value the more value (more potential use) he gets out of it, the more he is willing to use it AND in addition the user is pointing in ENUM again to services. So the more services he may point to, the better for service providers =20 3. In Infrastructure ENUM also the provider hosting the domain may provide more services - again more value for=20 the customer. =20 4. the time of metered services is IMHO over in future the billing will be simpler - flat fees. That saves money on complicated billing systems cheers Richard =20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 24 16:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCkpn-0001il-N6; Fri, 24 Feb 2006 16:50:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCkpm-0001id-Ih for enum@ietf.org; Fri, 24 Feb 2006 16:50:42 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FCkpm-0003HA-5G for enum@ietf.org; Fri, 24 Feb 2006 16:50:42 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1140817800!9428145!13 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 17190 invoked from network); 24 Feb 2006 21:50:41 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-6.tower-120.messagelabs.com with SMTP; 24 Feb 2006 21:50:41 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 43F8A544000F1A25; Fri, 24 Feb 2006 16:50:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] General question on Enumservices Date: Fri, 24 Feb 2006 16:50:38 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0C3B538B@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] General question on Enumservices Thread-Index: AcY5TmHYXgYCZShoTJ2fQcq69q+l2gAO59BAAACCXdA= From: "Pfautz, Penn L, NEO" To: "James McEachern" , "Stastny Richard" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Not everyone agrees with your assumption about intent. =20 -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: Friday, February 24, 2006 4:41 PM To: Stastny Richard; enum@ietf.org Subject: RE: [Enum] General question on Enumservices Richard, I have been having a similar nagging concern for some time now. I believe the original intent of ENUM was to facilitate the smooth transition from E.164 numbers to SIP URIs. But with all these Enumservices, we may achieve exactly the opposite effect, by making E.164 numbers indispensable. =20 I assume this is not our intent. Your proposal may be one way around this. Other thoughts? Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Friday, February 24, 2006 9:27 AM To: enum@ietf.org Subject: [Enum] General question on Enumservices Folks, I have a general question concerning Enumservices Considering the bunch of the different Enumservices popping up recently I ask myself if we are not overdoing it On one hand a lot of people seem to have very creative ideas on what kind information one may link to a communication identifier such as an E.164 number So we are back to the original idea of the electronic business card. Bernie mentioned in context with the IM service that one my put all is Yahoo, aol, icq, jabber etc ID into ENUM and somebody else may try to find out which is matching his service. If I add now to this the webpage, email, vcard, calendar, eventually the old idea we had in TS 102 172 with=20 location (loc), and the public KEY (eh domainkey?), ... I see ENUM domains coming up with 20 and more entries. Most of this information could be put into vcard If not, we may consider one or two general pointers containing all the required information, e.g. publicinfo and privateinfo and define the template This would allow on one hand sceened access with policies and on the other hand more flexibility in data provisioning Thoughts? Richard _______________________________________________ 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 enum-bounces@ietf.org Fri Feb 24 17:02:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCl09-0001kH-1Y; Fri, 24 Feb 2006 17:01:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCl07-0001jR-EZ; Fri, 24 Feb 2006 17:01:23 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCl06-0003PE-2O; Fri, 24 Feb 2006 17:01:23 -0500 Received: from [10.31.13.102] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1OM1n2H003962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2006 14:01:50 -0800 Message-ID: <43FF8226.90001@shockey.us> Date: Fri, 24 Feb 2006 17:01:10 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: iesg-secretary@ietf.org, Cullen Jennings , "Peterson, Jon" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , enum@ietf.org, Allison Mankin Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Enum] Request for Publication - draft-ietf-enum-validation-arch-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a request for publication for one IETF ENUM WG working group document. A two week WG last call on this document concluded on Feb 24, 2006. The document listed below is being proposed for Informational RFC. This document incorporates comments from the last call. Status - Informational Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-ietf-enum-validation-arch-02.txt Pages : 18 Date : 2006-2-23 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-02.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 24 17:09:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCl7X-00078G-GQ; Fri, 24 Feb 2006 17:09:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCl7W-00077r-UQ for enum@ietf.org; Fri, 24 Feb 2006 17:09:02 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FCl7W-0003b9-Im for enum@ietf.org; Fri, 24 Feb 2006 17:09:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] General question on Enumservices Date: Fri, 24 Feb 2006 23:13:00 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C488B@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] General question on Enumservices Thread-Index: AcY5TmHYXgYCZShoTJ2fQcq69q+l2gAO59BAAADGS7I= From: "Stastny Richard" To: "James McEachern" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Jim, >I believe the original intent of ENUM was to facilitate the smooth = transition from E.164 numbers to SIP URIs. =20 =20 This is not correct, historically. Funny: originally the basic idea of ENUM was exactly where we are now: The replacement of the business card This was killed by SPAM and privacy sherriffs. Then for some time it looked that the only feasable enumservice was SIP = and only SIP Some proposals from us got killed (remember vovi) and others had a very = hard time (msg) because it was said SIP is enough, because one may do anything by = establishing a sip session and negotiate the rest later. Eventually one may use Pres (I never completely understood why one needs pres if you have sip (or = IM), but not video:sip, but I am not an AD. Now we are round the full circle ;-) =20 My position here is somewhere in the middle. I have learned that the original business card idea putting everything in the DNS is not so = good, but I also know you cannot do anything with SIP. The vcard approach = makes sense, and of course we need additional Enumservices such as email:mailto, = because not everybody has all services with one (sip) provider. =20 But we should be careful not to overdo it simple because it will get too = complicated for the end-user =20 >But with all these Enumservices, we may achieve exactly the opposite = effect, by making E.164 numbers indispensable.=20 >I assume this is not our intent. =20 Hmm, aren't they indispensible? How many people can you reach via a SIP URI and how many with a phone = number? How many large voice providers give you a sip URI?=20 And I still wonder how they will provide global connectivity with SIP URIs (public user identities) in IMS Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 24 17:47:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FClil-0000SH-AL; Fri, 24 Feb 2006 17:47:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FClij-0000Kk-GU for enum@ietf.org; Fri, 24 Feb 2006 17:47:29 -0500 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FClii-0004oL-8p for enum@ietf.org; Fri, 24 Feb 2006 17:47:29 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.13.4) with ESMTP id k1OMsRGG005163; Fri, 24 Feb 2006 17:54:27 -0500 Received: from trutkowski-desk.verisign.com ([10.169.64.229]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 17:47:27 -0500 Message-Id: <7.0.1.0.2.20060224172744.03d3fb80@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 24 Feb 2006 17:47:26 -0500 To: "Stastny Richard" , From: Tony Rutkowski Subject: Re: [Enum] General question on Enumservices In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C488A@oefeg-s04.oefeg.loc > References: <32755D354E6B65498C3BD9FD496C7D462C488A@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 24 Feb 2006 22:47:27.0159 (UTC) FILETIME=[4922AC70:01C63994] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, >2. USER ENUM is for the End User = Customer >The service is providing him a domain in ENUM >He is willing to pay for this only if it gives him some value >the more value (more potential use) he gets out of it, the more >he is willing to use it >AND in addition the user is pointing in ENUM again >to services. So the more services he may point to, the better >for service providers All of this is nice in theory. However, it's apparent that the nature of the services being provided as well as the interactions among multiple kinds of providers of services associated with a single number is significantly more complex for both the user and providers involved, as well as subject to all kinds of authentications as part of the associated administrative processes. Someone will bear those costs and it's not clear who will want to get left "holding the bag" for some flat rate, and be unable to charge for supplementary services. So the cost model remains unclear. Additionally, all the nations of the world add substantial regulatory, justice, and security burdens on top of this identifier system that get more complex and extensive by the day. (Check out today's FCC delegation of number pooling to the State Commissions.) At last check, these burdens include: number portability, priority access, roaming, directory assistance, callerid, disability assistance, language preference, personal emergency (E112/911), law enforcement assistance (including data retention in many countries), public emergency alerts, donotcall, intercarrier compensation, service provider specification. ENUM is cool. However, the administrative challenges and sorting out of the associated burdens and costs is non-trivial. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 24 18:58:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCmos-0002d9-4E; Fri, 24 Feb 2006 18:57:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCmoq-0002cj-N9 for enum@ietf.org; Fri, 24 Feb 2006 18:57:52 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCmop-0008Si-Bz for enum@ietf.org; Fri, 24 Feb 2006 18:57:52 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 24 Feb 2006 15:57:51 -0800 X-IronPort-AV: i="4.02,145,1139212800"; d="scan'208"; a="409774967:sNHT32583164" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1ONvoVb018335; Fri, 24 Feb 2006 15:57:50 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 18:57:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] General question on Enumservices Date: Fri, 24 Feb 2006 18:57:48 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3012456F5@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] General question on Enumservices Thread-Index: AcY5lFytJdlJynXgRRCTdOJhwJAv3AACTbxw From: "Michael Hammer \(mhammer\)" To: "Tony Rutkowski" , "Stastny Richard" , X-OriginalArrivalTime: 24 Feb 2006 23:57:49.0771 (UTC) FILETIME=[1E0221B0:01C6399E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org In the end, which number/name is the index (business card) to the others is arbitrary. The choice of E.164 number is an artifact of the fact that phones have keypads (0-9, #, *) and most of the world uses phones, while access to computers is not as universal. Beyond that, the main concern is to have an address associated with a protocol (need that clue) that can be used to further the communications. Mike > -----Original Message----- > From: Tony Rutkowski [mailto:trutkowski@verisign.com]=20 > Sent: Friday, February 24, 2006 5:47 PM > To: Stastny Richard; enum@ietf.org > Subject: Re: [Enum] General question on Enumservices >=20 > Hi Richard, >=20 > >2. USER ENUM is for the End User =3D Customer The service is = providing=20 > >him a domain in ENUM He is willing to pay for this only if=20 > it gives him=20 > >some value the more value (more potential use) he gets out=20 > of it, the=20 > >more he is willing to use it AND in addition the user is pointing in=20 > >ENUM again to services. So the more services he may point to, the=20 > >better for service providers >=20 > All of this is nice in theory. However, it's apparent that=20 > the nature of the services being provided as well as the=20 > interactions among multiple kinds of providers of services=20 > associated with a single number is significantly more complex=20 > for both the user and providers involved, as well as subject=20 > to all kinds of authentications as part of the associated > administrative processes. Someone will bear those costs > and it's not clear who will want to get left "holding the=20 > bag" for some flat rate, and be unable to charge for=20 > supplementary services. So the cost model remains unclear. >=20 > Additionally, all the nations of the world add substantial=20 > regulatory, justice, and security burdens on top of this=20 > identifier system that get more complex and extensive by the=20 > day. (Check out today's FCC delegation of number > pooling to the State Commissions.) At last check, these > burdens include: number portability, priority access,=20 > roaming, directory assistance, callerid, disability=20 > assistance, language preference, personal emergency=20 > (E112/911), law enforcement assistance (including data=20 > retention in many countries), public emergency alerts,=20 > donotcall, intercarrier compensation, service provider specification. >=20 > ENUM is cool. However, the administrative challenges and=20 > sorting out of the associated burdens and costs is non-trivial. >=20 > --tony=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 24 21:40:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCpLv-0007Wg-Mz; Fri, 24 Feb 2006 21:40:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCpLu-0007Wb-N0 for enum@ietf.org; Fri, 24 Feb 2006 21:40:10 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCpLt-0006ih-9P for enum@ietf.org; Fri, 24 Feb 2006 21:40:10 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1P2eeaO001842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2006 18:40:42 -0800 Message-ID: <43FFC381.50307@shockey.us> Date: Fri, 24 Feb 2006 21:40:01 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Enum] General question on Enumservices References: <072C5B76F7CEAB488172C6F64B30B5E3012456F5@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3012456F5@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: enum@ietf.org, Stastny Richard , Scott Bradner , Tony Rutkowski X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Michael Hammer (mhammer) wrote: > In the end, which number/name is the index (business card) to the others > is arbitrary. > > The choice of E.164 number is an artifact of the fact that phones have > keypads (0-9, #, *) and most of the world uses phones, while access to > computers is not as universal. and E.164 numbers are linguistically neutral. We cannot forget there are two globally reckonized naming and addressing schemes for communications. E.164 and the ICANN domain root. ENUM is the definitive mapping between the two. All others are private silo, such as most IM or P2P systems and skype. These have their place in the world. > > Beyond that, the main concern is to have an address associated with a > protocol (need that clue) that can be used to further the > communications. I have to admit that some of this discussion over Enumservice registrations is mildly amusing to me. I too have vacillated between what is caller vs called party control of communications and I tried to touch on this in my security and privacy draft that I'm continuing to review. I see no reason to restrict what Enumservices should be registered ..this is what markets are for. We will not decide what prevails. >> >> ENUM is cool. However, the administrative challenges and >> sorting out of the associated burdens and costs is non-trivial. >> >> --tony Tony .. you admitting that ENUM is 'cool' after all these years is high praise indeed. :-) Many of us remember when you thought otherwise. Best wishes as always, >> >> > > Mike > > >> -----Original Message----- >> From: Tony Rutkowski [mailto:trutkowski@verisign.com] >> Sent: Friday, February 24, 2006 5:47 PM >> To: Stastny Richard; enum@ietf.org >> Subject: Re: [Enum] General question on Enumservices >> >> Hi Richard, >> >>> 2. USER ENUM is for the End User = Customer The service is providing >>> him a domain in ENUM He is willing to pay for this only if >> it gives him >>> some value the more value (more potential use) he gets out >> of it, the >>> more he is willing to use it AND in addition the user is pointing in >>> ENUM again to services. So the more services he may point to, the >>> better for service providers >> All of this is nice in theory. However, it's apparent that >> the nature of the services being provided as well as the >> interactions among multiple kinds of providers of services >> associated with a single number is significantly more complex >> for both the user and providers involved, as well as subject >> to all kinds of authentications as part of the associated >> administrative processes. Someone will bear those costs >> and it's not clear who will want to get left "holding the >> bag" for some flat rate, and be unable to charge for >> supplementary services. So the cost model remains unclear. >> >> Additionally, all the nations of the world add substantial >> regulatory, justice, and security burdens on top of this >> identifier system that get more complex and extensive by the >> day. (Check out today's FCC delegation of number >> pooling to the State Commissions.) At last check, these >> burdens include: number portability, priority access, >> roaming, directory assistance, callerid, disability >> assistance, language preference, personal emergency >> (E112/911), law enforcement assistance (including data >> retention in many countries), public emergency alerts, >> donotcall, intercarrier compensation, service provider specification. >> >> ENUM is cool. However, the administrative challenges and >> sorting out of the associated burdens and costs is non-trivial. >> >> --tony >> >> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Feb 25 08:03:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCz4w-0003QM-1Y; Sat, 25 Feb 2006 08:03:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCz4u-0003Ok-OW for enum@ietf.org; Sat, 25 Feb 2006 08:03:16 -0500 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCz4u-0007JJ-Hh for enum@ietf.org; Sat, 25 Feb 2006 08:03:16 -0500 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.1/8.13.4) with ESMTP id k1PD8xC9027457; Sat, 25 Feb 2006 08:09:59 -0500 Received: from trutkowski-desk.verisign.com ([10.169.64.230]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Feb 2006 08:02:38 -0500 Message-Id: <7.0.1.0.2.20060225072501.037225a0@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 25 Feb 2006 08:02:37 -0500 To: Richard Shockey , "Michael Hammer (mhammer)" From: Tony Rutkowski Subject: Re: [Enum] General question on Enumservices In-Reply-To: <43FFC381.50307@shockey.us> References: <072C5B76F7CEAB488172C6F64B30B5E3012456F5@xmb-rtp-20b.amer.cisco.com> <43FFC381.50307@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 25 Feb 2006 13:02:38.0646 (UTC) FILETIME=[C12A3D60:01C63A0B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: enum@ietf.org, Stastny Richard , Scott Bradner X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, >and E.164 numbers are linguistically neutral. We cannot forget there >are two globally reckonized naming and addressing schemes for >communications. E.164 and the ICANN domain root. Not quite. There are many such schemes. The original and still a very large one is the OID root that emerged from Jim White's IFIPS 6.5 work. If you want to look at definitive collections, check the two contending "root of roots" in the form of TBL's URN and Bob Kahn's Handles. >Tony .. you admitting that ENUM is 'cool' after all these years is >high praise indeed. :-) Many of us remember when you thought otherwise. Uh...maybe in some alternative universe you've been visiting. I significantly promoted the original implementation and concept - which was Marshall T. Rose's and Carl Malamud's TPC.INT implementation in 1994. That was followed by the NetNumber and WebNum variants circa 1999. Gluing Michael's DDDS NAPTR RR concept was the cool innovation circa 2000 - which is when my "ENUM as Superglue" article was published in CommWeek. My expressed concern thereafter had nothing to do with ENUM, but rather a certain continuing obliviousness to the real world of public network infrastructure, and the needs of revenue earning providers, end users (other than geeks), regulatory authorities, justice officials, and NS/EP agencies. That in turn requires more than just resolver architectures and platforms; and includes rather notably, good directory and OA&M platforms. So here we are in 2006. All the concerns remain and indeed have escalated. You have much more involvement by government authorities, the industry is largely focussed on NGN, the EU has adopted a profoundly far reaching data retention directive, the FCC is about to a new USF scheme based on 90 cents/number and a new statute effectively requiring CallerID for VoIP. The token scheme is a useful innovation to begin dealing with some of these developments. So is EIDQ's E.115v2 and EREG - although IMHO E.115v2 has far more useful features. It's time, however, to engage with the outside world and produce capabilities that meet the needs of the world that exists, not the one that we wish existed. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Feb 25 09:12:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD0A5-00021r-8U; Sat, 25 Feb 2006 09:12:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD0A4-00020d-1n for enum@ietf.org; Sat, 25 Feb 2006 09:12:40 -0500 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD0A2-0000mL-Se for enum@ietf.org; Sat, 25 Feb 2006 09:12:40 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.13.4) with ESMTP id k1PEJjUt029471; Sat, 25 Feb 2006 09:19:46 -0500 Received: from trutkowski-desk.verisign.com ([10.169.64.230]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Feb 2006 09:12:36 -0500 Message-Id: <7.0.1.0.2.20060225090216.011add78@verisign.com> Message-Id: <7.0.1.0.2.20060225072501.037225a0@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 25 Feb 2006 09:12:36 -0500 To: Richard Shockey , "Michael Hammer (mhammer)" From: Tony Rutkowski Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 25 Feb 2006 14:12:37.0010 (UTC) FILETIME=[8795BF20:01C63A15] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: enum@ietf.org, Stastny Richard , Scott Bradner Subject: [Enum] Cudos for the most successful ENUM implementation X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, While we are exploring the fascinating world of namespaces, resolvers, and ENUM, we shouldn't forget what is arguably the most successful and perhaps ultimately the most ubiquitous implementation of ENUM - in the form of EPCglobal's ONS to provide NAPTRs for EPC object identifiers. Truly cool. At last week's seminal RFID/object networking workshop at the ITU, we also learned that several new implementations have emerged to resolve additional object namespaces - ODS and uIDs. Projections were on the order of "several thousand" objects per person. Those are big namespaces! best, tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Feb 25 17:14:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD7g3-0000Nj-W9; Sat, 25 Feb 2006 17:14:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCgn4-0004h2-Q7 for enum@ietf.org; Fri, 24 Feb 2006 12:31:38 -0500 Received: from mail.telecounselllc.com ([208.38.168.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCgn4-0002ft-Gm for enum@ietf.org; Fri, 24 Feb 2006 12:31:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] General question on Enumservices Date: Fri, 24 Feb 2006 12:31:11 -0500 Message-ID: <5107F667449A02408E283F92E6025FA63A9526@tpaesol01.TeleCounsel.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Enum] General question on Enumservices Thread-Index: AcY5TmHYXgYCZShoTJ2fQcq69q+l2gAGQrdA From: "Mark Hewitt" To: "Stastny Richard" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 X-Mailman-Approved-At: Sat, 25 Feb 2006 17:14:10 -0500 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2145016079==" Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============2145016079== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_0152_01C6393E.31D005F0"; micalg=SHA1; protocol="application/x-pkcs7-signature" This is a multi-part message in MIME format. ------=_NextPart_000_0152_01C6393E.31D005F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Richard; Good observation however consider for a moment that the structure of DNS is already well established and considered part of every basic IP device today. ENUM is simply a series of extensions for indexing more complex services than just the translation of an IP address to a name and the reverse. There are certainly more efficient protocols and technologies than the weighty IP protocol today - yet it is an accepted standard - DNS is the same. Some additional extensions of services now include "Identity Management" - allowing for a single logon to member services and sites. So let's think about how ENUM can support vCard rather than devise an entirely new protocol, service, and technology. _______________________________ Mark S. Hewitt (813) 849-7821 Direct -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Friday, February 24, 2006 9:27 AM To: enum@ietf.org Subject: [Enum] General question on Enumservices Folks, I have a general question concerning Enumservices Considering the bunch of the different Enumservices popping up recently I ask myself if we are not overdoing it On one hand a lot of people seem to have very creative ideas on what kind information one may link to a communication identifier such as an E.164 number So we are back to the original idea of the electronic business card. Bernie mentioned in context with the IM service that one my put all is Yahoo, aol, icq, jabber etc ID into ENUM and somebody else may try to find out which is matching his service. If I add now to this the webpage, email, vcard, calendar, eventually the old idea we had in TS 102 172 with location (loc), and the public KEY (eh domainkey?), ... I see ENUM domains coming up with 20 and more entries. Most of this information could be put into vcard If not, we may consider one or two general pointers containing all the required information, e.g. publicinfo and privateinfo and define the template This would allow on one hand sceened access with policies and on the other hand more flexibility in data provisioning Thoughts? Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------=_NextPart_000_0152_01C6393E.31D005F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOUDCCBHAw ggNYoAMCAQICEB+0zZj6uUmxQ2K5VZ1P12EwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDUwNjA3 MDgwOTEwWhcNMTkwNzA5MTczNjU4WjBlMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3Qg QUIxHTAbBgNVBAsTFEFkZFRydXN0IFRUUCBOZXR3b3JrMSEwHwYDVQQDExhBZGRUcnVzdCBDbGFz cyAxIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCWltQhSWDia+hBBwze xODcEyPNwTXH+9ZOEQpnXvUGW2ulCDtbKRY654eyNAbFvAWlA3yCyykQruGIgb3WntP+LVbBFc7j Jp0VLhD7Bo8wBN6ntGO0/7Gcrjyvd7ZWxbWroulpOj0OM3kyP3CCkplhbY0wCI9xP6ZIVxn4JdxL ZlyldI+Yrsj5wAYi56xz36Uu+1LcsRVlIPo1Zmne3yzxbrww2ywkEtvrNTVokMsAsJchPXQhI2U0 K7t4WaPW4XY5mqRJjox0r26kmqPZm9I4XJuiGMx1I4S+6+JNM3GOGvDC+Mcdoq0Dlyz4zyXG9rgk MbFjXZJ/Y/AlyVMuH79NAgMBAAGjgdEwgc4wHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4E bn0wHQYDVR0OBBYEFJWxtPCUtr3H2tERCSG+wa9J/RB7MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MBEGCWCGSAGG+EIBAQQEAwIAATBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDANBgkqhkiG9w0BAQUFAAOCAQEAaenDt4Gwt0ps0AgcIC5PrbDFLtmGHU116Z2Ok+MEWh9p Lgv/mvP50iMHmRqHMGGiIngTqsioHxNL64GxQF6EfG7tEpPCUr6dj4iW4XZvYFF0nT7/3AoLtP27 1e7/k+Dh7/LJxMN9flJEjrQZF5vTiDM1G5g5EMXVLk31lpzXfbxMV6X2iD9BrSNLmk7bZ69/EsDz W7Y44lu6XPYCWRWdZAuSfoopDa0AdQxf1MzGzSfdlSTlOEV9Y81qezrb2rXVR4y3DQPhCxjzImQo KXoyoBzj+hY78e3nhaNU4eI8IfyjqXjrzFTM9B8aFinNgbqmbMWOnmDn/WFJQN50NCXR9TCCBKIw ggOKoAMCAQICEES+DItQACS0EdM2JSVnyYkwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNOTkwNzA5 MTcyODUwWhcNMTkwNzA5MTczNjU4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOBuTCBtjALBgNVHQ8EBAMCAcYw DwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wWAYDVR0fBFEw TzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0G CSqGSIb3DQEBBQUAA4IBAQCxbWFdphp/fKtK5DD8U28lJMbK7eIxXCsO7u5hVW8EPs853sUbSZTk 6yBMtOaeUC5y2Y31qqOzStpWHGCXgNyCoq1KvYor/wsJtMbXIARF5M2AAbq6K27OqteS/uSv6/Qm HRYqf2wwlTcvMxKsf93H0RGMUZiy0KOR0K32n56Dkx4dQrhGr2tm8Jt/6uMDAuUCUcGq1TWdckAD iboxHcUQaFKe36KFxVwIpnjmU0+x6LfTFJ6TpsNk46x+cc28n+kDG8z76awxwa98FXQCmcOyR6bC MmHXx29IJFEnodWHVfJ7j5g9Fp7udbb40I7y88auKFun8PM2F/zDBdPKA0pUMIIFMjCCBBqgAwIB AgIQNUkl0whkhTOUzrB3gVmcwDANBgkqhkiG9w0BAQUFADBlMQswCQYDVQQGEwJTRTEUMBIGA1UE ChMLQWRkVHJ1c3QgQUIxHTAbBgNVBAsTFEFkZFRydXN0IFRUUCBOZXR3b3JrMSEwHwYDVQQDExhB ZGRUcnVzdCBDbGFzcyAxIENBIFJvb3QwHhcNMDYwMjE0MDAwMDAwWhcNMDcwMjE0MjM1OTU5WjCB 3zE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFURUQx RjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5jb21vZG8u bmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQxFDASBgNVBAMT C01hcmsgSGV3aXR0MScwJQYJKoZIhvcNAQkBFhhtYXJrLmhld2l0dEBpbnRlbGlneS5jb20wgZ8w DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOb1YBnM3hMqYZ4mrHgIQe1AMckYajOLluHMETrj58W3 5XR6WRsLhS7Kt5xAKMcpheZC7XTYc3rX+adPe41n8GFb6poCUaDShrQ1j155ATKmN3A3ozUN16kr UE+irKTaMBDs3hSsETMCvQ6dX2T0Z2dRuET+4+cZjjUWUBWIOhiNAgMBAAGjggHlMIIB4TAdBgNV HQ4EFgQUPDIFtVKFUV7Dcu6WVw0K8JZAaRswDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAw IAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNV HSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21v ZG8ubmV0L0NQUzB3BgNVHR8EcDBuMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdENsYXNzMUNBUm9vdC5jcmwwNKAyoDCGLmh0dHA6Ly9jcmwuY29tb2RvLm5ldC9BZGRUcnVz dENsYXNzMUNBUm9vdC5jcmwwgYYGCCsGAQUFBwEBBHoweDA7BggrBgEFBQcwAoYvaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQWRkVHJ1c3RVVE5DbGllbnRDQS5jcnQwOQYIKwYBBQUHMAKGLWh0dHA6 Ly9jcnQuY29tb2RvLm5ldC9BZGRUcnVzdFVUTkNsaWVudENBLmNydDAjBgNVHREEHDAagRhtYXJr Lmhld2l0dEBpbnRlbGlneS5jb20wDQYJKoZIhvcNAQEFBQADggEBAH/nlTK9G4uLba0bETxzujdm RQI47t9739vmjTIfCeV6y8TWjD39VV3VtoRB7UmguIhzgq1G20P9VtoorZERbZjwsk9xV0+a5Qgf gzShk7fxi69HdH59f7PKp+5ZpQZcFfgoM4cmtaTnDuEaB23Koqi3W+YBdYjurVDwDYKhvNTX2ATi G3++WYS8W5kx0N/Vs2TgeCV59nqRqj9eFFebS0qmhWX93qaxN0Yn5je3EQyXOJmdtAa5eYeg3k4c /f3rGuh8XF2dNE/55eKklV+13RdcDGg33W29JdmUPwkUgJIlvsQTJVW2fQuu0/WVANKXW8RwUelx AUd6us51NJVDGbAxggNUMIIDUAIBATB5MGUxCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVz dCBBQjEdMBsGA1UECxMUQWRkVHJ1c3QgVFRQIE5ldHdvcmsxITAfBgNVBAMTGEFkZFRydXN0IENs YXNzIDEgQ0EgUm9vdAIQNUkl0whkhTOUzrB3gVmcwDAJBgUrDgMCGgUAoIICMTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMjQxNzMxMTFaMCMGCSqGSIb3DQEJ BDEWBBRR1k7IMPXrBVLqV0+s3L2QDBFgsDBRBgsqhkiG9w0BCRACATFCMEAEHQAAAAAQAAAAwckW dOzRZUCerSEDBWTzEwEAAAAAgAEAMBwwGoEYbWFyay5oZXdpdHRAaW50ZWxpZ3kuY29tMGcGCSqG SIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGIBgkrBgEEAYI3EAQx ezB5MGUxCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEdMBsGA1UECxMUQWRkVHJ1 c3QgVFRQIE5ldHdvcmsxITAfBgNVBAMTGEFkZFRydXN0IENsYXNzIDEgQ0EgUm9vdAIQNUkl0whk hTOUzrB3gVmcwDCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtB ZGRUcnVzdCBBQjEdMBsGA1UECxMUQWRkVHJ1c3QgVFRQIE5ldHdvcmsxITAfBgNVBAMTGEFkZFRy dXN0IENsYXNzIDEgQ0EgUm9vdAIQNUkl0whkhTOUzrB3gVmcwDANBgkqhkiG9w0BAQEFAASBgLpM EY+fqfEGp22G9EZNTqABOdw/mmU0YjPJMIx1O4ixVcOhortHoq7vkkZYS5bSHJNrprupoHVNyFZf j9r3qcxx15+lWM75NdTAB435Wp/qLp4z4zeQwKpLcnd+aikFQtDe9rcP0GchUBHxdt3GYW18tfvB 0cBdSm3qRKzy9AUuAAAAAAAA ------=_NextPart_000_0152_01C6393E.31D005F0-- --===============2145016079== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============2145016079==-- From enum-bounces@ietf.org Sat Feb 25 17:14:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD7go-0000mD-9R; Sat, 25 Feb 2006 17:14:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCn3M-00036H-Mt for enum@ietf.org; Fri, 24 Feb 2006 19:12:52 -0500 Received: from gregale.wcom.co.uk ([193.131.254.138] helo=gregale.emea.verizonbusiness.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCn3M-000196-3r for enum@ietf.org; Fri, 24 Feb 2006 19:12:52 -0500 Received: from gregale.wcom.co.uk ([170.127.79.98] helo=gregale.emea.mci.com) by gregale.emea.verizonbusiness.com with esmtp (Exim 4.42) id 1FCn3D-0000sN-Gx; Sat, 25 Feb 2006 00:12:45 +0000 Received: from breen.emea.verizonbusiness.com (vardar [170.127.64.33]) by gregale.emea.mci.com (4.7.0.120) with ESMTP id ; Sat, 25 Feb 2006 00:12:27 GMT Received: from ms-lon-exgw01.uk.mcilink.com ([170.127.78.40]) by breen.emea.verizonbusiness.com with esmtp (Exim 4.42) id 1FCn2x-0006Tx-Cl; Sat, 25 Feb 2006 00:12:27 +0000 Received: by ms-lon-exgw01.uk.mcilink.com with Internet Mail Service (5.5.2657.72) id <1LFTNLBH>; Sat, 25 Feb 2006 00:12:18 -0000 Message-ID: From: "Lupton, Ronan" To: "'mhammer@cisco.com'" , "'trutkowski@verisign.com'" , "'Richard.Stastny@oefeg.at'" , "'enum@ietf.org'" Subject: Re: [Enum] General question on Enumservices Date: Sat, 25 Feb 2006 00:12:16 -0000 X-Mailer: Internet Mail Service (5.5.2657.72) MIME-Version: 1.0 (Generated by NET-TEL Mailguard SMTP version 4.0.1.40) X-VZ-EMEA-Spam-Score: -98.0 (---------------------------------------------------) X-VZ-EMEA-Signature: 2ecae6f698321a1a8bd4f77adb8deb72 X-Spam-Score: 0.1 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 X-Mailman-Approved-At: Sat, 25 Feb 2006 17:14:57 -0500 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2104946728==" Errors-To: enum-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2104946728== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C639A0.225DFD3B" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C639A0.225DFD3B Content-Type: text/plain Mike your correct! Bell v. Net. Debate 2.0 If more people would bother to think outside the box we would not have to entertain such trivia. Regards, R. -----Original Message----- From: Michael Hammer (mhammer) To: Tony Rutkowski; Stastny Richard; enum@ietf.org Sent: Fri Feb 24 23:57:48 2006 Subject: RE: [Enum] General question on Enumservices In the end, which number/name is the index (business card) to the others is arbitrary. The choice of E.164 number is an artifact of the fact that phones have keypads (0-9, #, *) and most of the world uses phones, while access to computers is not as universal. Beyond that, the main concern is to have an address associated with a protocol (need that clue) that can be used to further the communications. Mike > -----Original Message----- > From: Tony Rutkowski [mailto:trutkowski@verisign.com] > Sent: Friday, February 24, 2006 5:47 PM > To: Stastny Richard; enum@ietf.org > Subject: Re: [Enum] General question on Enumservices > > Hi Richard, > > >2. USER ENUM is for the End User = Customer The service is providing > >him a domain in ENUM He is willing to pay for this only if > it gives him > >some value the more value (more potential use) he gets out > of it, the > >more he is willing to use it AND in addition the user is pointing in > >ENUM again to services. So the more services he may point to, the > >better for service providers > > All of this is nice in theory. However, it's apparent that > the nature of the services being provided as well as the > interactions among multiple kinds of providers of services > associated with a single number is significantly more complex > for both the user and providers involved, as well as subject > to all kinds of authentications as part of the associated > administrative processes. Someone will bear those costs > and it's not clear who will want to get left "holding the > bag" for some flat rate, and be unable to charge for > supplementary services. So the cost model remains unclear. > > Additionally, all the nations of the world add substantial > regulatory, justice, and security burdens on top of this > identifier system that get more complex and extensive by the > day. (Check out today's FCC delegation of number > pooling to the State Commissions.) At last check, these > burdens include: number portability, priority access, > roaming, directory assistance, callerid, disability > assistance, language preference, personal emergency > (E112/911), law enforcement assistance (including data > retention in many countries), public emergency alerts, > donotcall, intercarrier compensation, service provider specification. > > ENUM is cool. However, the administrative challenges and > sorting out of the associated burdens and costs is non-trivial. > > --tony > > > _______________________________________________ > 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 ------_=_NextPart_001_01C639A0.225DFD3B Content-Type: text/html Content-Transfer-Encoding: quoted-printable Re: [Enum] General question on Enumservices

Mike your correct!

Bell v. Net. Debate 2.0

If more people would bother to think outside the box = we would not have to entertain such trivia.

Regards,

R.




-----Original Message-----
From: Michael Hammer (mhammer)
To: Tony Rutkowski; Stastny Richard; = enum@ietf.org
Sent: Fri Feb 24 23:57:48 2006
Subject: RE: [Enum] General question on = Enumservices

In the end, which number/name is the index (business = card) to the others
is arbitrary.

The choice of E.164 number is an artifact of the fact = that phones have
keypads (0-9, #, *) and most of the world uses = phones, while access to
computers is not as universal.

Beyond that, the main concern is to have an address = associated with a
protocol (need that clue) that can be used to = further the
communications.

Mike


> -----Original Message-----
> From: Tony Rutkowski [mailto:trutkowski@verisign.com]
> Sent: Friday, February 24, 2006 5:47 PM
> To: Stastny Richard; enum@ietf.org
> Subject: Re: [Enum] General question on = Enumservices
>
> Hi Richard,
>
> >2. USER ENUM is for the End User =3D = Customer The service is providing
> >him a domain in ENUM He is willing to pay = for this only if
> it gives him
> >some value the more value (more potential = use) he gets out
> of it, the
> >more he is willing to use it AND in = addition the user is pointing in
> >ENUM again to services. So the more = services he may point to, the
> >better for service providers
>
> All of this is nice in theory.  However, = it's apparent that
> the nature of the services being provided as = well as the
> interactions among multiple kinds of providers = of services
> associated with a single number is = significantly more complex
> for both the user and providers involved, as = well as subject
> to all kinds of authentications as part of the = associated
> administrative processes.   Someone = will bear those costs
> and it's not clear who will want to get left = "holding the
> bag" for some flat rate, and be unable to = charge for
> supplementary services.  So the cost model = remains unclear.
>
> Additionally, all the nations of the world add = substantial
> regulatory, justice, and security burdens on = top of this
> identifier system that get more complex and = extensive by the
> day.  (Check out today's FCC delegation of = number
> pooling to the State Commissions.)   = At last check, these
> burdens include:  number portability, = priority access,
> roaming, directory assistance, callerid, = disability
> assistance, language preference, personal = emergency
> (E112/911), law enforcement assistance = (including data
> retention in many countries), public emergency = alerts,
> donotcall, intercarrier compensation, service = provider specification.
>
> ENUM is cool.  However, the administrative = challenges and
> sorting out of the associated burdens and costs = is non-trivial.
>
> --tony
>
>
> = _______________________________________________
> 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=

------_=_NextPart_001_01C639A0.225DFD3B-- --===============2104946728== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============2104946728==-- From enum-bounces@ietf.org Sat Feb 25 17:34:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD7zB-0003ZI-Bh; Sat, 25 Feb 2006 17:33:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD7zA-0003ZD-2L for enum@ietf.org; Sat, 25 Feb 2006 17:33:56 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FD7z8-0007BF-Jq for enum@ietf.org; Sat, 25 Feb 2006 17:33:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] General question on Enumservices Date: Sat, 25 Feb 2006 23:35:50 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4890@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] General question on Enumservices Thread-Index: AcY5TmHYXgYCZShoTJ2fQcq69q+l2gAGQrdAAD0Z7UM= From: "Stastny Richard" To: "Mark Hewitt" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >So let's think about how ENUM can support vCard rather than devise an >entirely new protocol, service, and technology. =20 There seems to be a slight misunderstanding =20 I did not propose anything like that =20 On the contrary, IMHO some of the new proposed Enumservices could be replaced by using vcard =20 Richard ________________________________ Von: Mark Hewitt [mailto:mark.hewitt@inteligy.com] Gesendet: Fr 24.02.2006 18:31 An: Stastny Richard; enum@ietf.org Betreff: RE: [Enum] General question on Enumservices Richard; Good observation however consider for a moment that the structure of DNS = is already well established and considered part of every basic IP device = today. ENUM is simply a series of extensions for indexing more complex services than just the translation of an IP address to a name and the reverse. There are certainly more efficient protocols and technologies than the weighty IP protocol today - yet it is an accepted standard - DNS is the same. Some additional extensions of services now include "Identity Management" = - allowing for a single logon to member services and sites. So let's think about how ENUM can support vCard rather than devise an entirely new protocol, service, and technology. _______________________________ Mark S. Hewitt (813) 849-7821 Direct -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Friday, February 24, 2006 9:27 AM To: enum@ietf.org Subject: [Enum] General question on Enumservices Folks, I have a general question concerning Enumservices Considering the bunch of the different Enumservices popping up recently I ask myself if we are not overdoing it On one hand a lot of people seem to have very creative ideas on what kind information one may link to a communication identifier such as an E.164 number So we are back to the original idea of the electronic business card. Bernie mentioned in context with the IM service that one my put all is Yahoo, aol, icq, jabber etc ID into ENUM and somebody else may try to find out which is matching his service. If I add now to this the webpage, email, vcard, calendar, eventually the old idea we had in TS 102 172 with location (loc), and the public KEY (eh domainkey?), ... I see ENUM domains coming up with 20 and more entries. Most of this information could be put into vcard If not, we may consider one or two general pointers containing all the required information, e.g. publicinfo and privateinfo and define the template This would allow on one hand sceened access with policies and on the other hand more flexibility in data provisioning Thoughts? Richard _______________________________________________ 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 enum-bounces@ietf.org Sat Feb 25 17:55:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8JU-0000yU-Nz; Sat, 25 Feb 2006 17:54:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8JT-0000yK-0C for enum@ietf.org; Sat, 25 Feb 2006 17:54:55 -0500 Received: from [213.152.49.123] (helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD8JS-0007iz-90 for enum@ietf.org; Sat, 25 Feb 2006 17:54:54 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 166E67DBFC; Sat, 25 Feb 2006 22:54:53 +0000 (GMT) In-Reply-To: <340745048.28264@cnnic.cn> References: <43FD16C4.9050203@shockey.us> <340698409.05165@cnnic.cn> <340745048.28264@cnnic.cn> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5DF639B7-41D7-4DF7-B41E-D909E41D7F36@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt Date: Sat, 25 Feb 2006 22:54:51 +0000 To: chenhui X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: IETF ENUM WG , rohan@ekabal.com, Richard Stastny X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Chenhui, Rohan, folks, First, thanks Chenhui - from your comment I went back and re-read Rohan's draft *and the RFCs it references*. I had missed a couple of crucial features in the references. Now it makes much more sense. However, with regret I withdraw my comment on re-writing our clients and provisioning systems to fit - this draft has a completely different model from the one in use. Does anyone use the scheme proposed in RFC 2778/2779 and in RFC 3861? IIRC, several large systems *nearly* did in 2001, but will they now? Rohan's draft is the missing bit in the IETF RAI (SIP/...) architecture - now there's an anointed way to do with IM what was done to Presence. As such, I'm sure that it WILL progress quickly on the standards track. Somehow I don't think that the existing IM system URI schemes will ever be registered, so I do not think it will be feasible to move an Enumservice like (im:) through the IETF process - the IM system URIs in use in the World still are not registered, so a standards track document can't refer to their specifications, so it won't be acceptable. For the rest of us, it looks like (X-IM:aim, X-IM:ymsgr, X-IM:icq, X- IM:msim, X-IM:jabber, X-IM:xmpp X-IM:skype) is still the quick answer to fire up IM clients and send messages to people. It certainly works for me. For Skype voice calls a number of us have been using X-Skype:callto, as the Skype client registers itself as handling the "Callto:" URL scheme, and will place a voice call if you send the URL to Windows (or MacOS). That works for me as well :). But...of course, in that case if you have Windoz and have installed Microsoft's NetMeeting but *don't* have Skype installed, then your computer will try to place an H.323 call when it sees a "Callto:" URL, and will fail. However, these days that is a VERY rare problem. all the best, Lawrence On 24 Feb 2006, at 01:37, chenhui wrote: > Hi Rohan, > > The draft is a great progress to push ENUM IM service. > > We have also been considering the ENUM-IM service and developing > some ENUM-IM application. > As we know, there are so many kinds of IM clients and different IM > protocols, so how to intercommunication between different clients > is a problem. > > "Service Type" field is used to mark the registration of IM > service, but it seems limited to present the information of IM. > Therefore, we suggest to add the "subtype" field. > > Regards! > Chenhui > >>> -------- Original Message -------- >>> Subject: I-D ACTION:draft-mahy-enum-im-service-00.txt >>> Date: Wed, 22 Feb 2006 15:50:02 -0500 >>> From: Internet-Drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : A Telephone Number Mapping (ENUM) Service >>> Registration for Instant Messaging (IM) Services >>> >>> Author(s) : R. Mahy >>> Filename : draft-mahy-enum-im-service-00.txt >>> Pages : 5 >>> Date : 2006-2-22 >>> This document registers a Telephone Number Mapping (ENUM) service >>> for >>> Instant Messaging (IM). Specifically, this document focuses on >>> provisioning im: URIs in ENUM. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-mahy-enum-im- >>> service-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the >>> body of the >>> message. >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >>> announce >>> to change your subscription settings. >>> >>> >>> 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-mahy-enum-im-service-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-mahy-enum-im-service-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. >> >> _______________________________________________ >> 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 enum-bounces@ietf.org Sat Feb 25 18:04:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8SP-0007Ei-5i; Sat, 25 Feb 2006 18:04:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8SN-0007By-4t for enum@ietf.org; Sat, 25 Feb 2006 18:04:07 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD8SL-0007qL-Ia for enum@ietf.org; Sat, 25 Feb 2006 18:04:07 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1PN4QS2019492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Feb 2006 15:04:28 -0800 Message-ID: <4400E253.2070408@shockey.us> Date: Sat, 25 Feb 2006 18:03:47 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] General question on Enumservices References: <32755D354E6B65498C3BD9FD496C7D462C4890@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4890@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: enum@ietf.org, Mark Hewitt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Stastny Richard wrote: >> So let's think about how ENUM can support vCard rather than devise an >> entirely new protocol, service, and technology. > > There seems to be a slight misunderstanding > > I did not propose anything like that > > On the contrary, IMHO some of the new proposed Enumservices > could be replaced by using vcard Well a reminder that the vcard draft we reviewed in Vancouver is a WG item we have not as yet seen another version. Minutes attached. I certainly thought this was a "good idea" tm. I agree many of these parameters could be included in a vcard and indeed should but I dont see why we should restrict individual application submissions. But as usual I could be wrong. IANA Registration for ENUMservice vCard 10-Min =============================================== Author(s) : A. Mayrhofer, D. Lindner Filename : draft-mayrhofer-enum-vcard-00.txt Pages : 7 Date : 2005-10-5 This memo registers the ENUMservice "vCard" using the URI schemes http" and "https" according to the IANA ENUMservice registration process described in RFC3671. This ENUMservice is to be used to refer from an ENUM domain name to the vCard of the entity using the corresponding E.164 number. Clients may use information gathered from those vCards before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before he picks up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-vcard-00.txt DISCUSSION: ENUMservice for refering from phone numbers to URIs containing vCard. Came from questions from service providers which wanted to publish. Usage scenario: query for number, receive vCard URI, fetch vCard. No subtypes defined right now, two URI schemes (http and https) proposed now. Feedback received about subtypes: Should subtypes reflect protocol? Faltstrom (as WG member): Privacy constriants, and granularity limits of HTTP. vCards could be synthesized based on authentication. HTTP not optimal for detailed access constraints. A bit nervous that usage of http is too quick. Recommend at least subtyping because good WP systems should not use http, but could be started with http now. Suggestion is to check HTTP, LDAP, IRIS Shockey: Want to see granularity on access control as well. Schiefner: Would like to see this a WG item, looking at moving that forward. Levi ??: vCards heavily used in XMPP. Should look at this. Not sure if granularity is what people expect from publishing a vCard. Jimmy ??: Suggestions to granularity on access controls could be out of scope of the ENUM WG? Mayrhofer: Could simply say "we make the reference, what behind this is out of scope for ENUM". Faltstrom: Clarification on privacy needed. Baskin: Privacy needs to be highlighted each time. However, "ENUM" does not the vCard, ENUM just returns a reference. It's done after the lookup. Faltstrom: Agreed, need to be subtyped to differentiated. ??: There is a draft about vCard over WebDAV in the calendaring for WebDAV. draft-debut-carddav? Schwartz: Issues on identifying when using HTTP. WG ACTION: Based on a hum of the WG, consensus for adopting this as WG item. > > Richard > > ________________________________ > > Von: Mark Hewitt [mailto:mark.hewitt@inteligy.com] > Gesendet: Fr 24.02.2006 18:31 > An: Stastny Richard; enum@ietf.org > Betreff: RE: [Enum] General question on Enumservices > > > > Richard; > > Good observation however consider for a moment that the structure of DNS is > already well established and considered part of every basic IP device today. > ENUM is simply a series of extensions for indexing more complex services > than just the translation of an IP address to a name and the reverse. > > There are certainly more efficient protocols and technologies than the > weighty IP protocol today - yet it is an accepted standard - DNS is the > same. > > Some additional extensions of services now include "Identity Management" - > allowing for a single logon to member services and sites. > > So let's think about how ENUM can support vCard rather than devise an > entirely new protocol, service, and technology. > > > _______________________________ > > > > Mark S. Hewitt > (813) 849-7821 Direct > > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, February 24, 2006 9:27 AM > To: enum@ietf.org > Subject: [Enum] General question on Enumservices > > Folks, > > I have a general question concerning Enumservices > > Considering the bunch of the different Enumservices > popping up recently I ask myself if we are not overdoing it > > On one hand a lot of people seem to have very creative > ideas on what kind information one may link to a > communication identifier such as an E.164 number > > So we are back to the original idea of the electronic > business card. > > Bernie mentioned in context with the IM service that > one my put all is Yahoo, aol, icq, jabber etc ID into > ENUM and somebody else may try to find out which is > matching his service. > > If I add now to this the webpage, email, vcard, calendar, > eventually the old idea we had in TS 102 172 with > location (loc), and the public KEY (eh domainkey?), ... > > I see ENUM domains coming up with 20 and more entries. > > Most of this information could be put into vcard > > If not, we may consider one or two general pointers > containing all the required information, e.g. > publicinfo and privateinfo and define the template > > This would allow on one hand sceened access with policies > and on the other hand more flexibility in data provisioning > > Thoughts? > > Richard > > > _______________________________________________ > 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, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Feb 25 18:13:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8aq-0004CA-N0; Sat, 25 Feb 2006 18:12:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8ao-0004AW-Lv for enum@ietf.org; Sat, 25 Feb 2006 18:12:50 -0500 Received: from bay103-f33.bay103.hotmail.com ([65.54.174.43] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD8ao-0008P3-9I for enum@ietf.org; Sat, 25 Feb 2006 18:12:50 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 25 Feb 2006 15:12:49 -0800 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Sat, 25 Feb 2006 23:12:46 GMT X-Originating-IP: [69.239.157.96] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <5107F667449A02408E283F92E6025FA63A9526@tpaesol01.TeleCounsel.net> From: "Peter Williams" To: mark.hewitt@inteligy.com, Richard.Stastny@oefeg.at, enum@ietf.org Bcc: Subject: RE: [Enum] General question on Enumservices Date: Sat, 25 Feb 2006 15:12:46 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Feb 2006 23:12:49.0348 (UTC) FILETIME=[FED80840:01C63A60] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >From: "Mark Hewitt" >To: "Stastny Richard" , >Subject: RE: [Enum] General question on Enumservices >Date: Fri, 24 Feb 2006 12:31:11 -0500 > >Richard; > >Good observation however consider for a moment that the structure of DNS is >already well established and considered part of every basic IP device >today. >ENUM is simply a series of extensions for indexing more complex services >than just the translation of an IP address to a name and the reverse. > >There are certainly more efficient protocols and technologies than the >weighty IP protocol today - yet it is an accepted standard - DNS is the >same. > >Some additional extensions of services now include "Identity Management" - >allowing for a single logon to member services and sites. Hmmm. 15107967919@passport.com. I think Ive seen that somewhere, before, on my "nicely converged" windowsmobile IP cellphone/PDA/sipclient! I suppose IETF could add some value by leading the pack with an ENUM/SSO that obligates presentation of said id (an "ENUM-SENDER-ID enumservice") to detectably come (somehow) only from a (nationally-regulated) device that was provisioned with said E.164 name rights by a regulated carrier, or a SIP PBX falling ultimately under national regs. This would basically add a "national-regulation assurance" to the SSO scheme, such as passport - which is a valuable assurance, lets face in to parties transacting business across an open network. As we are talking only about design that make money for folks, its main problem is that the revenue derived from this value of this assurance is obtained by the passport SSO provider versus the core provider (the regulated carrier) , given the SSO broker can freely leverage/repurpose the assurance delivered by the phone companies regulated by public tarifs. > >So let's think about how ENUM can support vCard rather than devise an >entirely new protocol, service, and technology. > > >_______________________________ > > > >Mark S. Hewitt >(813) 849-7821 Direct > > >-----Original Message----- >From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >Sent: Friday, February 24, 2006 9:27 AM >To: enum@ietf.org >Subject: [Enum] General question on Enumservices > >Folks, > >I have a general question concerning Enumservices > >Considering the bunch of the different Enumservices >popping up recently I ask myself if we are not overdoing it > >On one hand a lot of people seem to have very creative >ideas on what kind information one may link to a >communication identifier such as an E.164 number > >So we are back to the original idea of the electronic >business card. > >Bernie mentioned in context with the IM service that >one my put all is Yahoo, aol, icq, jabber etc ID into >ENUM and somebody else may try to find out which is >matching his service. > >If I add now to this the webpage, email, vcard, calendar, >eventually the old idea we had in TS 102 172 with >location (loc), and the public KEY (eh domainkey?), ... > >I see ENUM domains coming up with 20 and more entries. > >Most of this information could be put into vcard > >If not, we may consider one or two general pointers >containing all the required information, e.g. >publicinfo and privateinfo and define the template > >This would allow on one hand sceened access with policies >and on the other hand more flexibility in data provisioning > >Thoughts? > >Richard > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum ><< smime.p7s >> >_______________________________________________ >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 enum-bounces@ietf.org Sat Feb 25 18:27:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8oP-0004mI-Ut; Sat, 25 Feb 2006 18:26:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8oP-0004mD-4t for enum@ietf.org; Sat, 25 Feb 2006 18:26:53 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FD8oO-0000aC-Ej for enum@ietf.org; Sat, 25 Feb 2006 18:26:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt Date: Sun, 26 Feb 2006 00:30:50 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4891@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt Thread-Index: AcY6XxKL17aAIeNRSgmJNjG4jbzSCAAAzi+Z From: "Stastny Richard" To: "lconroy" , "chenhui" X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: IETF ENUM WG , rohan@ekabal.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I am a bit confused =20 >For the rest of us, it looks like (X-IM:aim, X-IM:ymsgr, X-IM:icq, X- = IM:msim, X-IM:jabber, >X-IM:xmpp X-IM:skype) is still the quick answer to fire up IM clients=20 >and send messages to people. It certainly works for me. >For Skype voice calls a number of us have been using X-Skype:callto,=20 >as the Skype client registers itself as handling the "Callto:" URL = scheme, and will place=20 >a voice call if you send the URL to Windows (or MacOS). That works for = me as well :).=20 ... =20 What is the difference between am IM-session, and a voice or video = session, not to mention presenence. Some of these clients allow to change between IM and voice during the session, some dont, but are planning to add this = soon (Tello ;-). Some also provide file tranfer, desktop sharing, = white-boards. Some are standards, some are not (e.g. skype) =20 I do not complete understand the differnence between IM, pres etc URIs How does sip fit into this. Should there be a session URI? and a=20 related Enumservice? =20 Could anybody please explain how to get aout of these mess =20 Richard ________________________________ Von: lconroy [mailto:lconroy@insensate.co.uk] Gesendet: Sa 25.02.2006 23:54 An: chenhui Cc: rohan@ekabal.com; Stastny Richard; IETF ENUM WG Betreff: Re: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt Hi Chenhui, Rohan, folks, First, thanks Chenhui - from your comment I went back and re-read=20 Rohan's draft *and the RFCs it references*. I had missed a couple of crucial features in the=20 references. Now it makes much more sense. However, with regret I withdraw my comment on re-writing our clients=20 and provisioning systems to fit - this draft has a completely different model from the=20 one in use. Does anyone use the scheme proposed in RFC 2778/2779 and in RFC 3861? IIRC, several large systems *nearly* did in 2001, but will they now? Rohan's draft is the missing bit in the IETF RAI (SIP/...)=20 architecture - now there's an anointed way to do with IM what was done to Presence. As such, I'm=20 sure that it WILL progress quickly on the standards track. Somehow I don't think that the existing IM system URI schemes will=20 ever be registered, so I do not think it will be feasible to move an Enumservice like=20 (im:) through the IETF process - the IM system URIs in use in the World=20 still are not registered, so a standards track document can't refer to their specifications, so=20 it won't be acceptable. For the rest of us, it looks like (X-IM:aim, X-IM:ymsgr, X-IM:icq, X- IM:msim, X-IM:jabber, X-IM:xmpp X-IM:skype) is still the quick answer to fire up IM clients=20 and send messages to people. It certainly works for me. For Skype voice calls a number of us have been using X-Skype:callto,=20 as the Skype client registers itself as handling the "Callto:" URL scheme, and will place=20 a voice call if you send the URL to Windows (or MacOS). That works for me as well :). But...of course, in that case if you have Windoz and have installed=20 Microsoft's NetMeeting but *don't* have Skype installed, then your computer will try to=20 place an H.323 call when it sees a "Callto:" URL, and will fail. However, these days that is a=20 VERY rare problem. all the best, Lawrence On 24 Feb 2006, at 01:37, chenhui wrote: > Hi Rohan, > > The draft is a great progress to push ENUM IM service. > > We have also been considering the ENUM-IM service and developing=20 > some ENUM-IM application. > As we know, there are so many kinds of IM clients and different IM=20 > protocols, so how to intercommunication between different clients=20 > is a problem. > > "Service Type" field is used to mark the registration of IM=20 > service, but it seems limited to present the information of IM.=20 > Therefore, we suggest to add the "subtype" field. > > Regards! > Chenhui > >>> -------- Original Message -------- >>> Subject: I-D ACTION:draft-mahy-enum-im-service-00.txt >>> Date: Wed, 22 Feb 2006 15:50:02 -0500 >>> From: Internet-Drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : A Telephone Number Mapping (ENUM) Service >>> Registration for Instant Messaging (IM) Services >>> >>> Author(s) : R. Mahy >>> Filename : draft-mahy-enum-im-service-00.txt >>> Pages : 5 >>> Date : 2006-2-22 >>> This document registers a Telephone Number Mapping (ENUM) service=20 >>> for >>> Instant Messaging (IM). Specifically, this document focuses on >>> provisioning im: URIs in ENUM. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-mahy-enum-im- >>> service-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the=20 >>> body of the >>> message. >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >>> announce >>> to change your subscription settings. >>> >>> >>> Internet-Drafts are also available by anonymous FTP. Login with=20 >>> the username >>> "anonymous" and a password of your e-mail address. After logging in, >>> type "cd internet-drafts" and then >>> "get draft-mahy-enum-im-service-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-mahy-enum-im-service-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. >> >> _______________________________________________ >> 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 enum-bounces@ietf.org Sat Feb 25 18:30:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8s1-0007O3-WC; Sat, 25 Feb 2006 18:30:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8s0-0007Ny-Sk for enum@ietf.org; Sat, 25 Feb 2006 18:30:36 -0500 Received: from [213.152.49.123] (helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD8s0-0000dZ-2x for enum@ietf.org; Sat, 25 Feb 2006 18:30:36 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id DF1A07DC34; Sat, 25 Feb 2006 23:30:34 +0000 (GMT) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C488B@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C488B@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] General question on Enumservices Date: Sat, 25 Feb 2006 23:30:33 +0000 To: Richard Stastny , Alexander Mayrhofer X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: enum@ietf.org, James McEachern X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, Jim, Axel, folks, I speak as a co-author and thus having felt the pain with vovi and msg (and the rest). It has indeed been a long and winding road. However... given where we are, telephone numbers are "where it's at" for the vast majority of folk out there (for which read, customers), so telephone numbers are convenient unless and until it proves impossible to get approved registration in a single tree. I still believe that there is a place for user ENUM, and that storing contacts in this way is useful to end users. It's just taken somewhat longer than it should, in no small part due to intense discussion of alternatives and baroque definitions of consumer protection requirements. However, before Axel and the mob spend another 3 years grinding a Vcard:http Enumservice through the system and experiencing yet more pain, perhaps we should look at what we have already. Yes - one could have a LOT of NAPTRs in a zone if one includes every possible way of contacting the registrant. However, these do not have to be in the same domain/owner. Non-Terminal NAPTRs are already "on the books:, and whilst understanding how they work is fiercely difficult, they DO allow sets of contacts to be partitioned - that's what they were designed to do. Thus it IS possible to include extra NAPTRs in other domains and "point to" those with a Non-Terminal NAPTR or two. In practice, how many contacts will people publish? - I doubt most people will have more than 10 or 20, in which case partitioning into main and "auxiliary" sets is not hard at all. It may take a year to develop a client to deal with Non-Terminal NAPTRs properly, but from experience that has to be quicker than getting a Vcard Enumservice defined and approved (even in ETSI, Richard :). I also agree that the Vcard proposal still not quite removed from the drafts archive will be fine for authenticated (i.e. private/protected) access to Vcard data. It's a different use case. Personally, I would MUCH prefer it to have :http and :https sub-types, as a caller may only be interested in a secured set of data (or conversely a "public/anonymous" set), and so will process only :https or :http Vcard Enumservices. However... other than that I think it's fine. Setting up secured connections to HTTPS servers will take time and bandwidth, but for many users this is not going to be a problem. For those who don't want to wait (or pay the GPRS roaming charges 8|, let's use Non-Terminal NAPTRs. all the best, Lawrence On 24 Feb 2006, at 22:13, Stastny Richard wrote: > Jim, >> I believe the original intent of ENUM was to facilitate the smooth >> transition from E.164 numbers to SIP URIs. > > This is not correct, historically. > Funny: originally the basic idea of ENUM was exactly where we are now: > The replacement of the business card > This was killed by SPAM and privacy sherriffs. > Then for some time it looked that the only feasable enumservice was > SIP and only SIP > Some proposals from us got killed (remember vovi) and others had a > very hard time (msg) > because it was said SIP is enough, because one may do anything by > establishing > a sip session and negotiate the rest later. Eventually one may use > Pres > (I never completely understood why one needs pres if you have sip > (or IM), > but not video:sip, but I am not an AD. > Now we are round the full circle ;-) > > My position here is somewhere in the middle. I have learned that > the original business card idea putting everything in the DNS is > not so good, > but I also know you cannot do anything with SIP. The vcard approach > makes sense, > and of course we need additional Enumservices such as email:mailto, > because > not everybody has all services with one (sip) provider. > > But we should be careful not to overdo it simple because it will > get too complicated > for the end-user > >> But with all these Enumservices, we may achieve exactly the >> opposite effect, by making E.164 numbers indispensable. >> I assume this is not our intent. > > Hmm, aren't they indispensible? > > How many people can you reach via a SIP URI and how many with a > phone number? > How many large voice providers give you a sip URI? > > And I still wonder how they will provide global connectivity > with SIP URIs (public user identities) in IMS > > Richard > > _______________________________________________ > 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 enum-bounces@ietf.org Sat Feb 25 18:32:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8u6-00009Q-Ri; Sat, 25 Feb 2006 18:32:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8u4-00005X-Rh for enum@ietf.org; Sat, 25 Feb 2006 18:32:44 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FD8u3-0000j7-3r for enum@ietf.org; Sat, 25 Feb 2006 18:32:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] General question on Enumservices Date: Sun, 26 Feb 2006 00:36:40 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4892@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] General question on Enumservices Thread-Index: AcY6YFglPXCggEsNRd6WAPvVynrQtAAA0cVx From: "Stastny Richard" To: "Richard Shockey" X-Spam-Score: 0.5 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: enum@ietf.org, Mark Hewitt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >I agree many of these parameters could be included in a vcard and = indeed >should but I dont see why we should restrict individual application >submissions. >But as usual I could be wrong. Of course you are wong ;-) I already wanted to answer your previous e-mail I never said I wanted to restrict individual applications; especially because they bring forward potential use cases I just wanted a discussion if some of the may be covered also by other means Richard PS: Maybe we finally found a new killer application for (End) User ENUM to make Tony happy BYO personal Enumservice ;-) ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: So 26.02.2006 00:03 An: Stastny Richard Cc: Mark Hewitt; enum@ietf.org Betreff: Re: [Enum] General question on Enumservices Stastny Richard wrote: >> So let's think about how ENUM can support vCard rather than devise an >> entirely new protocol, service, and technology. >=20 > There seems to be a slight misunderstanding >=20 > I did not propose anything like that >=20 > On the contrary, IMHO some of the new proposed Enumservices > could be replaced by using vcard Well a reminder that the vcard draft we reviewed in Vancouver is a WG item we have not as yet seen another version. Minutes attached. I certainly thought this was a "good idea" tm. I agree many of these parameters could be included in a vcard and indeed should but I dont see why we should restrict individual application submissions. But as usual I could be wrong. IANA Registration for ENUMservice vCard 10-Min =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Author(s) : A. Mayrhofer, D. Lindner Filename : draft-mayrhofer-enum-vcard-00.txt Pages : 7 Date : 2005-10-5 =20 This memo registers the ENUMservice "vCard" using the URI schemes http" and "https" according to the IANA ENUMservice registration process described in RFC3671. This ENUMservice is to be used to refer from an ENUM domain name to the vCard of the entity using the corresponding E.164 number. Clients may use information gathered from those vCards before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before he picks up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-vcard-00.txt DISCUSSION: ENUMservice for refering from phone numbers to URIs containing vCard. Came from questions from service providers which wanted to publish. Usage scenario: query for number, receive vCard URI, fetch vCard. No subtypes defined right now, two URI schemes (http and https) proposed now. Feedback received about subtypes: Should subtypes reflect protocol? Faltstrom (as WG member): Privacy constriants, and granularity limits of HTTP. vCards could be synthesized based on authentication. HTTP not optimal for detailed access constraints. A bit nervous that usage of http is too quick. Recommend at least subtyping because good WP systems should not use http, but could be started with http now. Suggestion is to check HTTP, LDAP, IRIS Shockey: Want to see granularity on access control as well. Schiefner: Would like to see this a WG item, looking at moving that = forward. Levi ??: vCards heavily used in XMPP. Should look at this. Not sure if granularity is what people expect from publishing a vCard. Jimmy ??: Suggestions to granularity on access controls could be out of scope of the ENUM WG? Mayrhofer: Could simply say "we make the reference, what behind this is out of scope for ENUM". Faltstrom: Clarification on privacy needed. Baskin: Privacy needs to be highlighted each time. However, "ENUM" does not the vCard, ENUM just returns a reference. It's done after the = lookup. Faltstrom: Agreed, need to be subtyped to differentiated. ??: There is a draft about vCard over WebDAV in the calendaring for WebDAV. draft-debut-carddav? Schwartz: Issues on identifying when using HTTP. WG ACTION: Based on a hum of the WG, consensus for adopting this as WG = item. >=20 > Richard > > ________________________________ > > Von: Mark Hewitt [mailto:mark.hewitt@inteligy.com] > Gesendet: Fr 24.02.2006 18:31 > An: Stastny Richard; enum@ietf.org > Betreff: RE: [Enum] General question on Enumservices > > > > Richard; > > Good observation however consider for a moment that the structure of = DNS is > already well established and considered part of every basic IP device = today. > ENUM is simply a series of extensions for indexing more complex = services > than just the translation of an IP address to a name and the reverse. > > There are certainly more efficient protocols and technologies than the > weighty IP protocol today - yet it is an accepted standard - DNS is = the > same. > > Some additional extensions of services now include "Identity = Management" - > allowing for a single logon to member services and sites. > > So let's think about how ENUM can support vCard rather than devise an > entirely new protocol, service, and technology. > > > _______________________________ > > > > Mark S. Hewitt > (813) 849-7821 Direct > > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, February 24, 2006 9:27 AM > To: enum@ietf.org > Subject: [Enum] General question on Enumservices > > Folks, > > I have a general question concerning Enumservices > > Considering the bunch of the different Enumservices > popping up recently I ask myself if we are not overdoing it > > On one hand a lot of people seem to have very creative > ideas on what kind information one may link to a > communication identifier such as an E.164 number > > So we are back to the original idea of the electronic > business card. > > Bernie mentioned in context with the IM service that > one my put all is Yahoo, aol, icq, jabber etc ID into > ENUM and somebody else may try to find out which is > matching his service. > > If I add now to this the webpage, email, vcard, calendar, > eventually the old idea we had in TS 102 172 with > location (loc), and the public KEY (eh domainkey?), ... > > I see ENUM domains coming up with 20 and more entries. > > Most of this information could be put into vcard > > If not, we may consider one or two general pointers > containing all the required information, e.g. > publicinfo and privateinfo and define the template > > This would allow on one hand sceened access with policies > and on the other hand more flexibility in data provisioning > > Thoughts? > > Richard > > > _______________________________________________ > 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, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Feb 25 18:52:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD9DN-0004kA-4J; Sat, 25 Feb 2006 18:52:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD9DL-0004k5-Hf for enum@ietf.org; Sat, 25 Feb 2006 18:52:39 -0500 Received: from [213.152.49.123] (helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD9DK-0000xf-KU for enum@ietf.org; Sat, 25 Feb 2006 18:52:39 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id C3DC67DC5B; Sat, 25 Feb 2006 23:52:36 +0000 (GMT) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4891@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4891@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3CD96E0B-64F6-46E0-9F5A-82935574D378@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt Date: Sat, 25 Feb 2006 23:52:34 +0000 To: Stastny Richard X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: IETF ENUM WG , rohan@ekabal.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, folks, First, do what I should have done before hitting the send key - read RFC 2778, 2779, and 3861. Then go have a drink. Whilst you're doing that, think of the IM systems "out there" that people use that support this architecture. You may want to have another drink at this point. As the esteemed author of ETSI TS 102 172, you recall your definition of a "generic client" - with this client, an end user will look up the available contacts, select one, and use it to set up some kind of communication. Given the generic ENUM client can "fire up" an appropriate IM/Voice/Video/... program, that program will do exactly what you want. Hence including the X-IM NAPTRs is "a way into a mutually acceptable session", assuming that a suitable program exists and the end user has an account with that system. The X-Skype NAPTR merely gives a different way of starting the session - the effect is similar once the program is "up and running". For the session URI - it's called SIP. If you look at section 3 of Jon's RFC 3764 - the SIP Enumservice spec - it goes on at length about the SIP AoR and its purpose in life, and from this mailing list archive, you know that SIP is all you need for a session. I'm afraid I still don't quite understand the dance all of these protocols make, but (after a brief libation) I'm back to 2778/2779 & 3861. I live in hope of enlightenment from these standards. all the best, Lawrence On 25 Feb 2006, at 23:30, Stastny Richard wrote: > I am a bit confused > >> For the rest of us, it looks like (X-IM:aim, X-IM:ymsgr, X-IM:icq, >> X- IM:msim, X-IM:jabber, >> X-IM:xmpp X-IM:skype) is still the quick answer to fire up IM clients >> and send messages to people. It certainly works for me. > >> For Skype voice calls a number of us have been using X-Skype:callto, >> as the Skype client registers itself as handling the "Callto:" URL >> scheme, and will place >> a voice call if you send the URL to Windows (or MacOS). That works >> for me as well :). > ... > > What is the difference between am IM-session, and a voice or video > session, > not to mention presenence. Some of these clients allow to change > between > IM and voice during the session, some dont, but are planning to add > this soon > (Tello ;-). Some also provide file tranfer, desktop sharing, white- > boards. > Some are standards, some are not (e.g. skype) > > I do not complete understand the differnence between IM, pres etc URIs > How does sip fit into this. Should there be a session URI? and a > related Enumservice? > > Could anybody please explain how to get aout of these mess > > Richard > > ________________________________ > > Von: lconroy [mailto:lconroy@insensate.co.uk] > Gesendet: Sa 25.02.2006 23:54 > An: chenhui > Cc: rohan@ekabal.com; Stastny Richard; IETF ENUM WG > Betreff: Re: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt > > > > Hi Chenhui, Rohan, folks, > First, thanks Chenhui - from your comment I went back and re-read > Rohan's draft *and the > RFCs it references*. I had missed a couple of crucial features in the > references. Now it > makes much more sense. > > However, with regret I withdraw my comment on re-writing our clients > and provisioning > systems to fit - this draft has a completely different model from the > one in use. > Does anyone use the scheme proposed in RFC 2778/2779 and in RFC 3861? > IIRC, several large systems *nearly* did in 2001, but will they now? > > Rohan's draft is the missing bit in the IETF RAI (SIP/...) > architecture - now there's > an anointed way to do with IM what was done to Presence. As such, I'm > sure that it WILL > progress quickly on the standards track. > > Somehow I don't think that the existing IM system URI schemes will > ever be registered, so > I do not think it will be feasible to move an Enumservice like > (im:) > through the IETF process - the IM system URIs in use in the World > still are not registered, > so a standards track document can't refer to their specifications, so > it won't be acceptable. > > For the rest of us, it looks like (X-IM:aim, X-IM:ymsgr, X-IM:icq, X- > IM:msim, X-IM:jabber, > X-IM:xmpp X-IM:skype) is still the quick answer to fire up IM clients > and send messages > to people. It certainly works for me. > > For Skype voice calls a number of us have been using X-Skype:callto, > as the Skype client > registers itself as handling the "Callto:" URL scheme, and will place > a voice call if you > send the URL to Windows (or MacOS). That works for me as well :). > But...of course, in that case if you have Windoz and have installed > Microsoft's NetMeeting > but *don't* have Skype installed, then your computer will try to > place an H.323 call when > it sees a "Callto:" URL, and will fail. However, these days that is a > VERY rare problem. > > all the best, > Lawrence > > On 24 Feb 2006, at 01:37, chenhui wrote: >> Hi Rohan, >> >> The draft is a great progress to push ENUM IM service. >> >> We have also been considering the ENUM-IM service and developing >> some ENUM-IM application. >> As we know, there are so many kinds of IM clients and different IM >> protocols, so how to intercommunication between different clients >> is a problem. >> >> "Service Type" field is used to mark the registration of IM >> service, but it seems limited to present the information of IM. >> Therefore, we suggest to add the "subtype" field. >> >> Regards! >> Chenhui >> >>>> -------- Original Message -------- >>>> Subject: I-D ACTION:draft-mahy-enum-im-service-00.txt >>>> Date: Wed, 22 Feb 2006 15:50:02 -0500 >>>> From: Internet-Drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : A Telephone Number Mapping (ENUM) Service >>>> Registration for Instant Messaging (IM) Services >>>> >>>> Author(s) : R. Mahy >>>> Filename : draft-mahy-enum-im-service-00.txt >>>> Pages : 5 >>>> Date : 2006-2-22 >>>> This document registers a Telephone Number Mapping (ENUM) service >>>> for >>>> Instant Messaging (IM). Specifically, this document focuses on >>>> provisioning im: URIs in ENUM. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-mahy-enum-im- >>>> service-00.txt >>>> >>>> To remove yourself from the I-D Announcement list, send a >>>> message to >>>> i-d-announce-request@ietf.org with the word unsubscribe in the >>>> body of the >>>> message. >>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >>>> announce >>>> to change your subscription settings. >>>> >>>> >>>> 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-mahy-enum-im-service-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-mahy-enum-im-service-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. >>> >>> _______________________________________________ >>> 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 enum-bounces@ietf.org Sun Feb 26 15:14:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDSH1-00030q-VV; Sun, 26 Feb 2006 15:13:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDSH0-00030l-L9 for enum@ietf.org; Sun, 26 Feb 2006 15:13:42 -0500 Received: from [213.46.255.26] (helo=viefep12-int.chello.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDSGz-0005Ql-Uh for enum@ietf.org; Sun, 26 Feb 2006 15:13:42 -0500 Received: from localhost ([127.0.0.1]) by viefep12-int.chello.at (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with SMTP id <20060226201340.ILVX12753.viefep12-int.chello.at@localhost> for ; Sun, 26 Feb 2006 21:13:40 +0100 X-Mailer: Openwave WebEngine, version 2.8.16 (webedge20-101-1106-20040809) X-Originating-IP: [212.186.110.89] From: To: Subject: Re: Re: [Enum] General question on Enumservices Date: Sun, 26 Feb 2006 21:13:40 +0100 MIME-Version: 1.0 Message-Id: <20060226201340.ILVX12753.viefep12-int.chello.at@localhost> X-Spam-Score: 2.2 (++) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kurt.reichinger@chello.at List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0600005498==" Errors-To: enum-bounces@ietf.org --===============0600005498== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Dear Richard, dear colleagues, After scanning the mail traffic generated in the last days in response to Richard's "general question" I would like to comment on the issue of general need for new Enumservices. In my opinion (at least) three groups of users have to be differentiated with all of them possibly having different needs: 1. End Users maintaining their own User ENUM entries - typical usage scenarios being end user VoIP, the electronic business card case or ENUM-enabled applications (e.g. e-mail clients) 2. Providers maintaining their own Infrastructure ENUM entries - typical usage scenarios being VoIP interconnection or number portability issues 3. Third party service providers creating new services relying on publicly available data from both User and Infrastructure ENUM Looking at these three groups one can imagine that the individual players can have strongly differing needs with regard to the Enumservices available. The introduction of a new Enumservice for each and every new idea, however, will not work in terms of scalability, overall clarity and time-to-market. Instead of introducing a huge pile of new Enumservices it could be a better way forward to use generic Enumservices like the “vCard” or (my very own) “foaf” proposal. Both follow the concept of opening a door to other identifiers and services allowing e.g. RDF/XML parsers to retrieve information made available. Therefore existing and upcoming identifiers (services) could easily be accessed with Skype, flickr, del.icio.us, woo2do, 43things, writely, plazes, openomy, CalendarHub or RSS blog feeds being just a few examples. Any comments on this? Best regards, Kurt. P.S.: Don't slap me too hard as this is my first posting. ;-) > > Von: "Stastny Richard" > Datum: 2006/02/26 So AM 12:36:40 CET > An: "Richard Shockey" > Cc: enum@ietf.org, Mark Hewitt > Betreff: Re: [Enum] General question on Enumservices > > >I agree many of these parameters could be included in a vcard and indeed > >should but I dont see why we should restrict individual application > >submissions. > > >But as usual I could be wrong. > > Of course you are wong ;-) > I already wanted to answer your previous e-mail > > I never said I wanted to restrict individual applications; > especially because they bring forward potential use cases > > I just wanted a discussion if some of the may be covered also > by other means > > Richard > PS: Maybe we finally found a new killer application for (End) User ENUM > to make Tony happy > BYO personal Enumservice ;-) > > > > ________________________________ > > Von: Richard Shockey [mailto:richard@shockey.us] > Gesendet: So 26.02.2006 00:03 > An: Stastny Richard > Cc: Mark Hewitt; enum@ietf.org > Betreff: Re: [Enum] General question on Enumservices > > > > Stastny Richard wrote: > >> So let's think about how ENUM can support vCard rather than devise an > >> entirely new protocol, service, and technology. > > > > There seems to be a slight misunderstanding > > > > I did not propose anything like that > > > > On the contrary, IMHO some of the new proposed Enumservices > > could be replaced by using vcard > > Well a reminder that the vcard draft we reviewed in Vancouver is a WG > item we have not as yet seen another version. Minutes attached. I > certainly thought this was a "good idea" tm. > > > I agree many of these parameters could be included in a vcard and indeed > should but I dont see why we should restrict individual application > submissions. > > But as usual I could be wrong. > > > > IANA Registration for ENUMservice vCard 10-Min > =============================================== > > Author(s) : A. Mayrhofer, D. Lindner > Filename : draft-mayrhofer-enum-vcard-00.txt > Pages : 7 > Date : 2005-10-5 > > This memo registers the ENUMservice "vCard" using the URI schemes > http" and "https" according to the IANA ENUMservice registration process > described in RFC3671. This ENUMservice is to be used to refer from an > ENUM domain name to the vCard of the entity using the corresponding > E.164 number. > > Clients may use information gathered from those vCards before, during > or after inbound or outbound communication takes place. For example, a > callee might be presented with the name and association of the caller > before he picks up the call. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-vcard-00.txt > > > > DISCUSSION: > > ENUMservice for refering from phone numbers to URIs containing vCard. > Came from questions from service providers which wanted to publish. > Usage scenario: query for number, receive vCard URI, fetch vCard. > > No subtypes defined right now, two URI schemes (http and https) proposed > now. > > Feedback received about subtypes: Should subtypes reflect protocol? > > Faltstrom (as WG member): Privacy constriants, and granularity > limits of HTTP. vCards could be synthesized based on authentication. > HTTP not optimal for detailed access constraints. A bit nervous that > usage of http is too quick. Recommend at least subtyping because good WP > systems should not use http, but could be started > with http now. Suggestion is to check HTTP, LDAP, IRIS > > Shockey: Want to see granularity on access control as well. > > Schiefner: Would like to see this a WG item, looking at moving that forward. > > Levi ??: vCards heavily used in XMPP. Should look at this. Not sure if > granularity is what people expect from publishing a vCard. > > Jimmy ??: Suggestions to granularity on access controls could be out of > scope of the ENUM WG? > > Mayrhofer: Could simply say "we make the reference, what behind this is > out of scope for ENUM". > > Faltstrom: Clarification on privacy needed. > > Baskin: Privacy needs to be highlighted each time. However, "ENUM" does > not the vCard, ENUM just returns a reference. It's done after the lookup. > > Faltstrom: Agreed, need to be subtyped to differentiated. > > ??: There is a draft about vCard over WebDAV in the calendaring for > WebDAV. draft-debut-carddav? > > Schwartz: Issues on identifying when using HTTP. > > WG ACTION: Based on a hum of the WG, consensus for adopting this as WG item. > > > > > > > Richard > > > > ________________________________ > > > > Von: Mark Hewitt [mailto:mark.hewitt@inteligy.com] > > Gesendet: Fr 24.02.2006 18:31 > > An: Stastny Richard; enum@ietf.org > > Betreff: RE: [Enum] General question on Enumservices > > > > > > > > Richard; > > > > Good observation however consider for a moment that the structure of DNS is > > already well established and considered part of every basic IP device today. > > ENUM is simply a series of extensions for indexing more complex services > > than just the translation of an IP address to a name and the reverse. > > > > There are certainly more efficient protocols and technologies than the > > weighty IP protocol today - yet it is an accepted standard - DNS is the > > same. > > > > Some additional extensions of services now include "Identity Management" - > > allowing for a single logon to member services and sites. > > > > So let's think about how ENUM can support vCard rather than devise an > > entirely new protocol, service, and technology. > > > > > > _______________________________ > > > > > > > > Mark S. Hewitt > > (813) 849-7821 Direct > > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, February 24, 2006 9:27 AM > > To: enum@ietf.org > > Subject: [Enum] General question on Enumservices > > > > Folks, > > > > I have a general question concerning Enumservices > > > > Considering the bunch of the different Enumservices > > popping up recently I ask myself if we are not overdoing it > > > > On one hand a lot of people seem to have very creative > > ideas on what kind information one may link to a > > communication identifier such as an E.164 number > > > > So we are back to the original idea of the electronic > > business card. > > > > Bernie mentioned in context with the IM service that > > one my put all is Yahoo, aol, icq, jabber etc ID into > > ENUM and somebody else may try to find out which is > > matching his service. > > > > If I add now to this the webpage, email, vcard, calendar, > > eventually the old idea we had in TS 102 172 with > > location (loc), and the public KEY (eh domainkey?), ... > > > > I see ENUM domains coming up with 20 and more entries. > > > > Most of this information could be put into vcard > > > > If not, we may consider one or two general pointers > > containing all the required information, e.g. > > publicinfo and privateinfo and define the template > > > > This would allow on one hand sceened access with policies > > and on the other hand more flexibility in data provisioning > > > > Thoughts? > > > > Richard > > > > > > _______________________________________________ > > 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, Director - Member of Technical Staff > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > Fax: +1 815.333.1237 > or > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > 




--===============0600005498==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0600005498==--



From enum-bounces@ietf.org Sun Feb 26 17:03:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDTzE-0002HY-G1; Sun, 26 Feb 2006 17:03:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FDTzC-0002HT-Hq
	for enum@ietf.org; Sun, 26 Feb 2006 17:03:26 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FDTz8-0008Mq-79
	for enum@ietf.org; Sun, 26 Feb 2006 17:03:26 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt
Date: Sun, 26 Feb 2006 23:04:16 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4895@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt
Thread-Index: AcY6ZyA2XJhF4T2YR3+XlRpr6USsIAAuXWLJ
From: "Stastny Richard" 
To: "lconroy" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: IETF ENUM WG , rohan@ekabal.com
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

Lawrence wrote:
=20
>For the session URI - it's called SIP.
=20
Really? You don't say  ;-)
=20
The only ones seeming to remember this are the IMS people ;-)
=20
Richard
=20

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



From enum-bounces@ietf.org Mon Feb 27 02:20:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDcfq-0002Z5-VG; Mon, 27 Feb 2006 02:20:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FDcfq-0002Yu-82
	for enum@ietf.org; Mon, 27 Feb 2006 02:20:02 -0500
Received: from [213.46.255.26] (helo=viefep12-int.chello.at)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDcfo-0006fD-Qp
	for enum@ietf.org; Mon, 27 Feb 2006 02:20:02 -0500
Received: from localhost ([127.0.0.1]) by viefep12-int.chello.at
	(InterMail vM.6.01.04.04 201-2131-118-104-20050224) with SMTP
	id <20060227071957.ZHPA12753.viefep12-int.chello.at@localhost>
	for ; Mon, 27 Feb 2006 08:19:57 +0100
X-Mailer: Openwave WebEngine, version 2.8.16 (webedge20-101-1106-20040809)
X-Originating-IP: [81.223.31.34]
From: 
To: 
Subject: Re: Re: [Enum] General question on Enumservices
Date: Mon, 27 Feb 2006 8:19:57 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-Id: <20060227071957.ZHPA12753.viefep12-int.chello.at@localhost>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: kurt.reichinger@chello.at
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

Sorry for the strange formatting of my previous mail - hope this works better now.

Dear Richard, dear colleagues, 

After scanning the mail traffic generated in the last days in response to Richard's "general question" I would like to comment on the issue of general need for new Enumservices. In my opinion (at least) three groups of users have to be differentiated with all of them possibly having different needs: 

1. End Users maintaining their own User ENUM entries - typical usage scenarios being end user VoIP, the electronic business card case or ENUM-enabled applications (e.g. e-mail clients) 

2. Providers maintaining their own Infrastructure ENUM entries - typical usage scenarios being VoIP interconnection or number portability issues 

3. Third party service providers creating new services relying on publicly available data from both User and Infrastructure ENUM 

Looking at these three groups one can imagine that the individual players can have strongly differing needs with regard to the Enumservices available. The introduction of a new Enumservice for each and every new idea, however, will not work in terms of scalability, overall clarity and time-to-market. Instead of introducing a huge pile of new Enumservices it could be a better way forward to use generic Enumservices like the “vCard” or (my very own) “foaf” proposal. Both follow the concept of opening a door to other identifiers and services allowing e.g. RDF/XML parsers to retrieve information made available. Therefore existing and upcoming identifiers (services) could easily be accessed with Skype, flickr, del.icio.us, woo2do, 43things, writely, plazes, openomy, CalendarHub or RSS blog feeds being just a few examples. Any comments on this? 

Best regards,       Kurt. 



> 
> Von: 
> Datum: 2006/02/26 So PM 09:13:40 CET
> An: 
> Betreff: Re: Re: [Enum] General question on Enumservices
> 
> 


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



From enum-bounces@ietf.org Mon Feb 27 07:29:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDhVW-0005ef-1W; Mon, 27 Feb 2006 07:29:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FDhVV-0005eX-35
	for enum@ietf.org; Mon, 27 Feb 2006 07:29:41 -0500
Received: from omta02sl.mx.bigpond.com ([144.140.93.154])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDhVT-0008I5-LK
	for enum@ietf.org; Mon, 27 Feb 2006 07:29:41 -0500
Received: from MartinsTP ([60.227.39.59]) by omta02sl.mx.bigpond.com with SMTP
	id <20060227122937.VUIH18661.omta02sl.mx.bigpond.com@MartinsTP>
	for ; Mon, 27 Feb 2006 12:29:37 +0000
Message-ID: <003901c63b99$86b546e0$6400a8c0@aunz.lncorp.net>
From: "admin" 
To: 
Date: Mon, 27 Feb 2006 23:29:59 +1100
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Subject: [Enum] Re: ENUM toolbar for Firefox
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1282873210=="
Errors-To: enum-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1282873210==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0036_01C63BF5.B98FE780"

This is a multi-part message in MIME format.

------=_NextPart_000_0036_01C63BF5.B98FE780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Just letting you know that the "official" SIP Broker ENUM URL for the =
web service is:

http://www.sipbroker.com/enum/4319793321

This convention adheres to the REST web service format.

Martin
------=_NextPart_000_0036_01C63BF5.B98FE780
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Just letting you know that the =
"official" SIP=20
Broker ENUM URL for the web service is:


 


http://www.sipbroker.co=
m/enum/4319793321


 


This convention adheres to the REST web =
service=20
format.


 


Martin


------=_NextPart_000_0036_01C63BF5.B98FE780--




--===============1282873210==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1282873210==--






From enum-bounces@ietf.org Mon Feb 27 16:00:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDpUB-00077S-HG; Mon, 27 Feb 2006 16:00:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDpU7-00073K-H7; Mon, 27 Feb 2006 16:00:47 -0500
Received: from willow.neustar.com ([209.173.53.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FDpU7-0003Fv-6t; Mon, 27 Feb 2006 16:00:47 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10])
	by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k1RKo29W019358
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Feb 2006 20:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FDpJi-000733-CN; Mon, 27 Feb 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Mon, 27 Feb 2006 15:50:02 -0500
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: enum@ietf.org
Subject: [Enum] I-D ACTION:draft-ietf-enum-enumservices-guide-00.txt 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: Guide and Template for IANA Registrations of Enumervices
	Author(s)	: J. Livingood, B. Hoeneisen
	Filename	: draft-ietf-enum-enumservices-guide-00.txt
	Pages		: 12
	Date		: 2006-2-27
	
   This document provides a guide to and template for the creation of
   new IANA registration of ENUM services.  It is also to be used for
   updates of existing IANA registrations.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-enum-enumservices-guide-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-enumservices-guide-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: <2006-2-27142241.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-enumservices-guide-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-enum-enumservices-guide-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-2-27142241.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From enum-bounces@ietf.org Mon Feb 27 18:50:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDs88-00029N-AW; Mon, 27 Feb 2006 18:50:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDs7v-00022A-2l; Mon, 27 Feb 2006 18:50:03 -0500
Received: from oak.neustar.com ([209.173.53.70])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FDs7u-0007JM-MX; Mon, 27 Feb 2006 18:50:03 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10])
	by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k1RNo2BX013761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Feb 2006 23:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FDs7u-0005jH-D2; Mon, 27 Feb 2006 18:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Mon, 27 Feb 2006 18:50:02 -0500
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: enum@ietf.org
Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-token-02.txt 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: ENUM Validation Token Format Definition
	Author(s)	: O. Lendl
	Filename	: draft-ietf-enum-validation-token-02.txt
	Pages		: 16
	Date		: 2006-2-27
	
An ENUM domain name is tightly coupled with the underlying E.164
   number.  The process of verifying whether the Registrant of an ENUM
   domain name is identical to the Assignee of the corresponding E.164
   number is commonly called "validation".  This document describes an
   signed XML data format -- the Validation Token -- with which
   Validation Entities can convey successful completion of a validation
   procedure in a secure fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-enum-validation-token-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-enum-validation-token-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.

--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: <2006-2-27155112.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-validation-token-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-enum-validation-token-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-2-27155112.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From enum-bounces@ietf.org Tue Feb 28 05:48:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FE2Or-0004ZH-3S; Tue, 28 Feb 2006 05:48:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FE2Op-0004Xp-9T
	for enum@ietf.org; Tue, 28 Feb 2006 05:48:11 -0500
Received: from [213.152.49.123] (helo=norman.insensate.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE2Oo-0006ZA-Le
	for enum@ietf.org; Tue, 28 Feb 2006 05:48:11 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by norman.insensate.co.uk (Postfix) with ESMTP
	id AA0B47E0E8; Tue, 28 Feb 2006 10:48:08 +0000 (GMT)
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: lconroy 
Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-enumservices-guide-00.txt 
Date: Tue, 28 Feb 2006 10:48:07 +0000
To: IETF ENUM WG 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: Bernie Hoeneisen ,
	Jason Livingood 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

Hi folks,
   my initial reaction is "good stuff".
I like to read printouts - no tree-hugging here - so formal comments  
will follow
(especially as the section 5 ["consider update"] may involve me in  
work :).

On initial scan, I do have a couple of slight questions:

Section 3.2 states "This Enumservice indicates that the remote  
resource identified
     can be addressed by the associated URI scheme in order to foo  
the bar.".
Is this always required to be true?

Section 3.5 (Security Considerations) mandates coverage of access to  
Personally
Identifying Information. Good stuff.
Is it useful to split the Security Considerations section into two  
sub-headings
- one for protocol security issues and one for privacy/personal  
identity issues?

Again in Section 3.5, I note that the security section of an  
Enumservice registration
should not cover general issues.
Is is useful to split out the issues mentioned in the existing drafts  
and to produce
a general BCP that covers the issues mentioned already in those  
registrations (and
adds others if folk raise new issues :), including a reference to  
this BCP in each
Enumservice registration?
It would involve work to generate such a BCP, but it would deal with  
the general issues
in one place.
 From experience, this is A Good Idea, as some folk will just look at  
a single Enumservice
registration and so may miss some of the issues covered in others.
[It looks like this template proposes that the existing RFCs are to  
be considered for
re-drafting, so perhaps such a BCP could be done in concert with the  
proposed review.]

all the best,
   Lawrence

On 27 Feb 2006, at 20:50, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Telephone Number Mapping Working  
> Group of the IETF.
>
> 	Title		: Guide and Template for IANA Registrations of Enumervices
> 	Author(s)	: J. Livingood, B. Hoeneisen
> 	Filename	: draft-ietf-enum-enumservices-guide-00.txt
> 	Pages		: 12
> 	Date		: 2006-2-27
> 	
>    This document provides a guide to and template for the creation of
>    new IANA registration of ENUM services.  It is also to be used for
>    updates of existing IANA registrations.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices- 
> guide-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body  
> of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the  
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-enum-enumservices-guide-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-enum-enumservices-guide-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: <2006-2-27142241.I-D@ietf.org>
>
> ENCODING mime
> FILE /internet-drafts/draft-ietf-enum-enumservices-guide-00.txt
> _______________________________________________
> 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 enum-bounces@ietf.org Tue Feb 28 08:25:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FE4rF-0003v9-Mn; Tue, 28 Feb 2006 08:25:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FE4rE-0003uk-Cu
	for enum@ietf.org; Tue, 28 Feb 2006 08:25:40 -0500
Received: from central.switch.ch ([130.59.11.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE4rD-0003Ux-3L
	for enum@ietf.org; Tue, 28 Feb 2006 08:25:40 -0500
Received: from machb.switch.ch ([130.59.6.129])
	by central.switch.ch with esmtp (Exim 3.20 #1)
	id 1FE4rB-00000g-00; Tue, 28 Feb 2006 14:25:37 +0100
Date: Tue, 28 Feb 2006 14:25:31 +0100 (CET)
From: Bernie Hoeneisen 
X-X-Sender: bhoeneis@machb
To: lconroy 
Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-enumservices-guide-00.txt 
In-Reply-To: 
Message-ID: 
References: 
	
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: IETF ENUM WG ,
	Jason Livingood 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

Hi Lawrence

Thanks for your good comments.

On Tue, 28 Feb 2006, lconroy wrote:

> Section 3.2 states "This Enumservice indicates that the remote resource 
> identified
>   can be addressed by the associated URI scheme in order to foo the bar.".
> Is this always required to be true?

This is meant as an example. I think the content of such a section depends 
on the Enumservice to be registered.

> Section 3.5 (Security Considerations) mandates coverage of access to 
> Personally Identifying Information. Good stuff. Is it useful to split 
> the Security Considerations section into two sub-headings - one for 
> protocol security issues and one for privacy/personal identity issues?

IMHO this makes sense.

> Again in Section 3.5, I note that the security section of an Enumservice 
> registration should not cover general issues.
> Is is useful to split out the issues mentioned in the existing drafts 
> and to produce a general BCP that covers the issues mentioned already in 
> those registrations (and adds others if folk raise new issues :), 
> including a reference to this BCP in each Enumservice registration?
> It would involve work to generate such a BCP, but it would deal with the 
> general issues in one place.
> From experience, this is A Good Idea, as some folk will just look at a 
> single Enumservice registration and so may miss some of the issues 
> covered in others.

IMHO it makes sense to have the general issues at one place, where those 
can be referred to. I guess we'd have to find a clear structure for this 
to keep it manageable.

> [It looks like this template proposes that the existing RFCs are to be 
> considered for re-drafting, so perhaps such a BCP could be done in 
> concert with the proposed review.]

Hmmmm....Looks like a bigger concert...;-)

cheers
  Bernie

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



From enum-bounces@ietf.org Tue Feb 28 13:27:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FE9ZO-0007TZ-4J; Tue, 28 Feb 2006 13:27:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9ZM-0007TJ-Rj
	for enum@ietf.org; Tue, 28 Feb 2006 13:27:32 -0500
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE9ZM-00059k-D3
	for enum@ietf.org; Tue, 28 Feb 2006 13:27:32 -0500
Received: from ([10.20.62.13])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH3.17295086;
	Tue, 28 Feb 2006 13:27:02 -0500
Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by
	PACDCEXCRLY01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 13:27:01 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 28 Feb 2006 13:27:00 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A403@PACDCEXCMB01.cable.comcast.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Section 3.2 of draft-ietf-enum-enumservices-guide-00 
Thread-Index: AcY74PzZhgIgUJWMThatbL+7L82+nQAprMrQ
From: "Livingood, Jason" 
To: 
X-OriginalArrivalTime: 28 Feb 2006 18:27:01.0619 (UTC)
	FILETIME=[913D7C30:01C63C94]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Subject: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

I would like to point out section 3.2 and ask for some specific WG
feedback.  Here is the text:

   This section MUST be included in an Enumservice registration.  In
   addition, where a given registration type has multiple subtypes,
   there MUST be a separate registration section for each subtype.  The
   following lists the sections and order of an Enumservice Registration
   section.  All types and subtypes SHOULD be listed in lower-case.

This took into account WG feedback to have a separate Enumservice
registration section for each sub-type (a given I-D could therefore have
several registrations). =20

The question we now have is...  What about when there are multiple URI
schemes for a given sub-types? =20

This is, for example, what was done in RFC 4002, where the URIs http and
https each had separate registrations, as each URI was tied to a
specific sub-type that matched the URI scheme.  (URI=3Dhttp,
sub-type=3Dhttp, and URI=3Dhttps, sub-type=3Dhttps)

In contrast, RFC 3764, has multiple URIs given type (no sub-type is
registered).

Our tendency is to assert that these may be guiding principles:
1.  A sub-type should always be specified.
2.  There should be a separate registration for each sub-type.
3.  There should be a separate sub-type for each URI scheme.

Thanks for your feedback,
Jason



> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20
> Sent: Monday, February 27, 2006 3:50 PM
> To: i-d-announce@ietf.org
> Cc: enum@ietf.org
> Subject: [Enum] I-D ACTION:draft-ietf-enum-enumservices-guide-00.txt=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Telephone Number Mapping=20
> Working Group of the IETF.
>=20
> 	Title		: Guide and Template for IANA=20
> Registrations of Enumervices
> 	Author(s)	: J. Livingood, B. Hoeneisen
> 	Filename	: draft-ietf-enum-enumservices-guide-00.txt
> 	Pages		: 12
> 	Date		: 2006-2-27
> =09
>    This document provides a guide to and template for the creation of
>    new IANA registration of ENUM services.  It is also to be used for
>    updates of existing IANA registrations.
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservic
> es-guide-00.txt
>=20
> To remove yourself from the I-D Announcement list, send a=20
> message to i-d-announce-request@ietf.org with the word=20
> unsubscribe in the body of the message. =20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login=20
> with the username "anonymous" and a password of your e-mail=20
> address. After logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-enum-enumservices-guide-00.txt".
>=20
> A list of Internet-Drafts directories can be found in=20
> http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE=20
> /internet-drafts/draft-ietf-enum-enumservices-guide-00.txt".
> =09
> 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=20
> 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.
> 	=09
> 	=09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20

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



From enum-bounces@ietf.org Tue Feb 28 13:41:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FE9mb-0008Ij-H4; Tue, 28 Feb 2006 13:41:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9ma-0008G4-V6
	for enum@ietf.org; Tue, 28 Feb 2006 13:41:12 -0500
Received: from mail124.messagelabs.com ([85.158.136.19])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FE9ma-0005av-FP
	for enum@ietf.org; Tue, 28 Feb 2006 13:41:12 -0500
X-VirusChecked: Checked
X-Env-Sender: ppfautz@att.com
X-Msg-Ref: server-6.tower-124.messagelabs.com!1141152069!7290407!2
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 6364 invoked from network); 28 Feb 2006 18:41:10 -0000
Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4)
	by server-6.tower-124.messagelabs.com with SMTP;
	28 Feb 2006 18:41:10 -0000
Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by
	attrh2i.attrh.att.com (7.2.052)
	id 43F8A5440016794D; Tue, 28 Feb 2006 13:41:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00 
Date: Tue, 28 Feb 2006 13:41:09 -0500
Message-ID: <34DA635B184A644DA4588E260EC0A25A0C3F31B6@ACCLUST02EVS1.ugd.att.com>
In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302A3A403@PACDCEXCMB01.cable.comcast.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00 
Thread-Index: AcY74PzZhgIgUJWMThatbL+7L82+nQAprMrQAAOQXoA=
From: "Pfautz, Penn L, NEO" 
To: "Livingood, Jason" ,
	
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

Jason:
Actually, one the things that I like about the current draft was the
indication (in the XML template) that sub-type was not always required
("use N/A if none") as this accommodates non-terminal NAPTRs. Thus, the
guideline,
=20
1.  A sub-type should always be specified.

Needs to be reworded to make clear when subtypes are or aren't required.

Penn
-----Original Message-----
From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20
Sent: Tuesday, February 28, 2006 1:27 PM
To: enum@ietf.org
Subject: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00


I would like to point out section 3.2 and ask for some specific WG
feedback.  Here is the text:

   This section MUST be included in an Enumservice registration.  In
   addition, where a given registration type has multiple subtypes,
   there MUST be a separate registration section for each subtype.  The
   following lists the sections and order of an Enumservice Registration
   section.  All types and subtypes SHOULD be listed in lower-case.

This took into account WG feedback to have a separate Enumservice
registration section for each sub-type (a given I-D could therefore have
several registrations). =20

The question we now have is...  What about when there are multiple URI
schemes for a given sub-types? =20

This is, for example, what was done in RFC 4002, where the URIs http and
https each had separate registrations, as each URI was tied to a
specific sub-type that matched the URI scheme.  (URI=3Dhttp,
sub-type=3Dhttp, and URI=3Dhttps, sub-type=3Dhttps)

In contrast, RFC 3764, has multiple URIs given type (no sub-type is
registered).

Our tendency is to assert that these may be guiding principles:
1.  A sub-type should always be specified.
2.  There should be a separate registration for each sub-type.
3.  There should be a separate sub-type for each URI scheme.

Thanks for your feedback,
Jason



> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20
> Sent: Monday, February 27, 2006 3:50 PM
> To: i-d-announce@ietf.org
> Cc: enum@ietf.org
> Subject: [Enum] I-D ACTION:draft-ietf-enum-enumservices-guide-00.txt=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Telephone Number Mapping=20
> Working Group of the IETF.
>=20
> 	Title		: Guide and Template for IANA=20
> Registrations of Enumervices
> 	Author(s)	: J. Livingood, B. Hoeneisen
> 	Filename	: draft-ietf-enum-enumservices-guide-00.txt
> 	Pages		: 12
> 	Date		: 2006-2-27
> =09
>    This document provides a guide to and template for the creation of
>    new IANA registration of ENUM services.  It is also to be used for
>    updates of existing IANA registrations.
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservic
> es-guide-00.txt
>=20
> To remove yourself from the I-D Announcement list, send a=20
> message to i-d-announce-request@ietf.org with the word=20
> unsubscribe in the body of the message. =20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login=20
> with the username "anonymous" and a password of your e-mail=20
> address. After logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-enum-enumservices-guide-00.txt".
>=20
> A list of Internet-Drafts directories can be found in=20
> http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE=20
> /internet-drafts/draft-ietf-enum-enumservices-guide-00.txt".
> =09
> 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=20
> 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.
> 	=09
> 	=09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20

_______________________________________________
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 enum-bounces@ietf.org Tue Feb 28 16:33:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FECTV-0006pa-N4; Tue, 28 Feb 2006 16:33:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FEC4M-0005AM-8g
	for enum@ietf.org; Tue, 28 Feb 2006 16:07:42 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FEC4I-0004MK-NY
	for enum@ietf.org; Tue, 28 Feb 2006 16:07:41 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00 
Date: Tue, 28 Feb 2006 22:10:35 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C489C@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00 
Thread-Index: AcY74PzZhgIgUJWMThatbL+7L82+nQAprMrQAAOQXoAABQmcaw==
From: "Stastny Richard" 
To: "Pfautz, Penn L, NEO" ,
	"Livingood, Jason" , 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

My (our) opinion is well known: I prefer
3.  There should be a separate sub-type for each URI scheme.

Re to Penns question:

Lets not mix up this with Enumservices and non-terminal
NAPTRs. IMHO we should dicuss the issue of non-terminal NAPTRs
separate, i.e if non-terminals should contain an Enumservice or
may not contain an Enumservice at all, and if they should contain =
subtypes

see Otmars I-D
http://www.ietf.org/internet-drafts/draft-lendl-domain-policy-ddds-00.txt=


on policy NAPTRs:

 An empty (non-existent) flag means that this rule is non-terminal and
   the client MUST use the key resulting from this rule as the input
   into a new DDDS loop.  Such non-terminal NAPTRs MUST NOT contain a
   policy-type element in the service-field.

I do not suggest yet any answer, but we should have a
statement in an eventual RFC3761bis, to make this clear.

regards

Richard







________________________________

Von: Pfautz, Penn L, NEO [mailto:ppfautz@att.com]
Gesendet: Di 28.02.2006 19:41
An: Livingood, Jason; enum@ietf.org
Betreff: RE: [Enum] RE: Section 3.2 of =
draft-ietf-enum-enumservices-guide-00=20



Jason:
Actually, one the things that I like about the current draft was the
indication (in the XML template) that sub-type was not always required
("use N/A if none") as this accommodates non-terminal NAPTRs. Thus, the
guideline,

1.  A sub-type should always be specified.

Needs to be reworded to make clear when subtypes are or aren't required.

Penn
-----Original Message-----
From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
Sent: Tuesday, February 28, 2006 1:27 PM
To: enum@ietf.org
Subject: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00


I would like to point out section 3.2 and ask for some specific WG
feedback.  Here is the text:

   This section MUST be included in an Enumservice registration.  In
   addition, where a given registration type has multiple subtypes,
   there MUST be a separate registration section for each subtype.  The
   following lists the sections and order of an Enumservice Registration
   section.  All types and subtypes SHOULD be listed in lower-case.

This took into account WG feedback to have a separate Enumservice
registration section for each sub-type (a given I-D could therefore have
several registrations).=20

The question we now have is...  What about when there are multiple URI
schemes for a given sub-types?=20

This is, for example, what was done in RFC 4002, where the URIs http and
https each had separate registrations, as each URI was tied to a
specific sub-type that matched the URI scheme.  (URI=3Dhttp,
sub-type=3Dhttp, and URI=3Dhttps, sub-type=3Dhttps)

In contrast, RFC 3764, has multiple URIs given type (no sub-type is
registered).

Our tendency is to assert that these may be guiding principles:
1.  A sub-type should always be specified.
2.  There should be a separate registration for each sub-type.
3.  There should be a separate sub-type for each URI scheme.

Thanks for your feedback,
Jason



> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Monday, February 27, 2006 3:50 PM
> To: i-d-announce@ietf.org
> Cc: enum@ietf.org
> Subject: [Enum] I-D ACTION:draft-ietf-enum-enumservices-guide-00.txt
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Telephone Number Mapping
> Working Group of the IETF.
>
>       Title           : Guide and Template for IANA
> Registrations of Enumervices
>       Author(s)       : J. Livingood, B. Hoeneisen
>       Filename        : draft-ietf-enum-enumservices-guide-00.txt
>       Pages           : 12
>       Date            : 2006-2-27
>     =20
>    This document provides a guide to and template for the creation of
>    new IANA registration of ENUM services.  It is also to be used for
>    updates of existing IANA registrations.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservic
> es-guide-00.txt
>
> To remove yourself from the I-D Announcement list, send a
> message to i-d-announce-request@ietf.org with the word
> unsubscribe in the body of the message.=20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login
> with the username "anonymous" and a password of your e-mail
> address. After logging in, type "cd internet-drafts" and then
>       "get draft-ietf-enum-enumservices-guide-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>       mailserv@ietf.org.
> In the body type:
>       "FILE
> /internet-drafts/draft-ietf-enum-enumservices-guide-00.txt".
>     =20
> 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.
>             =20
>             =20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

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

_______________________________________________
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 enum-bounces@ietf.org Tue Feb 28 18:42:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEETW-0007BA-R5; Tue, 28 Feb 2006 18:41:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FEETV-0007B5-By
	for enum@ietf.org; Tue, 28 Feb 2006 18:41:49 -0500
Received: from [213.152.49.123] (helo=norman.insensate.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEETU-0005OA-C2
	for enum@ietf.org; Tue, 28 Feb 2006 18:41:49 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by norman.insensate.co.uk (Postfix) with ESMTP
	id 74CA77E44F; Tue, 28 Feb 2006 23:41:46 +0000 (GMT)
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C489C@oefeg-s04.oefeg.loc>
References: <32755D354E6B65498C3BD9FD496C7D462C489C@oefeg-s04.oefeg.loc>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3BCD6CE0-672F-4161-BA57-95770D462F27@insensate.co.uk>
Content-Transfer-Encoding: 7bit
From: lconroy 
Subject: Re: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00 
Date: Tue, 28 Feb 2006 23:41:44 +0000
To: Stastny Richard 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b
Cc: enum@ietf.org, "Livingood, Jason" ,
	"Pfautz, Penn L, NEO" 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

Hi Richard, Penn, folks,
  Like he said. Sub-types are good.
Even with SIP, the type is typically the kind of thing you do (all
that wonderful negotiation, rendezvous, and stuff), whilst SIP is
also the protocol you use to carry the exchanges to do it. In that
particular case, the two are and always will be synonymous.
For pretty much everything else, that you can't always be so sure.

As we should not "look right" (to the RegExpfield) in the NAPTR, the
sub-type is a good place to indicate the protocol used.
RFC 4355 is a good example, as MMS is the thing to do, whilst this
can be done via mailto: or tel:. Likewise for Web, via http: or https:.
Personally, I would *always* like a sub-type holding the protocol,
even if it is a duplicate. It also makes parsing the Services field
easier :)

----
Re. Non-Terminals (again).
This was discussed on this list last year. Indeed, IIRC, Penn raised it.
The conclusion then was that it is not possible with RFC 3761 to do this
- it isn't just the sub-type that's the problem, it's the whole thing.
This is already mentioned in the Experiences draft.

To recap the situation:
Any Enumservice registration MUST specify the "something" it does,
as well as the protocol it uses to do it; That's tied (in ENUM) to
the 'u' flag, indicating that the result is a URI.
A Non-terminal does not generate a URI to do something, it holds a
domain name in which to search. Thus the 'u' flag (and an Enumservice
registration) is inappropriate.

At present, ENUM only specifies the 'u' flag or no flag (an empty
flags field). It states that this lack of a flag means that this NAPTR
is non-terminal (and by implication, uses the replacement field to hold
the domain name). Note that other DDDS applications make this  
assumption,
so we can't just re-interpret an empty flags field without causing a
potential collision with searches being carried out with other DDDS
applications (not to mention confusing the poor developers further :).

New idea, new work - If we want to do something else in ENUM, then (as
I said last time this came up):
(i) we need to add a new flag, specifying that this flag is non- 
terminal,
and whether it uses the replacement field or the regexp field to hold or
generate its domain name (i.e. the key to be used in the next query on
the only rule store defined for use with ENUM -> DNS).
(ii) We need to define a new "Non-terminal Enumservice" registration
process that is tied to that flag (in the same way that there is now
the current Enumservice registration process tied to the 'u' flag).
(iii) IF this new flag indicates that the RegExp field is to be used to
construct a domain name, then we will need to specify quite how it is  
used.

This can be done, it could even be a neat idea, but it is not trivial.
I suspect that (iii) will take some effort to define in enough detail to
be usable/possible to implement securely. It will be fun. Perhaps we
can discuss this at the upcoming "high bandwidth exchange" in Dallas?

However, any such new work has nothing at all to do with the existing
(terminal, tied to the 'u' flag) Enumservice registration process as
specified in RFC 3761. Gaining consistency in THAT process is what the
template draft is trying to clear up, and does well, IMHO.
----

all the best,
   Lawrence

On 28 Feb 2006, at 21:10, Stastny Richard wrote:
> My (our) opinion is well known: I prefer
> 3.  There should be a separate sub-type for each URI scheme.
>
> Re to Penns question:
>
> Lets not mix up this with Enumservices and non-terminal
> NAPTRs. IMHO we should dicuss the issue of non-terminal NAPTRs
> separate, i.e if non-terminals should contain an Enumservice or
> may not contain an Enumservice at all, and if they should contain  
> subtypes
>
> see Otmars I-D
> http://www.ietf.org/internet-drafts/draft-lendl-domain-policy- 
> ddds-00.txt
>
> on policy NAPTRs:
>
>  An empty (non-existent) flag means that this rule is non-terminal and
>    the client MUST use the key resulting from this rule as the input
>    into a new DDDS loop.  Such non-terminal NAPTRs MUST NOT contain a
>    policy-type element in the service-field.
>
> I do not suggest yet any answer, but we should have a
> statement in an eventual RFC3761bis, to make this clear.
>
> regards
>
> Richard
>
>
>
>
>
>
>
> ________________________________
>
> Von: Pfautz, Penn L, NEO [mailto:ppfautz@att.com]
> Gesendet: Di 28.02.2006 19:41
> An: Livingood, Jason; enum@ietf.org
> Betreff: RE: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices- 
> guide-00
>
>
>
> Jason:
> Actually, one the things that I like about the current draft was the
> indication (in the XML template) that sub-type was not always required
> ("use N/A if none") as this accommodates non-terminal NAPTRs. Thus,  
> the
> guideline,
>
> 1.  A sub-type should always be specified.
>
> Needs to be reworded to make clear when subtypes are or aren't  
> required.
>
> Penn
> -----Original Message-----
> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
> Sent: Tuesday, February 28, 2006 1:27 PM
> To: enum@ietf.org
> Subject: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices- 
> guide-00
>
>
> I would like to point out section 3.2 and ask for some specific WG
> feedback.  Here is the text:
>
>    This section MUST be included in an Enumservice registration.  In
>    addition, where a given registration type has multiple subtypes,
>    there MUST be a separate registration section for each subtype.   
> The
>    following lists the sections and order of an Enumservice  
> Registration
>    section.  All types and subtypes SHOULD be listed in lower-case.
>
> This took into account WG feedback to have a separate Enumservice
> registration section for each sub-type (a given I-D could therefore  
> have
> several registrations).
>
> The question we now have is...  What about when there are multiple URI
> schemes for a given sub-types?
>
> This is, for example, what was done in RFC 4002, where the URIs  
> http and
> https each had separate registrations, as each URI was tied to a
> specific sub-type that matched the URI scheme.  (URI=http,
> sub-type=http, and URI=https, sub-type=https)
>
> In contrast, RFC 3764, has multiple URIs given type (no sub-type is
> registered).
>
> Our tendency is to assert that these may be guiding principles:
> 1.  A sub-type should always be specified.
> 2.  There should be a separate registration for each sub-type.
> 3.  There should be a separate sub-type for each URI scheme.
>
> Thanks for your feedback,
> Jason
>
>
>
>> -----Original Message-----
>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>> Sent: Monday, February 27, 2006 3:50 PM
>> To: i-d-announce@ietf.org
>> Cc: enum@ietf.org
>> Subject: [Enum] I-D ACTION:draft-ietf-enum-enumservices-guide-00.txt
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>> This draft is a work item of the Telephone Number Mapping
>> Working Group of the IETF.
>>
>>       Title           : Guide and Template for IANA
>> Registrations of Enumervices
>>       Author(s)       : J. Livingood, B. Hoeneisen
>>       Filename        : draft-ietf-enum-enumservices-guide-00.txt
>>       Pages           : 12
>>       Date            : 2006-2-27
>>
>>    This document provides a guide to and template for the creation of
>>    new IANA registration of ENUM services.  It is also to be used for
>>    updates of existing IANA registrations.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservic
>> es-guide-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a
>> message to i-d-announce-request@ietf.org with the word
>> unsubscribe in the body of the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- 
>> announce
>> to change your subscription settings.
>>
>>
>> Internet-Drafts are also available by anonymous FTP. Login
>> with the username "anonymous" and a password of your e-mail
>> address. After logging in, type "cd internet-drafts" and then
>>       "get draft-ietf-enum-enumservices-guide-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>       mailserv@ietf.org.
>> In the body type:
>>       "FILE
>> /internet-drafts/draft-ietf-enum-enumservices-guide-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.
>>
>
> _______________________________________________
> 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


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



From enum-bounces@ietf.org Tue Feb 28 19:36:12 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEFK0-00045o-U2; Tue, 28 Feb 2006 19:36:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FEFK0-00045I-9X
	for enum@ietf.org; Tue, 28 Feb 2006 19:36:04 -0500
Received: from mail124.messagelabs.com ([85.158.136.19])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FEFJy-0002b9-Pu
	for enum@ietf.org; Tue, 28 Feb 2006 19:36:04 -0500
X-VirusChecked: Checked
X-Env-Sender: ppfautz@att.com
X-Msg-Ref: server-6.tower-124.messagelabs.com!1141173337!7299588!5
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 1555 invoked from network); 1 Mar 2006 00:36:01 -0000
Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4)
	by server-6.tower-124.messagelabs.com with SMTP;
	1 Mar 2006 00:36:01 -0000
Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by
	attrh2i.attrh.att.com (7.2.052)
	id 43F8A54400178C99 for enum@ietf.org; Tue, 28 Feb 2006 19:36:00 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00 
Date: Tue, 28 Feb 2006 19:35:57 -0500
Message-ID: <34DA635B184A644DA4588E260EC0A25A0C41ED35@ACCLUST02EVS1.ugd.att.com>
In-Reply-To: <3BCD6CE0-672F-4161-BA57-95770D462F27@insensate.co.uk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00 
Thread-Index: AcY8wJZNXxV7Q5BCQqSCZEZGqQve/QABnNUw
From: "Pfautz, Penn L, NEO" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

 Lawrence,
I don't want to belabor this as I'm not even sure that *I* wish to go
forward with the non-terminals but I'm not sure the working group came
to a consensus that non-terminals were generally not workable. They
clearly have their limitations with the regard to the specific problem
space I wanted to use them in - mostly because of the POSIX's weak-kneed
string processing capabilities (:-). The (non-binding) hum in Paris
indicated a strong preference for alternate or branching domains for
meeting the carrier ENUM need and I accept that.

If the WG is really ready to ban non-terminals than we should agree
formally and reflect it in the guidelines draft.

Regards,
Penn

-----Original Message-----
From: lconroy [mailto:lconroy@insensate.co.uk]=20
Sent: Tuesday, February 28, 2006 6:42 PM
To: Stastny Richard
Cc: Pfautz, Penn L, NEO; Livingood, Jason; enum@ietf.org
Subject: Re: [Enum] RE: Section 3.2 of
draft-ietf-enum-enumservices-guide-00=20

Hi Richard, Penn, folks,
  Like he said. Sub-types are good.
Even with SIP, the type is typically the kind of thing you do (all
that wonderful negotiation, rendezvous, and stuff), whilst SIP is
also the protocol you use to carry the exchanges to do it. In that
particular case, the two are and always will be synonymous.
For pretty much everything else, that you can't always be so sure.

As we should not "look right" (to the RegExpfield) in the NAPTR, the
sub-type is a good place to indicate the protocol used.
RFC 4355 is a good example, as MMS is the thing to do, whilst this
can be done via mailto: or tel:. Likewise for Web, via http: or https:.
Personally, I would *always* like a sub-type holding the protocol,
even if it is a duplicate. It also makes parsing the Services field
easier :)

----
Re. Non-Terminals (again).
This was discussed on this list last year. Indeed, IIRC, Penn raised it.
The conclusion then was that it is not possible with RFC 3761 to do this
- it isn't just the sub-type that's the problem, it's the whole thing.
This is already mentioned in the Experiences draft.

To recap the situation:
Any Enumservice registration MUST specify the "something" it does,
as well as the protocol it uses to do it; That's tied (in ENUM) to
the 'u' flag, indicating that the result is a URI.
A Non-terminal does not generate a URI to do something, it holds a
domain name in which to search. Thus the 'u' flag (and an Enumservice
registration) is inappropriate.

At present, ENUM only specifies the 'u' flag or no flag (an empty
flags field). It states that this lack of a flag means that this NAPTR
is non-terminal (and by implication, uses the replacement field to hold
the domain name). Note that other DDDS applications make this =20
assumption,
so we can't just re-interpret an empty flags field without causing a
potential collision with searches being carried out with other DDDS
applications (not to mention confusing the poor developers further :).

New idea, new work - If we want to do something else in ENUM, then (as
I said last time this came up):
(i) we need to add a new flag, specifying that this flag is non-=20
terminal,
and whether it uses the replacement field or the regexp field to hold or
generate its domain name (i.e. the key to be used in the next query on
the only rule store defined for use with ENUM -> DNS).
(ii) We need to define a new "Non-terminal Enumservice" registration
process that is tied to that flag (in the same way that there is now
the current Enumservice registration process tied to the 'u' flag).
(iii) IF this new flag indicates that the RegExp field is to be used to
construct a domain name, then we will need to specify quite how it is =20
used.

This can be done, it could even be a neat idea, but it is not trivial.
I suspect that (iii) will take some effort to define in enough detail to
be usable/possible to implement securely. It will be fun. Perhaps we
can discuss this at the upcoming "high bandwidth exchange" in Dallas?

However, any such new work has nothing at all to do with the existing
(terminal, tied to the 'u' flag) Enumservice registration process as
specified in RFC 3761. Gaining consistency in THAT process is what the
template draft is trying to clear up, and does well, IMHO.
----

all the best,
   Lawrence

On 28 Feb 2006, at 21:10, Stastny Richard wrote:
> My (our) opinion is well known: I prefer
> 3.  There should be a separate sub-type for each URI scheme.
>
> Re to Penns question:
>
> Lets not mix up this with Enumservices and non-terminal
> NAPTRs. IMHO we should dicuss the issue of non-terminal NAPTRs
> separate, i.e if non-terminals should contain an Enumservice or
> may not contain an Enumservice at all, and if they should contain =20
> subtypes
>
> see Otmars I-D
> http://www.ietf.org/internet-drafts/draft-lendl-domain-policy-=20
> ddds-00.txt
>
> on policy NAPTRs:
>
>  An empty (non-existent) flag means that this rule is non-terminal and
>    the client MUST use the key resulting from this rule as the input
>    into a new DDDS loop.  Such non-terminal NAPTRs MUST NOT contain a
>    policy-type element in the service-field.
>
> I do not suggest yet any answer, but we should have a
> statement in an eventual RFC3761bis, to make this clear.
>
> regards
>
> Richard
>
>
>
>
>
>
>
> ________________________________
>
> Von: Pfautz, Penn L, NEO [mailto:ppfautz@att.com]
> Gesendet: Di 28.02.2006 19:41
> An: Livingood, Jason; enum@ietf.org
> Betreff: RE: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-=20
> guide-00
>
>
>
> Jason:
> Actually, one the things that I like about the current draft was the
> indication (in the XML template) that sub-type was not always required
> ("use N/A if none") as this accommodates non-terminal NAPTRs. Thus, =20
> the
> guideline,
>
> 1.  A sub-type should always be specified.
>
> Needs to be reworded to make clear when subtypes are or aren't =20
> required.
>
> Penn
> -----Original Message-----
> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
> Sent: Tuesday, February 28, 2006 1:27 PM
> To: enum@ietf.org
> Subject: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-=20
> guide-00
>
>
> I would like to point out section 3.2 and ask for some specific WG
> feedback.  Here is the text:
>
>    This section MUST be included in an Enumservice registration.  In
>    addition, where a given registration type has multiple subtypes,
>    there MUST be a separate registration section for each subtype.  =20
> The
>    following lists the sections and order of an Enumservice =20
> Registration
>    section.  All types and subtypes SHOULD be listed in lower-case.
>
> This took into account WG feedback to have a separate Enumservice
> registration section for each sub-type (a given I-D could therefore =20
> have
> several registrations).
>
> The question we now have is...  What about when there are multiple URI
> schemes for a given sub-types?
>
> This is, for example, what was done in RFC 4002, where the URIs =20
> http and
> https each had separate registrations, as each URI was tied to a
> specific sub-type that matched the URI scheme.  (URI=3Dhttp,
> sub-type=3Dhttp, and URI=3Dhttps, sub-type=3Dhttps)
>
> In contrast, RFC 3764, has multiple URIs given type (no sub-type is
> registered).
>
> Our tendency is to assert that these may be guiding principles:
> 1.  A sub-type should always be specified.
> 2.  There should be a separate registration for each sub-type.
> 3.  There should be a separate sub-type for each URI scheme.
>
> Thanks for your feedback,
> Jason
>
>
>
>> -----Original Message-----
>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>> Sent: Monday, February 27, 2006 3:50 PM
>> To: i-d-announce@ietf.org
>> Cc: enum@ietf.org
>> Subject: [Enum] I-D ACTION:draft-ietf-enum-enumservices-guide-00.txt
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>> This draft is a work item of the Telephone Number Mapping
>> Working Group of the IETF.
>>
>>       Title           : Guide and Template for IANA
>> Registrations of Enumervices
>>       Author(s)       : J. Livingood, B. Hoeneisen
>>       Filename        : draft-ietf-enum-enumservices-guide-00.txt
>>       Pages           : 12
>>       Date            : 2006-2-27
>>
>>    This document provides a guide to and template for the creation of
>>    new IANA registration of ENUM services.  It is also to be used for
>>    updates of existing IANA registrations.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservic
>> es-guide-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a
>> message to i-d-announce-request@ietf.org with the word
>> unsubscribe in the body of the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-=20
>> announce
>> to change your subscription settings.
>>
>>
>> Internet-Drafts are also available by anonymous FTP. Login
>> with the username "anonymous" and a password of your e-mail
>> address. After logging in, type "cd internet-drafts" and then
>>       "get draft-ietf-enum-enumservices-guide-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>       mailserv@ietf.org.
>> In the body type:
>>       "FILE
>> /internet-drafts/draft-ietf-enum-enumservices-guide-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 =20
>> documentation on
>>       how to manipulate these messages.
>>
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
>
> _______________________________________________
> 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 enum-bounces@ietf.org Tue Feb 28 20:30:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEGAe-00023o-Eh; Tue, 28 Feb 2006 20:30:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FEGAc-00023H-MQ
	for enum@ietf.org; Tue, 28 Feb 2006 20:30:26 -0500
Received: from [213.152.49.123] (helo=norman.insensate.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEGAc-0004He-7P
	for enum@ietf.org; Tue, 28 Feb 2006 20:30:26 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by norman.insensate.co.uk (Postfix) with ESMTP
	id 716117E4BF; Wed,  1 Mar 2006 01:30:24 +0000 (GMT)
In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0C41ED35@ACCLUST02EVS1.ugd.att.com>
References: <34DA635B184A644DA4588E260EC0A25A0C41ED35@ACCLUST02EVS1.ugd.att.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: lconroy 
Subject: Re: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00 
Date: Wed, 1 Mar 2006 01:30:23 +0000
To: "Pfautz, Penn L, NEO" 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

Hi Penn, folks,
   OK - I was not clear.
I don't think that Non-terminals are a bad idea. They're just hard to
understand and to test the clients we develop to support them. In fact,
I think that there definitely IS a place for Non-terminals, and would
be very unhappy with any decision to BAN them before we have had a
chance to play with them properly.

The Experiences draft already states that one should not use them for
"prime time" as many clients do not yet support them - that is not at
all the same as saying that they should be banned.

The new ideas we kicked around last year were interesting, and I'm
pretty sure could be added as I listed - it's just not trivial, and
there was a simpler way of solving the Carrier ENUM issue (i.e. one
that does not involve a lot of waiting around for a enhanced and
re-written standard to grind through the process ;).

Personally, I think that it would be a lot of fun to add a new flag.
However, in practice it would take some time - 3761 was not exactly
"fast out of the traps" in replacing 2916. Thus maybe we defer doing
that for the future - It's something to discuss in Dallas.

I suspect that the existing Non-terminal mechanism works for a lot
of different use cases - few have really tried them out yet in ENUM.
They may well be enough for even fairly whacky situations - just
not quite right for User/Carrier splits.

all the best,
   Lawrence

On 1 Mar 2006, at 00:35, Pfautz, Penn L, NEO wrote:
>  Lawrence,
> I don't want to belabor this as I'm not even sure that *I* wish to go
> forward with the non-terminals but I'm not sure the working group came
> to a consensus that non-terminals were generally not workable. They
> clearly have their limitations with the regard to the specific problem
> space I wanted to use them in - mostly because of the POSIX's weak- 
> kneed
> string processing capabilities (:-). The (non-binding) hum in Paris
> indicated a strong preference for alternate or branching domains for
> meeting the carrier ENUM need and I accept that.
>
> If the WG is really ready to ban non-terminals than we should agree
> formally and reflect it in the guidelines draft.
>
> Regards,
> Penn


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



From enum-bounces@ietf.org Tue Feb 28 20:52:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEGW7-00076j-Ky; Tue, 28 Feb 2006 20:52:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEGW3-0006zM-EE; Tue, 28 Feb 2006 20:52:35 -0500
Received: from nit.isi.edu ([128.9.160.116])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FEGW2-0005QI-2c; Tue, 28 Feb 2006 20:52:35 -0500
Received: from nit.isi.edu (loopback [127.0.0.1])
	by nit.isi.edu (8.12.8/8.12.8) with ESMTP id k211qXWV010902;
	Tue, 28 Feb 2006 17:52:33 -0800
Received: (from apache@localhost)
	by nit.isi.edu (8.12.8/8.12.8/Submit) id k211qX3B010901;
	Tue, 28 Feb 2006 17:52:33 -0800
Date: Tue, 28 Feb 2006 17:52:33 -0800
Message-Id: <200603010152.k211qX3B010901@nit.isi.edu>
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
X-Spam-Score: -14.8 (--------------)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: enum@ietf.org, rfc-editor@rfc-editor.org
Subject: [Enum] RFC 4414 on An ENUM Registry Type for the Internet Registry
	Information Service (IRIS)
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4414

        Title:      An ENUM Registry Type for 
                    the Internet Registry Information Service (IRIS) 
        Author:     A. Newton
        Status:     Standards Track
        Date:       February 2006
        Mailbox:    andy@hxr.us
        Pages:      51
        Characters: 89985
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-enum-iris-ereg-02.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4414.txt

This document describes an Internet Registry Information Service
(IRIS) registry schema for registered ENUM information.  The schema
extends the necessary query and result operations of IRIS to provide
the functional information service needs for syntaxes and results used
by ENUM registries.  [STANDARDS TRACK]

This document is a product of the Telephone Number Mapping
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization state
and status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...



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



From enum-bounces@ietf.org Tue Feb 28 22:38:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEIAO-0000QK-3L; Tue, 28 Feb 2006 22:38:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FEIAN-0000QE-1o
	for enum@ietf.org; Tue, 28 Feb 2006 22:38:19 -0500
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEIAL-0001ng-Q0
	for enum@ietf.org; Tue, 28 Feb 2006 22:38:19 -0500
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k213cD029845; Tue, 28 Feb 2006 22:38:13 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] General question on Enumservices
Date: Tue, 28 Feb 2006 22:38:07 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] General question on Enumservices
Thread-Index: AcY5TmHYXgYCZShoTJ2fQcq69q+l2gAO59BAAADGS7IA0uRhoA==
From: "James McEachern" 
To: "Stastny Richard" , 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

Richard,
I fully understand that E.164 numbers are indispensable in the short =
term.  My question was whether the intent was to make E.164 numbers =
more, or less, important in the long term.=20

Jim=20

-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20
Sent: Friday, February 24, 2006 5:13 PM
To: McEachern, James [CAR:5N00:EXCH]; enum@ietf.org
Subject: Re: [Enum] General question on Enumservices


>But with all these Enumservices, we may achieve exactly the opposite =
effect, by making E.164 numbers indispensable.=20
>I assume this is not our intent.
=20
Hmm, aren't they indispensible?

How many people can you reach via a SIP URI and how many with a phone =
number?
How many large voice providers give you a sip URI?=20

And I still wonder how they will provide global connectivity
with SIP URIs (public user identities) in IMS

Richard


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



From enum-bounces@ietf.org Tue Feb 28 22:39:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEIBY-00015V-Ul; Tue, 28 Feb 2006 22:39:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FEIBY-00015Q-6S
	for enum@ietf.org; Tue, 28 Feb 2006 22:39:32 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]
	helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FEIBW-0001s8-QY
	for enum@ietf.org; Tue, 28 Feb 2006 22:39:32 -0500
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k213dC027179; Tue, 28 Feb 2006 22:39:12 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] General question on Enumservices
Date: Tue, 28 Feb 2006 22:38:57 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Enum] General question on Enumservices
Thread-Index: AcY5tOQNVdolVu+VQN+l2UZJM9tprgDJMw5w
From: "James McEachern" 
To: "Richard Shockey" ,
	"Michael Hammer \(mhammer\)" 
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: enum-bounces@ietf.org

Richard,
You correctly point out that=20

> ... there are two globally reckonized naming and addressing schemes =
for=20
> communications. E.164 and the ICANN domain root.

> ENUM is the definitive mapping between the two.

Part of my earlier point was that ENUM may be the definitive mapping, =
but it is only a one way mapping, which effectively makes E.164 the =
definitive global addressing scheme.  Maybe I'm missing something here, =
but this still seems ironic for an IETF working group.

Jim


-----Original Message-----
From: Richard Shockey [mailto:richard@shockey.us]=20
Sent: Friday, February 24, 2006 9:40 PM
To: Michael Hammer (mhammer)
Cc: enum@ietf.org; Stastny Richard; Scott Bradner; Tony Rutkowski
Subject: Re: [Enum] General question on Enumservices

Michael Hammer (mhammer) wrote:
> In the end, which number/name is the index (business card) to the =
others
> is arbitrary.
>=20
> The choice of E.164 number is an artifact of the fact that phones have
> keypads (0-9, #, *) and most of the world uses phones, while access to
> computers is not as universal.


and E.164 numbers are linguistically neutral. We cannot forget there are =

two globally reckonized naming and addressing schemes for=20
communications. E.164 and the ICANN domain root.

ENUM is the definitive mapping between the two.

All others are private silo, such as most IM or P2P systems and skype.=20
These have their place in the world.
>=20
> Beyond that, the main concern is to have an address associated with a
> protocol (need that clue) that can be used to further the
> communications.

I have to admit that some of this discussion over Enumservice=20
registrations is mildly amusing to me. I too have vacillated between=20
what is caller vs called party control of communications and I tried to=20
touch on this in my security and privacy draft that I'm continuing to=20
review.

I see no reason to restrict what Enumservices should be registered=20
..this is what markets are for.  We will not decide what prevails.


 >>
 >> ENUM is cool.  However, the administrative challenges and
 >> sorting out of the associated burdens and costs is non-trivial.
 >>
 >> --tony


Tony .. you admitting that ENUM is 'cool' after all these years is high=20
praise indeed. :-) Many of us remember when you thought otherwise.

Best wishes as always,

 >>
 >>

>=20
> Mike
>=20
>=20
>> -----Original Message-----
>> From: Tony Rutkowski [mailto:trutkowski@verisign.com]=20
>> Sent: Friday, February 24, 2006 5:47 PM
>> To: Stastny Richard; enum@ietf.org
>> Subject: Re: [Enum] General question on Enumservices
>>
>> Hi Richard,
>>
>>> 2. USER ENUM is for the End User =3D Customer The service is =
providing=20
>>> him a domain in ENUM He is willing to pay for this only if=20
>> it gives him=20
>>> some value the more value (more potential use) he gets out=20
>> of it, the=20
>>> more he is willing to use it AND in addition the user is pointing in =

>>> ENUM again to services. So the more services he may point to, the=20
>>> better for service providers
>> All of this is nice in theory.  However, it's apparent that=20
>> the nature of the services being provided as well as the=20
>> interactions among multiple kinds of providers of services=20
>> associated with a single number is significantly more complex=20
>> for both the user and providers involved, as well as subject=20
>> to all kinds of authentications as part of the associated
>> administrative processes.   Someone will bear those costs
>> and it's not clear who will want to get left "holding the=20
>> bag" for some flat rate, and be unable to charge for=20
>> supplementary services.  So the cost model remains unclear.
>>
>> Additionally, all the nations of the world add substantial=20
>> regulatory, justice, and security burdens on top of this=20
>> identifier system that get more complex and extensive by the=20
>> day.  (Check out today's FCC delegation of number
>> pooling to the State Commissions.)   At last check, these
>> burdens include:  number portability, priority access,=20
>> roaming, directory assistance, callerid, disability=20
>> assistance, language preference, personal emergency=20
>> (E112/911), law enforcement assistance (including data=20
>> retention in many countries), public emergency alerts,=20
>> donotcall, intercarrier compensation, service provider specification.
>>
>> ENUM is cool.  However, the administrative challenges and=20
>> sorting out of the associated burdens and costs is non-trivial.
>>
>> --tony=20
>>
>>

--=20


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
 or

 ; 
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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


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