From iesg-secretary@ietf.org Mon, 10 Jan 2005 03:58:01 -0500 From: "Mildner, Frank via RT" Date: Mon, 10 Jan 2005 03:58:01 -0500 To: enum at ietf.org Subject: AW: [Enum] [Inquiry #28743] AutoReply: In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R -----UrsprĂngliche Nachricht----- Von: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] Im Auftrag von Markou Kleoniki via RT Gesendet: Dienstag, 28. Dezember 2004 11:19 An: enum at ietf.org Betreff: RE: [Enum] [Inquiry #28743] AutoReply: -----Original Message----- From: IETF-IESG-Support via RT [mailto:iesg-secretary at ietf.org] Sent: Friday, December 24, 2004 1:53 PM To: enum at ietf.org Subject: [Enum] [Inquiry #28743] AutoReply: Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #28743] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #28743] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary at ietf.org ------------------------------------------------------------------------- _______________________________________________ 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 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 14 Jan 2005 11:17:14 -0500 From: Richard Shockey Date: Fri, 14 Jan 2005 11:17:14 -0500 To: enum at ietf.org Subject: [Enum] Fwd: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting in Minneapolis, MN Message-ID: <6.2.0.14.2.20050114104808.04480c40@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R From: ietf-secretariat at ietf.org To: IETF-Announce at ietf.org Date: Fri, 14 Jan 2005 10:09:15 -0500 Cc: Subject: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting in Minneapolis, MN X-BeenThere: ietf-announce at ietf.org X-Mailman-Version: 2.1.5 List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-announce-bounces at ietf.org X-Keywords: There are two (2) Internet-Draft cutoff dates for the 62nd IETF Meeting in Minneapolis, MN: February 14th: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions All initial Internet-Drafts (-00) must be submitted by Monday, February 14th at 9:00 AM ET. As always, all initial submissions (-00) with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. WG Chair approval must be received by Monday, February 7th at 9:00 AM ET. February 21st: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (-01 and higher) must be submitted by Monday, February 21st at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced, and will have to be resubmitted. Please do not wait until the last minute to submit. The Secretariat will begin accepting Internet-Draft submissions starting Monday, March 7th at 9:00 AM ET, but may not post or announce them until Monday, March 14th. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts at ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 62nd IETF Meeting can be found at http://www.ietf.org/meetings/IETF-62.html. _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/ietf-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 richard@shockey.us Fri, 14 Jan 2005 14:10:30 -0500 From: Richard Shockey Date: Fri, 14 Jan 2005 14:10:30 -0500 To: enum at ietf.org Subject: [Enum] Its that time again ... Message-ID: <6.2.0.14.2.20050114135146.04479d90@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Do we have any outstanding Agenda items or new documents we anticipate coming up in Minneapolis? I'd like to hear thoughts on this as soon as possible. We will probably discuss the enumdi document again on behalf of the IPTEL WG which will not be formally meeting in Minneapolis. Do the authors ..(including myself) plan on having a revision ready? Are there any more IESG issues with the web FT document? What about the operational experience document? Any additions here? Is VOID ready for last call? Will we see a WG revision of ENUM IRIS? Andy ..? We are hitting most of the WG milestones now. Time to discuss recharter? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 rfc-editor@rfc-editor.org Mon, 24 Jan 2005 19:03:19 -0500 From: rfc-editor@rfc-editor.org Date: Mon, 24 Jan 2005 19:03:19 -0500 To: ietf-announce at ietf.org Subject: [Enum] RFC 3953 on Telephone Number Mapping (ENUM) Service Registration for Presence Services Message-ID: <200501242354.j0ONs7Q27886@boreas.isi.edu> MIME-Version: 1.0 Content-Type: text/plain Status: R A new Request for Comments is now available in online RFC libraries. RFC 3953 Title: Telephone Number Mapping (ENUM) Service Registration for Presence Services Author(s): J. Peterson Status: Standards Track Date: January 2005 Mailbox: jon.peterson at neustar.biz Pages: 7 Characters: 13875 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-pres-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3953.txt This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM. This document is a product of the Telephone Number Mapping Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From klaus.darilion@nic.at Tue, 25 Jan 2005 06:01:05 -0500 From: "Klaus Darilion" Date: Tue, 25 Jan 2005 06:01:05 -0500 To: Subject: RE: [Enum] RFC 3953 on Telephone Number Mapping (ENUM) ServiceRegistration for Presence Services Message-ID: <8BC845943058D844ABFC73D2220D46650154CB9C@nics-mail.sbg.nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi all! I've went through this RFC and RFC 3861 and I'm trying to apply this methods to a real world scenario but without luck - maybe someone can elp me out: For example, I'm using a presence enabled SIP client which is registered as sip:klaus at mysipprovider.com. This presence notifier should be reachable via ENUM. First I will need a pres: URI, e.g. pres:klaus at mysipprovider.com. Thus, the entity (A) which is interested in my presence performs an ENUM lookup. This reveals: pres:klaus at mysipprovider.com A is also capable of SIP, thus it makes an SRV lookup for: _pres._sip.mysipprovider.com (btw: I have to bother my SIP provider to make the proper SRV records) This for example reveals a target: proxy.mysipprovider.com But what does A next? It will send a SUBSCRIBE message to proxy.mysipprovider.com, but how will the request URI look like? Will it be the pres URI like: SUBSCRIBE pres:klaus at mysipprovider.com Or is there some mechanism to map the pres: URI to a sip: URI? IMO this is laborious - wouldn't it be easier to use ENUM services which describes the protocol too, e.g. E2U+pres:sip E2U+pres:icq or using a URI which includes the protocol, e.g. IN NAPTR 100 10 "u" "E2U+pres" "!^.*$!sip:klaus at mysipprovider.com!" regards, klaus _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Wed, 26 Jan 2005 01:26:08 -0500 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Wed, 26 Jan 2005 01:26:08 -0500 To: "Klaus Darilion" Subject: Re: [Enum] RFC 3953 on Telephone Number Mapping (ENUM) ServiceRegistration for Presence Services In-Reply-To: <8BC845943058D844ABFC73D2220D46650154CB9C@nics-mail.sbg.nic.at> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Jan 25, 2005, at 11:55, Klaus Darilion wrote: IMO this is laborious - wouldn't it be easier to use ENUM services which describes the protocol too, e.g. E2U+pres:sip E2U+pres:icq or using a URI which includes the protocol, e.g. IN NAPTR 100 10 "u" "E2U+pres" "!^.*$!sip:klaus at mysipprovider.com!" What happens is to be described in the service specification for "pres" or "sip" or "icq" or whatever you call the string that is in the E2U service field. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@O2.COM Wed, 26 Jan 2005 06:50:12 -0500 From: "Fullbrook Kim (UK)" Date: Wed, 26 Jan 2005 06:50:12 -0500 To: "'enum at ietf.org> Subject: [Enum] "Enumservices" and RFC 3953 Message-ID: <0CD3FFEAEC982F489F872AB8DA32D6241FA05E@Uksthmsx012> MIME-Version: 1.0 Content-Type: text/plain Title: "Enumservices" and RFC 3953 Status: R This note is partly about the new RFC 3953 and mainly about "enumservices" in general. Various RFCs seem to treat the subject in slightly different ways and I'd like to ask some experts if I've interpreted the RFC's correctly. This has implications for DNS data and ensuring compatibility of services, and an example is included which I believe breaks in the current system. If I've misinterpreted the RFCs and the RFC proposals are fine, I'll be happy to be corrected. RFC 3953 describes use of ENUM with Presence services. Firstly, I'm not sure why we need a new RFC dealing specifically with Presence when the major existing services (or those under development) which would use E.164-based addressing actually utilise SIP and would be covered by existing RFCs. I'm thinking particularly of IMS here which is showing signs of global adoption by mobile and fixed operators. Anyway, that's not the main point and I'd prefer not to get side-tracked too far and would rather discuss the perceived flaw. From this point on I'm assuming that we do need to distinguish the Presence service as described by RFC 3953. A bit of background - what is an "enumservice" ?   There seems to be a conflict between RFCs. - RFC 3761 section 2.4.2 says "In other words, a non-optional "E2U" .... followed by 1 or more or more Enumservices which indicate what class of functionality a given end point offers.  Each Enumservice is indicated by an initial '+' character."  So in an NAPTR record with field "E2U+pres", the 'pres' bit is the enumservice and we could potentially have "E2U+servicea+serviceb".  - However, RFC3953 describes in Section 4 the "E2U+pres" Enumservice. So in this case the enumservice is "E2U+pres". Is the enumservice the combination "E2U+pres" or the singular "pres" ? I'll move on to the point of functionality that I'm concerned about, with an example to illustrate my question/concern. There are two users A and B. A is a customer of a new "Presence" service as described in RFC3953, which utilises the SIP protocol. ENUM data is in place with an NAPTR field of "E2U+pres". B is a customer of an existing RFC3824-compliant SIP-based system which has implemented presence. ENUM data is already in place with an NAPTR field of "E2U+SIP". Let us suppose that the new Presence service has a compatibility mode so that it can work with the existing SIP based presence service. Customer A calls B via their E.164 number. B's number is looked up in the ENUM DNS and all the NAPTR records for that number are returned. The NAPTR field i s "E2U+SIP".  A's service knows that it can work with SIP so a match of records is found, it also understands the sip: URI scheme, and the call goes through. Now Customer B calls A via their E.164 number. A's number is looked up in the ENUM DNS and all the NAPTR records for that number are returned. The NAPTR field is "E2U+pres".  B's service only knows that it can work with "SIP" service so there is no match of records - it does not know about "pres" - and the call fails. RFC 3953 specifies that the URI scheme has "pres:" URI scheme rather than "sip:" so potentially it could have failed here too because B does not understand "pres:" protocol. This is where my understanding fails regarding what is intended by the RFC authors. What the RFCs say does not implement what we need because in the example the call has failed. How do we solve the situation that I've described ? I'd suggest that one way it could be solved would be for the new Presence service to implement its ENUM data using an NAPTR field of "E2U+pres+SIP" while also using a "sip:" URI scheme (i.e. NAPTR record includes sip:+123456789 at networka.com). Then when B looks up A's ENUM data it can find a match with the "SIP" service. However, this can only work if the enumservice is based on the component parts (i.e. "pres" or "SIP") rather than the combination "E2U+pres", and the sip: URI scheme is used.  Another way it could work would be for the ENUM data for A to have two NAPTR records, one "E2U+pres" using the "pres:" URI and the other "E2U+SIP" using the "sip:" URI. This option seems to me to be a wasteful solution (twice as much data stored) which ignores the value of the "enumservice" field as described in RFC3761. I'll come back to the question posed above "what is an enumservice" ? If it is the component part i.e. "pres" or "SIP" then the design can work but some RFCs have misleading wording and have all the resolvers been implemented correctly to support what is needed ? Is there a problem here ? What do others think ? ========================================================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 klaus.darilion@nic.at Wed, 26 Jan 2005 09:06:15 -0500 From: "Klaus Darilion" Date: Wed, 26 Jan 2005 09:06:15 -0500 To: "Fullbrook Kim \(UK\)" Subject: RE: [Enum] "Enumservices" and RFC 3953 Message-ID: <8BC845943058D844ABFC73D2220D46650154CC93@nics-mail.sbg.nic.at> MIME-Version: 1.0 Content-Type: text/plain Title: "Enumservices" and RFC 3953 Status: R  
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Fullbrook Kim (UK)Sent: Wednesday, January 26, 2005 12:49 PMTo: 'enum at ietf.org'Subject: [Enum] "Enumservices" and RFC 3953  ...  Now Customer B calls A via their E.164 number. A's number is looked up in the ENUM DNS and all the NAPTR records for that number are returned. The NAPTR field is "E2U+pres".  B's service only knows that it can work with "SIP" service so there is no match of records - it does not know about "pres" - and the call fails. RFC 3953 specifies that the URI scheme has "pres:" URI scheme rather than "sip:" so potentially it could have failed here too because B does not understand "pres:" protocol. If the clients of A and B support several services - e.g. voice calls and presence - you have to publish them in DNS, e.g. make 2 NAPTRS E2U+voice:sip    sip:user at domainE2U+pres       pres:user at domain or if the URI is the same, you could use:E2U+voice:sip+pres    sip:user at domain Of course you could use a "generic" NAPTR using E2U+sip, nut this doesn't tell you if the client is capable of presence, video ... or not.
 Another way it could work would be for the ENUM data for A to have two NAPTR records, one "E2U+pres" using the "pres:" URI and the other "E2U+SIP" using the "sip:" URI. This option seems to me to be a wasteful solution (twice as much data stored) which ignores the value of the "enumservice" field as described in RFC3761. This is how ENUM works. If you want to publish your contact data, e.g. your email contact and your homepage, you also use one NAPTR for each service:E2U+web:http    http://domain/E2U+email:mailto       mailto:user at domain regards, klaus   _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@O2.COM Wed, 26 Jan 2005 09:55:16 -0500 From: "Fullbrook Kim (UK)" Date: Wed, 26 Jan 2005 09:55:16 -0500 To: "'Klaus Darilion'" Subject: RE: [Enum] "Enumservices" and RFC 3953 Message-ID: <0CD3FFEAEC982F489F872AB8DA32D6241FA094@Uksthmsx012> MIME-Version: 1.0 Content-Type: text/plain Title: Message Status: R Klaus,   Thanks, the suggestions make sense and are consistent with RFC 3761. They suggest that there is a series of terminology mistakes in RFC 3953: Where it says, for example, in Section 4 "the 'E2U+pres' enumservice" what it should have said was "the 'pres' enumservice"   Kim. -----Original Message-----From: Klaus Darilion [mailto:klaus.darilion at nic.at] Sent: 26 January 2005 13:52To: Fullbrook Kim (UK); enum at ietf.orgSubject: RE: [Enum] "Enumservices" and RFC 3953  
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Fullbrook Kim (UK)Sent: Wednesday, January 26, 2005 12:49 PMTo: 'enum at ietf.org'Subject: [Enum] "Enumservices" and RFC 3953  ...  Now Customer B calls A via their E.164 number. A's number is looked up in the ENUM DNS and all the NAPTR records for that number are returned. The NAPTR field is "E2U+pres".  B's service only knows that it can work with "SIP" service so there is no match of records - it does not know about "pres" - and the call fails. RFC 3953 specifies that the URI scheme has "pres:" URI scheme rather than "sip:" so potentially it could have failed here too because B does not understand "pres:" protocol. If the clients of A and B support several services - e.g. voice calls and presence - you have to publish them in DNS, e.g. make 2 NAPTRS E2U+voice:sip    sip:user at domainE2U+pres       pres:user at domain or if the URI is the same, you could use:E2U+voice:sip+pres    sip:user at domain Of course you could use a "generic" NAPTR using E2U+sip, nut this doesn't tell you if the client is capable of presence, video ... or not.
 Another way it could work would be for the ENUM data for A to have two NAPTR records, one "E2U+pres" using the "pres:" URI and the other "E2U+SIP" using the "sip:" URI. This option seems to me to be a wasteful solution (twice as much data stored) which ignores the value of the "enumservice" field as described in RFC3761. This is how ENUM works. If you want to publish your contact data, e.g. your email contact and your homepage, you also use one NAPTR for each service:E2U+web:http    http://domain/E2U+email:mailto       mailto:user at domain regards, klaus  ========================================================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 Thu, 27 Jan 2005 13:20:16 -0500 From: "Stastny Richard" Date: Thu, 27 Jan 2005 13:20:16 -0500 To: "Fullbrook Kim \(UK\)" Subject: RE: [Enum] "Enumservices" and RFC 3953 Message-ID: <32755D354E6B65498C3BD9FD496C7D46FAB7@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Kim and all, >A bit of background - what is an "enumservice" ? There seems to be a conflict between RFCs. >- RFC 3761 section 2.4.2 says "In other words, a non-optional "E2U" .... followed by 1 or more or more Enumservices which >indicate what class of functionality a given end point offers. Each Enumservice is indicated by an initial '+' character." >So in an NAPTR record with field "E2U+pres", the 'pres' bit is the enumservice and we could potentially have >"E2U+servicea+serviceb". >- However, RFC3953 describes in Section 4 the "E2U+pres" Enumservice. So in this case the enumservice is "E2U+pres". >Is the enumservice the combination "E2U+pres" or the singular "pres" ? I also recognized this problem some tme ago by looking at the IANA registrations for "enumservices", but I did not really follow-up. Maybe this is a good opportunity to do so, and the issue can be put on the agenda of the next IETF enum wg. The current registrations as shown in > are inconsistent and are likely to cause confusion with implementors: The Service Name (which is not defined in the template of RFC3761 section 3.2.3 shows in some case "examples" of the "service-field", in some other cases the "type" of the enumservice. IMHO ALL current registrations including webft should be changed considering RFC3761: service-field = "E2U" 1*(servicespec) servicespec = "+" enumservice enumservice = type 0*(subtypespec) subtypespec = ":" subtype type = 1*32(ALPHA / DIGIT) subtype = 1*32(ALPHA / DIGIT) the "Enumservice Name" should be type or type:subtype (or type:subtype:subtype...) and ALL registrations should contain Type(s): and Subtype(s): it should therefore be e.g. Service Name: "H323" and NOT "E2U+H323" Type: "H323" - missing Subtype: N/A - missing URI Scheme(s): "h323:" Service Name: "SIP" and NOT "E2U+SIP" Type(s): "SIP" Subtype(s): N/A URI Scheme(s): "sip", "sips:" Service Name: "ifax:mailto" and NOT "E2U+ifax" Type: "ifax" Subtype: "mailto" URI Scheme: "mailto" Service Name: "pres" and NOT "E2U+pres" Type: "pres" - missing Subtype: N/A - missing URI Scheme(s): "pres:" Service Name: "web:http" and NOT "web" Type: "web" Subtype: "http" URI Scheme: 'http:' Service Name: "web:https" and NOT "web" Type: "web" Subtype: "https" URI Scheme: 'https:' Service Name: "ft:ftp" and NOT "ft" Type: "ft" Subtype: "ftp" URI Scheme: 'ftp:' I suggest that this proposal is considered by the responsible A-Ds and WG chairs and that IANA is contacted appropriately after a decision is made. best regards Richard Stastny _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Thu, 27 Jan 2005 19:21:43 -0500 From: lconroy Date: Thu, 27 Jan 2005 19:21:43 -0500 To: "Stastny Richard" Subject: Re: [Enum] "Enumservices" and RFC 3953 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FAB7@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Richard, Klaus, Kim, all, Happy new year. Dead Right - the "E2U+blah" registrations are indeed wrong, in that they don't match the framework for registrations specified in RFC3761 section 3. That states that Enumservice registrations are based on type, with all sub-types and (generated) URI (schemes) being included in the registration. The type forms the apex of a namespace branch - there can be no other sub-types/URI schemes unless the "master" specification is updated/obsoleted. Tedious, but necessary. In the IANA tree specifications, conformance with RFC3761 is required, and the values put into the current IANA tree aren't. These normative specifications need to be precise, as otherwise the protocol is unclear. For example, at present, the IANA registration implies that a service string of the form "E2U+E2U+SIP", with a generated URI scheme of "sip:" is valid. It isn't. IMO, We should fix all the registrations ASAP. Looking at the ones with which I'm involved: As webft SHOULD be going through the IESG process, I'd suggest that we can change this during the Author's 48, assuming that ever occurs. Similarly, if the clarifications requested and provided for the msg draft have removed any reasonable remaining doubt, then we can ensure that the same is true for the individual service registrations included there too when that goes through Author's 48. I'll look through the Experiences draft to see if there's anywhere where the Enumservice strings could be ambiguous, but I don't think there is anything. I've heard no more issues raised, so from my perspective the current Experiences draft is complete. However, as the anointed Enumservices are RFCs already, does the errata mechanism need to be invoked? all the best, Lawrence On 27 Jan 2005, at 18:06, Stastny Richard wrote: Hi Kim and all, A bit of background - what is an "enumservice" ? There seems to be a conflict between RFCs. - RFC 3761 section 2.4.2 says "In other words, a non-optional "E2U" .... followed by 1 or more or more Enumservices which >indicate what class of functionality a given end point offers. Each Enumservice is indicated by an initial '+' character." So in an NAPTR record with field "E2U+pres", the 'pres' bit is the enumservice and we could potentially have >"E2U+servicea+serviceb". - However, RFC3953 describes in Section 4 the "E2U+pres" Enumservice. So in this case the enumservice is "E2U+pres". Is the enumservice the combination "E2U+pres" or the singular "pres" ? I also recognized this problem some time ago by looking at the IANA registrations for "enumservices", but I did not really follow-up. Maybe this is a good opportunity to do so, and the issue can be put on the agenda of the next IETF enum wg. The current registrations as shown in > are inconsistent and are likely to cause confusion with implementors: The Service Name (which is not defined in the template of RFC3761 section 3.2.3 shows in some case "examples" of the "service-field", in some other cases the "type" of the enumservice. IMHO ALL current registrations including webft should be changed considering RFC3761: service-field = "E2U" 1*(servicespec) servicespec = "+" enumservice enumservice = type 0*(subtypespec) subtypespec = ":" subtype type = 1*32(ALPHA / DIGIT) subtype = 1*32(ALPHA / DIGIT) the "Enumservice Name" should be type or type:subtype (or type:subtype:subtype...) and ALL registrations should contain Type(s): and Subtype(s): it should therefore be e.g. Service Name: "H323" and NOT "E2U+H323" Type: "H323" - missing Subtype: N/A - missing URI Scheme(s): "h323:" Service Name: "SIP" and NOT "E2U+SIP" Type(s): "SIP" Subtype(s): N/A URI Scheme(s): "sip", "sips:" Service Name: "ifax:mailto" and NOT "E2U+ifax" Type: "ifax" Subtype: "mailto" URI Scheme: "mailto" Service Name: "pres" and NOT "E2U+pres" Type: "pres" - missing Subtype: N/A - missing URI Scheme(s): "pres:" Service Name: "web:http" and NOT "web" Type: "web" Subtype: "http" URI Scheme: 'http:' Service Name: "web:https" and NOT "web" Type: "web" Subtype: "https" URI Scheme: 'https:' Service Name: "ft:ftp" and NOT "ft" Type: "ft" Subtype: "ftp" URI Scheme: 'ftp:' I suggest that this proposal is considered by the responsible A-Ds and WG chairs and that IANA is contacted appropriately after a decision is made. best regards Richard Stastny _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Sat, 29 Jan 2005 08:16:09 -0500 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Sat, 29 Jan 2005 08:16:09 -0500 To: "Stastny Richard" Subject: Re: [Enum] "Enumservices" and RFC 3953 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FAB7@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R I will take this up with IANA. paf On Jan 27, 2005, at 19:06, Stastny Richard wrote: Hi Kim and all, A bit of background - what is an "enumservice" ? There seems to be a conflict between RFCs. - RFC 3761 section 2.4.2 says "In other words, a non-optional "E2U" .... followed by 1 or more or more Enumservices which >indicate what class of functionality a given end point offers. Each Enumservice is indicated by an initial '+' character." So in an NAPTR record with field "E2U+pres", the 'pres' bit is the enumservice and we could potentially have >"E2U+servicea+serviceb". - However, RFC3953 describes in Section 4 the "E2U+pres" Enumservice. So in this case the enumservice is "E2U+pres". Is the enumservice the combination "E2U+pres" or the singular "pres" ? I also recognized this problem some tme ago by looking at the IANA registrations for "enumservices", but I did not really follow-up. Maybe this is a good opportunity to do so, and the issue can be put on the agenda of the next IETF enum wg. The current registrations as shown in > are inconsistent and are likely to cause confusion with implementors: The Service Name (which is not defined in the template of RFC3761 section 3.2.3 shows in some case "examples" of the "service-field", in some other cases the "type" of the enumservice. IMHO ALL current registrations including webft should be changed considering RFC3761: service-field = "E2U" 1*(servicespec) servicespec = "+" enumservice enumservice = type 0*(subtypespec) subtypespec = ":" subtype type = 1*32(ALPHA / DIGIT) subtype = 1*32(ALPHA / DIGIT) the "Enumservice Name" should be type or type:subtype (or type:subtype:subtype...) and ALL registrations should contain Type(s): and Subtype(s): it should therefore be e.g. Service Name: "H323" and NOT "E2U+H323" Type: "H323" - missing Subtype: N/A - missing URI Scheme(s): "h323:" Service Name: "SIP" and NOT "E2U+SIP" Type(s): "SIP" Subtype(s): N/A URI Scheme(s): "sip", "sips:" Service Name: "ifax:mailto" and NOT "E2U+ifax" Type: "ifax" Subtype: "mailto" URI Scheme: "mailto" Service Name: "pres" and NOT "E2U+pres" Type: "pres" - missing Subtype: N/A - missing URI Scheme(s): "pres:" Service Name: "web:http" and NOT "web" Type: "web" Subtype: "http" URI Scheme: 'http:' Service Name: "web:https" and NOT "web" Type: "web" Subtype: "https" URI Scheme: 'https:' Service Name: "ft:ftp" and NOT "ft" Type: "ft" Subtype: "ftp" URI Scheme: 'ftp:' I suggest that this proposal is considered by the responsible A-Ds and WG chairs and that IANA is contacted appropriately after a decision is made. best regards Richard Stastny _______________________________________________ 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