From lconroy@insensate.co.uk Tue, 01 Mar 2005 20:20:16 -0500 From: lconroy Date: Tue, 01 Mar 2005 20:20:16 -0500 To: "'enum at ietf.org> Subject: [Enum] To Err is stupid, but Message-ID: <1a9b2d2567daa464afa64a4e9d91eb04@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Folks, I noticed (why is it always AFTER you ship the document?) that due to a major screw up on my part, the ENUM DIP Indicator draft seems to have lost one of the authors. Richard Shockey was and is the second author in this doc, and it's only my inability to type XML correctly that messed up the draft. The rest of the doc is fine - only the author bit at the start seems to have been mangled. This is all my fault, and I apologise to the disappeared Richard. Thus expect to see a version -01 as soon as we're out of draft shadow; the only change will be that I'll put the XML in correctly, and the missing man will reappear. all the best, Lawrence --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From fluffy@cisco.com Thu, 03 Mar 2005 12:32:38 -0500 From: Cullen Jennings Date: Thu, 03 Mar 2005 12:32:38 -0500 To: Subject: [Enum] better way to do johnston-enum-conf-service In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FB36@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO I read this and I may be missing the point on it but it seemed sort of like a bad idea. The conference phone number should have registrations with the services such as sip and web - defining new servers will make things worse. It will hamper interoperability and the existing mechanism will work better. Imagine a UA that supports ENUM where I type in a phone number to call. If it supports enum today, it will do a lookup, find the sip service and no what to do. Now if it finds the conference service with a sip uri and sip service - what does it do? which one would it choose? will we need another service for IVRs? What about voicemail? What benefit would it have to know that it is a conference - the signaling will tell it that as soon as it contacts it in some signaling protocols. Now image a conference that only published the conf service in ENUM but the UA did not support this, it would not work. What about if the sip service pointed to one place and the conf service pointed to another. All sounds like a very confusing state of affairs with little to nothing to be gained. I think I am basically saying that the the currently defined services in RFC 4002 and 3762 fully solve the problem that this draft is trying to address. Cullen _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Fri, 04 Mar 2005 08:27:51 -0500 From: James Seng Date: Fri, 04 Mar 2005 08:27:51 -0500 To: "'enum at ietf.org> Subject: [Enum] Success with APEET ENUM/SIP Live Trial at APRICOT 2005 Message-ID: <1be7fc2f7f4e557c7c2fe0b18c9bc851@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: RO http://www.apenum.org/Press_Releases/Live_Trial_At_APRICOT2005 Singapore, Mar 4, 2005– Asia Pacific ENUM Engineering Team (APEET) announced the successful conclusion of the APEET ENUM/SIP Live Trial at APRICOT 2005. The Live Trial conducted by APEET involves loaning Wifi SIP phones, sponsored by Hitachi-cable, preconfigured with an ENUM number and SIP account. Participants in the Live Trial was able to use the Wifi SIP phones to make free unlimited calls to each other and also PSTN calls to the Beijing, Singapore, Sweden, Taiwan and United States supported by Jeff Pulver/LibreTel (US), Jakob Schlyter (SE), APRICOT 2005 NOC team and members of APEET.  “It is stunning to see so many people excitingly calling each another as if they never made a phone call in their life.”, said James Seng, Chairman of APEET, “Very few technology can create such enthusiasm among the engineers.” The purpose of the Live Trial is to demonstrate the readiness of ENUM and SIP technology and to get engineers familiar with it. Much of effort of the trial involves ensuring the wireless network infrastructure is capable of handling VoIP over WiFi and making the phones “just work out of the box”. “This Live Trial has achieved more than what a hundred presentations can do in evangelizing the technology”, said Richard Shockey, IETF ENUM Working Group co-chair and Senior Manager, Strategic Technology Initiatives, NeuStar Inc.   The Live Trial was so well received by APRICOT delegate that the Wifi SIP phones were out-of-stock in 5 hours. “Seeing conference participants fight to get a phone so they can participate is the best score a live trial can get”, said Patrik Fältström, Cisco Systems, co-author of ENUM specification. Participants were impressed with the neat system provided by APEET, ease of use of the Hitachi-cable phones and the voice quality of the calls. “I used the phone to call home and the performance was better then US cell phone!”, said Bill Norton, co-founder of Equinix. “Users were so pleased with the success of the trial, that there was a great demand for continuation of this project at the next IETF meeting.”, said Bill Woodcock, Research Director of Packet Clearing House and Operator of INOC-DBA global VoIP hotline phone system.  APEET received many favorable feedbacks and will conduct a larger trial at some other event within the next 12 months. For more information, please visit http://www.apenum.org/ Media Contact APEET info at apenum.org About Asia Pacific ENUM Engineering Team (APEET)  Started in 2004, APEET is an informal project team comprises of engineers from CNNIC, JPRS, KRNIC, SGNIC and TWNIC and invited experts. The goal of APEET is to conduct joint trials and to promote the development of ENUM and its related technology such as SIP. We welcome other engineers from ccTLD communities to join APEET. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@seng.cc Fri, 04 Mar 2005 10:29:13 -0500 From: James Seng Date: Fri, 04 Mar 2005 10:29:13 -0500 To: "'enum-wg at ripe.net Subject: [Enum] Success with APEET ENUM/SIP Live Trial at APRICOT 2005 Message-ID: <09b92e2c9b93b51957226ebbb9379ac6@seng.cc> MIME-Version: 1.0 Content-Type: text/plain Status: RO http://www.apenum.org/Press_Releases/Live_Trial_At_APRICOT2005 Singapore, Mar 4, 2005– Asia Pacific ENUM Engineering Team (APEET) announced the successful conclusion of the APEET ENUM/SIP Live Trial at APRICOT 2005. The Live Trial conducted by APEET involves loaning Wifi SIP phones, sponsored by Hitachi-cable, preconfigured with an ENUM number and SIP account. Participants in the Live Trial was able to use the Wifi SIP phones to make free unlimited calls to each other and also PSTN calls to the Beijing, Singapore, Sweden, Taiwan and United States supported by Jeff Pulver/LibreTel (US), Jakob Schlyter (SE), APRICOT 2005 NOC team and members of APEET.  “It is stunning to see so many people excitingly calling each another as if they never made a phone call in their life.”, said James Seng, Chairman of APEET, “Very few technology can create such enthusiasm among the engineers.” The purpose of the Live Trial is to demonstrate the readiness of ENUM and SIP technology and to get engineers familiar with it. Much of effort of the trial involves ensuring the wireless network infrastructure is capable of handling VoIP over WiFi and making the phones “just work out of the box”. “This Live Trial has achieved more than what a hundred presentations can do in evangelizing the technology”, said Richard Shockey, IETF ENUM Working Group co-chair and Senior Manager, Strategic Technology Initiatives, NeuStar Inc.   The Live Trial was so well received by APRICOT delegate that the Wifi SIP phones were out-of-stock in 5 hours. “Seeing conference participants fight to get a phone so they can participate is the best score a live trial can get”, said Patrik Fältström, Cisco Systems, co-author of ENUM specification. Participants were impressed with the neat system provided by APEET, ease of use of the Hitachi-cable phones and the voice quality of the calls. “I used the phone to call home and the performance was better then US cell phone!”, said Bill Norton, co-founder of Equinix. “Users were so pleased with the success of the trial, that there was a great demand for continuation of this project at the next IETF meeting.”, said Bill Woodcock, Research Director of Packet Clearing House and Operator of INOC-DBA global VoIP hotline phone system.  APEET received many favorable feedbacks and will conduct a larger trial at some other event within the next 12 months. For more information, please visit http://www.apenum.org/ Media Contact APEET info at apenum.org About Asia Pacific ENUM Engineering Team (APEET)  Started in 2004, APEET is an informal project team comprises of engineers from CNNIC, JPRS, KRNIC, SGNIC and TWNIC and invited experts. The goal of APEET is to conduct joint trials and to promote the development of ENUM and its related technology such as SIP. We welcome other engineers from ccTLD communities to join APEET. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 04 Mar 2005 12:23:27 -0500 From: Richard Shockey Date: Fri, 04 Mar 2005 12:23:27 -0500 To: enum at ietf.org Subject: [Enum] News from +49 Message-ID: <6.2.1.2.2.20050304122246.051324a0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO All, some ENUM related news from Germany: Best, Carsten Schiefner >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 alan.johnston@mci.com Sat, 05 Mar 2005 22:58:11 -0500 From: "Johnston, Alan" Date: Sat, 05 Mar 2005 22:58:11 -0500 To: Cullen Jennings MIME-Version: 1.0 Content-Type: text/plain Status: RO Cullen, Thanks for your comments on the draft. I disagree that the 'sip' and 'web' ENUM service solves this problem. The problem is allowing an application to discover that a phone number is associated with a conference, and discovering URIs that provide control and content related to the conference. If you disagree that providing a mechanism for conference discovery is useful, then we should start with this. However, we defined "isfocus" for SIP to solve this problem. H.323, PSTN, and other protocols don't have such a useful mechanism. Remember that all the world is not (yet) SIP enabled :-) For the web page, there is a huge difference between just knowing there is some HTTP URI somehow associated with this phone number vs. there is a web conference which provides control and content directly associated with the conference hosted by this phone number. If you think that having multiple ENUM service records is a bad thing, then we should start discussing this, because this approach will require some duplicate records. However, I think the extra information provided is useful, and I think others think so as well. Thanks, Alan Johnston sip:alan at sipstation.com > -----Original Message----- > From: Cullen Jennings [mailto:fluffy at cisco.com] > Sent: Thursday, March 03, 2005 11:32 AM > To: enum at ietf.org; Johnston, Alan > Subject: better way to do johnston-enum-conf-service > > > > I read this and I may be missing the point on it but it > seemed sort of like a bad idea. The conference phone number > should have registrations with the services such as sip and > web - defining new servers will make things worse. It will > hamper interoperability and the existing mechanism will work better. > > Imagine a UA that supports ENUM where I type in a phone > number to call. If it supports enum today, it will do a > lookup, find the sip service and no what to do. Now if it > finds the conference service with a sip uri and sip service - > what does it do? which one would it choose? will we need > another service for IVRs? What about voicemail? What benefit > would it have to know that it is a conference - the signaling > will tell it that as soon as it contacts it in some signaling > protocols. Now image a conference that only published the > conf service in ENUM but the UA did not support this, it > would not work. What about if the sip service pointed to one > place and the conf service pointed to another. All sounds > like a very confusing state of affairs with little to nothing > to be gained. > > I think I am basically saying that the the currently defined > services in RFC 4002 and 3762 fully solve the problem that > this draft is trying to address. > > Cullen > > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Sun, 06 Mar 2005 08:39:29 -0500 From: lconroy Date: Sun, 06 Mar 2005 08:39:29 -0500 To: "Johnston, Alan" Subject: Re: [Enum] RE: better way to do johnston-enum-conf-service In-Reply-To: <40AF35183B110B4899DD3221904B6B58F4BC56@usashms001.mcilink.com> Message-ID: <632d84a64429e2794274961bec5df881@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Alan, Cullen, Folks, I fully expect to include a web link to a logo/picture in my ENUM domain (just haven't "got a round toit" yet), as I don't have the privacy concerns that other do. (That'll certainly be compliant to RFC4002 :). You *could* do the same for the proposed conference web link. However, this won't tell you that this has information on a conference. Yes it's a web link, so from an ENUM perspective your client needs to know only that it has to fire up a browser to use the generated URI. However, information on a conference is more than just that - it tells me that peripheral information on a conference is stored "behind" this service, and it does so right in the ENUM data I've retrieved. How many times have you been given a dial-in number, but not known how to find out what's the schedule for your use of this number, or that there is a related number for text phones or for simultaneous translation, or ... ? AFAICT, Alan isn't suggesting that each of these be separate ENUM entries, but simply that the ENUM client knows that "this is where you can get the information". IMHO, it's a great idea, and one I trust customers can use real soon now. all the best, Lawrence On 6 Mar 2005, at 03:57, Johnston, Alan wrote: Cullen, Thanks for your comments on the draft. I disagree that the 'sip' and 'web' ENUM service solves this problem. The problem is allowing an application to discover that a phone number is associated with a conference, and discovering URIs that provide control and content related to the conference. If you disagree that providing a mechanism for conference discovery is useful, then we should start with this. However, we defined "isfocus" for SIP to solve this problem. H.323, PSTN, and other protocols don't have such a useful mechanism. Remember that all the world is not (yet) SIP enabled :-) For the web page, there is a huge difference between just knowing there is some HTTP URI somehow associated with this phone number vs. there is a web conference which provides control and content directly associated with the conference hosted by this phone number. If you think that having multiple ENUM service records is a bad thing, then we should start discussing this, because this approach will require some duplicate records. However, I think the extra information provided is useful, and I think others think so as well. Thanks, Alan Johnston sip:alan at sipstation.com -----Original Message----- From: Cullen Jennings [mailto:fluffy at cisco.com] Sent: Thursday, March 03, 2005 11:32 AM To: enum at ietf.org; Johnston, Alan Subject: better way to do johnston-enum-conf-service I read this and I may be missing the point on it but it seemed sort of like a bad idea. The conference phone number should have registrations with the services such as sip and web - defining new servers will make things worse. It will hamper interoperability and the existing mechanism will work better. Imagine a UA that supports ENUM where I type in a phone number to call. If it supports enum today, it will do a lookup, find the sip service and no what to do. Now if it finds the conference service with a sip uri and sip service - what does it do? which one would it choose? will we need another service for IVRs? What about voicemail? What benefit would it have to know that it is a conference - the signaling will tell it that as soon as it contacts it in some signaling protocols. Now image a conference that only published the conf service in ENUM but the UA did not support this, it would not work. What about if the sip service pointed to one place and the conf service pointed to another. All sounds like a very confusing state of affairs with little to nothing to be gained. I think I am basically saying that the the currently defined services in RFC 4002 and 3762 fully solve the problem that this draft is trying to address. Cullen _______________________________________________ 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 lconroy@insensate.co.uk Sun, 06 Mar 2005 11:08:43 -0500 From: lconroy Date: Sun, 06 Mar 2005 11:08:43 -0500 To: "'enum at ietf.org> Subject: [Enum] Sufficient information in NAPTRs, MSG, and VOVI Message-ID: <5496fce19afdce26589577f43921dc0e@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi folks, The conf-service thread has pushed me to a couple of general issues that have been lurking around. As "whatever happened to VOVI?" is down on the agenda, I offer this generalisation for your comments, as I think they're related. Sorry for its length - those with ADD can skip to the last bit starting "In short...". ---- * The web Enumservice is very similar to a TXT resource record - it's general. That's good, and TXT records are already being used to show a person's name (and/or the textual label one could pop up for this E-number). The SIP Enumservice is also general - this generated URI "points to" a SIP service and you "do the SIP thing" to negotiate further. From a protocol perspective, this is enough information - the ENUM client fires up a Web or SIP client and we're done. [Of course the provider for that service and the registered SIP device set "behind" it may or may not support the communications ->mode<- the querying user wants to use. He or she can find out by firing up a SIP invite, have their machine spend some CPU cycles with any puzzle challenge, and then potentially find out that they don't do IM, for example, or that the registrant hasn't told that SIP registrar about their IM-capable device and/or their preferred presence/IM service with a chained registration. It is left as an exercise for the various providers' help desk(s) to explain this to their customers. :-] * There is potential to carry "higher level" application information in NAPTRs. There have also been comments in the past that you might want to indicate that a target URL is associated with a mobile device (a WiFi phone, in Henry's case :), or with a work phone, or a home phone, or ... Conversely, Cullen was worried that you could end up indicating an IVR, or VM, or other things that have defeated the learned experts of SIP/SIPPING for years - it has proved to be a rat's nest. Quelle Surprise. I suspect that this is not going to go away. Is there any way that this "higher level extra information" can be encoded into the data published in ENUM? If so, do we need to *codify* every possible alternative in a way that a machine can process the entries to come out with a single result on its own? 3761 allows a nested set of sub*[-sub]-types. It specifies that each pattern of type (and, optionally, sub-type) is unique, and that these are required to be processed in deciding on the acceptability/support for an Enumservice. All of these elements are codified and are considered by the ENUM client in resolving the NAPTR rrset. If we have SIP entries and web entries as well as voice telephone entries, then the program sitting on the querying client's machine (or on that of their agent server, which is even more interesting) may have no easy way of telling which mode of communication and which protocol is the "best" one from that end user's perspective. It may well have to ask. In this case, we already have "a human in the loop". It seems to me that there is a valid case for someone tagging on some extra information to an Enumservice that is intended purely for the querying Human, rather than their machine. From the ENUM client's perspective, this extra information is not relevant, but if there's no obvious single answer, it can be presented to the end user for their edification. Thus we have Enumservice specifications defining the (mandatory) data that the ENUM client needs to consider, but "beyond that", any extra information (in sub-sub-types, or in sub-sub-sub-types) is ignored as part of the evaluation but can be passed on to the end user if there's a tie. ---- In the case of the "tel:" URI scheme, we have an issue - it's why we included MSG and VOVI. The PSTN is used to provide a number of different Teleservices ->that use different programs on the end user's machine<-. Someone may well have a voice client on their machine that they use to place and receive voice calls with E.164 telephone numbers as destination address - could be via a SIP provider, or if they're rich, they could be using, say, a direct ISDN connection. They could also have a fax program that they use to receive and send faxes. They could also have an SMS program that they use to send and receive texts. These will be completely different programs, so from an ENUM client perspective, it would like to know which program to fire up. The URL scheme is not enough in this case. IMHO, it's mandatory to include an indication of the Teleservice, so that the ENUM Client can fire up the right program, as these programs will be associated with discrete Teleservices. You *could* just fire up a voice program and when you hear a fax answer tone realise that this is not what you need. However, whilst it may make sense for SIP of H323 if the clients have a defined mechanism for mode negotiation, for for these "legacy support" applications it isn't going to make the end user very happy. ---- In short, I think that the important thing is whether or not an ENUM client has the information it needs to fire up the right program. This information is mandatory for us to include in the Enumservice specification and for the ENUM client to consider in its resolution. There may also be "high level application extra information" that is intended only for a Human rather than a machine, and so the ENUM client does not need to consider but can present to that Human if they are "in the loop" for NAPTR rrset evaluation. Any such information could well be "tagged on" after the mandatory Enumservice type (and sub-type, if it's there), and is just ignored in ENUM client evaluation. Thus folk who really want to indicate that this URL is dedicated to VM can do so, without breaking anything and without requiring an infinite length Enumservice registration RFC. My vote's for putting such optional info on the right of an Enumservice. My vote's also for having the Enumservice as well as the URL scheme for the different Teleservices associated with a "tel:" URL, as otherwise the ENUM client will not *know* which program to run. I believe that this should be on the "left end" of the Enumservice definition (e.g. sms:tel). Comments, please. all the best, Lawrence --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Sun, 06 Mar 2005 15:45:27 -0500 From: Richard Shockey Date: Sun, 06 Mar 2005 15:45:27 -0500 To: lconroy Message-ID: <6.2.1.2.2.20050306153409.054c1e80@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 11:08 AM 3/6/2005, lconroy wrote: Hi folks, The conf-service thread has pushed me to a couple of general issues that have been lurking around. As "whatever happened to VOVI?" is down on the agenda, I offer this generalisation for your comments, as I think they're related. Sorry for its length - those with ADD can skip to the last bit starting "In short...". ---- * The web Enumservice is very similar to a TXT resource record - it's general. That's good, and TXT records are already being used to show a person's name (and/or the textual label one could pop up for this E-number). The SIP Enumservice is also general - this generated URI "points to" a SIP service and you "do the SIP thing" to negotiate further. From a protocol perspective, this is enough information - the ENUM client fires up a Web or SIP client and we're done. [Of course the provider for that service and the registered SIP device set "behind" it may or may not support the communications ->mode<- the querying user wants to use. He or she can find out by firing up a SIP invite, have their machine spend some CPU cycles with any puzzle challenge, and then potentially find out that they don't do IM, for example, or that the registrant hasn't told that SIP registrar about their IM-capable device and/or their preferred presence/IM service with a chained registration. It is left as an exercise for the various providers' help desk(s) to explain this to their customers. :-] Yes ... we had this debate before remember there was substantial objections by the SIP community to adding granular information or hints to the registration as in E2U+sip:voice E2U+sip:im etc .. personally Ive never seen the reason for the objection but I respect the opinion of those who see a problem here. I'd be willing to revisit the issue if there was as good argument to do so. Now on the issue of the VOVI draft ..no it is not on the agenda since I did not have a request for it..but frankly I dont like it. What I want is a comprehensive tel registration document and we need that now for several reasons. What I would like to see is where tel is the type and everything else is a subtype. tel:voice tel:fax tel:sms tel:mms i dont want them reversed IMHO voice is not a "type" in this context maybe * ______________ 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.Stastny@oefeg.at Sun, 06 Mar 2005 17:44:19 -0500 From: "Stastny Richard" Date: Sun, 06 Mar 2005 17:44:19 -0500 To: "Richard Shockey" Subject: AW: [Enum] Sufficient information in NAPTRs, MSG, and VOVI Message-ID: <32755D354E6B65498C3BD9FD496C7D46FBDE@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO My esteemed co-chair, >What I want is a comprehensive tel registration document and we need that >now for several reasons. >What I would like to see is where tel is the type and everything else is a >subtype. I do not want to discuss >tel:voice here but if you want to define >tel:fax >tel:sms >tel:mms then plese submit a draft explaining the difference to fax:tel sms:tel mms:tel defined in the RFC-tobe http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-04.txt Richard >i dont want them reversed IMHO voice is not a "type" in this context >maybe _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Sun, 06 Mar 2005 18:06:28 -0500 From: lconroy Date: Sun, 06 Mar 2005 18:06:28 -0500 To: Richard Shockey Subject: Re: [Enum] Sufficient information in NAPTRs, MSG, and VOVI In-Reply-To: <5496fce19afdce26589577f43921dc0e@insensate.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Richard, folks, Re. application:network identifier vs network identifier:application: I note that this issue wasn't raised before or during the WGLC or IETF LC for MSG, which includes a registration for 'tel:fax'. Are we really running out of reasons to block/re-assess the MSG draft? ---- Re. do I remember VOVI? - it's indelibly burnt into my brain. (BTW, I threw this in this originally only so that the Helpdesk crowd will know who to thank for their full lives - not me :). SIP was airbrushed out of VOVI-01 way back in 2003 as a reaction to The SIP Community who saw a problem with it. When we next had a chance to talk with Orit (who couldn't be heard in the original meeting for the enthusiasm of The Community :) we removed h323 from the mix as well, in -02 which came out last year after the Seoul meeting. Since then VOVI dealt exclusively with voice and video services using E.164 network identifiers. The only reference to SIP or H323 is to indicate that a call to a PLMN (or PSTN) device may be made indirectly (via a SIP or H323 to PSTN gateway). VOVI-02 has some minor cut-and-paste typos and a reference to RFC2806 so it needed a refresh but, as there is an objection, I guess we just let it expire in the IETF. It's in use already so isn't worth the grief. ---- The esteemed co-chair has spoken - I'm not sure in what Language, but I get the tone. all the best, Lawrence On 6 Mar 2005, at 20:43, Richard Shockey wrote: At 11:08 AM 3/6/2005, lconroy wrote: Hi folks, The conf-service thread has pushed me to a couple of general issues that have been lurking around. As "whatever happened to VOVI?" is down on the agenda, I offer this generalisation for your comments, as I think they're related. Sorry for its length - those with ADD can skip to the last bit starting "In short...". ---- * The web Enumservice is very similar to a TXT resource record - it's general. That's good, and TXT records are already being used to show a person's name (and/or the textual label one could pop up for this E-number). The SIP Enumservice is also general - this generated URI "points to" a SIP service and you "do the SIP thing" to negotiate further. From a protocol perspective, this is enough information - the ENUM client fires up a Web or SIP client and we're done. [Of course the provider for that service and the registered SIP device set "behind" it may or may not support the communications ->mode<- the querying user wants to use. He or she can find out by firing up a SIP invite, have their machine spend some CPU cycles with any puzzle challenge, and then potentially find out that they don't do IM, for example, or that the registrant hasn't told that SIP registrar about their IM-capable device and/or their preferred presence/IM service with a chained registration. It is left as an exercise for the various providers' help desk(s) to explain this to their customers. :-] Yes ... we had this debate before remember there was substantial objections by the SIP community to adding granular information or hints to the registration as in E2U+sip:voice E2U+sip:im etc .. personally Ive never seen the reason for the objection but I respect the opinion of those who see a problem here. I'd be willing to revisit the issue if there was as good argument to do so. Now on the issue of the VOVI draft ..no it is not on the agenda since I did not have a request for it..but frankly I dont like it. What I want is a comprehensive tel registration document and we need that now for several reasons. What I would like to see is where tel is the type and everything else is a subtype. tel:voice tel:fax tel:sms tel:mms i dont want them reversed IMHO voice is not a "type" in this context maybe * ______________ 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 --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Mon, 07 Mar 2005 10:39:55 -0500 From: Richard Shockey Date: Mon, 07 Mar 2005 10:39:55 -0500 To: "Stastny Richard" Subject: Re: AW: [Enum] Sufficient information in NAPTRs, MSG, and VOVI In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FBDE@oefeg-s04.oefeg.loc> Message-ID: <6.2.1.2.2.20050307103212.04440eb0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO A I do not want to discuss >tel:voice here Oh why not ? :-) what is clear is that we need 1. generic tel: registration and the issues raised by the vovi draft 2. yes we need something like a voice:tel 3 yes we need something like video:tel but if you want to define >tel:fax >tel:sms >tel:mms then plese submit a draft explaining the difference to fax:tel sms:tel mms:tel Now that is exactly my point ..what IYHO is the difference between the semantics of the two. Operationally if someone sees tel:fax vs fax:tel should they reject the record... are the two functionally the same ...should they be functionally the same? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.Stastny@oefeg.at Mon, 07 Mar 2005 10:53:25 -0500 From: "Stastny Richard" Date: Mon, 07 Mar 2005 10:53:25 -0500 To: "Richard Shockey" Subject: Re: [Enum] Sufficient information in NAPTRs, MSG, and VOVI Message-ID: <32755D354E6B65498C3BD9FD496C7D46FBE2@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO >Now that is exactly my point ..what IYHO is the difference between the >semantics of the two. >Operationally if someone sees tel:fax vs fax:tel should they reject the >record... are the two functionally the same ...should they be functionally >the same? Question 1 to Patrik and MM as editors of RFC3761: Is is syntatical possible for two enumservices foo:bar and bar:foo to be semantically the same? IMHO not, because the idea of types, subtypes and subsubtypes is meaningless, each type would stand on its own and could be combined randomly by dice (we would not need the +) Question 2: if not, they cannot be functionally the same, so the question arises What is the difference between fax:tel and tel:fax Please elaborate Also please elaborate what you want to achieve with this discussion Richard ________________________________ Von: Richard Shockey [mailto:richard at shockey.us] Gesendet: Mo 07.03.2005 16:39 An: Stastny Richard; lconroy; enum at ietf.org Betreff: Re: AW: [Enum] Sufficient information in NAPTRs, MSG, and VOVI A >I do not want to discuss > >tel:voice >here Oh why not ? :-) what is clear is that we need 1. generic tel: registration and the issues raised by the vovi draft 2. yes we need something like a voice:tel 3 yes we need something like video:tel > >but if you want to define > > >tel:fax > >tel:sms > >tel:mms > >then plese submit a draft explaining the difference to > >fax:tel >sms:tel >mms:tel > Now that is exactly my point ..what IYHO is the difference between the semantics of the two. Operationally if someone sees tel:fax vs fax:tel should they reject the record... are the two functionally the same ...should they be functionally the same? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Mon, 07 Mar 2005 14:50:13 -0500 From: Richard Shockey Date: Mon, 07 Mar 2005 14:50:13 -0500 To: "Stastny Richard" Subject: Re: [Enum] Sufficient information in NAPTRs, MSG, and VOVI In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FBE2@oefeg-s04.oefeg.loc> Message-ID: <6.2.1.2.2.20050307105648.047ca7e0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 10:55 AM 3/7/2005, Stastny Richard wrote: >Now that is exactly my point ..what IYHO is the difference between the >semantics of the two. >Operationally if someone sees tel:fax vs fax:tel should they reject the >record... are the two functionally the same ...should they be functionally >the same? Question 1 to Patrik and MM as editors of RFC3761: I'd certainly be interested in Patrik's view here but it is something we can clarify in the Operational Experiences draft. Is is syntatical possible for two enumservices foo:bar and bar:foo to be semantically the same? IMHO not, because the idea of types, subtypes and subsubtypes is meaningless, each type would stand on its own and could be combined randomly by dice (we would not need the +) I'm not sure of that .. the service is the union of E2U+(types) I'm suggesting that the order could be meaningless. Question 2: if not, they cannot be functionally the same, so the question arises What is the difference between fax:tel and tel:fax I dont know that is the problem. Please elaborate Also please elaborate what you want to achieve with this discussion Clarity ... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.Stastny@oefeg.at Mon, 07 Mar 2005 15:22:55 -0500 From: "Stastny Richard" Date: Mon, 07 Mar 2005 15:22:55 -0500 To: Subject: Re: [Enum] Sufficient information in NAPTRs, MSG, and VOVI Message-ID: <32755D354E6B65498C3BD9FD496C7D46FBE6@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO >Does that help? Yes, thanks, you asserted my opinion ;-) Rich, does it help? Richard ________________________________ Von: Michael Mealling [mailto:michael at refactored-networks.com] Gesendet: Mo 07.03.2005 17:07 An: Stastny Richard; enum-bounces at ietf.org; Richard Shockey; lconroy; enum at ietf.org Betreff: Re: [Enum] Sufficient information in NAPTRs, MSG, and VOVI Fax:tel and tel:fax are different since the rhs is defined by the lhs. The difference I would attach is that the 'tel' part of 'fax:tel' suggests that it is a restricted definition of telephony (I.e. a profile) that is specific to how faxing works. For example it might define that litle beep some faxes send during what seems like a voice call to see if another fax might be evesdropping. Does that help? -.. -----Original Message----- From: "Stastny Richard" Date: Mon, 7 Mar 2005 16:55:37 To:"Richard Shockey" , "lconroy" , enum at ietf.org Subject: Re: [Enum] Sufficient information in NAPTRs, MSG, and VOVI >Now that is exactly my point ..what IYHO is the difference between the >semantics of the two. >Operationally if someone sees tel:fax vs fax:tel should they reject the >record... are the two functionally the same ...should they be functionally >the same? Question 1 to Patrik and MM as editors of RFC3761: Is is syntatical possible for two enumservices foo:bar and bar:foo to be semantically the same? IMHO not, because the idea of types, subtypes and subsubtypes is meaningless, each type would stand on its own and could be combined randomly by dice (we would not need the +) Question 2: if not, they cannot be functionally the same, so the question arises What is the difference between fax:tel and tel:fax Please elaborate Also please elaborate what you want to achieve with this discussion Richard ________________________________ Von: Richard Shockey [mailto:richard at shockey.us] Gesendet: Mo 07.03.2005 16:39 An: Stastny Richard; lconroy; enum at ietf.org Betreff: Re: AW: [Enum] Sufficient information in NAPTRs, MSG, and VOVI A >I do not want to discuss > >tel:voice >here Oh why not ? :-) what is clear is that we need 1. generic tel: registration and the issues raised by the vovi draft 2. yes we need something like a voice:tel 3 yes we need something like video:tel > >but if you want to define > > >tel:fax > >tel:sms > >tel:mms > >then plese submit a draft explaining the difference to > >fax:tel >sms:tel >mms:tel > Now that is exactly my point ..what IYHO is the difference between the semantics of the two. Operationally if someone sees tel:fax vs fax:tel should they reject the record... are the two functionally the same ...should they be functionally the same? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 This was sent from my blackberry so please forgive the terse nature of the response. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Wed, 09 Mar 2005 10:23:38 -0500 From: Richard Shockey Date: Wed, 09 Mar 2005 10:23:38 -0500 To: enum at ietf.org Subject: [Enum] If you have presentations for this afternoon please start to send them to me Message-ID: <6.2.1.2.2.20050309095926.0554f1d0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO That way I can have them on my laptop and organize them for the proceedings. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 paf@cisco.com Wed, 09 Mar 2005 13:59:35 -0500 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Wed, 09 Mar 2005 13:59:35 -0500 To: "Stastny Richard" Subject: Re: [Enum] Enumservices and draft-ietf-vpim-routing-08.txt In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FAE1@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Feb 3, 2005, at 09:51, Stastny Richard wrote: basically I agree with Kim that the templates in the draft need to be fixed, but we should wait for this until Patrik has clariefied this with IANA, it is only editorial. We (as the chairs) have resolved the issues with IANA regarding ENUMservices registration. IANA will now go through the website and update the text on the site. paf But the vpim draft raises new issues on enumservices regarding type:subtype Currently we have two facets of enumservices: Type A has only a type: e.g. h323, sip, pres indicating that the service is provided with one URI only (except sips) Type B provides services with (potentially) more then ony URI, and since some clients may be to stupid to evaluate the whole NATPRs including the regexp before evaluating which NAPTR to chose, the type contains also the URI as subtype: eg web:http, or fax:tel Now vpim introduces a Type C: voice:dir using URI scheme ldap: (note: I like the revival of enum type voice ;-) and also a Type B: vpim:mailto Is there any reason tot to name the first one instead of voice:dir -> vpim:ldap ? regards Richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Richard Shockey Gesendet: Do 03.02.2005 15:37 An: Fullbrook Kim (UK); enum at ietf.org Betreff: Re: [Enum] Enumservices and draft-ietf-vpim-routing-08.txt At 09:00 AM 2/3/2005, you wrote: The draft appears to have similar errors in terminology as with other enumservice registrations. Lawrence - is this something you'll include in your "cleanup" activities or should the point be raised directly with the author ? do it directly with the author on this particular draft ... Kim. -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Richard Shockey Sent: 02 February 2005 22:12 To: enum at ietf.org Subject: [Enum] Fwd: [vpim] I-D ACTION:draft-ietf-vpim-routing-08.txt worth reading ... >To: i-d-announce at ietf.org >From: Internet-Drafts at ietf.org >Date: Wed, 02 Feb 2005 15:37:29 -0500 >Cc: vpim at ietf.org >Subject: [vpim] I-D ACTION:draft-ietf-vpim-routing-08.txt >X-BeenThere: vpim at ietf.org >X-Mailman-Version: 2.1.5 >List-Id: Voice Profile for Internet Mail Discussion Archive >List-Unsubscribe: < https://www1.ietf.org/mailman/listinfo/vpim >, > < mailto:vpim-request at ietf.org?subject=unsubscribe > >List-Post: >List-Help: < mailto:vpim-request at ietf.org?subject=help > >List-Subscribe: < https://www1.ietf.org/mailman/listinfo/vpim >, > < mailto:vpim-request at ietf.org?subject=subscribe > >Sender: vpim-bounces at ietf.org >X-Keywords: > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Voice Profile for Internet Mail Working >Group of the IETF. > > Title : Voice Message Routing Service > Author(s) &nbs p; : G. Vaudreuil > Filename : draft-ietf-vpim-routing-08.txt > Pages : 10 > Date : 2005-2-2 > >Voice messaging is traditionally addressed using telephone number >addressing. This document describes two techniques for routing voice >messages based on a telephone number. The VPIM Directory service >provides a directory mechanism to lookup a VPIM email address with a >telephone number and confirm that the address is both valid and the >associated with the intended recipient. However this service will >take time become widely deployed in the nearest term. This document >also describes a more limited send-and-pray service useful simply to >route and deliver messages using only the ENUM telephone number >resolution service and the existing DNS mail routing facilies. >Please send comments on this document to the VPIM working group >mailing list > >A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-08.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-ietf-vpim-routing-08.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-ietf-vpim-routing-08.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: <2005-2-2143537.I-D at ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-vpim-routing-08.txt > >< ftp://ftp.ietf.org/internet-drafts/draft-ietf-vpim-routing-08.txt > >_______________________________________________ >VPIM mailing list >VPIM at ietf.org > https://www1.ietf.org/mailman/listinfo/vpim ________________________________ ======================================================== 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 addres s above) immediately. ======================================================== _______________________________________________ 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 < mailto:richard(at)shockey.us > or < mailto:richard.shockey(at)neustar.biz > < http://www.neustar.biz > ; < http://www.enum.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 From Richard.Stastny@oefeg.at Thu, 10 Mar 2005 09:59:58 -0500 From: "Stastny Richard" Date: Thu, 10 Mar 2005 09:59:58 -0500 To: Subject: [Enum] tel loop detection and prevention Message-ID: <32755D354E6B65498C3BD9FD496C7D46FC11@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Dear all, in yesterday's ENUM wg in conjunction with the enumdi draft the issue of loop detection and prevention with Enumservices featuring a tel URI was raised. It was decided to put some text for clarification into the enumdi draft. Although I am still not 100% convinced that this is the perfect place to clarify the issue, I myself do currently not know of a better place, since tel URIs are dealt with in different places (msg, vovi). (maybe it should in addition also be mentioned in the experiences) So I propose to add a section 4.3 to the enumdi draft with the following text below:. I include also the existing text of section 4.2 to get the idea: existing text in section 4.2: 4.2 Adding the "enumdi" parameter to URIs When a VoIP network element accesses ENUM in e164.arpa for a given E.164 number and the result of the query is NXDOMAIN, and the network element chooses to pass the call to the next network element by using a "tel" URI, the "enumdi" parameter MUST be set. When a VoIP network element accesses ENUM in e164.arpa for a given E.164 number and either: o the result of the query includes a NAPTR RR containing a "tel" URI that has the same E.164 number, or o the result of the query includes a NAPTR RR containing a "tel" URI with the "enumdi" parameter set, then if that retrieved "tel" URI is chosen to be passed to the next network element, the sending VoIP network element MUST pass on the retrieved URI with the "enumdi" parameter set. New text to be added 4.3 Loop detection and prevention If the result of the query contains another tel: URI with a different E.164 number, the VoIP network element may either choose to pass the retrieved "tel:" URI to the next network element with the "enumdi" indicator set or the network element may choose to make another ENUM query with the "tel" URI retrieved, looking for the same Enumservice. To prevent endless loops, the network element MUST do only up to 5 such queries until the result is resolved as described in section 4.2. If this is not the case, or a number already queried should be queried again, the call should be dropped by the VoIP network element by signaling back service not available. End of new text regards Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 10 Mar 2005 14:45:33 -0500 From: "Stastny Richard" Date: Thu, 10 Mar 2005 14:45:33 -0500 To: "David R Oran" Subject: [Enum] Re: [Iptel] tel loop detection and prevention Message-ID: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO David, On the counter in enumdi: Basically the enumdi is used in signalling between VoIP network elements the loop need to be detected WITHIN a VoIP network element before the enumdi is set, so this counter does not help there In addition the counter issue was discussed last meeting and rejected. On the "magic" solution: Please propose text to be put into the draft and not home work for editors Or should we put the following text in the I-D: If you want to detect loops, go read Vol.1 of Knuth ? Richard ________________________________ Von: David R Oran [mailto:oran at cisco.com] Gesendet: Do 10.03.2005 20:32 An: Stastny Richard Cc: iptel at ietf.org; enum at ietf.org Betreff: Re: [Iptel] tel loop detection and prevention There are MUCH better ways to deal with the loop issue. See below. On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote: > Dear all, > New text to be added > 4.3 Loop detection and prevention > > If the result of the query contains another tel: URI with a > different > E.164 number, the VoIP network element may either choose to pass the > retrieved "tel:" URI to the next network element with the "enumdi" > indicator set or the network element may choose to make another ENUM > query with the "tel" URI retrieved, looking for the same > Enumservice. > > To prevent endless loops, the network element MUST do only up to 5 > such queries > until the result is resolved as described in section 4.2. This is unreasonable (or at least incredibly ugly). Magic numbers should be avoided like the plague. Not to mention that it does not solve the problem in the distributed case... Two suggestions: 1) make the enumdi a counter rather than a boolean. It would hold the translation count. Note that this is *not* the number of calls to some enum resolution service, but rather then number of translations that have been done. This will be the same if the caller is querying directly via a dns resolver, but may result in a count higher than 1 if there is some kind of recursive lookup client API on the system doing the enum translations. 2) Base the loop detect on the counter. A dumb client can just decide on a maximum value as part of its configuration. We could suggest a default value, but that is different from mandating a constant value as a magic number. However, this is actually not necessary - those interested read on. I mentioned privately to a few people that there is a really elegant way to detect loops of the sort introduced by cyclic database pointers in a distributed database (like DNS). I used in a distributed naming service I designed about 20 years ago, and it worked like a charm. It's based on an algorithm in Vol.1 of Knuth which everybody reads and then promptly forgets in their CS training. It's called "even-odd iteration counting" - go look it up. It has the following wonderful properties. a) works in constant memory (two string variables) b) never falsely detects a loop in a long translation chain c) detects all loops of degree 2 immediately d) detects all loops of degree 3 after one time around the loop e) detects a loop of arbitrary degree after traversing the loop no more than 3 times. Dave. > If this is not > the case, or a number already queried should be queried again, the > call > should be dropped by the VoIP network element by signaling back > service > not available. > > End of new text > > regards > Richard > > _______________________________________________ > Iptel mailing list > Iptel at ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran at cisco.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Thu, 10 Mar 2005 15:15:31 -0500 From: lconroy Date: Thu, 10 Mar 2005 15:15:31 -0500 To: "Stastny Richard" Subject: [Enum] Re: [Iptel] tel loop detection and prevention In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> Message-ID: <7ba08e54ace96acf95842a162f6b3b90@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Dave, Richard, Juha, folks, I'm also glad that someone else has finally commented on something that's been in the ENUM Experiences draft since 2003 - I'm very happy if we can improve that, as the "depth limit" of 5 is (and always has been) a kludge. ---- Re. the even-odd solution: I had thought that "even-odd" required distributed control - in the case of ENUM the nasty cases occur when the zones are under completely independent control and the NAPTRs they contain may not include this flag -at all-. I'd greatly appreciate a clarification one the use of this algorithm, as it is an *awful* long time since I looked at that fine book, and I obviously didn't understand it (or have miss-remembered it). ---- I'm afraid that I disagree with my learned co-author on the proposed text. (i) The broken behaviour is a proxy that does an ENUM look up when it receives a tel: URI but then stops and just passes the result onwards. It either handles a tel: URI or it doesn't. If it re-tried until it found a URI it liked, or detected a loop (NXDOMAIN is already covered), the problem wouldn't occur. (ii) This is an ENUM "Dip" Indicator flag. It indicates that the element has done an ENUM query on this telephone number, or otherwise KNOWS that there is no useful data associated with it in ENUM. Of course, the sending element may always lie. It may not have done an ENUM query at all on the number. It might choose to do this to force the receiving element to place a call to the PSTN or fail. However, that is not a compliant use of this flag - you can lie, but it's a lie. Thus, if we MUST allow broken proxies to push the problem onwards, then I believe that the 1st paragraph for 4.3 will have to be: ------------ If the result of the query contains another tel: URI with a different E.164 number, the VoIP network element MAY either choose to pass the original "tel:" URI to the next network element with the "enumdi" indicator set or the network element MAY choose to make another ENUM query with the "tel" URI retrieved, looking for the same Enumservice. ------------ i.e. the proxy MUST NOT pass on a request with the TEL: URI it has retrieved from ENUM with the enumdi flag set, as that would be a lie. Instead, the original TEL: URI is passed on, with the flag set. This is the number it HAS checked in ENUM. all the best, Lawrence On 10 Mar 2005, at 19:47, Stastny Richard wrote: David, On the counter in enumdi: Basically the enumdi is used in signalling between VoIP network elements the loop need to be detected WITHIN a VoIP network element before the enumdi is set, so this counter does not help there In addition the counter issue was discussed last meeting and rejected. On the "magic" solution: Please propose text to be put into the draft and not home work for editors Or should we put the following text in the I-D: If you want to detect loops, go read Vol.1 of Knuth ? Richard ________________________________ Von: David R Oran [mailto:oran at cisco.com] Gesendet: Do 10.03.2005 20:32 An: Stastny Richard Cc: iptel at ietf.org; enum at ietf.org Betreff: Re: [Iptel] tel loop detection and prevention There are MUCH better ways to deal with the loop issue. See below. On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote: Dear all, New text to be added 4.3 Loop detection and prevention If the result of the query contains another tel: URI with a different E.164 number, the VoIP network element may either choose to pass the retrieved "tel:" URI to the next network element with the "enumdi" indicator set or the network element may choose to make another ENUM query with the "tel" URI retrieved, looking for the same Enumservice. To prevent endless loops, the network element MUST do only up to 5 such queries until the result is resolved as described in section 4.2. This is unreasonable (or at least incredibly ugly). Magic numbers should be avoided like the plague. Not to mention that it does not solve the problem in the distributed case... Two suggestions: 1) make the enumdi a counter rather than a boolean. It would hold the translation count. Note that this is *not* the number of calls to some enum resolution service, but rather then number of translations that have been done. This will be the same if the caller is querying directly via a dns resolver, but may result in a count higher than 1 if there is some kind of recursive lookup client API on the system doing the enum translations. 2) Base the loop detect on the counter. A dumb client can just decide on a maximum value as part of its configuration. We could suggest a default value, but that is different from mandating a constant value as a magic number. However, this is actually not necessary - those interested read on. I mentioned privately to a few people that there is a really elegant way to detect loops of the sort introduced by cyclic database pointers in a distributed database (like DNS). I used in a distributed naming service I designed about 20 years ago, and it worked like a charm. It's based on an algorithm in Vol.1 of Knuth which everybody reads and then promptly forgets in their CS training. It's called "even-odd iteration counting" - go look it up. It has the following wonderful properties. a) works in constant memory (two string variables) b) never falsely detects a loop in a long translation chain c) detects all loops of degree 2 immediately d) detects all loops of degree 3 after one time around the loop e) detects a loop of arbitrary degree after traversing the loop no more than 3 times. Dave. If this is not the case, or a number already queried should be queried again, the call should be dropped by the VoIP network element by signaling back service not available. End of new text regards Richard _______________________________________________ Iptel mailing list Iptel at ietf.org https://www1.ietf.org/mailman/listinfo/iptel David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran at cisco.com _______________________________________________ Iptel mailing list Iptel at ietf.org https://www1.ietf.org/mailman/listinfo/iptel --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From oran@cisco.com Thu, 10 Mar 2005 15:45:15 -0500 From: David R Oran Date: Thu, 10 Mar 2005 15:45:15 -0500 To: "Stastny Richard" Subject: [Enum] Re: [Iptel] tel loop detection and prevention In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC11@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO There are MUCH better ways to deal with the loop issue. See below. On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote: Dear all, New text to be added 4.3 Loop detection and prevention If the result of the query contains another tel: URI with a different E.164 number, the VoIP network element may either choose to pass the retrieved "tel:" URI to the next network element with the "enumdi" indicator set or the network element may choose to make another ENUM query with the "tel" URI retrieved, looking for the same Enumservice. To prevent endless loops, the network element MUST do only up to 5 such queries until the result is resolved as described in section 4.2. This is unreasonable (or at least incredibly ugly). Magic numbers should be avoided like the plague. Not to mention that it does not solve the problem in the distributed case... Two suggestions: 1) make the enumdi a counter rather than a boolean. It would hold the translation count. Note that this is *not* the number of calls to some enum resolution service, but rather then number of translations that have been done. This will be the same if the caller is querying directly via a dns resolver, but may result in a count higher than 1 if there is some kind of recursive lookup client API on the system doing the enum translations. 2) Base the loop detect on the counter. A dumb client can just decide on a maximum value as part of its configuration. We could suggest a default value, but that is different from mandating a constant value as a magic number. However, this is actually not necessary - those interested read on. I mentioned privately to a few people that there is a really elegant way to detect loops of the sort introduced by cyclic database pointers in a distributed database (like DNS). I used in a distributed naming service I designed about 20 years ago, and it worked like a charm. It's based on an algorithm in Vol.1 of Knuth which everybody reads and then promptly forgets in their CS training. It's called "even-odd iteration counting" - go look it up. It has the following wonderful properties. a) works in constant memory (two string variables) b) never falsely detects a loop in a long translation chain c) detects all loops of degree 2 immediately d) detects all loops of degree 3 after one time around the loop e) detects a loop of arbitrary degree after traversing the loop no more than 3 times. Dave. If this is not the case, or a number already queried should be queried again, the call should be dropped by the VoIP network element by signaling back service not available. End of new text regards Richard _______________________________________________ Iptel mailing list Iptel at ietf.org https://www1.ietf.org/mailman/listinfo/iptel David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran at cisco.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From oran@cisco.com Thu, 10 Mar 2005 15:45:15 -0500 From: David R Oran Date: Thu, 10 Mar 2005 15:45:15 -0500 To: "Stastny Richard" Subject: [Enum] Re: [Iptel] tel loop detection and prevention In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> Message-ID: <06b95eb9c88be8cf68489e6aac616867@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Mar 10, 2005, at 2:47 PM, Stastny Richard wrote: David, On the counter in enumdi: Basically the enumdi is used in signalling between VoIP network elements the loop need to be detected WITHIN a VoIP network element before the enumdi is set, so this counter does not help there I disagree. If the translator does not traverse the entire cycle before stopping and forwarding the invite, you can still get loops. If you don't want to have a counter, the spec then has to say that a translator MUST continue doing translations until it either gets a non-TEL url or detects a loop and gives up. In addition the counter issue was discussed last meeting and rejected. I remember the discussion and recall that we did not consider the distributed case at that time. Now that Juha has brought up the need to support the distributed case, the distributed loop detect question needs to be revisited since now loops are not automagically suppressed by a boolean dip indicator. On the "magic" solution: Please propose text to be put into the draft and not home work for editors What I suggested is that the loop max be either a) configured on the proxy b) rendered unnecessary by implementing a loop-detect algorithm that does not require configuration of a maximum degree parameter. Or should we put the following text in the I-D: If you want to detect loops, go read Vol.1 of Knuth ? Sort of. Say you MUST detect loops. Say that there is no architecturally-mandated translation chain maximum. Say that if you can live with occasional false loop detections for the (hopefully uncommon) case of high-degree loops, you can implement a translation-max which you compare with the enumdi count, but that if you want to avoid false detections, you can implement something fancier, such as the scheme in Vol.1 or Knuth. Cheers, Dave. Richard ________________________________ Von: David R Oran [mailto:oran at cisco.com] Gesendet: Do 10.03.2005 20:32 An: Stastny Richard Cc: iptel at ietf.org; enum at ietf.org Betreff: Re: [Iptel] tel loop detection and prevention There are MUCH better ways to deal with the loop issue. See below. On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote: Dear all, New text to be added 4.3 Loop detection and prevention If the result of the query contains another tel: URI with a different E.164 number, the VoIP network element may either choose to pass the retrieved "tel:" URI to the next network element with the "enumdi" indicator set or the network element may choose to make another ENUM query with the "tel" URI retrieved, looking for the same Enumservice. To prevent endless loops, the network element MUST do only up to 5 such queries until the result is resolved as described in section 4.2. This is unreasonable (or at least incredibly ugly). Magic numbers should be avoided like the plague. Not to mention that it does not solve the problem in the distributed case... Two suggestions: 1) make the enumdi a counter rather than a boolean. It would hold the translation count. Note that this is *not* the number of calls to some enum resolution service, but rather then number of translations that have been done. This will be the same if the caller is querying directly via a dns resolver, but may result in a count higher than 1 if there is some kind of recursive lookup client API on the system doing the enum translations. 2) Base the loop detect on the counter. A dumb client can just decide on a maximum value as part of its configuration. We could suggest a default value, but that is different from mandating a constant value as a magic number. However, this is actually not necessary - those interested read on. I mentioned privately to a few people that there is a really elegant way to detect loops of the sort introduced by cyclic database pointers in a distributed database (like DNS). I used in a distributed naming service I designed about 20 years ago, and it worked like a charm. It's based on an algorithm in Vol.1 of Knuth which everybody reads and then promptly forgets in their CS training. It's called "even-odd iteration counting" - go look it up. It has the following wonderful properties. a) works in constant memory (two string variables) b) never falsely detects a loop in a long translation chain c) detects all loops of degree 2 immediately d) detects all loops of degree 3 after one time around the loop e) detects a loop of arbitrary degree after traversing the loop no more than 3 times. Dave. If this is not the case, or a number already queried should be queried again, the call should be dropped by the VoIP network element by signaling back service not available. End of new text regards Richard _______________________________________________ Iptel mailing list Iptel at ietf.org https://www1.ietf.org/mailman/listinfo/iptel David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran at cisco.com _______________________________________________ Iptel mailing list Iptel at ietf.org https://www1.ietf.org/mailman/listinfo/iptel David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran at cisco.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From oran@cisco.com Thu, 10 Mar 2005 15:55:59 -0500 From: David R Oran Date: Thu, 10 Mar 2005 15:55:59 -0500 To: lconroy Subject: [Enum] Re: [Iptel] tel loop detection and prevention In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Mar 10, 2005, at 3:15 PM, lconroy wrote: Hi Dave, Richard, Juha, folks, I'm also glad that someone else has finally commented on something that's been in the ENUM Experiences draft since 2003 - I'm very happy if we can improve that, as the "depth limit" of 5 is (and always has been) a kludge. ---- Re. the even-odd solution: I had thought that "even-odd" required distributed control - in the case It works better if you send the values of the two memory cells instead of the count (since the count has only tell you if you are in the even or odd part of the chain when you forward). Since you are in fact forwarding MAx-forwards will eventually suppress the chain. In the absence of max-forwards as a backup you would be right that a counter is insufficient state to encode into the forwarded message. of ENUM the nasty cases occur when the zones are under completely independent control and the NAPTRs they contain may not include this flag -at all-. Sure. I'd greatly appreciate a clarification one the use of this algorithm, as it is an *awful* long time since I looked at that fine book, and I obviously didn't understand it (or have miss-remembered it). Did the above help? ---- I'm afraid that I disagree with my learned co-author on the proposed text. (i) The broken behaviour is a proxy that does an ENUM look up when it receives a tel: URI but then stops and just passes the result onwards. It either handles a tel: URI or it doesn't. If it re-tried until it found a URI it liked, or detected a loop (NXDOMAIN is already covered), the problem wouldn't occur. Correct. This was the point I made in a message I sent a little while ago. (ii) This is an ENUM "Dip" Indicator flag. It indicates that the element has done an ENUM query on this telephone number, or otherwise KNOWS that there is no useful data associated with it in ENUM. Of course, the sending element may always lie. It may not have done an ENUM query at all on the number. It might choose to do this to force the receiving element to place a call to the PSTN or fail. However, that is not a compliant use of this flag - you can lie, but it's a lie. Thus, if we MUST allow broken proxies to push the problem onwards, then I believe that the 1st paragraph for 4.3 will have to be: ------------ If the result of the query contains another tel: URI with a different E.164 number, the VoIP network element MAY either choose to pass the original "tel:" URI to the next network element with the "enumdi" indicator set or the network element MAY choose to make another ENUM query with the "tel" URI retrieved, looking for the same Enumservice. ------------ i.e. the proxy MUST NOT pass on a request with the TEL: URI it has retrieved from ENUM with the enumdi flag set, as that would be a lie. Unless we change it to a count... Instead, the original TEL: URI is passed on, with the flag set. This is the number it HAS checked in ENUM. What does this mean, exactly? Your above says is means "the number in the uri was input to an enum query". I thought it was supposed to mean "the number in the uri was the RESULT of an enum query. I don't see what good this does Juha if it's the input, not the output. Or perhaps I misunderstood what Juha was asking for. Dave. all the best, Lawrence On 10 Mar 2005, at 19:47, Stastny Richard wrote: David, On the counter in enumdi: Basically the enumdi is used in signalling between VoIP network elements the loop need to be detected WITHIN a VoIP network element before the enumdi is set, so this counter does not help there In addition the counter issue was discussed last meeting and rejected. On the "magic" solution: Please propose text to be put into the draft and not home work for editors Or should we put the following text in the I-D: If you want to detect loops, go read Vol.1 of Knuth ? Richard ________________________________ Von: David R Oran [mailto:oran at cisco.com] Gesendet: Do 10.03.2005 20:32 An: Stastny Richard Cc: iptel at ietf.org; enum at ietf.org Betreff: Re: [Iptel] tel loop detection and prevention There are MUCH better ways to deal with the loop issue. See below. On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote: Dear all, New text to be added 4.3 Loop detection and prevention If the result of the query contains another tel: URI with a different E.164 number, the VoIP network element may either choose to pass the retrieved "tel:" URI to the next network element with the "enumdi" indicator set or the network element may choose to make another ENUM query with the "tel" URI retrieved, looking for the same Enumservice. To prevent endless loops, the network element MUST do only up to 5 such queries until the result is resolved as described in section 4.2. This is unreasonable (or at least incredibly ugly). Magic numbers should be avoided like the plague. Not to mention that it does not solve the problem in the distributed case... Two suggestions: 1) make the enumdi a counter rather than a boolean. It would hold the translation count. Note that this is *not* the number of calls to some enum resolution service, but rather then number of translations that have been done. This will be the same if the caller is querying directly via a dns resolver, but may result in a count higher than 1 if there is some kind of recursive lookup client API on the system doing the enum translations. 2) Base the loop detect on the counter. A dumb client can just decide on a maximum value as part of its configuration. We could suggest a default value, but that is different from mandating a constant value as a magic number. However, this is actually not necessary - those interested read on. I mentioned privately to a few people that there is a really elegant way to detect loops of the sort introduced by cyclic database pointers in a distributed database (like DNS). I used in a distributed naming service I designed about 20 years ago, and it worked like a charm. It's based on an algorithm in Vol.1 of Knuth which everybody reads and then promptly forgets in their CS training. It's called "even-odd iteration counting" - go look it up. It has the following wonderful properties. a) works in constant memory (two string variables) b) never falsely detects a loop in a long translation chain c) detects all loops of degree 2 immediately d) detects all loops of degree 3 after one time around the loop e) detects a loop of arbitrary degree after traversing the loop no more than 3 times. Dave. If this is not the case, or a number already queried should be queried again, the call should be dropped by the VoIP network element by signaling back service not available. End of new text regards Richard _______________________________________________ Iptel mailing list Iptel at ietf.org https://www1.ietf.org/mailman/listinfo/iptel David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran at cisco.com _______________________________________________ Iptel mailing list Iptel at ietf.org https://www1.ietf.org/mailman/listinfo/iptel --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ Iptel mailing list Iptel at ietf.org https://www1.ietf.org/mailman/listinfo/iptel David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran at cisco.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Thu, 10 Mar 2005 15:58:16 -0500 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 10 Mar 2005 15:58:16 -0500 To: David R Oran Subject: Re: [Enum] Re: [Iptel] tel loop detection and prevention In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Mar 10, 2005, at 14:24, David R Oran wrote: If you want to detect loops, go read Vol.1 of Knuth ? Sort of. Say you MUST detect loops. Say that there is no architecturally-mandated translation chain maximum. Say that if you can live with occasional false loop detections for the (hopefully uncommon) case of high-degree loops, you can implement a translation-max which you compare with the enumdi count, but that if you want to avoid false detections, you can implement something fancier, such as the scheme in Vol.1 or Knuth. Yes. We have to disconnect the existence of the protocol parameter enumdi (in the future) and the need for loop detection. Loop detection can possibly be done in many ways. I.e. a network element that receive some signalling and know how to do ENUM lookup can use the enumdi parameter for what it is, that enum lookup has been done. It doesn't say doing yet another enum lookup is forbidden. Loop detection is a MUST. I agree with this. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Thu, 10 Mar 2005 16:13:13 -0500 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 10 Mar 2005 16:13:13 -0500 To: David R Oran Subject: Re: [Enum] Re: [Iptel] tel loop detection and prevention In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC11@oefeg-s04.oefeg.loc> Message-ID: <4efd525e1d7d640d62f7bbe35e597751@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Good suggestion. paf On Mar 10, 2005, at 13:32, David R Oran wrote: There are MUCH better ways to deal with the loop issue. See below. On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote: Dear all, New text to be added 4.3 Loop detection and prevention If the result of the query contains another tel: URI with a different E.164 number, the VoIP network element may either choose to pass the retrieved "tel:" URI to the next network element with the "enumdi" indicator set or the network element may choose to make another ENUM query with the "tel" URI retrieved, looking for the same Enumservice. To prevent endless loops, the network element MUST do only up to 5 such queries until the result is resolved as described in section 4.2. This is unreasonable (or at least incredibly ugly). Magic numbers should be avoided like the plague. Not to mention that it does not solve the problem in the distributed case... Two suggestions: 1) make the enumdi a counter rather than a boolean. It would hold the translation count. Note that this is *not* the number of calls to some enum resolution service, but rather then number of translations that have been done. This will be the same if the caller is querying directly via a dns resolver, but may result in a count higher than 1 if there is some kind of recursive lookup client API on the system doing the enum translations. 2) Base the loop detect on the counter. A dumb client can just decide on a maximum value as part of its configuration. We could suggest a default value, but that is different from mandating a constant value as a magic number. However, this is actually not necessary - those interested read on. I mentioned privately to a few people that there is a really elegant way to detect loops of the sort introduced by cyclic database pointers in a distributed database (like DNS). I used in a distributed naming service I designed about 20 years ago, and it worked like a charm. It's based on an algorithm in Vol.1 of Knuth which everybody reads and then promptly forgets in their CS training. It's called "even-odd iteration counting" - go look it up. It has the following wonderful properties. a) works in constant memory (two string variables) b) never falsely detects a loop in a long translation chain c) detects all loops of degree 2 immediately d) detects all loops of degree 3 after one time around the loop e) detects a loop of arbitrary degree after traversing the loop no more than 3 times. Dave. If this is not the case, or a number already queried should be queried again, the call should be dropped by the VoIP network element by signaling back service not available. End of new text regards Richard _______________________________________________ Iptel mailing list Iptel at ietf.org https://www1.ietf.org/mailman/listinfo/iptel David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran at cisco.com _______________________________________________ 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.Stastny@oefeg.at Thu, 10 Mar 2005 16:27:03 -0500 From: "Stastny Richard" Date: Thu, 10 Mar 2005 16:27:03 -0500 To: Patrik Fältström Subject: AW: [Enum] Re: [Iptel] tel loop detection and prevention Message-ID: <32755D354E6B65498C3BD9FD496C7D46FC1A@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Thank you Patrik for getting this dicusion back on track, I was getting lost already I agree with you that we have to sepate the issues again and there are three separate topics 1. the prorpose of the enumdi is basically to tell the NEXT network element that an ENUM query has been done on the E.164 number. period. It may do another ENUM query or not. A counter does not add anything here. 2. Loop detection is necessary, and each network elemnt has to do this on his own. the enumdi may just prevent the next network element to run into a loop again, but if it chosses ignore the enumdi, it is up to this network elemnt to detect a loop. I am fine with Davids text if this is agreed 3. the last issue also mixed in was the action the network element should take if it detects a loop. If have not heard a clear answer to this yet I see two options here: a. signal back service not available b. take the original tel URI (the one sent in in most cases by the client) and act the same way as decribed for NXDOMAIN or same number. option c to take the last number queried is not a good chioce, because this may depend on the loop detection algorithm. If this approach is agreed I will try tp formulate a new text proposal richard ________________________________ Von: Patrik Fältström [mailto:paf at cisco.com] Gesendet: Do 10.03.2005 21:57 An: David R Oran Cc: Stastny Richard; iptel at ietf.org; enum at ietf.org Betreff: Re: [Enum] Re: [Iptel] tel loop detection and prevention On Mar 10, 2005, at 14:24, David R Oran wrote: >> If you want to detect loops, go read Vol.1 of Knuth ? >> > Sort of. Say you MUST detect loops. Say that there is no > architecturally-mandated translation chain maximum. Say that if you > can live with occasional false loop detections for the (hopefully > uncommon) case of high-degree loops, you can implement a > translation-max which you compare with the enumdi count, but that if > you want to avoid false detections, you can implement something > fancier, such as the scheme in Vol.1 or Knuth. Yes. We have to disconnect the existence of the protocol parameter enumdi (in the future) and the need for loop detection. Loop detection can possibly be done in many ways. I.e. a network element that receive some signalling and know how to do ENUM lookup can use the enumdi parameter for what it is, that enum lookup has been done. It doesn't say doing yet another enum lookup is forbidden. Loop detection is a MUST. I agree with this. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Thu, 10 Mar 2005 16:46:19 -0500 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 10 Mar 2005 16:46:19 -0500 To: "Stastny Richard" Subject: Re: AW: [Enum] Re: [Iptel] tel loop detection and prevention In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC1A@oefeg-s04.oefeg.loc> Message-ID: <035f050cbc021b6b9df56b2057efce13@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Mar 10, 2005, at 15:29, Stastny Richard wrote: 3. the last issue also mixed in was the action the network element should take if it detects a loop. If have not heard a clear answer to this yet I see two options here: a. signal back service not available b. take the original tel URI (the one sent in in most cases by the client) and act the same way as decribed for NXDOMAIN or same number. Is this not a local policy that is highly dependent on context? I.e. that all of the above is possible. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ag@ag-projects.com Thu, 10 Mar 2005 16:47:05 -0500 From: Adrian Georgescu Date: Thu, 10 Mar 2005 16:47:05 -0500 To: "Stastny Richard" Subject: Re: AW: [Enum] Re: [Iptel] tel loop detection and prevention In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC1A@oefeg-s04.oefeg.loc> Message-ID: <0335a40d97378bb6f5d04c1edea3cfbb@ag-projects.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Mar 10, 2005, at 3:29 PM, Stastny Richard wrote: Thank you Patrik for getting this dicusion back on track, I was getting lost already I agree with you that we have to sepate the issues again and there are three separate topics 1. the prorpose of the enumdi is basically to tell the NEXT network element that an ENUM query has been done on the E.164 number. period. It may do another ENUM query or not. A counter does not add anything here. I think the same 2. Loop detection is necessary, and each network elemnt has to do this on his own. the enumdi may just prevent the next network element to run into a loop again, but if it chosses ignore the enumdi, it is up to this network elemnt to detect a loop. I like this approach. ENUM is not the only way we can enter an endless loop and counting the ENUM lookups is not the solution. There are aliases, conditional or unconditional redirections that may be combined with ENUM look-ups. Each routing element should detect a loop across multiple type of lookups, it is up to the application to do this. I am fine with Davids text if this is agreed 3. the last issue also mixed in was the action the network element should take if it detects a loop. If have not heard a clear answer to this yet I see two options here: a. signal back service not available This is good, we use a similar setup and we currently send Loop detected as release status back. Adrian b. take the original tel URI (the one sent in in most cases by the client) and act the same way as decribed for NXDOMAIN or same number. option c to take the last number queried is not a good chioce, because this may depend on the loop detection algorithm. If this approach is agreed I will try tp formulate a new text proposal richard ________________________________ Von: Patrik Fältström [mailto:paf at cisco.com] Gesendet: Do 10.03.2005 21:57 An: David R Oran Cc: Stastny Richard; iptel at ietf.org; enum at ietf.org Betreff: Re: [Enum] Re: [Iptel] tel loop detection and prevention On Mar 10, 2005, at 14:24, David R Oran wrote: If you want to detect loops, go read Vol.1 of Knuth ? Sort of. Say you MUST detect loops. Say that there is no architecturally-mandated translation chain maximum. Say that if you can live with occasional false loop detections for the (hopefully uncommon) case of high-degree loops, you can implement a translation-max which you compare with the enumdi count, but that if you want to avoid false detections, you can implement something fancier, such as the scheme in Vol.1 or Knuth. Yes. We have to disconnect the existence of the protocol parameter enumdi (in the future) and the need for loop detection. Loop detection can possibly be done in many ways. I.e. a network element that receive some signalling and know how to do ENUM lookup can use the enumdi parameter for what it is, that enum lookup has been done. It doesn't say doing yet another enum lookup is forbidden. Loop detection is a MUST. I agree with this. paf _______________________________________________ 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.Stastny@oefeg.at Thu, 10 Mar 2005 16:53:00 -0500 From: "Stastny Richard" Date: Thu, 10 Mar 2005 16:53:00 -0500 To: Patrik Fältström Subject: [Enum] Re: [Iptel] tel loop detection and prevention Message-ID: <32755D354E6B65498C3BD9FD496C7D46FC1E@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO >Is this not a local policy that is highly dependent on context? >I.e. that all of the above is possible. Agree, we may also offer the two options to choose from Richard ________________________________ Von: Patrik Fältström [mailto:paf at cisco.com] Gesendet: Do 10.03.2005 22:39 An: Stastny Richard Cc: David R Oran; iptel at ietf.org; enum at ietf.org Betreff: Re: AW: [Enum] Re: [Iptel] tel loop detection and prevention On Mar 10, 2005, at 15:29, Stastny Richard wrote: > 3. the last issue also mixed in was the action the network element > should take > if it detects a loop. If have not heard a clear answer to this yet > I see two options here: > a. signal back service not available > b. take the original tel URI (the one sent in in most cases by the > client) and act the same way as decribed for NXDOMAIN or same number. Is this not a local policy that is highly dependent on context? I.e. that all of the above is possible. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Thu, 10 Mar 2005 17:11:15 -0500 From: lconroy Date: Thu, 10 Mar 2005 17:11:15 -0500 To: Adrian Georgescu Subject: Re: AW: [Enum] Re: [Iptel] tel loop detection and prevention In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC1A@oefeg-s04.oefeg.loc> Message-ID: <55d4f12d9815ac51961c50e3fbcc80cd@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Everyone, this is slightly tangled. There are two cases: (i) The application that requests the ENUM lookup(s) has to do loop detection if if chooses to re-query ENUM based on the content of an initial ENUM query. This was Juha's original issue. (ii) The ENUM client itself has to deal with a potential loop, when processing non-final NAPTRs. It's this second case that's covered in the ENUM Experiences draft already - we recommended a Max-Queries value as a vary basic "loop quencher" for THIS case. It's ugly, but it does work, and I defy anyone to produce a provisioning system that handles a greater depth of ENUM domains and remain sane, so false positives are unlikely and/or a sign of serious strangeness on the part of the ENUM zones being searched. ---- The first case (Application using ENUM) is a separate issue - the ENUM client can't really help, as it doesn't retain state beyond the end of each final look up. I think that we're converging on an agreement that each individual element MUST deal with this kind of loop detection on its own. How it does loop detection is a local issue and is out of scope of the ENUMDI draft. ";enumdi" only states that an ENUM query has been done *on this number* (i.e. the number is the input to an ENUM query). No - it doesn't help a distributed set of elements from breaking the loop - but this is not its job. Each element must do this detection. It can be done, and is being done, but if an element doesn't deal with this problem, it's broken. is this all correct? all the best, Lawrence ------------------------------------------------------------------------ --------- On 10 Mar 2005, at 21:45, Adrian Georgescu wrote: On Mar 10, 2005, at 3:29 PM, Stastny Richard wrote: Thank you Patrik for getting this dicusion back on track, I was getting lost already I agree with you that we have to sepate the issues again and there are three separate topics 1. the prorpose of the enumdi is basically to tell the NEXT network element that an ENUM query has been done on the E.164 number. period. It may do another ENUM query or not. A counter does not add anything here. I think the same 2. Loop detection is necessary, and each network elemnt has to do this on his own. the enumdi may just prevent the next network element to run into a loop again, but if it chosses ignore the enumdi, it is up to this network elemnt to detect a loop. I like this approach. ENUM is not the only way we can enter an endless loop and counting the ENUM lookups is not the solution. There are aliases, conditional or unconditional redirections that may be combined with ENUM look-ups. Each routing element should detect a loop across multiple type of lookups, it is up to the application to do this. I am fine with Davids text if this is agreed 3. the last issue also mixed in was the action the network element should take if it detects a loop. If have not heard a clear answer to this yet I see two options here: a. signal back service not available This is good, we use a similar setup and we currently send Loop detected as release status back. Adrian b. take the original tel URI (the one sent in in most cases by the client) and act the same way as decribed for NXDOMAIN or same number. option c to take the last number queried is not a good chioce, because this may depend on the loop detection algorithm. If this approach is agreed I will try tp formulate a new text proposal richard ________________________________ Von: Patrik Fältström [mailto:paf at cisco.com] Gesendet: Do 10.03.2005 21:57 An: David R Oran Cc: Stastny Richard; iptel at ietf.org; enum at ietf.org Betreff: Re: [Enum] Re: [Iptel] tel loop detection and prevention On Mar 10, 2005, at 14:24, David R Oran wrote: If you want to detect loops, go read Vol.1 of Knuth ? Sort of. Say you MUST detect loops. Say that there is no architecturally-mandated translation chain maximum. Say that if you can live with occasional false loop detections for the (hopefully uncommon) case of high-degree loops, you can implement a translation-max which you compare with the enumdi count, but that if you want to avoid false detections, you can implement something fancier, such as the scheme in Vol.1 or Knuth. Yes. We have to disconnect the existence of the protocol parameter enumdi (in the future) and the need for loop detection. Loop detection can possibly be done in many ways. I.e. a network element that receive some signalling and know how to do ENUM lookup can use the enumdi parameter for what it is, that enum lookup has been done. It doesn't say doing yet another enum lookup is forbidden. Loop detection is a MUST. I agree with this. paf _______________________________________________ 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 --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 10 Mar 2005 17:25:51 -0500 From: "Stastny Richard" Date: Thu, 10 Mar 2005 17:25:51 -0500 To: "lconroy" Subject: [Enum] Loop detection and prevention - 2nd try Message-ID: <32755D354E6B65498C3BD9FD496C7D46FC1F@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Folks, here the 2nd text proposal: 4.2 Adding the "enumdi" parameter to URIs When a VoIP network element accesses ENUM in e164.arpa for a given E.164 number and the result of the query is NXDOMAIN, and the network element chooses to pass the call to the next network element by using a "tel" URI, the "enumdi" parameter MUST be set. When a VoIP network element accesses ENUM in e164.arpa for a given E.164 number and either: o the result of the query includes a NAPTR RR containing a "tel" URI that has the same E.164 number, or o the result of the query includes a NAPTR RR containing a "tel" URI with the "enumdi" parameter set, then if that retrieved "tel" URI is chosen to be passed to the next network element, the sending VoIP network element MUST pass on the retrieved URI with the "enumdi" parameter set. 4.3 Loop detection and prevention If the result of the query contains another tel: URI with a different E.164 number, and the network element chooses to make another ENUM query with the "tel" URI retrieved in the previous query, an endless loop may occur. The VoIP network element MUST be able to detect such loops. The implementation of a proper algorithm is left to the VoIP network element. This could be a simple algorithm such as upper limit of the number queries or sophisticated ones as described e.g. in [KNUTH]. If a loop is detected, the VoIP network element may either drop the call and signal back to the previous network element with the proper signaling available (e.g. loop detected or service not available) or it may take the original received tel URI and act in the same way as described above if the result of the query is NXDOMAIN. [KNUTHl Algoritmos Fundamentales - Vol. I by D. E. Knuth (out of print) _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jh@tutpro.com Fri, 11 Mar 2005 01:33:52 -0500 From: Juha Heinanen Date: Fri, 11 Mar 2005 01:33:52 -0500 To: David R Oran Subject: [Enum] Re: [Iptel] tel loop detection and prevention In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> Message-ID: <16945.11890.335078.531252@harjus.tutpro.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO David R Oran writes: > I don't see what good this does Juha if it's the input, not the > output. Or perhaps I misunderstood what Juha was asking for. no you didn't misunderstood me. i have written an enum module for a high-performance open source sip proxy and don't want that proxy to be subject to enum dos attacks that would force the proxy to make several enum queries (and analyze the result) for each sip request. i would therefore like to be able to mark that a tel uri was a result of an enum query and if i see that kind of tel uri, i would not do another enum query on it. so i very much like your count idea. -- juha _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jaap@NLnetLabs.nl Fri, 11 Mar 2005 02:10:14 -0500 From: Jaap Akkerhuis Date: Fri, 11 Mar 2005 02:10:14 -0500 To: Juha Heinanen Subject: Re: [Enum] Re: [Iptel] tel loop detection and prevention In-Reply-To: <16945.11890.335078.531252@harjus.tutpro.com> Message-ID: <200503110709.j2B79oi2067804@bartok.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain Status: RO David R Oran writes: and juha writes: [Messages deleted]. There are a stream of messages which needed to be approved by hand. Probably due to the cross posting with iptel at ietf.org. Note that these messages are easely missed due to the enormous amount of spam to filter and/or will might be delayed because the enum maillist admins have day job beside filtering spam from the enum list. So please, subscribe to the enum list or don't cross post. Thanks in advance, jaap _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 11 Mar 2005 10:40:12 -0500 From: "Michael Hammer \(mhammer\)" Date: Fri, 11 Mar 2005 10:40:12 -0500 To: "Patrik Faltstrom \(pfaltstr\)" Subject: RE: [Enum] Re: [Iptel] tel loop detection and prevention Message-ID: <072C5B76F7CEAB488172C6F64B30B5E304DA01@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Patrik, I think we all agree that ENUM is extremely important to routing and that loops in dereferencing ENUM dips is a very bad thing. Thus we need to get this right the first time. What I haven't seen in this discussion anywhere is the notion of *Time Scale*, that is WHEN should the resolution of the dereferencing be done. Also, the primary purpose of ENUM was to enable an IP-based terminal to be reached using an E.164 telephone number. So, if a trade-off requires something to suffer, it should be translations in the opposite direction. Correct me if I am wrong, but ENUM registrations are on the order of hours or days and not likely to change often; while ENUM dips are on the order of milliseconds. Also, doing many ENUM dips also becomes a "post-dial delay" issue. That tells me that loop detection and correction should occur during the registration process, *NOT* during ENUM dips during session setup. This leads me to a simple rule: ENUM NAPTR records should be validated to ensure that an ENUM dip against any included tel:URI results in a negative hit. The consequence of this is that an ENUM client can safely be assured that it need only do a single dip against a tel:URI. Of course, such a PSTN-based E.164 could later be migrated to an IP terminal and an ENUM record created. Registrars could periodically, during off-hours, test records that have tel:URI entries by doing a second dip. If a hit occurs, it would be a violation and 3 actions could be taken: 1) remove the tel:URI from the record, 2) replace the tel:URI with the results of the second ENUM dip (optional), 3) notify the first record holder of the problem and fix made. (That person may have an alternate registration solution.) Such checking is not a big deal during registration, but is during session setup. I found the idea that a node would do a single dip, then pass the message on to a second node that then will do a dip because the tel:URI would not have the ENUMDI set to be a recipe for looping via distributing the ENUM lookup process. To avoid this, I would suggest that a second ENUMPDI (ENUM Parent Dip Indicator) be created. The intent is to tell subsequent session processing nodes that this tel:URI resulted from an ENUM dip and should therefore be located in the PSTN. If the second node chooses to do an ENUM dip on a tel:URI with ENUMPDI, then it should also assume responsibility for reporting the presence of this registration error to the ENUM police, and likely should also fail the call until the registry is corrected. (This may fall to PSTN GWs to protect themselves as potential bottlenecks between the PSTN and IP domains.) That might also suggest an additional error or warning code for SIP, but so be it. Better to get the routing databases cleaned up immediately than sit there looping ENUM dips or calls. Mike >-----Original Message----- >From: iptel-bounces at ietf.org [mailto:iptel-bounces at ietf.org] >On Behalf Of Patrik Faltstrom (pfaltstr) >Sent: Thursday, March 10, 2005 3:57 PM >To: Dave Oran (oran) >Cc: iptel at ietf.org; enum at ietf.org; Stastny Richard >Subject: Re: [Enum] Re: [Iptel] tel loop detection and prevention > > >On Mar 10, 2005, at 14:24, David R Oran wrote: > >>> If you want to detect loops, go read Vol.1 of Knuth ? >>> >> Sort of. Say you MUST detect loops. Say that there is no >> architecturally-mandated translation chain maximum. Say that if you >> can live with occasional false loop detections for the (hopefully >> uncommon) case of high-degree loops, you can implement a >> translation-max which you compare with the enumdi count, but that if >> you want to avoid false detections, you can implement something >> fancier, such as the scheme in Vol.1 or Knuth. > >Yes. > >We have to disconnect the existence of the protocol parameter >enumdi (in the future) and the need for loop detection. Loop >detection can possibly be done in many ways. > >I.e. a network element that receive some signalling and know >how to do ENUM lookup can use the enumdi parameter for what it >is, that enum lookup has been done. It doesn't say doing yet >another enum lookup is forbidden. > >Loop detection is a MUST. I agree with this. > > paf > >_______________________________________________ >Iptel mailing list >Iptel at ietf.org >https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From chair@ietf.org Mon, 14 Mar 2005 05:19:16 -0500 From: "Herschel Adkins" Date: Mon, 14 Mar 2005 05:19:16 -0500 To: chair at ietf.org Subject: [Enum] Don't get ripped off by your pharmacy! chamberlain Message-ID: <2F8EAB15.40795@ujug.org> MIME-Version: 1.0 Content-Type: text/plain Status: RO adore discriminant New week end viagra... Cialis..... lasts upto 48 hours Upto 80% off!!! buy from us now today http://ctwq.realeasymeds.com/a/209078/dvlesow/ that there is more to loving that gifts. (Cowie 37) Hearst gave lavish parties and demonstrations to try to win people over totaled one million dollars for the year, a staggering sum to have been "What I tell them to think!" (Citizen Kane) Everything about Hearst's Felipe Finch sponge bout idle _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Tue, 15 Mar 2005 15:15:39 -0500 From: Richard Shockey Date: Tue, 15 Mar 2005 15:15:39 -0500 To: enum at ietf.org Subject: [Enum] Draft Minutes from IETF 62 MN Message-ID: <6.2.1.2.2.20050315143942.054a0e70@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Thank You Spencer !!! Please note any changes or clarifications. ********* Telephone Number Mapping WG (enum) IETF 62 Minneapolis, MN Wednesday, March 9 at 1300-1500 =============================== CHAIRS: Patrik Faltstrom               Richard Shockey Transport Area Advisor: Allison Mankin  Mailing Lists: General Discussion:enum at ietf.org To Subscribe: enum-request at ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ SCRIBE : Spencer Dawkins AGENDA: Report from APEET SIP/ENUM trial at Apricot 2005 at Kyoto. Informational item - Yoshiro Yoneya Goal of APEET is to conduct joint trials and promote ENUM and related technologies, including SIP Trial goal was to provide ENUM/SIP experience for every Apricot attendee Not providing telephony service - no warranties! Provided 802.11 handsets and id/passwords for ENUM directory Participants communicated with other attendees, overseas, registered ENUM information/opt-in phone book About 100 participants registered in phonebook, about 30 with more than two URIs Registration prototype now available as free software Supported three common SIP phone types 888-205-xxxx calls, overseas calls made with ENUM lookup About 7800 200-OKs, 300 other responses SIP really can use ENUM for call routing Authentication mechanism from SIP server to MGW is different for each gateway - requires testing Handover between access points is still difficult RTP within same AP still difficult Planning to offer same service at IETF 64 (500-2000 handsets) in Vancouver Was this trial only on ENUM operation or on delegation, etc? Mostly providing experience for participants WG business. 1. Discussion of the ENUM dip indicator on behalf of the IPTEL WG. Left out an author in 00 draft - will add in 01 after blackout period Enumdi syntax has not changed Replaced MUST NOT retrieve with SHOULD NOT retrieve Updated examples as example.com domain names Recommending IPTEL WGLC on this document 2. Status from Patrik on what is happening with the IANA and enumservice registrations. Issues resolved on Monday of this week - everything has been sorted out with IANA Are VPIM registrations consistent with what we want? Yes, with no additional changes identified on the mailing list - they have been approved by IESG and are good to go now Enum+? This will be updated in RFCs 2b. There seems to be a sense that we need to at least discuss some of the structure issues in enumservice registrations in general terms ..this seems to be a warm issue recently with various requirements coming out of 3GPP etc . In particular we do not have a TEL URL enum registration document as of yet and someone needs to take on that task. VOPI registration draft? Make this a working group item, as informational document? Still need a standards-track TEL URL document - we'll clarify all this on the list 3. Issues related to  IRIS for ENUM  -- We have had no in-depth discussion of this draft on the list and we'd like to see more.    http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-00.txt Who has read it? Not a lot of people in the room Opinions or concerns about this document? ENUM administrations are looking at this document as a potential requirement This is a wonderful document ... Minimal changes since last revision, fourth version as WG document 4. New Item Enumservice registrations for Conferencing  Alan Johnston  20M    A URL for this Internet-Draft is:    http://www.ietf.org/internet-drafts/draft-johnston-enum-conf-service-00.txt conf-web and conf-uri registrations conf-web is discovery mechanism for web conferences - URI is a source of information about the conference either HTTP or HTTPS Value over RFC 4002 web? Don't know a web URI is about a conference Will a single phone number route to a single person or to a conference? Why would a UA ever do this lookup? My phone number might have a web page associated with it, but most callers won't bring up the web page unless they know it's part of the conference Madness lies this way - there's no end to what we might treat as a special case If both web and conf-web are present, they probably point to the same URI Problem we're solving is telling a caller "this is a conference" - even if it doesn't exist on the IP network at all? Is this even an ENUM problem? Do see difference between web and conf-web - should they refer to different phone numbers? Not finding a resource, but providing information about the resource - this isn't how we want to use ENUM service tags If the service provider needs to provide multiple URIs, multiple ENUM tags make sense Is this a phone number that identifies a conference, or a conference server? If it's a conference server, that's ludicrous, if it's a conference, it makes more sense Would a user go to a single web server to enter a PIN number? What about different PINs for different components of the conference? We're moving along discovering how much information we want to publish for ENUM services, and there are lots of potential kinds of things to publish - "the client might want to know" doesn't let us draw the line anywhere SIP has a negotiation capability so we don't need this in SIP - this is more about the kind of thing you'll find if you call the resource - picture of a dog on the web page? conversations about communism? What does a client do differently when they see this tag? Is interpretation based on human intelligence, or does it accommodate automatons? Automatons would require a lot more structure than we're talking about here. Isn't this the same as isfocus in SIP? If we needed that, we need this We should be keying off a specific kind of XML document, not off an enumservice tag Conf-uri is actually the controversial part of the proposal... Says that the resource is a focus How many telephone numbers are true conference URIs with no passcode or PIN needed? Is it OK to have both a sip and a conf-uri URI? Not hearing clear consensus on what to do with this document, or what to do with conferences in enumservice registrations (is it needed or is this part of normal SIP negotiation?) Concern is that devices who don't understand this tag won't be able to connect to a conference - need to include sip if you include conf or conf-uri What's wrong with just saying "isfocus" in the SIP URI returned from the lookup? Is it necessary to know that it's a conference before you start negotiationg? Is there anything you'd differently before you contact the URI? That's the critical question We're trying to create boundaries on what a service is, on an ad hoc basis, and that's not working well Alan to respin this document with more use cases to see if we can move forward We need to be a lot better at deciding what is a service than we are now... it can't be this painful every time someone proposes an enumservice! We also need to worry about URI schemes defined by people who didn't think about any of this 5. In private discussions with folks there seems to me a demonstrable need    to create a SOAP binding for EPP-164. I believe this is an extremely    important project and I'd like to see if there is A. sufficient interest    in the project and if there is sufficient interest B. find some folks    who would be willing to work on the draft.    http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-08.txt Mostly enterprise-level interest, and their toolkits are based on SOAP. Anything that helps with provisioning is good. 6. ENUM Validation update w/Bernie Hoeneisen Ensure that ENUM owner == E.164 owner at registration time Version 01 is adding requirements section, split into transport and content, handling renewal and transfer, adding acknowledgements and corrections/updates Should this be a working group item? as Informational item? Room hum is "yes" 7. Status of ENUM Operational Experiences draft? No new items in document - can we WGLC a new revision before Paris? Yes 8. WG next steps? Enumdi loops when we're trying to prevent loops? discussion on mailing list - if you get the same tel URI back, this is just loop detection with one bounce - can we just cover the general loop case with hop count > 1? What do you do when you get a loop back with or without enumdi? Use first one, last one ... GSMA or 3GPP may be requesting ENUM for GRX network - two NAPTR, one with SIP and one with e-mail for SMS messages. If there is an IMS enum service, should the enumservice be ims: or sip+ims:? This is another slippery slope - is this IMS release 5, IMS release 6, ... but it sounds really wrong. Do we need to take on a liaison on this? Slippery slope is about 80-percent incline. Doesn't matter if we have an official liaison or not - we need to know what to tell them, either way. ETSI has asked and we can give them our opinions. Why do you need to know that a user is within the IMS system? We have no idea. This is using the DNS as a replacement for negotiation. There's an IAB draft on DNS assumptions that's in last call - please look at this and comment! ENUM idea is that you look up one number and get back one URI - if you voice and IM from the same SIP URI, this has to come from one provider, right? Where do we multiplex- ENUM or SIP? How much SIP call routing do we put in DNS (suggested answer = none). If we don't want to do this, we need to make sure people can't try, or they'll try for sure. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 < mailto:richard(at)shockey.us> or < mailto:richard.shockey(at)neustar.biz> < http://www.neustar.biz> ; < http://www.enum.org> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 17 Mar 2005 03:58:18 -0500 From: "Stastny Richard" Date: Thu, 17 Mar 2005 03:58:18 -0500 To: "Richard Shockey" Subject: RE: [Enum] Fwd: Protocol Action: 'IFAX service of ENUM' to Proposed Standard Message-ID: <32755D354E6B65498C3BD9FD496C7D4601D8A5@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Just curious, is the mentioned draft still in the Editor Queue? Richard > -----Original Message----- > From: Richard Shockey [mailto:richard at shockey.us] > Sent: Monday, July 12, 2004 10:16 PM > To: enum at ietf.org > Subject: [Enum] Fwd: Protocol Action: 'IFAX service of ENUM' to Proposed > Standard > > > >X-test-idtracker: no > >From: The IESG > >To: IETF-Announce > >Date: Mon, 12 Jul 2004 14:24:56 -0400 > >X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on > > ietf-mx.ietf.org > >X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no > version=2.60 > >Cc: Internet Architecture Board , > > fax chair , fax chair > > , > > fax mailing list , RFC Editor > > > >Subject: Protocol Action: 'IFAX service of ENUM' to Proposed Standard > >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 > > > > > >The IESG has approved the following document: > > > >- 'IFAX service of ENUM ' > > as a Proposed Standard > > > >This document is the product of the Internet Fax Working Group. > > > >The IESG contact persons are Scott Hollenbeck and Ted Hardie. > > > >Technical Summary > > > >This document describes the functional specification and the > >definition of the ENUM NAPTR record for IFax service. IFax is > >"Facsimile using Internet Mail". For this use, the DNS returns > >the email address of the referenced IFax system. This mechanism > >allows email-based fax communication to use telephone numbers, > >rather than requiring that the sender already know the recipient > >email address. > > > >Working Group Summary > > > >This document was reviewed by both the FAX and ENUM working groups. > >The FAX working group reached consensus on the document, and review > >by the ENUM working group was requested. Comments provided by the > >ENUM working group were received and incorporated to produce the > >document. > > > >Protocol Quality > > > >Scott Hollenbeck has reviewed the specification for the IESG. > > > > > >_______________________________________________ > >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 > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From shollenbeck@verisign.com Thu, 17 Mar 2005 07:28:05 -0500 From: "Hollenbeck, Scott" Date: Thu, 17 Mar 2005 07:28:05 -0500 To: "Stastny Richard" Subject: RE: [Enum] Fwd: Protocol Action: 'IFAX service of ENUM' to Proposed Standard Message-ID: <046F43A8D79C794FA4733814869CDF0759A549@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO > is the mentioned draft still in the Editor Queue? > > Richard The status of all documents queued for RFC publication is visible to the public: http://www.rfc-editor.org/queue.html It's still there: 2004/07/12 draft-ietf-fax-faxservice-enum-03.txt REF draft-ietf-fax-ffpim-04.txt K. Toyoda, D. Crocker IFAX service of ENUM Bytes: 8085 Working Group: Internet Fax -Scott- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Claudio.Allocchio@garr.it Thu, 17 Mar 2005 07:56:26 -0500 From: Claudio Allocchio Date: Thu, 17 Mar 2005 07:56:26 -0500 To: "Hollenbeck, Scott" Subject: RE: [Enum] Fwd: Protocol Action: 'IFAX service of ENUM' to Proposed Standard In-Reply-To: <046F43A8D79C794FA4733814869CDF0759A549@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO It's still there: 2004/07/12 draft-ietf-fax-faxservice-enum-03.txt REF draft-ietf-fax-ffpim-04.txt K. Toyoda, D. Crocker IFAX service of ENUM Bytes: 8085 Working Group: Internet Fax yes, but the REF waiting list can be cleared now (REF should point to -08): 2005/01/10 draft-ietf-fax-ffpim-08.txt EDIT REF draft-ietf-fax-esmtp-conneg-09.txt D. Crocker, G. Klyne Full-mode Fax Profile for Internet Mail (FFPIM) Bytes: 17989 Working Group: Internet Fax (again, REF should point to -13 now), and: 2005/01/27 draft-ietf-fax-esmtp-conneg-13.txt EDIT K. Toyoda, D. Crocker SMTP and MIME Extensions For Content Conversion Bytes: 53380 Working Group: Internet Fax which closes the loop. I do not think we need any specific action with the RFC-editor, do we? -Scott- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio at garr.it Project Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From matthew.stafford@cingular.com Thu, 17 Mar 2005 17:11:44 -0500 From: "Stafford, Matthew" Date: Thu, 17 Mar 2005 17:11:44 -0500 To: enum at ietf.org Subject: [Enum] IANA registration status Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: IANA registration status Status: RO I've been following draft-ietf-enum-msg-xx.txt but am confused about its current status. I am keen for E2U+mms:mailto to pass muster; I think that will be a good thing for intercarrier MMS. I saw that the document made it to the RFC Editor's queue (in its -02 incarnation). After the -03 version was posted, I saw the message exchange asking what was wrong with it, followed shortly by the appearance of the -04 version. Also saw the message chain about inconsistent usage of the term "ENUMservice" and plans to clean that up. Is the newest version good to go, so to speak? What happens next? Does it go back to the RFC Editor's queue before reappearing as an RFC? Thanks, Matt Stafford ----------------------------------- Matthew Stafford Principal Member of Technical Staff Cingular Wireless, Inc. 9505 Arboretum Blvd Austin TX 78759 matthew.stafford at cingular.com Voice : (512)372-5623 Fax : (512)372-5891 ----------------------------------- This email and any files transmitted with it are property of Cingular Wireless, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 512/372-5623 and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this email is strictly prohibited. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 17 Mar 2005 17:26:04 -0500 From: Richard Shockey Date: Thu, 17 Mar 2005 17:26:04 -0500 To: "Stafford, Matthew" Message-ID: <6.2.1.2.2.20050317172152.04cfa7d0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 05:11 PM 3/17/2005, Stafford, Matthew wrote: I've been following draft-ietf-enum-msg-xx.txt but am confused about its current status. I am keen for E2U+mms:mailto to pass muster; I think that will be a good thing for intercarrier MMS. I saw that the document made it to the RFC Editor's queue (in its -02 incarnation). After the -03 version was posted, I saw the message exchange asking what was wrong with it, followed shortly by the appearance of the -04 version. Also saw the message chain about inconsistent usage of the term "ENUMservice" and plans to clean that up. Is the newest version good to go, so to speak? What happens next? Does it go back to the RFC Editor's queue before reappearing as an RFC? Thanks for your note ... we believe we have resolved all the relevant issues brought up by the IESG in the 04 version and yes it goes back into the RFC Editors Queue before appearing as an RFC. BTW we are very interested in any possible developments that might require enumservice registrations for IMS related services.  Are you aware of any requirements for this? Thanks, Matt Stafford ----------------------------------- Matthew Stafford Principal Member of Technical Staff Cingular Wireless, Inc. 9505 Arboretum Blvd Austin TX 78759 matthew.stafford at cingular.com Voice : (512)372-5623 Fax : (512)372-5891 ----------------------------------- This email and any files transmitted with it are property of Cingular Wireless, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 512/372-5623 and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this email is strictly prohibited. _______________________________________________ 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 < mailto:richard(at)shockey.us> or < mailto:richard.shockey(at)neustar.biz> < http://www.neustar.biz> ; < http://www.enum.org> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@O2.COM Fri, 18 Mar 2005 05:18:58 -0500 From: "Fullbrook Kim (UK)" Date: Fri, 18 Mar 2005 05:18:58 -0500 To: "'Richard Shockey'" Subject: RE: [Enum] IANA registration status Message-ID: <0CD3FFEAEC982F489F872AB8DA32D624B3AE92@Uksthmsx012> MIME-Version: 1.0 Content-Type: text/plain Title: Message Status: RO >> BTW we are very interested in any possible developments that might require >> enumservice registrations for IMS related services. Are you aware of any >> requirements for this?   At the present time we are working with other potential IMS operators to gain consensus on whether or not we need an “IMS” enumservice.   Kim Fullbrook O2 UK Chair, ENUM Group, GSM Association    ========================================================This electronic message contains information from O2which 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 paf@cisco.com Sat, 19 Mar 2005 16:27:04 -0500 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Sat, 19 Mar 2005 16:27:04 -0500 To: "Stastny Richard" Subject: Re: [Enum] Fwd: Protocol Action: 'IFAX service of ENUM' to Proposed Standard In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4601D8A5@oefeg-s04.oefeg.loc> Message-ID: <922da61db6cf4e9ec7fc8bd498952dbe@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Mar 17, 2005, at 10:00, Stastny Richard wrote: Just curious, is the mentioned draft still in the Editor Queue? Yes. Waiting for draft-ietf-fax-ffpim-08.txt that in turn is waiting for draft-ietf-fax-esmtp-conneg-13.txt. But, the last one of this chain of dependencies has been in the queue now for a while. At least it is in EDIT mode which imply the RFC Editor is working on that particular document. See http://www.rfc-editor.org/queue.html paf Richard -----Original Message----- From: Richard Shockey [mailto:richard at shockey.us] Sent: Monday, July 12, 2004 10:16 PM To: enum at ietf.org Subject: [Enum] Fwd: Protocol Action: 'IFAX service of ENUM' to Proposed Standard X-test-idtracker: no From: The IESG To: IETF-Announce Date: Mon, 12 Jul 2004 14:24:56 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Cc: Internet Architecture Board , fax chair , fax chair , fax mailing list , RFC Editor Subject: Protocol Action: 'IFAX service of ENUM' to Proposed Standard 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 The IESG has approved the following document: - 'IFAX service of ENUM ' as a Proposed Standard This document is the product of the Internet Fax Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. Technical Summary This document describes the functional specification and the definition of the ENUM NAPTR record for IFax service. IFax is "Facsimile using Internet Mail". For this use, the DNS returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers, rather than requiring that the sender already know the recipient email address. Working Group Summary This document was reviewed by both the FAX and ENUM working groups. The FAX working group reached consensus on the document, and review by the ENUM working group was requested. Comments provided by the ENUM working group were received and incorporated to produce the document. Protocol Quality Scott Hollenbeck has reviewed the specification for the IESG. _______________________________________________ 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 _______________________________________________ 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 paf@cisco.com Sat, 19 Mar 2005 16:29:08 -0500 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Sat, 19 Mar 2005 16:29:08 -0500 To: "Stafford, Matthew" Subject: Re: [Enum] IANA registration status In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Mar 17, 2005, at 23:11, Stafford, Matthew wrote: I am keen for E2U+mms:mailto to pass muster Note it is "mms:mailto" that is the enumservice, not "E2U+mms:mailto". See grammar in RFC 3761. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 24 Mar 2005 15:45:34 -0500 From: Richard Shockey Date: Thu, 24 Mar 2005 15:45:34 -0500 To: proceedings at ietf.org Subject: [Enum] FINAL Minutes from IETF 62 MN Message-ID: <6.2.1.2.2.20050324113710.053aae80@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Telephone Number Mapping WG (enum) IETF 62 Minneapolis, MN Wednesday, March 9 at 1300-1500 =============================== CHAIRS: Patrik Faltstrom               Richard Shockey Transport Area Advisor: Allison Mankin  Mailing Lists: General Discussion:enum at ietf.org To Subscribe: enum-request at ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ SCRIBE : Spencer Dawkins AGENDA: Report from APEET SIP/ENUM trial at Apricot 2005 at Kyoto. Informational item - Yoshiro Yoneya Goal of APEET is to conduct joint trials and promote ENUM and related technologies, including SIP Trial goal was to provide ENUM/SIP experience for every Apricot attendee Not providing telephony service - no warranties! Provided 802.11 handsets and id/passwords for ENUM directory Participants communicated with other attendees, overseas, registered ENUM information/opt-in phone book About 100 participants registered in phonebook, about 30 with more than two URIs Registration prototype now available as free software Supported three common SIP phone types 888-205-xxxx calls, overseas calls made with ENUM lookup About 7800 200-OKs, 300 other responses SIP really can use ENUM for call routing Authentication mechanism from SIP server to MGW is different for each gateway - requires testing Handover between access points is still difficult RTP within same AP still difficult Planning to offer same service at IETF 64 (500-2000 handsets) in Vancouver Was this trial only on ENUM operation or on delegation, etc? Mostly providing experience for participants WG business. 1. Discussion of the ENUM dip indicator on behalf of the IPTEL WG. Left out an author in 00 draft - will add in 01 after blackout period Enumdi syntax has not changed Replaced MUST NOT retrieve with SHOULD NOT retrieve Updated examples as example.com domain names Recommending IPTEL WGLC on this document 2. Status from Patrik on what is happening with the IANA and enumservice registrations. Issues resolved on Monday of this week - everything has been sorted out with IANA Are VPIM registrations consistent with what we want? Yes, with no additional changes identified on the mailing list - they have been approved by IESG and are good to go now Enum+? This will be updated in RFCs 2b. There seems to be a sense that we need to at least discuss some of the structure issues in enumservice registrations in general terms ..this seems to be a warm issue recently with various requirements coming out of 3GPP etc . In particular we do not have a TEL URL enum registration document as of yet and someone needs to take on that task. VOPI registration draft? Make this a working group item, as informational document? Still need a standards-track TEL URL document - we'll clarify all this on the list 3. Issues related to  IRIS for ENUM  -- We have had no in-depth discussion of this draft on the list and we'd like to see more.    http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-00.txt Who has read it? Not a lot of people in the room Opinions or concerns about this document? ENUM administrations are looking at this document as a potential requirement This is a wonderful document ... Minimal changes since last revision, fourth version as WG document 4. New Item Enumservice registrations for Conferencing  Alan Johnston  20M    A URL for this Internet-Draft is:    http://www.ietf.org/internet-drafts/draft-johnston-enum-conf-service-00.txt conf-web and conf-uri registrations conf-web is discovery mechanism for web conferences - URI is a source of information about the conference either HTTP or HTTPS Value over RFC 4002 web? Don't know a web URI is about a conference Will a single phone number route to a single person or to a conference? Why would a UA ever do this lookup? My phone number might have a web page associated with it, but most callers won't bring up the web page unless they know it's part of the conference Madness lies this way - there's no end to what we might treat as a special case If both web and conf-web are present, they probably point to the same URI Problem we're solving is telling a caller "this is a conference" - even if it doesn't exist on the IP network at all? Is this even an ENUM problem? Do see difference between web and conf-web - should they refer to different phone numbers? Not finding a resource, but providing information about the resource - this isn't how we want to use ENUM service tags If the service provider needs to provide multiple URIs, multiple ENUM tags make sense Is this a phone number that identifies a conference, or a conference server? If it's a conference server, that's ludicrous, if it's a conference, it makes more sense Would a user go to a single web server to enter a PIN number? What about different PINs for different components of the conference? We're moving along discovering how much information we want to publish for ENUM services, and there are lots of potential kinds of things to publish - "the client might want to know" doesn't let us draw the line anywhere SIP has a negotiation capability so we don't need this in SIP - this is more about the kind of thing you'll find if you call the resource - picture of a dog on the web page? conversations about communism? What does a client do differently when they see this tag? Is interpretation based on human intelligence, or does it accommodate automatons? Automatons would require a lot more structure than we're talking about here. Isn't this the same as isfocus in SIP? If we needed that, we need this We should be keying off a specific kind of XML document, not off an enumservice tag Conf-uri is actually the controversial part of the proposal... Says that the resource is a focus How many telephone numbers are true conference URIs with no passcode or PIN needed? Is it OK to have both a sip and a conf-uri URI? Not hearing clear consensus on what to do with this document, or what to do with conferences in enumservice registrations (is it needed or is this part of normal SIP negotiation?) Concern is that devices who don't understand this tag won't be able to connect to a conference - need to include sip if you include conf or conf-uri What's wrong with just saying "isfocus" in the SIP URI returned from the lookup? Is it necessary to know that it's a conference before you start negotiating? Is there anything you'd differently before you contact the URI? That's the critical question We're trying to create boundaries on what a service is, on an ad hoc basis, and that's not working well Alan to respin this document with more use cases to see if we can move forward We need to be a lot better at deciding what is a service than we are now... it can't be this painful every time someone proposes an enumservice! We also need to worry about URI schemes defined by people who didn't think about any of this 5. In private discussions with folks there seems to me a demonstrable need    to create a SOAP binding for EPP-164. I believe this is an extremely    important project and I'd like to see if there is A. sufficient interest    in the project and if there is sufficient interest B. find some folks    who would be willing to work on the draft.    http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-08.txt Mostly enterprise-level interest, and their toolkits are based on SOAP. Anything that helps with provisioning is good. 6. ENUM Validation update w/Bernie Hoeneisen Ensure that ENUM owner == E.164 owner at registration time Version 01 is adding requirements section, split into transport and content, handling renewal and transfer, adding acknowledgements and corrections/updates Should this be a working group item? as Informational item? Room hum is "yes" 7. Status of ENUM Operational Experiences draft? No new items in document - can we WGLC a new revision before Paris? Yes 8. WG next steps? Enumdi loops when we're trying to prevent loops? discussion on mailing list - if you get the same tel URI back, this is just loop detection with one bounce - can we just cover the general loop case with hop count > 1? What do you do when you get a loop back with or without enumdi? Use first one, last one ... GSMA or 3GPP may be requesting ENUM for GRX network - two NAPTR, one with SIP and one with e-mail for SMS messages. If there is an IMS enum service, should the enumservice be ims: or sip+ims:? This is another slippery slope - is this IMS release 5, IMS release 6, ... but it sounds really wrong. Do we need to take on a liaison on this? Slippery slope is about 80-percent incline. Doesn't matter if we have an official liaison or not - we need to know what to tell them, either way. ETSI has asked and we can give them our opinions. Why do you need to know that a user is within the IMS system? We have no idea. This is using the DNS as a replacement for negotiation. There's an IAB draft on DNS assumptions that's in last call - please look at this and comment! ENUM idea is that you look up one number and get back one URI - if you voice and IM from the same SIP URI, this has to come from one provider, right? Where do we multiplex- ENUM or SIP? How much SIP call routing do we put in DNS (suggested answer = none). If we don't want to do this, we need to make sure people can't try, or they'll try for sure. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 < mailto:richard(at)shockey.us> or < mailto:richard.shockey(at)neustar.biz> < http://www.neustar.biz> ; < http://www.enum.org > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 < mailto:richard(at)shockey.us> or < mailto:richard.shockey(at)neustar.biz> < http://www.neustar.biz> ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum