From clive@demon.net Wed, 01 Sep 2004 11:49:51 -0400 From: "Clive D.W. Feather" Date: Wed, 01 Sep 2004 11:49:51 -0400 To: "Fullbrook Kim (UK)" Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <20040901103340.GT26877@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Fullbrook Kim (UK) said: > Just to confirm that my views on privacy are as summarised by Mike. If the > ENUM database contains the same information as the number portability > database there can't be any privacy concerns because this same information > is already available. Where? Which telco provides service to +44 1954 780223? To +44 7973 377646? -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bhoeneis@switch.ch Fri, 03 Sep 2004 10:27:32 -0400 From: Bernie Hoeneisen Date: Fri, 03 Sep 2004 10:27:32 -0400 To: "Hollenbeck, Scott" Subject: Re: [Enum] LAST CALL E.164 mapping for EPP In-Reply-To: <6.1.0.6.2.20040811204833.03cb4ec0@joy.songbird.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Scott et al.! I guess reference [2] needs some update. The URL points to the updated version of Feb 04, whereas in the reference text this is October 2000: In the I/D: [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, . http://www.w3.org/TR/REC-xml: W3C Recommendation 04 February 2004 This version: http://www.w3.org/TR/2004/REC-xml-20040204 Latest version: http://www.w3.org/TR/REC-xml Previous version: http://www.w3.org/TR/2003/PER-xml-20031030 cheers, Bernie On Wed, 11 Aug 2004, Richard Shockey wrote: It was the consensus of the WG in San Diego that we proceed to last call with this document. 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 2 weeks from today to at least Friday August 27 though we can modify that if new issues come up. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : E.164 Number Mapping for the Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-05.txt Pages : 17 Date : 2004-8-10 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-05.txt Richard Shockey, Senior Manager, Strategic Technology Initiatives 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From shollenbeck@verisign.com Fri, 03 Sep 2004 10:48:26 -0400 From: "Hollenbeck, Scott" Date: Fri, 03 Sep 2004 10:48:26 -0400 To: "'Bernie Hoeneisen'" Subject: RE: [Enum] LAST CALL E.164 mapping for EPP Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF040D8019@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Yup. Thanks for catching this, Bernie. Since XML itself has not changed, I need to update the text. -Scott- > -----Original Message----- > From: Bernie Hoeneisen [mailto:bhoeneis at switch.ch] > Sent: Friday, September 03, 2004 10:19 AM > To: Hollenbeck, Scott; Richard Shockey > Cc: enum at ietf.org; paf at cisco.com; Jon Peterson; mankin at psg.com > Subject: Re: [Enum] LAST CALL E.164 mapping for EPP > > > Hi Scott et al.! > > I guess reference [2] needs some update. The URL points to > the updated > version of Feb 04, whereas in the reference text this is October 2000: > > > In the I/D: > > [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, > "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, > October 2000, . > > > http://www.w3.org/TR/REC-xml: > > W3C Recommendation 04 February 2004 > > This version: > http://www.w3.org/TR/2004/REC-xml-20040204 > Latest version: > http://www.w3.org/TR/REC-xml > Previous version: > http://www.w3.org/TR/2003/PER-xml-20031030 > > > cheers, > Bernie > > > On Wed, 11 Aug 2004, Richard Shockey wrote: > > > It was the consensus of the WG in San Diego that we proceed > to last call with > > this document. > > > > 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 2 weeks from today to > at least Friday > > August 27 though we can modify that if new issues come up. > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Telephone Number Mapping > Working Group of > > the IETF. > > > > Title : E.164 Number Mapping for the Extensible > > Provisioning Protocol > > Author(s) : S. Hollenbeck > > Filename : draft-ietf-enum-epp-e164-05.txt > > Pages : 17 > > Date : 2004-8-10 > > > > This document describes an Extensible Provisioning Protocol (EPP) > > extension mapping for the provisioning and management of E.164 > > numbers representing domain names stored in a shared central > > repository. Specified in XML, this mapping extends the EPP domain > > name mapping to provide additional features required for the > > provisioning of E.164 numbers. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-05.txt > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Richard Shockey, Senior Manager, Strategic Technology Initiatives > > 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 at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 03 Sep 2004 11:37:59 -0400 From: Richard Shockey Date: Fri, 03 Sep 2004 11:37:59 -0400 To: "Hollenbeck, Scott" Subject: RE: [Enum] LAST CALL E.164 mapping for EPP In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF040D8019@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <6.1.0.6.2.20040903112446.041c5850@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 10:41 AM 9/3/2004, Hollenbeck, Scott wrote: Yup. Thanks for catching this, Bernie. Since XML itself has not changed, I need to update the text. Scott I think this can be done by the RFC editor. Other than that I think I can declare last call over. -Scott- > -----Original Message----- > From: Bernie Hoeneisen [mailto:bhoeneis at switch.ch] > Sent: Friday, September 03, 2004 10:19 AM > To: Hollenbeck, Scott; Richard Shockey > Cc: enum at ietf.org; paf at cisco.com; Jon Peterson; mankin at psg.com > Subject: Re: [Enum] LAST CALL E.164 mapping for EPP > > > Hi Scott et al.! > > I guess reference [2] needs some update. The URL points to > the updated > version of Feb 04, whereas in the reference text this is October 2000: > > > In the I/D: > > [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, > "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, > October 2000, . > > > http://www.w3.org/TR/REC-xml: > > W3C Recommendation 04 February 2004 > > This version: > http://www.w3.org/TR/2004/REC-xml-20040204 > Latest version: > http://www.w3.org/TR/REC-xml > Previous version: > http://www.w3.org/TR/2003/PER-xml-20031030 > > > cheers, > Bernie > > > On Wed, 11 Aug 2004, Richard Shockey wrote: > > > It was the consensus of the WG in San Diego that we proceed > to last call with > > this document. > > > > 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 2 weeks from today to > at least Friday > > August 27 though we can modify that if new issues come up. > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Telephone Number Mapping > Working Group of > > the IETF. > > > > Title : E.164 Number Mapping for the Extensible > > Provisioning Protocol > > Author(s) : S. Hollenbeck > > Filename : draft-ietf-enum-epp-e164-05.txt > > Pages : 17 > > Date : 2004-8-10 > > > > This document describes an Extensible Provisioning Protocol (EPP) > > extension mapping for the provisioning and management of E.164 > > numbers representing domain names stored in a shared central > > repository. Specified in XML, this mapping extends the EPP domain > > name mapping to provide additional features required for the > > provisioning of E.164 numbers. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-05.txt > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Richard Shockey, Senior Manager, Strategic Technology Initiatives > > 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 at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 03 Sep 2004 12:21:00 -0400 From: Richard Shockey Date: Fri, 03 Sep 2004 12:21:00 -0400 To: iesg-secretary at ietf.org Subject: [Enum] RESEND - Request to Publish draft-ietf-enum-epp-e164-05.txt Message-ID: <6.1.0.6.2.20040903120308.05053b40@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R This is a request for publication for one IETF ENUM WG working group document. WG last call on this document concluded on August 27, 2004 The document listed below is being proposed for Standards Track RFC. Status- Proposed Standard This document is a ENUM Working Group product, which has been extensively discussed during 2003 and 2004. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : E.164 Number Mapping for the Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-05.txt Pages : 17 Date : 2004-8-10 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-05.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 03 Sep 2004 14:54:24 -0400 From: Richard Shockey Date: Fri, 03 Sep 2004 14:54:24 -0400 To: proceedings at ietf.org Subject: [Enum] ENUM WG Minutes IETF 60 San Diego Message-ID: <6.1.0.6.2.20040903113506.041c7b50@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Telephone Number Mapping WG (enum) IETF 60 San Diego Wed August 2, 2004 1300-1500 Afternoon Sessions Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin =============================== SCRIBE: Chris Celeberti - Patrik Faltstrom - Jabber AGENDA BASHING (5 min) ( appointment of scribe etc) 130-1300 Break 1300-1500 Afternoon Sessions I I TSV enum Telephone and Number Mapping WG AGENDA BASHING (5 min) No objections to the Agenda being reordered from that posted. # 1 Disposition of [ 10 Min] Title : E.164 Number Mapping for the Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-04.txt Pages : 17 Date : 2004-6-8 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-04.txt Scott H: The central question is what will the WG do with the document since it has been lying around for some time. Chair. How many people have read the document ( 5-10) Chair: Does anyone have issues with document ?( 0 ) Chair : Scott what do you think ..Experimental or Proposed? Scott H. Experimental is generally for documents that have dragons we know of else it can be proposed standard. Other EPP extensions have been proposed if this needs to be revised in the future. Chair: So proposed path is to update the document once to reflect current drafts etc and then go to last call. Objections ? None stated. Stastny: Allison what is the current state of the service registrations? Allison: There have been some well known problems with ID tracker where the documents got lost in cyberspace so those should proceed asap. 2: Review of the ENUM Operations Document [ 10 Min] Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-00.txt Pages : 0 Date : 2004-7-12 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-00.txt Fujiwara: Co author of document could not come. General presentation of the document. Issues separated into server side and client side issues. Discussion of issues involving Non-Terminal NAPTR records. Question as to whether there is any need for discussion of non-terminal NAPTR records. Chair: Is anyone contemplating using non terminal NAPTR records? (no answer) Conclusion - draft enum experiences is close to being finished and ready for submission for last call etc. Further discussion on the list. #3 ENUM VOID [ 10 Min] Title : IANA Registration for enumservice void Author(s) : R. Stastny, L. Conroy Filename : draft-stastny-enum-void-00.txt Pages : 7 Date : 2004-7-13 This document registers the 'ENUMservice' 'void' using the URI scheme 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761 [2]. This 'ENUMservice' SHALL be used to indicate that the E.164 number or E.164 number range connected to the domain used in DNS as described in [2] is not assigned to an end-user in case of an E.164 number or to a communication service provider in case of an E.164 number range. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stastny-enum-void-00.txt Stastny: Overall issue is that for ENUM end user is controlling what is registered in the zone ..If no registration is made an NXDOMAIN results from a query in DNS. The result of this is a default condition of passing to the PSTN. Some NRA's now assigning specific E.164 number ranges for ENUM use such as +43780 in Austria. Calls using this range can only be addressed using ENUM. User agents don know the special call is for VoIP. It would be better if the origination caller gets a response from the DNS indicating the number is in a "unassigned" state. ENUM service called "VOID" should say the number is unused and not assigned to and end user then can then be used by NRA's and carriers for blocks for which they have been allocated but not assigned. ENUM service is 'void' subtype mail to URI scheme mailto: Shockey: What happens if a user doesnt want any email address published at all? From iesg-secretary@ietf.org Tue, 07 Sep 2004 13:22:50 -0400 From: The IESG Date: Tue, 07 Sep 2004 13:22:50 -0400 To: IETF-Announce Subject: [Enum] Protocol Action: 'IANA Registration for ENUMservices web and ft' to Proposed Standard Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R The IESG has approved the following document: - 'IANA Registration for ENUMservices web and ft ' as a Proposed Standard This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document registers the Enumservices 'web' and 'ft' using the URI schemes 'http:', 'https:' and 'ftp:' following the IANA registration process defined in the ENUM specification RFC 3761. Working Group Summary The working group supported this Enumservice. Protocol Quality Registrations using these services have been deployed. Allison Mankin reviewed this document for the IESG. RFC Editor Notes 1. Abstract OLD: This document registers the 'ENUMservices' [3] 'web' and 'ft' using the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification RFC3761 [3]. NEW: This document registers the Enumservices 'web' and 'ft' using the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification RFC 3761. 3833 ------ 2. In Section 6.2, add to reference [15], an Informative reference [16] to RFC 3833. ------ 3. Section 4 OLD: This ENUMservice indicates that the resource identified by the associated URI scheme is a file service from which a file or file listing can be retrieved. NEW: This Enumservice indicates that the resource identified by the associated URI scheme is a service usable in the manner specified for ftp: in RFC 1738, for instance, file retrieval. [Add a normative reference to RFC 1738]. ------- 4. Replace ENUMservice(s) and "ENUMservice(s)" with Enumservice in the title and throughout. This follows the usage of RFC 3761, which defines the term. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Tue, 07 Sep 2004 22:19:34 -0400 From: Jeff Williams Date: Tue, 07 Sep 2004 22:19:34 -0400 To: The IESG Subject: Re: [Enum] Protocol Action: 'IANA Registration for ENUMservices web and ft' to Proposed Standard In-Reply-To: Message-ID: <413E871C.929640B5@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear secretariat and all, Not surprising to yet again see the IESG screw up again. As Mr. Shokey know full well this proposed "Standard" is not in keeping with any consensus from the ENUM working group. The IESG wrote: > The IESG has approved the following document: > > - 'IANA Registration for ENUMservices web and ft ' > as a Proposed Standard > > This document is the product of the Telephone Number Mapping Working Group. > > The IESG contact persons are Allison Mankin and Jon Peterson. > > Technical Summary > > This document registers the Enumservices 'web' and 'ft' using > the URI schemes 'http:', 'https:' and 'ftp:' following the IANA > registration process defined in the ENUM specification RFC 3761. > > Working Group Summary > > The working group supported this Enumservice. > > Protocol Quality > > Registrations using these services have been deployed. Allison Mankin > reviewed this document for the IESG. > > RFC Editor Notes > > 1. > Abstract > OLD: > This document registers the 'ENUMservices' [3] 'web' and 'ft' using > the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA > registration process defined in the ENUM specification RFC3761 [3]. > > NEW: > This document registers the Enumservices 'web' and 'ft' using > the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA > registration process defined in the ENUM specification RFC 3761. > 3833 > ------ > 2. > In Section 6.2, add to reference [15], an Informative reference [16] to RFC > 3833. > ------ > 3. > Section 4 > OLD: > This ENUMservice indicates that the resource identified by the > associated URI scheme is a file service from which a file or file > listing can be retrieved. > > NEW: > > This Enumservice indicates that the resource identified by the > associated URI scheme is a service usable in the manner specified > for ftp: in RFC 1738, for instance, file retrieval. > > [Add a normative reference to RFC 1738]. > > ------- > 4. > Replace ENUMservice(s) and "ENUMservice(s)" with Enumservice in the > title and throughout. This follows the usage of RFC 3761, which > defines the term. > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Wed, 08 Sep 2004 10:52:47 -0400 From: Richard Shockey Date: Wed, 08 Sep 2004 10:52:47 -0400 To: Jeff Williams Subject: Re: [Enum] Protocol Action: 'IANA Registration for ENUMservices web and ft' to Proposed Standard In-Reply-To: Message-ID: <6.1.0.6.2.20040908102942.037c3eb0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 12:14 AM 9/8/2004, Jeff Williams wrote: Dear secretariat and all, Not surprising to yet again see the IESG screw up again. As Mr. Shokey know full well this proposed "Standard" is not in keeping with any consensus from the ENUM working group. > - 'IANA Registration for ENUMservices web and ft ' > as a Proposed Standard The document in question was given extensive discussion in the context of RFC 3761 and the IANA registration process for enumservices. The documentary record is quite clear on this. All proper procedures were taken in accordance with RFC 2026. There was no objections raised at Working Group Last call and the documents were then properly submitted for publication. As usual, Mr. Williams you have obviously not taken the time or trouble to read RFC 2026 which defines the Internet Standards Process, other wise you would know that you would have had one last avenue of appeal during IESG last call. But again ...you raised no objection then either. In the future I would appreciate it if A. you could spell my name correctly. B. confine your future remarks to WG items at hand. ################# Date: Tue, 17 Jun 2003 10:24:55 -0400 To: enum at ietf.org From: Richard Shockey Cc: paf at cisco.com, mankin at psg.com, jon.peterson at neustar.biz Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] ENUM Working Last Call on two enumservice field documents. Sender: enum-admin at ietf.org Errors-To: enum-admin at ietf.org X-BeenThere: enum at ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Status: This is a formal request for final comments within the IETF ENUM WG working group for two documents. The documents listed below are being proposed for forwarding on to the IESG for consideration as Standards Track RFC. These documents are working group products, which have been discussed during 2002-2003. 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. The 2 week Last Call will begin immediately and will end on July 2 at 12PM EST Title : Registration for enumservices of group messages Author(s) : R. Brandner et al. Filename : draft-ietf-enum-msg-00.txt Pages : 17 Date : 2003-6-16 This document registers a group of 'enumservices' [5] to be used to indicate that the associated resources are capable of receiving discrete messages. Specifically, the 'enumservices' registered with this document are 'email', 'fax', 'sms', 'ems' and 'mms' using the URI schemes 'mailto:' and 'tel:'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-00.txt ################# Title : Registration for enumservices web and ft Author(s) : R. Brandner et al. Filename : draft-ietf-enum-webft-00.txt Pages : 13 Date : 2003-6-16 This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are primarily sources for information. Specifically, the 'enumservices' registered with this document are 'web' and 'ft' using the URI schemes 'http:', 'https:' and 'ftp:'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-webft-00.txt ################# X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 11 Aug 2004 15:35:00 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: enum at ietf.org Subject: [Enum] Last Call: 'IANA Registration for ENUMservices web and ft' to Proposed Standard X-BeenThere: enum at ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg at ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces at ietf.org Errors-To: enum-bounces at ietf.org Status: The IESG has received a request from the Telephone Number Mapping WG to consider the following document: - 'IANA Registration for ENUMservices web and ft ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg at ietf.org or ietf at ietf.org mailing lists by 2004-08-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-webft-01.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Wed, 08 Sep 2004 11:35:16 -0400 From: Richard Shockey Date: Wed, 08 Sep 2004 11:35:16 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-bartosiewicz-enterprise-enum-01.txt Message-ID: <6.1.0.6.2.20040908113020.03880ce0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R FYI To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Tue, 07 Sep 2004 12:16:07 -0400 Subject: I-D ACTION:draft-bartosiewicz-enterprise-enum-01.txt X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Cost optimization based on Enterprise-ENUM Author(s) : A. Bartosiewicz Filename : draft-bartosiewicz-enterprise-enum-01.txt Pages : 0 Date : 2004-9-3 This paper presents an extension of NAPTR Resource Records and an application of the local DNS (called in further part of this document 'Enterprise -ENUM') in order to keep information required for costs optimization of telecommunication connections. The optimization should cover the cost reduction through the selection of cheapest form of telecommunication connections for the calling party (a person initializing a telecommunication connection). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bartosiewicz-enterprise-enum-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-bartosiewicz-enterprise-enum-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-bartosiewicz-enterprise-enum-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. Content-Type: text/plain Content-ID: <2004-9-7124426.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-bartosiewicz-enterprise-enum-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Thu, 09 Sep 2004 08:10:32 -0400 From: Jeff Williams Date: Thu, 09 Sep 2004 08:10:32 -0400 To: Richard Shockey Subject: Re: [Enum] Protocol Action: 'IANA Registration for ENUMservices web and ft' to Proposed Standard In-Reply-To: Message-ID: <41406150.1D6A057F@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard and all, I am sorry I mis-keyed your name. However my comments were directed *Percisely* to the WG activities. Perhaps your reading skills are limited, or you did not adequately interpret my previous comments properly? I fully recognize that neestar folks have a nagging habit of doing so more frequently than reasonable... :/ Richard Shockey wrote: > At 12:14 AM 9/8/2004, Jeff Williams wrote: > > >Dear secretariat and all, > > > > Not surprising to yet again see the IESG screw up again. As Mr. Shokey > >know full well this proposed "Standard" is not in keeping with any consensus > >from the ENUM working group. > > > - 'IANA Registration for ENUMservices web and ft ' > > > as a Proposed Standard > > The document in question was given extensive discussion in the context of > RFC 3761 and the IANA registration process for enumservices. The > documentary record is quite clear on this. > > All proper procedures were taken in accordance with RFC 2026. > > There was no objections raised at Working Group Last call and the documents > were then properly submitted for publication. > > As usual, Mr. Williams you have obviously not taken the time or trouble to > read RFC 2026 which defines the Internet Standards Process, other wise you > would know that you would have had one last avenue of appeal during IESG > last call. But again ...you raised no objection then either. > > In the future I would appreciate it if A. you could spell my name > correctly. B. confine your future remarks to WG items at hand. > > ################# > > Date: Tue, 17 Jun 2003 10:24:55 -0400 > To: enum at ietf.org > From: Richard Shockey > Cc: paf at cisco.com, mankin at psg.com, jon.peterson at neustar.biz > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii"; format=flowed > Subject: [Enum] ENUM Working Last Call on two enumservice field documents. > Sender: enum-admin at ietf.org > Errors-To: enum-admin at ietf.org > X-BeenThere: enum at ietf.org > X-Mailman-Version: 2.0.12 > Precedence: bulk > List-Unsubscribe: , > > List-Id: Enum Discussion List > List-Post: > List-Help: > List-Subscribe: , > > Status: > > This is a formal request for final comments within the IETF ENUM WG > working group for two documents. The documents listed below are being > proposed for forwarding on to the IESG for consideration as Standards Track > RFC. > > These documents are working group products, which have been discussed > during 2002-2003. > > 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. > > The 2 week Last Call will begin immediately and will end on July 2 at 12PM EST > > Title : Registration for enumservices of group messages > Author(s) : R. Brandner et al. > Filename : draft-ietf-enum-msg-00.txt > Pages : 17 > Date : 2003-6-16 > > This document registers a group of 'enumservices' [5] to be used to > indicate that the associated resources are capable of receiving > discrete messages. > Specifically, the 'enumservices' registered with this document are > 'email', 'fax', 'sms', 'ems' and 'mms' using the URI schemes > 'mailto:' and 'tel:'. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-00.txt > > ################# > > Title : Registration for enumservices web and ft > Author(s) : R. Brandner et al. > Filename : draft-ietf-enum-webft-00.txt > Pages : 13 > Date : 2003-6-16 > > This document registers a group of 'enumservices' [2] to be used to > indicate that the associated resources are primarily sources for > information. > Specifically, the 'enumservices' registered with this document are > 'web' and 'ft' using the URI schemes 'http:', 'https:' and 'ftp:'. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-webft-00.txt > > ################# > > X-test-idtracker: no > To: IETF-Announce > From: The IESG > Message-Id: > Date: Wed, 11 Aug 2004 15:35:00 -0400 > X-Spam-Score: 0.0 (/) > X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad > Cc: enum at ietf.org > Subject: [Enum] Last Call: 'IANA Registration for ENUMservices web and ft' > to Proposed Standard > X-BeenThere: enum at ietf.org > X-Mailman-Version: 2.1.5 > Precedence: list > Reply-To: iesg at ietf.org > List-Id: Enum Discussion List > List-Unsubscribe: , > > List-Post: > List-Help: > List-Subscribe: , > > Sender: enum-bounces at ietf.org > Errors-To: enum-bounces at ietf.org > Status: > > The IESG has received a request from the Telephone Number Mapping WG to > consider the following document: > > - 'IANA Registration for ENUMservices web and ft ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg at ietf.org or ietf at ietf.org mailing lists by 2004-08-25. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-enum-webft-01.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > 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 > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@eunet.at Thu, 09 Sep 2004 08:51:09 -0400 From: Michael Haberler Date: Thu, 09 Sep 2004 08:51:09 -0400 To: enum-trial at lists.nic.at Subject: [Enum] +43 ENUM operations contract - english version, press release online Message-ID: <6.1.2.0.2.20040909143019.08548ec0@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R on August 24 enum.at GmbH concluded the operations contract for the Austrian ENUM service (3.4.e164.arpa). The english version of the contract is now online at: http://www.rtr.at/web.nsf/lookuid/37ECAC2EFFDD8063C1256F0A0041B3F9/$file/ENUM_Agreement.pdf A press release about this contract can be found at: http://www.enum.at/egc.pdf Michael Haberler Internet Foundation Austria _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mankin@psg.com Thu, 09 Sep 2004 13:33:17 -0400 From: Allison Mankin Date: Thu, 09 Sep 2004 13:33:17 -0400 To: Richard Shockey Subject: Re: [Enum] Protocol Action: 'IANA Registration for ENUMservices web and ft' to Proposed Standard In-Reply-To: <6.1.0.6.2.20040908102942.037c3eb0@joy.songbird.com> Message-ID: <200409091725.NAA05763@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Rich, all, I support the Working Group and IETF/IESG on this Protocol Action (as is clear from my having brought the document through successful Last Call and IESG review). On another note, please remove iesg-secretary from any further cc list. It is an address for the support system and creates a new ticket for each email that goes there. Allison _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@O2.COM Mon, 13 Sep 2004 11:29:21 -0400 From: "Fullbrook Kim (UK)" Date: Mon, 13 Sep 2004 11:29:21 -0400 To: "'enum at ietf.org> Subject: [Enum] Call Routing Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: Call Routing Status: R Can anyone point me towards RFCs, design documentation, white papers etc which cover call routing via third parties ?  I'll explain what I mean in more detail: With Internet SIP calls, the design of the DNS in RFC 3263 intends calls to be routed point-to-point. For example if I use ENUM to look up the SIP URI of the person I'm calling, I'll then extract the domain from the SIP URI and use it to look up the IP address of the SIP server to receive my call. The call then routes directly from my SIP server to the receiving SIP server in their network. The PSTN rarely works in this simple way  (at least in the area that I know - it might be different in your environment).  If I'm a customer of Telco A and make a call to a customer of Telco B, the call may actually route via Telco C because A and B do not have a direct interconnection.  On the other hand, if I was a customer of Telco D that had a direct connection to Telco C I would expect the call to route directly between the two. What I'm looking for is a way of representing these differing arrangements using any kind of DNS records. (If this group isn't the right forum for discussing the topic of call routing, apologies -  I'd be very grateful if someone could advise which is the right place). ========================================================This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended tobe for the use of the individual(s) or entity named above. If you are notthe intended recipient be aware that any disclosure, copyingdistribution or use of the contents of this information is prohibited. If youhave received this electronic message in error, please notify usby telephone or email (to the numbers or address above) immediately.======================================================== _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 14 Sep 2004 12:28:47 -0400 From: "Stastny Richard" Date: Tue, 14 Sep 2004 12:28:47 -0400 To: "Fullbrook Kim (UK)" Subject: Re: [Enum] Call Routing Message-ID: <06CF906FE3998C4E944213062009F1624438AA@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R -----UrsprÃngliche Nachricht----- Von: Fullbrook Kim (UK) [mailto:Kim.Fullbrook at O2.COM] Gesendet: Mo 13.09.2004 17:11 An: 'enum at ietf.org' Cc: Betreff: [Enum] Call Routing >Can anyone point me towards RFCs, design documentation, white papers etc which cover call routing via third >parties ? I'll explain what I mean in more detail: As far as I know these issues are dealt with in TRIP and also the Open Settlement Protocol (OSP from ETSI. >With Internet SIP calls, the design of the DNS in RFC 3263 intends calls to be routed point-to-point. For >example if I use ENUM to look up the SIP URI of the person I'm calling, I'll then extract the domain from the >SIP URI and use it to look up the IP address of the SIP server to receive my call. The call then routes directly >from my SIP server to the receiving SIP server in their network. Correct, ENUM is end-to-end, there is currently no possibility for transit routing. >The PSTN rarely works in this simple way (at least in the area that I know - it might be different in your >environment). If I'm a customer of Telco A and make a call to a customer of Telco B, the call may actually >route via Telco C because A and B do not have a direct interconnection. On the other hand, if I was a >customer of Telco D that had a direct connection to Telco C I would expect the call to route directly between >the two. What I'm looking for is a way of representing these differing arrangements using any kind of DNS >records. ENUM in e164.arpa is to be used on the Internet. On the Internet there is no need to route via transit networks. Of course you could use some sorta "ENUM" (I do not want to say operator, carrier or infrastructure ENUM because I am not allowed to use certain terminology at the IETF or on this list) within your network to route calls to certain E.164 numbers via a border element to a transit network. >(If this group isn't the right forum for discussing the topic of call routing, apologies - I'd be very grateful if >someone could advise which is the right place). good question, I have no idea (after my experience with the mini-BOF on whatchamacallit ENUM in San Diego ;-) Richard _____ ======================================================== This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ======================================================== _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Mpierce1@aol.com Wed, 15 Sep 2004 12:39:34 -0400 From: Mpierce1@aol.com Date: Wed, 15 Sep 2004 12:39:34 -0400 To: enum at ietf.org Subject: [Enum] non-E.164 Numbers in ENUM Message-ID: <1cb.2b373cab.2e79c3e7@aol.com> MIME-Version: 1.0 Content-Type: text/plain Status: R To all, A recent discussion on the IPTEL list indicates that there is still confusion regarding the handling of non-E.164 compliant number in ENUM. The issue regards the handling of numbers that contain extra digits beyond what is considered a valid number. This practice is common in today's telephone network, when companies advertise their telephone number with convenient words which often exceed the actual digits needed. This is done, and works, since the telephone network today always knows when to throw away the extra digits, either at the originating exchange, or at some intermediate point. These extra digits can never have any effect on the routing of the call, nor should they result in the call being rejected. As an example, I just retrieved an ad from my wastebasket which lists a number as 1-888-OUR-BRAIN. Since the real E.164 number is +1-888-687-2724, the extra "6" must be ignored when dialed. Some responders on the IPTEL list indicated that they think that it is perfectly okay for end users to register number combinations with extra digits, at least in "Tier 2 nameservers". Some go so far as to suggest that ENUM should allow different translations for the actual (correct length) number and the ones with extra digits. As someone pointed out, the end user could create literally millions of extra combinations from one valid number. This situation arises when the originator of the ENUM request does not know the dialing plan that pertains to the number they are sending, and therefore may include more digits than are required. This relates to a general issue that has been raised many times in the past reqarding what to do when the originating device (end user's phone) does not know the dial plan. In existing telephone service, the end user's device never knows the dial plan, leaving it up to the network to know. This is why a cell phone user is required to press a key at the end of what they think a complete number is. The network then validates it and throws away extra digits, and intercepts if there are not enough digits. It appears that there needs to be a general solution to the unanswered question "What if my phone does not have a dial plan". For ENUM, there needs to be a clarification of what entries can be supported in ENUM. I believe it needs to be made very clear that it can not include number combinations that exceed the E.164 defined numbers (as regulated by various countries). In the world zone 1, that is currently 10 digits. Mike Pierce Artel _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From md@bts.sk Wed, 15 Sep 2004 13:37:28 -0400 From: Marian Durkovic Date: Wed, 15 Sep 2004 13:37:28 -0400 To: Mpierce1 at aol.com Subject: Re: [Enum] non-E.164 Numbers in ENUM In-Reply-To: <1cb.2b373cab.2e79c3e7@aol.com> Message-ID: <20040915172325.GA98331@us.svf.stuba.sk> MIME-Version: 1.0 Content-Type: text/plain Status: R > For ENUM, there needs to be a clarification of what entries can be supported > in ENUM. I believe it needs to be made very clear that it can not include > number combinations that exceed the E.164 defined numbers (as regulated by various > countries). In the world zone 1, that is currently 10 digits. I'm afraid this is not technically possible. Once you delegate a zone with NS record(s), the dalegated nameserver can put any number of subdomains under the delegated domain or even a wildcard record to match anything - this in fact drops all extra digits right away. In some cases adding extra digits might even be useful - for example to be able to directly reach PBX extensions on a PBX without DDI block. With kind regards, -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md at bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Wed, 15 Sep 2004 13:37:28 -0400 From: "Conroy, Lawrence (SMTP)" Date: Wed, 15 Sep 2004 13:37:28 -0400 To: Mpierce1 at aol.com Subject: Re: [Enum] non-E.164 Numbers in ENUM In-Reply-To: <1cb.2b373cab.2e79c3e7@aol.com> Message-ID: <12949A09-073C-11D9-9D23-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi MIke, folks, first, a plea - PLEASE don't sent HTML format mails - I have my mailer set to present plain text mails in a font size I can read, so whilst my myopia is not your problem, presentation of web pages in default (small) font size doesn't help my attitude :). On to the substance:: RFC3761 is clear - this is for E.164 numbers only. In DDDS terms, this means is that the Application Unique String is an E.164 number (with all non-numeric characters except the initial '+' removed). From james.yu@neustar.biz Wed, 15 Sep 2004 14:30:54 -0400 From: "Yu, James" Date: Wed, 15 Sep 2004 14:30:54 -0400 To: "'Marian Durkovic'" MIME-Version: 1.0 Content-Type: text/plain Status: R To add to the discussion, the ENUM registrars and Tier 1 Registry or Registries can enforce that a registered phone number is indeed a valid E.164 # per that country's or region's numbering plan. An end user who is assigned 1-571-434-1234 cannot register 1-571-434-1235 or 1-571-434-123. There is no way to prevent the Tier 2 nameservers from having an entry on 1-571-434-1234-3 in addition to an entry on 1-571-434-1234 unless there is a policy that the Tier 2 nameserver operators/providers must not include entries for phone numbers (in ENUM domain name format) that do not appear at the Tier 1 Registry and that policy can be enforced (e.g., end users cannot operate the Tier 2 nameservers for their own #s). But if the end users can operate their own Tier 2 nameservers, it would be difficult to detect the policy violation and enforce that policy, even if one exists. ENUM resolver (one that generates the ENUM query for a phone number) can only check if the phone number has more than 15 digits (a valid E.164# is up to 15 digits long) because it is not likely to understand the numbering plan in every country. It won't be able to know if 1-571-434-1234-5 is a valid E.164# if it does not understand the numbering plan for country code 1. So if someone tries to reach 1-571-434-1234-5 by following the advertised phone number or by mistakenly entering one additional digit , the ENUM resolver will generate an ENUM query on 5.4.3.2.1.4.3.4.1.7.5.1.e164.arpa. If the end user has the NAPTR RRs for 5.4.3.2.1.4.3.4.1.7.5.1.e164.arpa. or a wild card, the requester will get a response, whether there is a policy violation or not. Allowing the above would allow the caller to reach the called party based on the # advertised in either the IP domain or the PSTN domain. James -----Original Message----- From: Marian Durkovic [mailto:md at bts.sk] Sent: Wednesday, September 15, 2004 1:23 PM To: Mpierce1 at aol.com Cc: enum at ietf.org Subject: Re: [Enum] non-E.164 Numbers in ENUM > For ENUM, there needs to be a clarification of what entries can be supported > in ENUM. I believe it needs to be made very clear that it can not include > number combinations that exceed the E.164 defined numbers (as regulated by various > countries). In the world zone 1, that is currently 10 digits. I'm afraid this is not technically possible. Once you delegate a zone with NS record(s), the dalegated nameserver can put any number of subdomains under the delegated domain or even a wildcard record to match anything - this in fact drops all extra digits right away. In some cases adding extra digits might even be useful - for example to be able to directly reach PBX extensions on a PBX without DDI block. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Wed, 15 Sep 2004 14:45:46 -0400 From: Jim Reid Date: Wed, 15 Sep 2004 14:45:46 -0400 To: Marian Durkovic Subject: Re: [Enum] non-E.164 Numbers in ENUM In-Reply-To: <20040915172325.GA98331@us.svf.stuba.sk> Message-ID: <17591.1095273739@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Marian" == Marian Durkovic writes: >> For ENUM, there needs to be a clarification of what entries can >> be supported in ENUM. I believe it needs to be made very clear >> that it can not include number combinations that exceed the >> E.164 defined numbers (as regulated by various countries). In >> the world zone 1, that is currently 10 digits. Marian> I'm afraid this is not technically possible. Once you Marian> delegate a zone with NS record(s), the dalegated Marian> nameserver can put any number of subdomains under the Marian> delegated domain or even a wildcard record to match Marian> anything - this in fact drops all extra digits right away. This is not true. There is a maximum length of a domain name. It's one of the fundamental constants of the DNS. Though admittedly that length -- 255 characters including the dots -- is much more than the 15(?) digit maximum for an E.164 number. This limit also applies to wildcard matching. And as you should know by now, wildcards in the DNS are evil. They're even worse in the context of ENUM. That's because a DNS wildcard can match anything. If a query name contained non-digits, this would match a DNS wildcard if one existed. That could mean unexpected data getting input to the NAPTR rewriting rules. Or, worse, some telco equipment gets asked to dial a "number" like 01234Marian's+Funky+Wildcard-Match. You are however correct to suggest that once a delegation is made, the owner of that delegation can extend their part of the name space: for instance to add extra digits to telephone numbers. This may have undesirable consequences for telephone equipment and national/local numbering plans. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Wed, 15 Sep 2004 15:09:04 -0400 From: Jim Reid Date: Wed, 15 Sep 2004 15:09:04 -0400 To: "Yu, James" Subject: Re: [Enum] non-E.164 Numbers in ENUM In-Reply-To: <941284C9668BFD4FB342F1FF01ECA8240314A0@stntexch02.cis.neustar.com> Message-ID: <17634.1095274706@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "James" == Yu, James writes: James> ENUM resolver (one that generates the ENUM query for a James> phone number) can only check if the phone number has more James> than 15 digits (a valid E.164# is up to 15 digits long) James> because it is not likely to understand the numbering plan James> in every country. It won't be able to know if James> 1-571-434-1234-5 is a valid E.164# if it does not James> understand the numbering plan for country code 1. Indeed. In fact it would be very foolish for anyone to put a priori knowledge of a numbering plan into an ENUM resolver. Especially on an embedded device like a handset. Numbering plans change. Pretty much all an ENUM resolver could/should do is check that the input string conforms to the length and legal character set defined in E.164. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Wed, 15 Sep 2004 15:41:37 -0400 From: Mike Hammer Date: Wed, 15 Sep 2004 15:41:37 -0400 To: Jim Reid Subject: Re: [Enum] non-E.164 Numbers in ENUM In-Reply-To: Message-ID: <4.3.2.7.2.20040915152735.04107a98@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Likewise, would a check on a number of the form: tel:+xxxxxxxxxxxxxxxyyy... also be considered invalid (assuming no separators, x=1-9, y=0-9)? (+ = global-number = E.164 = 15 digits max) Mike At 07:58 PM 9/15/2004 +0100, Jim Reid wrote: >>>>> "James" == Yu, James writes: James> ENUM resolver (one that generates the ENUM query for a James> phone number) can only check if the phone number has more James> than 15 digits (a valid E.164# is up to 15 digits long) James> because it is not likely to understand the numbering plan James> in every country. It won't be able to know if James> 1-571-434-1234-5 is a valid E.164# if it does not James> understand the numbering plan for country code 1. Indeed. In fact it would be very foolish for anyone to put a priori knowledge of a numbering plan into an ENUM resolver. Especially on an embedded device like a handset. Numbering plans change. Pretty much all an ENUM resolver could/should do is check that the input string conforms to the length and legal character set defined in E.164. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From james.yu@neustar.biz Wed, 15 Sep 2004 17:12:37 -0400 From: "Yu, James" Date: Wed, 15 Sep 2004 17:12:37 -0400 To: "'Mike Hammer'" Subject: RE: [Enum] non-E.164 Numbers in ENUM Message-ID: <941284C9668BFD4FB342F1FF01ECA8240314A4@stntexch02.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain Status: R If the ENUM resolver does check the limit of 15 digits, it would block it if it only allows valid E.164 #s. But if it does not check, it would just follow the RFC to formulate the ENUM query. Whether it gets the NAPTR RRs back depends on the info. at the Tier 2 nameservers. James -----Original Message----- From: Mike Hammer [mailto:mhammer at cisco.com] Sent: Wednesday, September 15, 2004 3:30 PM To: Jim Reid; Yu, James Cc: enum at ietf.org; 'Marian Durkovic' Subject: Re: [Enum] non-E.164 Numbers in ENUM Likewise, would a check on a number of the form: tel:+xxxxxxxxxxxxxxxyyy... also be considered invalid (assuming no separators, x=1-9, y=0-9)? (+ = global-number = E.164 = 15 digits max) Mike At 07:58 PM 9/15/2004 +0100, Jim Reid wrote: > >>>>> "James" == Yu, James writes: > > James> ENUM resolver (one that generates the ENUM query for a > James> phone number) can only check if the phone number has more > James> than 15 digits (a valid E.164# is up to 15 digits long) > James> because it is not likely to understand the numbering plan > James> in every country. It won't be able to know if > James> 1-571-434-1234-5 is a valid E.164# if it does not > James> understand the numbering plan for country code 1. > >Indeed. In fact it would be very foolish for anyone to put a priori >knowledge of a numbering plan into an ENUM resolver. Especially on an >embedded device like a handset. Numbering plans change. Pretty much >all an ENUM resolver could/should do is check that the input string >conforms to the length and legal character set defined in E.164. > >_______________________________________________ >enum mailing list >enum at ietf.org >https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Wed, 15 Sep 2004 20:16:14 -0400 From: Jeff Williams Date: Wed, 15 Sep 2004 20:16:14 -0400 To: Jim Reid Subject: Re: [Enum] non-E.164 Numbers in ENUM In-Reply-To: <17591.1095273739@gromit.rfc1035.com> Message-ID: <4148F66B.32F9BE67@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim and all, Jim Reid wrote: > >>>>> "Marian" == Marian Durkovic writes: > > >> For ENUM, there needs to be a clarification of what entries can > >> be supported in ENUM. I believe it needs to be made very clear > >> that it can not include number combinations that exceed the > >> E.164 defined numbers (as regulated by various countries). In > >> the world zone 1, that is currently 10 digits. > > Marian> I'm afraid this is not technically possible. Once you > Marian> delegate a zone with NS record(s), the dalegated > Marian> nameserver can put any number of subdomains under the > Marian> delegated domain or even a wildcard record to match > Marian> anything - this in fact drops all extra digits right away. > > This is not true. There is a maximum length of a domain name. It's one > of the fundamental constants of the DNS. Though admittedly that length > -- 255 characters including the dots -- is much more than the 15(?) > digit maximum for an E.164 number. This limit also applies to wildcard > matching. Your of course correct here Jim, and thank you for again pointing this out and/or bringing it to attention. > > > And as you should know by now, wildcards in the DNS are evil. I disagree with this statement as stated. Yes, wildcards in DNS can be used for evil or disruptive purposes, but they can also be used for very beneficial uses as well. > They're > even worse in the context of ENUM. That's because a DNS wildcard can > match anything. If a query name contained non-digits, this would match > a DNS wildcard if one existed. That could mean unexpected data getting > input to the NAPTR rewriting rules. Or, worse, some telco equipment > gets asked to dial a "number" like 01234Marian's+Funky+Wildcard-Match. Why is this bad for ENUM? I can see easily specific situations were it could be bad or used badly. But I don't see any justification for it being bad in a broad sense as you stated it here. > > > You are however correct to suggest that once a delegation is made, the > owner of that delegation can extend their part of the name space: for > instance to add extra digits to telephone numbers. This may have > undesirable consequences for telephone equipment and national/local > numbering plans. Agreed that in some to many instances, this could have very undesirable consequences for antiquated telephone equipment as well as some, if not many national and/or local numbering plans... > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From clive@demon.net Thu, 16 Sep 2004 03:40:42 -0400 From: "Clive D.W. Feather" Date: Thu, 16 Sep 2004 03:40:42 -0400 To: Mpierce1 at aol.com Subject: Re: [Enum] non-E.164 Numbers in ENUM In-Reply-To: <1cb.2b373cab.2e79c3e7@aol.com> Message-ID: <20040916073559.GA13683@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Mpierce1 at aol.com said: > A recent discussion on the IPTEL list indicates that there is still confusion > regarding the handling of non-E.164 compliant number in ENUM. The issue > regards the handling of numbers that contain extra digits beyond what is considered > a valid number. This practice is common in today's telephone network, when > companies advertise their telephone number with convenient words which often > exceed the actual digits needed. This is done, and works, since the telephone > network today always knows when to throw away the extra digits, either at the > originating exchange, or at some intermediate point. These extra digits can never > have any effect on the routing of the call, nor should they result in the > call being rejected. This is called "overdialling" and it is *not* guaranteed to work in all telephone networks. There are cases in the UK - I am assured by my colleagues - where this will cause misrouteing or call failure. -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From clive@demon.net Thu, 16 Sep 2004 03:46:08 -0400 From: "Clive D.W. Feather" Date: Thu, 16 Sep 2004 03:46:08 -0400 To: Jim Reid Subject: Re: [Enum] non-E.164 Numbers in ENUM In-Reply-To: <20040915172325.GA98331@us.svf.stuba.sk> Message-ID: <20040916073819.GB13683@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim Reid said: > This is not true. There is a maximum length of a domain name. It's one > of the fundamental constants of the DNS. Though admittedly that length > -- 255 characters including the dots -- Nitpick: it's 255 octets including the length fields of each component including the final empty one. So "www.davros.org" is encoded as: 3 'w' 'w' 'w' 6 'd' 'a' 'v' 'r' 'o' 's' 3 'o' 'r' 'g' 0 and so is 16 octets and not the 14 you might expect. So the limit is actually 253. In addition, if both sides think that UTF-8 is in use (though, of course, it shouldn't be) then "character" is not "octet". -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From md@bts.sk Thu, 16 Sep 2004 06:05:53 -0400 From: Marian Durkovic Date: Thu, 16 Sep 2004 06:05:53 -0400 To: Jim Reid Subject: Re: [Enum] non-E.164 Numbers in ENUM In-Reply-To: <20040915172325.GA98331@us.svf.stuba.sk> Message-ID: <20040916100412.GA26019@us.svf.stuba.sk> MIME-Version: 1.0 Content-Type: text/plain Status: R > This is not true. There is a maximum length of a domain name. It's one > of the fundamental constants of the DNS. Though admittedly that length > -- 255 characters including the dots -- is much more than the 15(?) > digit maximum for an E.164 number. This limit also applies to wildcard > matching. Sure there's a DNS limit, however I was thinking in much smaller "scale" - when user wants to add 1 or 2 digits or so. > And as you should know by now, wildcards in the DNS are evil. They're > even worse in the context of ENUM. That's because a DNS wildcard can > match anything. If a query name contained non-digits, this would match > a DNS wildcard if one existed. That could mean unexpected data getting > input to the NAPTR rewriting rules. Or, worse, some telco equipment > gets asked to dial a "number" like 01234Marian's+Funky+Wildcard-Match. Jim, I don't think this can happen. According to RFC3761, all non-digit characters must be stripped out, so after applying this requirement, 01234Marian's+Funky+Wildcard-Match gets reduced to 01234. So yes, you will get a response when manually doing nslookup etc, but the real ENUM client should not perform any weird queries/substitutions. > You are however correct to suggest that once a delegation is made, the > owner of that delegation can extend their part of the name space: for > instance to add extra digits to telephone numbers. This may have > undesirable consequences for telephone equipment and national/local > numbering plans. The consequences depend on actual implementation. Suppose you have a PBX without DDI - so all users calling from PSTN dial +12345678 and get connected to the operator (or get to IVR asking them to dial extension usign DTMF). Then you add VoIP gateway to the PBX, which can reach the extensions directly. By populating the ENUM zone with: +12345678 -> operator at company.com +1234567811 -> ext-11 at company.com +1234567812 -> ext-12 at company.com ..... you will allow the ENUM clients to reach the extensions directly, but at the same time, if any equipment cuts the extra digits, the user will reach the operator/IVR as if calling from PSTN. So there are no bad consequences, just the users from IP world will have more comfort than the users from PSTN - they could bypass the operator and/or two-stage dialing process via IVR. With kind regards, -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md at bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Thu, 16 Sep 2004 06:11:15 -0400 From: "Conroy, Lawrence (SMTP)" Date: Thu, 16 Sep 2004 06:11:15 -0400 To: "Clive D.W. Feather" Subject: Re: [Enum] non-E.164 Numbers in ENUM In-Reply-To: <20040915172325.GA98331@us.svf.stuba.sk> Message-ID: <540CF228-07C8-11D9-AC4E-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Clive, folks, following this particular peregrination, ENUM domains are more fun that this - you have to multiply the number of digits by two, as each digit is a label, and so it gets a single octet (0x01) prepended to it, plus the apex labels (\004e164\004arpa\000) appended. Nevertheless, as both ENUM (and the tel URI spec) specifically mention E.164, then 15 digits is a name field length of (2*15 + 11) = 41 octets. With 255 octets, we have some "headroom" for any updates to the RFCs to reflect changes to E.164, but IMHO any major change (to e.g. E.192, or ISO network addresses, or any other abstract space you care to get a doctorate studying) MUST be an update to the 3761 (and whatever RFC2806bis becomes). Praise the stars, IDN (and punycode) doesn't come into it with registered ENUM domains, as the labels are digits and are required to be in the USASCII-equivalent set, whilst the apex is specified in USASCII characters, so is by definition in the equivalent set. Of course, if someone wants to have a sub-domain in their registered zone, then this could include any whacky stuff, so the punycode identifier string might be needed, along with the punycoded characters of that label, plus the label length octet. However, no ENUM client is going to look in this domain (unless it supports non-final NAPTRs) so, from an ENUM perspective, it's "invisible". all the best, Lawrence On 16 Sep 2004, at 08:38, Clive D.W. Feather wrote: Jim Reid said: This is not true. There is a maximum length of a domain name. It's one of the fundamental constants of the DNS. Though admittedly that length -- 255 characters including the dots -- Nitpick: it's 255 octets including the length fields of each component including the final empty one. So "www.davros.org" is encoded as: 3 'w' 'w' 'w' 6 'd' 'a' 'v' 'r' 'o' 's' 3 'o' 'r' 'g' 0 and so is 16 octets and not the 14 you might expect. So the limit is actually 253. In addition, if both sides think that UTF-8 is in use (though, of course, it shouldn't be) then "character" is not "octet". _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Mpierce1@aol.com Thu, 16 Sep 2004 10:02:52 -0400 From: Mpierce1@aol.com Date: Thu, 16 Sep 2004 10:02:52 -0400 To: james.yu at neustar.biz Subject: Re: [Enum] non-E.164 Numbers in ENUM Message-ID: <12c.4c080997.2e7af582@aol.com> MIME-Version: 1.0 Content-Type: text/plain Status: R In a message dated 9/15/2004 2:59:14 PM Eastern Standard Time, jim at rfc1035.com writes: Indeed. In fact it would be very foolish for anyone to put a priori knowledge of a numbering plan into an ENUM resolver. Especially on an embedded device like a handset. Numbering plans change. Pretty much all an ENUM resolver could/should do is check that the input string conforms to the length and legal character set defined in E.164. Since the phone on my desk was made, the maximum international number length changed from 12 to 15 digits. It doesn't care about such things. So we're assuming that, in the life of an IP handset, that there will not be any other such change in E.164? Mike _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From claus@faerber.muc.de Fri, 17 Sep 2004 07:22:56 -0400 From: claus@faerber.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=) Date: Fri, 17 Sep 2004 07:22:56 -0400 To: enum at ietf.org Subject: [Enum] Re: non-E.164 Numbers in ENUM In-Reply-To: <941284C9668BFD4FB342F1FF01ECA8240314A0@stntexch02.cis.neustar.com> Message-ID: <9GxXXA4ZcDD@gmane.3247.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Yu, James schrieb/wrote: > ENUM resolver (one that generates the ENUM query for a phone number) > can only check if the phone number has more than 15 digits (a valid > E.164# is up to 15 digits long) because it is not likely to understand > the numbering plan in every country. In Germany, for example, there is no numbering plan that indicates the length of the numbers. For example, +49-9999-123 could be a complete number while +49-9999-124 is not. With PBXes, this can even be the sole decision of the PBX's operator. It's even possible, although very rare, that both +49-9999-123 and +49-9999-1234 co-exist.[1] Further, while E.164 says that phone numbers can't be longer than 15 digits, some network or PBX operators hand out longer numbers for "special" purposes. Those can't be reached from all around the world, of course, but they still have their uses. Claus [1] In ENUM, it's possible to do that with CNAME: $ORIGIN 3.2.1.9.9.9.9.9.4.e164.int. @ CNAME _ _ XXX # entries for +49-999-123 1 XXX # entries for +49-999-1231 2 XXX # entries for +49-999-1232 Suddenly, you do need non-digits in the ENUM tree... -- http://www.faerber.muc.de _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From james.yu@neustar.biz Fri, 17 Sep 2004 09:28:40 -0400 From: "Yu, James" Date: Fri, 17 Sep 2004 09:28:40 -0400 To: "'claus at faerber.muc.de> Subject: RE: [Enum] Re: non-E.164 Numbers in ENUM Message-ID: <941284C9668BFD4FB342F1FF01ECA8240314A7@stntexch02.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Claus, For the example you gave, I assume that the person/entity that is assigned +49-9999-123 is also assigned +49-9999-1234. In that case, that person/entity only needs to register +49-9999-123 at Tier 1 Registry but it can put entries for both +49-9999-123 and +49-9999-1234 at the Tier 2 nameservers. If that person/entity (ENUM Registrant) tries to register +49-9999-123 and +49-9999-1234, there should be a requirement on the Tier 1 Registry in Germany to handle that situation. From the Tier 1 Registry's point of view, it may receive the registration for +49-9999-1234 followed by the registration for +49-9999-123 (registrations are done one by one via ENUM Registrar) or the order can be reversed. James -----Original Message----- From: claus at faerber.muc.de [mailto:claus at faerber.muc.de] Sent: Thursday, September 16, 2004 5:40 PM To: enum at ietf.org Subject: [Enum] Re: non-E.164 Numbers in ENUM Yu, James schrieb/wrote: > ENUM resolver (one that generates the ENUM query for a phone number) > can only check if the phone number has more than 15 digits (a valid > E.164# is up to 15 digits long) because it is not likely to understand > the numbering plan in every country. In Germany, for example, there is no numbering plan that indicates the length of the numbers. For example, +49-9999-123 could be a complete number while +49-9999-124 is not. With PBXes, this can even be the sole decision of the PBX's operator. It's even possible, although very rare, that both +49-9999-123 and +49-9999-1234 co-exist.[1] Further, while E.164 says that phone numbers can't be longer than 15 digits, some network or PBX operators hand out longer numbers for "special" purposes. Those can't be reached from all around the world, of course, but they still have their uses. Claus [1] In ENUM, it's possible to do that with CNAME: $ORIGIN 3.2.1.9.9.9.9.9.4.e164.int. @ CNAME _ _ XXX # entries for +49-999-123 1 XXX # entries for +49-999-1231 2 XXX # entries for +49-999-1232 Suddenly, you do need non-digits in the ENUM tree... -- http://www.faerber.muc.de _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From klaus.darilion@nic.at Mon, 20 Sep 2004 14:00:27 -0400 From: "Klaus Darilion" Date: Mon, 20 Sep 2004 14:00:27 -0400 To: Subject: [Enum] is the service field in NAPTR records case sensitive? Message-ID: <8BC845943058D844ABFC73D2220D466530D291@nics-mail.sbg.nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi!   I have some questions about the service field.     RFC 3761 defines that the service type can be written in lower or capital letters. type = 1*32(ALPHA / DIGIT) subtype = 1*32(ALPHA / DIGIT)Furthermore, RFC 3764 defines a service type "E2U+SIP"(note: sip in capital letters), but the examples uses lower letters: IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:edgar at example.com!" . My questions:Is there a difference between E2U+sip and E2U+SIP?Is E2U+SIP a valid service type?Does my ENUM resolver has to case insensitive? Thanks for answering my questions.regards,Klaus _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Mon, 20 Sep 2004 17:24:42 -0400 From: "Conroy, Lawrence (SMTP)" Date: Mon, 20 Sep 2004 17:24:42 -0400 To: Klaus Darilion Subject: Re: [Enum] is the service field in NAPTR records case sensitive? In-Reply-To: <8BC845943058D844ABFC73D2220D466530D291@nics-mail.sbg.nic.at> Message-ID: <4D1BEB81-0B44-11D9-BBBB-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Klaus, see the experiences draft, at all the best, Lawrence On 20 Sep 2004, at 18:55, Klaus Darilion wrote: Hi! I have some questions about the service field. RFC 3761 defines that the service type can be written in lower or capital letters. type = 1*32(ALPHA / DIGIT) subtype = 1*32(ALPHA / DIGIT) Furthermore, RFC 3764 defines a service type "E2U+SIP" (note: sip in capital letters), but the examples uses lower letters: IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:edgar at example.com!" . My questions: Is there a difference between E2U+sip and E2U+SIP? Is E2U+SIP a valid service type? Does my ENUM resolver has to case insensitive? Thanks for answering my questions. regards, Klaus _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bhoeneis@switch.ch Fri, 24 Sep 2004 14:03:47 -0400 From: Bernie Hoeneisen Date: Fri, 24 Sep 2004 14:03:47 -0400 To: enum at ietf.org Subject: [Enum] New I/D: draft-hoeneisen-enum-validation-epp-00 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi! I have just submitted a new I/D: draft-hoeneisen-enum-validation-epp-00 Abstract: This document describes an EPP extension for mapping information about the validation process the ENUM Registrar has 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 E.164 numbers. Until it appears in the archives, you can download it from the following URLs: * http://ietf.hoeneisen.ch/draft-hoeneisen-enum-validation-epp-00.txt * http://ietf.hoeneisen.ch/draft-hoeneisen-enum-validation-epp-00.html I am looking forward to your comments and proposals for improvement. Have fun! cheers, Bernie _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 24 Sep 2004 14:27:05 -0400 From: Richard Shockey Date: Fri, 24 Sep 2004 14:27:05 -0400 To: enum at ietf.org Subject: [Enum] Its that time again .. IETF 61 is coming. Message-ID: <6.1.0.6.2.20040924141649.040eb1a0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R The chairs would like to get a sense of what new documents we should be prepared for and what topics of discussion the WG needs to cover. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From shollenbeck@verisign.com Fri, 24 Sep 2004 14:35:43 -0400 From: "Hollenbeck, Scott" Date: Fri, 24 Sep 2004 14:35:43 -0400 To: "'Bernie Hoeneisen'" Subject: [Enum] RE: [ietf-provreg] New I/D: draft-hoeneisen-enum-validation-epp-0 0 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF040D84E6@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R > I am looking forward to your comments and proposals for improvement. It's customary to include an acknowledgements section, especially when much of the text is clearly copied from earlier work done by someone else. I'll review this in more detail when I have more time, but I'm not sure I understand how this can work without also using the ENUM extension [1] I've been working on. Wouldn't an response, for example, also need to return the data described in my draft once the domain exists in the registry? At first glance I think there needs to be some text in your document explaining the relationship to my document. -Scott- [1] http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-05.txt _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Sat, 25 Sep 2004 10:06:22 -0400 From: "Conroy, Lawrence (SMTP)" Date: Sat, 25 Sep 2004 10:06:22 -0400 To: "Hollenbeck, Scott" Subject: Re: [Enum] RE: [ietf-provreg] New I/D: draft-hoeneisen-enum-validation-epp-0 0 In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF040D84E6@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <80C3EE10-0EFB-11D9-A865-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Scott, Bernie, folks, Hmm... From shollenbeck@verisign.com Mon, 27 Sep 2004 07:37:31 -0400 From: "Hollenbeck, Scott" Date: Mon, 27 Sep 2004 07:37:31 -0400 To: "'Conroy, Lawrence (SMTP)'" Subject: RE: [Enum] RE: [ietf-provreg] New I/D: draft-hoeneisen-enum-valid ation-epp-0 0 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF040D84F0@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R > There is a reference to the main EPP documents in Bernie's > draft, so I don't > understand the annoyance either. It must be me. A very large portion of the text is copied directly from my documents, with no mention of where it came from. In some contexts this is considered to be plagiarism. The IETF tradition is to recognize building on the work of others by noting contributions in an "Acknowledgements" section. Something like this would be appropriate: "A large portion of the text in this document has been copied from earlier work written by Scott Hollenbeck." There should also be mention of contributions provided by others. I'm all for consistent format and structure of extensions. We shouldn't be passing off text that was written by someone else as new or original thought, though. -Scott- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bhoeneis@switch.ch Mon, 27 Sep 2004 08:25:08 -0400 From: Bernie Hoeneisen Date: Mon, 27 Sep 2004 08:25:08 -0400 To: "Hollenbeck, Scott" Subject: [Enum] RE: [ietf-provreg] New I/D: draft-hoeneisen-enum-validation-epp-0 0 In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF040D84E6@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Scott! On Fri, 24 Sep 2004, Hollenbeck, Scott wrote: It's customary to include an acknowledgements section, especially when much of the text is clearly copied from earlier work done by someone else. Sorry about my "omission sin"! I will add such an acknowledgements section in the next revision. Yes, I took your draft [1] as a template; because IMHO it has an excellent structure for EPP extensions. This actually also proofs, that I trust your documents! [...] I'm not sure I understand how this can work without also using the ENUM extension [1] I've been working on. The both extensions work independently, as they address completely different problems. Your extension [1] is about providing NAPTR records (for the DNS), my proposal [2] about providing validation information, (e.g. to comply legal requirements). Wouldn't an response, for example, also need to return the data described in my draft once the domain exists in the registry? Only if the registry supports also your extension [1]. At first glance I think there needs to be some text in your document explaining the relationship to my document. As this is not required to understand my validation information proposal [2], it is certainly useful to understand the differences between [1] and [2]. I'll think of something appropriate for the next revision. cheers, Bernie References: [1] http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-05.txt [2] http://ietf.hoeneisen.ch/draft-hoeneisen-enum-validation-epp-00.txt _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Patrick.Guillemin@etsi.org Mon, 27 Sep 2004 10:38:36 -0400 From: =?iso-8859-1?Q?Patrick_Ren=E9_Guillemin?= Date: Mon, 27 Sep 2004 10:38:36 -0400 To: Subject: [Enum] Simple question about ENUM service in SIP solutions ? Message-ID: <4091553999CBE4409CC2B562152B5A330406FA4B@email10.etsihq.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear All, Basic question : Do you know a SIP product available implementating enum ? We are preparing enum interop tests and need to identify which SIP products that already adopted enum ? We will contact them to set up the test bed for next coming enum Plugtests. Thank you very much I advance for any help. Patrick GUILLEMIN ETSI - Plugtests Technical Coordinator http://www.etsi.org/plugtests tel +33(0)4 92 94 43 31 fax +33(0)4 92 38 52 31 _______________________________________ _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From shollenbeck@verisign.com Mon, 27 Sep 2004 15:13:52 -0400 From: "Hollenbeck, Scott" Date: Mon, 27 Sep 2004 15:13:52 -0400 To: "'Bernie Hoeneisen'" Subject: [Enum] RE: [ietf-provreg] New I/D: draft-hoeneisen-enum-validation-epp-0 0 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF040D84FD@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R OK, I had a chance to take a closer look. I noticed that you're using a 31-character token for the E.164 number. Why is that? An E.164 number can contain no more than 15 digits per E.164, so why allow a maximum of 31? For what it's worth I used a type like this in the EPP contact mapping: With this you get the "+". The country code and the local part are separated by a "." (we did that in provreg mostly for "human eyes" reasons). The "+" and the "." added to the max E.164 length of 15 digits gives a maximum token length of 17 characters. Also, throughout the document s/März/March/ -Scott- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From clive@demon.net Tue, 28 Sep 2004 03:37:52 -0400 From: "Clive D.W. Feather" Date: Tue, 28 Sep 2004 03:37:52 -0400 To: "Hollenbeck, Scott" Subject: Re: [Enum] RE: [ietf-provreg] New I/D: draft-hoeneisen-enum-validation-epp-0 0 In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF040D84FD@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <20040928073651.GA79552@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Hollenbeck, Scott said: > OK, I had a chance to take a closer look. I noticed that you're using a > 31-character token for the E.164 number. Why is that? An E.164 number can > contain no more than 15 digits per E.164, so why allow a maximum of 31? "640k is enough for anyone"? While I don't see E.164 changing any time soon, there are cases where local allocations may be longer than the 15 digit limit, and there is no harm in leaving space for expansion. -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From shollenbeck@verisign.com Tue, 28 Sep 2004 07:08:36 -0400 From: "Hollenbeck, Scott" Date: Tue, 28 Sep 2004 07:08:36 -0400 To: "'Clive D.W. Feather'" Subject: [Enum] RE: New I/D: draft-hoeneisen-enum-validation-epp-0 0 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF040D850A@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R > While I don't see E.164 changing any time soon, there are > cases where local > allocations may be longer than the 15 digit limit, and there > is no harm in > leaving space for expansion. Well, then perhaps a more basic question: why is the number needed in the extension at all? You already have the domain name; the number can be trivially derived from the name. -Scott- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bhoeneis@switch.ch Tue, 28 Sep 2004 07:49:29 -0400 From: Bernie Hoeneisen Date: Tue, 28 Sep 2004 07:49:29 -0400 To: "Hollenbeck, Scott" Subject: [Enum] RE: [ietf-provreg] New I/D: draft-hoeneisen-enum-validation-epp-0 0 In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF040D84FD@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Scott! Thanks for your feedback! On Mon, 27 Sep 2004, Hollenbeck, Scott wrote: OK, I had a chance to take a closer look. I noticed that you're using a 31-character token for the E.164 number. Why is that? An E.164 number can contain no more than 15 digits per E.164, so why allow a maximum of 31? For what it's worth I used a type like this in the EPP contact mapping: The idea behind this was to leave it a Registry policy issue (or up to the validation method documentation), what format to use, in order to keep it as generic as possible. This would allow over-dialing, and characters such as "-", "(", ")" as seperators. Furthermore one could describe number ranges, e.g. "+41-44-26815xx", with this format. I do not have a strong opinion on which format to use for this. Also, throughout the document s/März/March/ Ouuppps...! This is due to a bug in the "xml2rfc" package. It used my locale settings, i.e. the environment variable "LC_TIME=de_CH" although any output documents of the xml2rfc tool are in English. I have submitted a Bug Report and informed the Debian maintainer about this issue. I even got immediately a patch! However, this will be correct in the next revision. cheers, Bernie _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bhoeneis@switch.ch Tue, 28 Sep 2004 08:21:04 -0400 From: Bernie Hoeneisen Date: Tue, 28 Sep 2004 08:21:04 -0400 To: "Hollenbeck, Scott" Subject: [Enum] RE: New I/D: draft-hoeneisen-enum-validation-epp-0 0 In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF040D850A@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Scott and Clive! Thanks for your feedback! On Tue, 28 Sep 2004, Hollenbeck, Scott wrote: While I don't see E.164 changing any time soon, there are cases where local allocations may be longer than the 15 digit limit, and there is no harm in leaving space for expansion. Well, then perhaps a more basic question: why is the number needed in the extension at all? You already have the domain name; the number can be trivially derived from the name. For the major part of the cases I agree with you. But I am trying to make the extension as generic as possible. Im can imagine, that certain validation procedures might need this optional field. I am even thinking of adding (optional) elements to be used for Contact information of the E.164 number (range) holder, e.g. as reported from the Validation Entity. This could enable easier handling of problem cases at the Registry. cheers, Bernie _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From shollenbeck@verisign.com Tue, 28 Sep 2004 08:25:43 -0400 From: "Hollenbeck, Scott" Date: Tue, 28 Sep 2004 08:25:43 -0400 To: "'Bernie Hoeneisen'" Subject: [Enum] RE: New I/D: draft-hoeneisen-enum-validation-epp-0 0 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF040D850B@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R > > Well, then perhaps a more basic question: why is the number > needed in the > > extension at all? You already have the domain name; the > number can be > > trivially derived from the name. > > For the major part of the cases I agree with you. > But I am trying to make the extension as generic as possible. > Im can imagine, that certain validation procedures might need this > optional field. I still don't get it. If the number is needed, it can be derived from the domain name. Why carry it twice? The only scenario I can imagine is one in which some kind of formatting or some extra information (such as over-dialing numbers) needs to be preserved. Is that what you have in mind? -Scott- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bownes@seiri.com Tue, 28 Sep 2004 08:32:24 -0400 From: bob bownes Date: Tue, 28 Sep 2004 08:32:24 -0400 To: "Hollenbeck, Scott" Subject: Re: [Enum] RE: New I/D: draft-hoeneisen-enum-validation-epp-0 0 In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF040D850A@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <4159591C.8000806@seiri.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Hollenbeck, Scott wrote: While I don't see E.164 changing any time soon, there are cases where local allocations may be longer than the 15 digit limit, and there is no harm in leaving space for expansion. Well, then perhaps a more basic question: why is the number needed in the extension at all? You already have the domain name; the number can be trivially derived from the name. One *should* be able to do that, but it is not necessarily the case unless the subdomains of an organization match with the dial plan of the organization. It also prevent number portability across internal organizational boundaries if extension maps to DID. Additionally, in a sufficiently large organization, there may be duplicate extension numbers (or names!) with different DIDs based on geography. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bownes@web9.com Tue, 28 Sep 2004 08:51:05 -0400 From: Bob Bownes Date: Tue, 28 Sep 2004 08:51:05 -0400 To: "'ietf-provreg at cafax.se> Subject: Re: [Enum] RE: New I/D: draft-hoeneisen-enum-validation-epp-0 0 In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF040D850A@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <41595BDB.4010406@web9.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Hollenbeck, Scott wrote: >> While I don't see E.164 changing any time soon, there are cases where local >> allocations may be longer than the 15 digit limit, and there is no harm in >> leaving space for expansion. > > > > Well, then perhaps a more basic question: why is the number needed in the > extension at all? You already have the domain name; the number can be > trivially derived from the name. > One *should* be able to do that, but it is not necessarily the case unless the subdomains of an organization match with the dial plan of the organization. It also prevent number portability across internal organizational boundaries if extension maps to DID. Additionally, in a sufficiently large organization, there may be duplicate extension numbers (or names!) with different DIDs based on geography. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bhoeneis@switch.ch Tue, 28 Sep 2004 09:13:59 -0400 From: Bernie Hoeneisen Date: Tue, 28 Sep 2004 09:13:59 -0400 To: "Hollenbeck, Scott" Subject: [Enum] RE: New I/D: draft-hoeneisen-enum-validation-epp-0 0 In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF040D850B@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Tue, 28 Sep 2004, Hollenbeck, Scott wrote: Well, then perhaps a more basic question: why is the number needed in the extension at all? You already have the domain name; the number can be trivially derived from the name. For the major part of the cases I agree with you. But I am trying to make the extension as generic as possible. Im can imagine, that certain validation procedures might need this optional field. I still don't get it. If the number is needed, it can be derived from the domain name. Why carry it twice? The only scenario I can imagine is one in which some kind of formatting or some extra information (such as over-dialing numbers) needs to be preserved. Is that what you have in mind? For example. cheers, Bernie _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From gregv@lucent.com Tue, 28 Sep 2004 09:15:46 -0400 From: "Vaudreuil, Greg M (Greg)" Date: Tue, 28 Sep 2004 09:15:46 -0400 To: Bernie Hoeneisen Subject: RE: [Enum] RE: [ietf-provreg] New I/D: draft-hoeneisen-enum-valid ation-epp-0 0 Message-ID: <54E40201497DF142B06B27255953F7970FE6BD27@il0015exch007u.ih.lucent.com> MIME-Version: 1.0 Content-Type: text/plain Status: R E.164 specifies a maximum of 15 digits, but also specifies an ISDN subaddressing parameter that can be (I believe) up to ten digits in length. It is quite common in North American voicemail applications to use up to a four digit subaddress at the tail of the E.164 number to indicate a mailbox partition. I believe in it's original use, the ISDN subaddress was intended to specify extensions behind a PBX or a specific terminal device in the residence. From the ENUM perspective, the distinction between the base E.164 number and the subaddress is meaningless, and in effect the E.164 "string of numbers" can be up to 25 digits long. I don't believe numbers should contain the user presentation markup, but if you did, I can see the number easily reaching 31 characters. Greg V. -----Original Message----- From: Bernie Hoeneisen [mailto:bhoeneis at switch.ch] Sent: Tuesday, September 28, 2004 7:44 AM To: Hollenbeck, Scott Cc: 'enum at ietf.org'; 'ietf-provreg at cafax.se' Subject: [Enum] RE: [ietf-provreg] New I/D: draft-hoeneisen-enum-validation-epp-0 0 Hi Scott! Thanks for your feedback! On Mon, 27 Sep 2004, Hollenbeck, Scott wrote: > OK, I had a chance to take a closer look. I noticed that you're using a > 31-character token for the E.164 number. Why is that? An E.164 number can > contain no more than 15 digits per E.164, so why allow a maximum of 31? For > what it's worth I used a type like this in the EPP contact mapping: The idea behind this was to leave it a Registry policy issue (or up to the validation method documentation), what format to use, in order to keep it as generic as possible. This would allow over-dialing, and characters such as "-", "(", ")" as seperators. Furthermore one could describe number ranges, e.g. "+41-44-26815xx", with this format. I do not have a strong opinion on which format to use for this. > Also, throughout the document s/März/March/ Ouuppps...! This is due to a bug in the "xml2rfc" package. It used my locale settings, i.e. the environment variable "LC_TIME=de_CH" although any output documents of the xml2rfc tool are in English. I have submitted a Bug Report and informed the Debian maintainer about this issue. I even got immediately a patch! However, this will be correct in the next revision. cheers, Bernie _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 28 Sep 2004 11:37:10 -0400 From: "Stastny Richard" Date: Tue, 28 Sep 2004 11:37:10 -0400 To: "Vaudreuil, Greg M (Greg)" Subject: RE: [Enum] RE: [ietf-provreg] New I/D: draft-hoeneisen-enum-validation-epp-0 0 Message-ID: <06CF906FE3998C4E944213062009F1624438CE@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Greg, >From the ENUM > perspective, the distinction between the base E.164 number > and the subaddress is meaningless, wrong >and in effect the E.164 "string of numbers" can be up to 25 digits long. wrong again, in this case it could be 55. RTFM Sorry, but the Subaddress (SA) is NOT part of the E.164 number, (OUTSIDE the ISDN numbering plan) and therefore MUST NOT be in ENUM. "Subaddress information is NOT REQUIRED to be processed within the public network" A partial number (DDI) is part of the E.164 number and therefore may be in ENUM. Richard BTW, the SA can be 40 digits Citation from E.164, please read carefully: B.3.2 Addressing by an ISDN number When selecting a destination in the subscriber installation, digits forming the end of the ISDN subscriber number are transferred to the called subscriber's installation as a partial number (see Figure B.1). The number of digits used depends upon the requirements of the called subscriber's equipment and the capacity of the numbering plan used. In instances where a partial number is utilized, e.g. Network Termination 2 (NT2), the number will be used in the context of the direct-dialling-in supplementary service. If the subscriber's installation consists of terminal equipment only, the transferred digits will be used in the context of the multiple-subscriber-number supplementary service. B.3.3 Sub-addressing (network address extension) Sub-addressing provides an additional addressing capacity OUTSIDE the ISDN numbering plan but constitutes an intrinsic part of the ISDN addressing capabilities. The sub-address is a sequence of digits, following the ISDN number. The maximum length should be 20 octets (40 digits). As shown in Figure B.1, the sub-address may follow the ISDN number and form the ISDN address, which is transferred to the equipment at the subscriber's premises. When required, the sub-address is sent by the calling party within the call set-up procedure and is passed transparently through the network as a separate entity from both the ISDN number and user to-user information. Sub-address information is not required to be processed within the public network. > -----Original Message----- > From: Vaudreuil, Greg M (Greg) [mailto:gregv at lucent.com] > Sent: Tuesday, September 28, 2004 3:11 PM > To: Bernie Hoeneisen; Hollenbeck, Scott > Cc: 'enum at ietf.org'; 'ietf-provreg at cafax.se' > Subject: RE: [Enum] RE: [ietf-provreg] New I/D: > draft-hoeneisen-enum-validation-epp-0 0 > > > E.164 specifies a maximum of 15 digits, but also specifies an > ISDN subaddressing parameter that can be (I believe) up to > ten digits in length. It is quite common in North American > voicemail applications to use up to a four digit subaddress > at the tail of the E.164 number to indicate a mailbox > partition. I believe in it's original use, the ISDN > subaddress was intended to specify extensions behind a PBX or > a specific terminal device in the residence. From the ENUM > perspective, the distinction between the base E.164 number > and the subaddress is meaningless, and in effect the E.164 > "string of numbers" can be up to 25 digits long. I don't > believe numbers should contain the user presentation markup, > but if you did, I can see the number easily reaching 31 characters. > > Greg V. > > -----Original Message----- > From: Bernie Hoeneisen [mailto:bhoeneis at switch.ch] > Sent: Tuesday, September 28, 2004 7:44 AM > To: Hollenbeck, Scott > Cc: 'enum at ietf.org'; 'ietf-provreg at cafax.se' > Subject: [Enum] RE: [ietf-provreg] New I/D: > draft-hoeneisen-enum-validation-epp-0 0 > > > Hi Scott! > > Thanks for your feedback! > > On Mon, 27 Sep 2004, Hollenbeck, Scott wrote: > > > OK, I had a chance to take a closer look. I noticed that > you're using > > a 31-character token for the E.164 number. Why is that? An E.164 > > number can contain no more than 15 digits per E.164, so why allow a > > maximum of 31? For what it's worth I used a type like this > in the EPP > > contact mapping: > > The idea behind this was to leave it a Registry policy issue > (or up to the > validation method documentation), what format to use, in > order to keep it > as generic as possible. This would allow over-dialing, and characters > such as "-", "(", ")" as seperators. Furthermore one could > describe number ranges, e.g. "+41-44-26815xx", with this > format. I do not have a strong opinion on which format to use > for this. > > > Also, throughout the document s/März/March/ > > Ouuppps...! > This is due to a bug in the "xml2rfc" package. It used my > locale settings, > i.e. the environment variable "LC_TIME=de_CH" although any output > documents of the xml2rfc tool are in English. I have submitted a Bug > Report and informed the Debian maintainer about this issue. I > even got > immediately a patch! > However, this will be correct in the next revision. > > > cheers, > Bernie > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.net Tue, 28 Sep 2004 12:18:22 -0400 From: Ray Anderson Date: Tue, 28 Sep 2004 12:18:22 -0400 To: Bernie Hoeneisen Subject: Re: [Enum] RE: New I/D: draft-hoeneisen-enum-validation-epp-0 0 In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF040D850B@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <6.1.2.0.2.20040928170647.01e0ff80@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R The "overdialling" concept also applies where the "extra digits" do not refer to a phone line, but are used to access another number space. We plan to accept calls in to a "phone number" where the "over dialling" together with Caller-id causes a WAP push or equivalent to push content to the user's phone.  This avoids us needing to "buy" loads of "phone numbers" for each piece of content. Long is good. Ray www.Bango.net At 14:04 28/09/2004, Bernie Hoeneisen wrote: On Tue, 28 Sep 2004, Hollenbeck, Scott wrote: Well, then perhaps a more basic question: why is the numberneeded in the extension at all?  You already have the domain name; thenumber can be trivially derived from the name. For the major part of the cases I agree with you. But I am trying to make the extension as generic as possible. Im can imagine, that certain validation procedures might need this optional field. I still don't get it.  If the number is needed, it can be derived from the domain name.  Why carry it twice? The only scenario I can imagine is one in which some kind of formatting or some extra information (such as over-dialing numbers) needs to be preserved. Is that what you have in mind? For example. cheers,  Bernie _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum Ray Anderson    CEO    Bango   ray at bango.net             5 Westbrook Centre, Cambridge CB4 1YG, UK   Tel +44 7768 454545  Fax +44 20 7692 5558  Speed date with leaders in Mobile Content including Carphone Warehouse, Vodafone, O2, Orange, Real, enPocket, and Volantis Make contacts.   Get your questions answered.   Learn and profit from those who've been successful. Bango Nexus 2004: Central London   14 October 2004 http://nexus.bango.net _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 30 Sep 2004 11:41:50 -0400 From: Richard Shockey Date: Thu, 30 Sep 2004 11:41:50 -0400 To: enum at ietf.org Subject: [Enum] Reminder on Cut-Off Dates etc - Call for Agenda Items Message-ID: <6.1.0.6.2.20040930111629.04ff9eb0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Reminder folks .. as it looks now ENUM is tentatively scheduled for Monday night .. http://www.ietf.org/meetings/cutoff_dates_61.html the Chairs would like to see agenda item proposals based on drafts ASAP It looks like we have some new things on the plate http://ietf.hoeneisen.ch/draft-hoeneisen-enum-validation-epp-00.txt http://ietf.hoeneisen.ch/draft-hoeneisen-enum-validation-epp-00.html and Title : An ENUM Registry Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-newton-iris-ereg-02.txt Pages : 45 Date : 2004-9-28 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for ENUM administrative information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-02.txt I'm aware of one other draft ... anything else coming? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 30 Sep 2004 11:41:52 -0400 From: Internet-Drafts@ietf.org (by way of Richard Shockey ) Date: Thu, 30 Sep 2004 11:41:52 -0400 To: enum at ietf.org Subject: [Enum] I-D ACTION:draft-newton-iris-ereg-02.txt Message-ID: <6.1.0.6.2.20040930112149.04c44a10@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An ENUM Registry Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-newton-iris-ereg-02.txt Pages : 45 Date : 2004-9-28 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for ENUM administrative information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-newton-iris-ereg-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-newton-iris-ereg-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2004-9-28153543.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-newton-iris-ereg-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 30 Sep 2004 17:10:12 -0400 From: Richard Shockey Date: Thu, 30 Sep 2004 17:10:12 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-hoeneisen-enum-validation-epp-00.txt Message-ID: <6.1.0.6.2.20040930163133.045f4010@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Thu, 30 Sep 2004 15:44:03 -0400 Subject: I-D ACTION:draft-hoeneisen-enum-validation-epp-00.txt X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author(s) : B. Hoeneisen Filename : draft-hoeneisen-enum-validation-epp-00.txt Pages : 17 Date : 2004-9-30 This document describes an EPP extension for mapping information about the validation process the ENUM Registrar has 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 E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-validation-epp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-hoeneisen-enum-validation-epp-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-hoeneisen-enum-validation-epp-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: <2004-9-30160207.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-hoeneisen-enum-validation-epp-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum