From exim@www1.ietf.org Fri Apr 2 00:00:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09126 for ; Fri, 2 Apr 2004 00:00:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Dz0-0000lo-65 for iptel-archive@odin.ietf.org; Thu, 01 Apr 2004 21:00:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3220YGG002950 for iptel-archive@odin.ietf.org; Thu, 1 Apr 2004 21:00:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Bbt-0007Iv-6s for iptel-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 18:28:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09058 for ; Thu, 1 Apr 2004 18:28:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Bbq-0001sw-00 for iptel-web-archive@ietf.org; Thu, 01 Apr 2004 18:28:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Bax-0001nT-00 for iptel-web-archive@ietf.org; Thu, 01 Apr 2004 18:27:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Bac-0001hp-00 for iptel-web-archive@ietf.org; Thu, 01 Apr 2004 18:27:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99PV-0004bB-NU for iptel-web-archive@ietf.org; Thu, 01 Apr 2004 16:07:37 -0500 Date: Thu, 01 Apr 2004 11:19:03 -0500 Message-ID: <20040401161903.11029.91745.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: iptel-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,DATE_IN_PAST_03_06, NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, iptel-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for iptel-web-archive@ietf.org: List Password // URL ---- -------- iptel@ietf.org aroxgu https://www.ietf.org/mailman/options/iptel/iptel-web-archive%40ietf.org From exim@www1.ietf.org Fri Apr 2 17:24:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08668 for ; Fri, 2 Apr 2004 17:24:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X4p-0001Vn-Jr for iptel-archive@odin.ietf.org; Fri, 02 Apr 2004 17:23:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MNp4Q005812 for iptel-archive@odin.ietf.org; Fri, 2 Apr 2004 17:23:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X4n-0001U8-AS for iptel-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:23:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08395 for ; Fri, 2 Apr 2004 17:23:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X4l-0000Kp-00 for iptel-web-archive@ietf.org; Fri, 02 Apr 2004 17:23:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WzG-000778-00 for iptel-web-archive@ietf.org; Fri, 02 Apr 2004 17:18:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WxO-0006bI-00 for iptel-web-archive@ietf.org; Fri, 02 Apr 2004 17:16:10 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9Wrm-0000YW-Cv for iptel-web-archive@ietf.org; Fri, 02 Apr 2004 17:10:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WrW-0006Fb-2Y; Fri, 02 Apr 2004 17:10:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9W2b-00061S-1z for iptel@optimus.ietf.org; Fri, 02 Apr 2004 16:17:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00315 for ; Fri, 2 Apr 2004 16:17:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9W2Z-0002aE-00 for iptel@ietf.org; Fri, 02 Apr 2004 16:17:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9W0B-00022N-00 for iptel@ietf.org; Fri, 02 Apr 2004 16:15:00 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 1B9Vy1-0001Js-00 for iptel@ietf.org; Fri, 02 Apr 2004 16:12:45 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i32LC8NK020363; Fri, 2 Apr 2004 21:12:08 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Fri, 2 Apr 2004 16:12:08 -0500 Message-ID: <4F29BE4689992A4B994A440C3EC924DB012D5313@stntexch01.cis.neustar.com> From: "Yu, James" To: "'Flemming Andreasen'" Cc: list iptel MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Iptel] RE: Comments on draft-ietf-iptel-tel-np-00.txt Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 2 Apr 2004 16:12:07 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Flemming, Thanks for the comments. Please see the responses below on non-editorial comments. James -----Original Message----- --------------------------------------------------- Non-Editorial: - Mandatory or Optional tel-URI extension parameters. I believe that "npdi" can be an optional extension, whereas "rn" and "cic" must be mandatory extensions, since ignoring them may lead to incorrect routing of the call. I'm not sure I fully understand the 2826bis syntax requirements on this point (i.e., must a mandatory parameter be defined with the "m-" prefix or not ?), but regardless it seems we need to agree on whether the above parameters are optional or mandatory and put that in the document. [Yu] Based on rfc2806bis, a network node shall not process a tel URI with unknown mandatory parameters. In order not to cause the call be dropped when a network node does not know the defined parameters (e.g., "rn"), they are defined as the optional parameters. Because if a network node that does not know "cic" and "rn" can still route based on the phone number. When the call (or signaling) reaches a network node that knows the new parameters, correct action can be taken there. - Section 4.2.3: Should probably add a sentence noting that the parameter as defined here is not authenticated, and hence use of it by any recipient for anything related to charging is done at their own risk. Of course, the parameter may be used in protocols that actually do provide authentication or other mechanisms that make it useful for its intended purpose. [Yu] Will add. I'll also add a case where the network node is a PSTN gateway that receives a call from the PSTN. In that case, the "rn" info. will be mapped from the ISUP JIP and would be "authenticated." The issue now is whether we need to differentiate the two (using an indicator). - Section 4.2.4, 6th paragraph: "The network node SHALL include" => "The network node MAY include". There are potentially several headers/cases associated with "caller information" where I wouldn't add this parameter and hence I'd make it a MAY instead. [Yu] Will change. - Section 6: "Protocols carrying the "tel" URI MAY need to ensure message integrity" => "It is RECOMMENDED, that protocols carrying the "tel" URI ensure message integrity" [Yu] Will change. - Section 7: Only the following five of the 14 parameters should be registered with IANA: "rn", "npdi", "cic", "rn-context", "cic-context". The rest are simply part of the ABNF and not actual parameters. [Yu] Agree that only the above five parameters will appear in the tel URI; therefore, need to be registered with IANA. It is not clear if those that are not registered can be re-used when defining new parameters in the future (may be by referencing to this I-D/RFC?). - Section 8: I believe references [1], [3], and [4] are Informative. Also, reference [2] is now 2806bis-05. [Yu] Will change. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Apr 7 16:51:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02642 for ; Wed, 7 Apr 2004 16:51:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBK17-0002uc-43 for iptel-archive@odin.ietf.org; Wed, 07 Apr 2004 16:51:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37KpPEY011195 for iptel-archive@odin.ietf.org; Wed, 7 Apr 2004 16:51:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBK16-0002uR-V3 for iptel-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 16:51:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02510 for ; Wed, 7 Apr 2004 16:51:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBK14-000119-00 for iptel-web-archive@ietf.org; Wed, 07 Apr 2004 16:51:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBHvK-0003g3-00 for iptel-web-archive@ietf.org; Wed, 07 Apr 2004 14:37:19 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBGyq-0002P3-00 for iptel-web-archive@ietf.org; Wed, 07 Apr 2004 13:36:52 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBGyr-0003rH-QD for iptel-web-archive@ietf.org; Wed, 07 Apr 2004 13:36:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBFsA-0001WI-18; Wed, 07 Apr 2004 12:25:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBF6L-0003cv-Q1 for iptel@optimus.ietf.org; Wed, 07 Apr 2004 11:36:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03842; Wed, 7 Apr 2004 11:35:22 -0400 (EDT) Message-Id: <200404071535.LAA03842@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: iptel@ietf.org From: Internet-Drafts@ietf.org Subject: [Iptel] I-D ACTION:draft-ietf-iptel-tel-np-01.txt Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 07 Apr 2004 11:35:21 -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.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : New Parameters for the 'tel' URI to Support Number Portability Author(s) : J. Yu Filename : draft-ietf-iptel-tel-np-01.txt Pages : 13 Date : 2004-4-6 This document defines several new parameters in the "tel" Uniform Resource Identifier (URI) to support number portability (NP) for geographical telephone numbers and freephone numbers. The "rn" parameter carries the routing number for a ported geographical telephone number. The presence of the "npdi" parameter indicates that NP database dip has been performed on a geographical telephone number. The "cic" parameter identifies the freephone service provider for a freephone number. The "rn-context" and "cic-context" parameters describe the "rn" and "cic" parameters respectively when the "rn" and "cic" parameters contain information in the "local" format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-np-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-tel-np-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-tel-np-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-7110740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-tel-np-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-tel-np-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110740.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Thu Apr 8 05:55:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28425 for ; Thu, 8 Apr 2004 05:55:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBWFj-0002Bs-JO for iptel-archive@odin.ietf.org; Thu, 08 Apr 2004 05:55:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i389tJcn008391 for iptel-archive@odin.ietf.org; Thu, 8 Apr 2004 05:55:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBWFi-0002Ax-Mu for iptel-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 05:55:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28279 for ; Thu, 8 Apr 2004 05:55:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBWFe-0007e8-00 for iptel-web-archive@ietf.org; Thu, 08 Apr 2004 05:55:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBU3M-0007NV-00 for iptel-web-archive@ietf.org; Thu, 08 Apr 2004 03:34:26 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBSBp-0000vJ-00 for iptel-web-archive@ietf.org; Thu, 08 Apr 2004 01:35:01 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBS4B-0002yn-FD for iptel-web-archive@ietf.org; Thu, 08 Apr 2004 01:27:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBS1G-0001Lu-ET; Thu, 08 Apr 2004 01:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBS0f-00015h-19 for iptel@optimus.ietf.org; Thu, 08 Apr 2004 01:23:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21368 for ; Thu, 8 Apr 2004 01:23:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBS0c-0006sB-00 for iptel@ietf.org; Thu, 08 Apr 2004 01:23:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBPxu-0007nG-00 for iptel@ietf.org; Wed, 07 Apr 2004 23:12:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBO6k-0001tK-00 for iptel@ietf.org; Wed, 07 Apr 2004 21:13:30 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBO6k-00086k-Fi for iptel@ietf.org; Wed, 07 Apr 2004 21:13:30 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 07 Apr 2004 18:13:46 -0700 Received: from cisco.com (sjc-vpn3-134.cisco.com [10.21.64.134]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i381Ctew022176; Wed, 7 Apr 2004 18:12:56 -0700 (PDT) Message-ID: <4074A716.E62BAE6F@cisco.com> From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Yu, James" CC: list iptel Subject: Re: [Iptel] RE: Comments on draft-ietf-iptel-tel-np-00.txt References: <4F29BE4689992A4B994A440C3EC924DB012D5313@stntexch01.cis.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 07 Apr 2004 21:12:54 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Yu, James" wrote: > Flemming, > > Thanks for the comments. > > Please see the responses below on non-editorial comments. > snipped the ones we're in sync on. > > James > > -----Original Message----- > --------------------------------------------------- > Non-Editorial: > - Mandatory or Optional tel-URI extension parameters. I believe that > "npdi" can be an optional extension, whereas "rn" and "cic" must be > mandatory extensions, since ignoring them may lead to incorrect routing > of the call. I'm not sure I fully understand the 2826bis syntax > requirements on this point (i.e., must a mandatory parameter be defined > with the "m-" prefix or not ?), but regardless it seems we need to agree > on whether the above parameters are optional or mandatory and put that > in the document. > > [Yu] Based on rfc2806bis, a network node shall not process a tel URI with > unknown mandatory parameters. In order not to cause the call be dropped > when a network node does not know the defined parameters (e.g., "rn"), they > are defined as the optional parameters. Because if a network node that > does not know "cic" and "rn" can still route based on the phone number. > When the call (or signaling) reaches a network node that knows the new > parameters, correct action can be taken there. > But what happens if the call does not reach a node that knows these extensions ? Thinking a bit further about this, maybe you are right though. In the LNP case, the telephone number that is present in the Request-URI is still the same; the "rn" parameter would simply instruct the routing part of the system to send the Request to another exchange than the one intended. The worst that can happen is that the incorrectly targeted exchange does not serve this telephone number and hence the call would fail. Similarly for the freephone number case; the number stays the same, and the worst that can happen is that it does not reach the intended carrier, and hence further translation of the number (which is needed to terminate the call) will simply not happen and again we just see a call failure. In either case, we're no worse off than if the intermediary did not support the extension (and clearly, it would be nice if we did have to require all intermediaries to support it). The only case that could be problematic is if the "cic" parameter is used for non-freephone numbers (in which case you could be using the wrong long distance carrier), but I guess the draft does not target this particular application for the "cic" parameter. Unless somebody see something wrong the above line of reasoning, I'm inclined to agree with them being optional after all. Still, it would be good hear from somebody else either way. -- Flemming _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Thu Apr 8 19:12:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06407 for ; Thu, 8 Apr 2004 19:12:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBih8-0004Di-BS for iptel-archive@odin.ietf.org; Thu, 08 Apr 2004 19:12:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38NCQkO016222 for iptel-archive@odin.ietf.org; Thu, 8 Apr 2004 19:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBih5-0004DQ-BS for iptel-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 19:12:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06328 for ; Thu, 8 Apr 2004 19:12:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBih3-0002Iu-00 for iptel-web-archive@ietf.org; Thu, 08 Apr 2004 19:12:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiBB-0006i4-00 for iptel-web-archive@ietf.org; Thu, 08 Apr 2004 18:39:26 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBgFo-00003E-00 for iptel-web-archive@ietf.org; Thu, 08 Apr 2004 16:36:05 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBgEz-0003Dm-1t for iptel-web-archive@ietf.org; Thu, 08 Apr 2004 16:35:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBgEo-0008He-GY; Thu, 08 Apr 2004 16:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBgEc-0008Ft-Ln for iptel@optimus.ietf.org; Thu, 08 Apr 2004 16:34:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20341 for ; Thu, 8 Apr 2004 16:34:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBgEY-0007gW-00 for iptel@ietf.org; Thu, 08 Apr 2004 16:34:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBdRu-0004AQ-00 for iptel@ietf.org; Thu, 08 Apr 2004 13:36:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBbUK-0005Wa-00 for iptel@ietf.org; Thu, 08 Apr 2004 11:30:44 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBbKP-0007jZ-Av for iptel@ietf.org; Thu, 08 Apr 2004 11:20:29 -0400 Received: from chiimc01.cis.neustar.com (chiimc01.neustar.com [10.32.90.4]) by cypress.neustar.com (8.12.8/8.11.6) with ESMTP id i38FJbcm016495; Thu, 8 Apr 2004 15:19:37 GMT Received: by chiimc01.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Apr 2004 10:20:05 -0500 Message-ID: <4F29BE4689992A4B994A440C3EC924DB012D5357@stntexch01.cis.neustar.com> From: "Yu, James" To: "'Flemming Andreasen'" Cc: list iptel Subject: RE: [Iptel] RE: Comments on draft-ietf-iptel-tel-np-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 10:19:29 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Flemming, Glad to see that your analysis reached the conclusion of using "optional" instead of "mandatory" for the defined parameters because this causes less call rejections. If I don't hear from others that favor "mandatory" parameter in two weeks, I'll assme that it is agreed those defined parameters are optional. James > --------------------------------------------------- > Non-Editorial: > - Mandatory or Optional tel-URI extension parameters. I believe that > "npdi" can be an optional extension, whereas "rn" and "cic" must be > mandatory extensions, since ignoring them may lead to incorrect routing > of the call. I'm not sure I fully understand the 2826bis syntax > requirements on this point (i.e., must a mandatory parameter be defined > with the "m-" prefix or not ?), but regardless it seems we need to agree > on whether the above parameters are optional or mandatory and put that > in the document. > > [Yu] Based on rfc2806bis, a network node shall not process a tel URI with > unknown mandatory parameters. In order not to cause the call be dropped > when a network node does not know the defined parameters (e.g., "rn"), they > are defined as the optional parameters. Because if a network node that > does not know "cic" and "rn" can still route based on the phone number. > When the call (or signaling) reaches a network node that knows the new > parameters, correct action can be taken there. > But what happens if the call does not reach a node that knows these extensions ? Thinking a bit further about this, maybe you are right though. In the LNP case, the telephone number that is present in the Request-URI is still the same; the "rn" parameter would simply instruct the routing part of the system to send the Request to another exchange than the one intended. The worst that can happen is that the incorrectly targeted exchange does not serve this telephone number and hence the call would fail. Similarly for the freephone number case; the number stays the same, and the worst that can happen is that it does not reach the intended carrier, and hence further translation of the number (which is needed to terminate the call) will simply not happen and again we just see a call failure. In either case, we're no worse off than if the intermediary did not support the extension (and clearly, it would be nice if we did have to require all intermediaries to support it). The only case that could be problematic is if the "cic" parameter is used for non-freephone numbers (in which case you could be using the wrong long distance carrier), but I guess the draft does not target this particular application for the "cic" parameter. Unless somebody see something wrong the above line of reasoning, I'm inclined to agree with them being optional after all. Still, it would be good hear from somebody else either way. -- Flemming _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Thu Apr 8 19:13:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06473 for ; Thu, 8 Apr 2004 19:13:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBihL-0004FV-VS for iptel-archive@odin.ietf.org; Thu, 08 Apr 2004 19:12:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38NCdrO016329 for iptel-archive@odin.ietf.org; Thu, 8 Apr 2004 19:12:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBihL-0004FI-Qz for iptel-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 19:12:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06362 for ; Thu, 8 Apr 2004 19:12:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBihK-0002MS-00 for iptel-web-archive@ietf.org; Thu, 08 Apr 2004 19:12:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiBs-0006oa-00 for iptel-web-archive@ietf.org; Thu, 08 Apr 2004 18:40:10 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBgGZ-0000Ck-00 for iptel-web-archive@ietf.org; Thu, 08 Apr 2004 16:36:51 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBg2Y-0002hv-MH for iptel-web-archive@ietf.org; Thu, 08 Apr 2004 16:22:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBg1O-00014X-OG; Thu, 08 Apr 2004 16:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBg0Z-0000Eu-PM for iptel@optimus.ietf.org; Thu, 08 Apr 2004 16:20:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18439; Thu, 8 Apr 2004 16:20:17 -0400 (EDT) Message-Id: <200404082020.QAA18439@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: iptel@ietf.org From: Internet-Drafts@ietf.org Subject: [Iptel] I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Apr 2004 16:20:16 -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.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : The tel URI for Telephone Calls Author(s) : H. Schulzrinne Filename : draft-ietf-iptel-rfc2806bis-06.txt Pages : 18 Date : 2004-4-8 This document specifies the URI (Uniform Resource Identifier) scheme 'tel'. The 'tel' URI describes resources identified by telephone numbers A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-rfc2806bis-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-rfc2806bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-rfc2806bis-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-8164325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-rfc2806bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-rfc2806bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-8164325.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Fri Apr 9 02:42:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14383 for ; Fri, 9 Apr 2004 02:42:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBpia-0007CN-Rs for iptel-archive@odin.ietf.org; Fri, 09 Apr 2004 02:42:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i396gOaF027672 for iptel-archive@odin.ietf.org; Fri, 9 Apr 2004 02:42:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBpia-0007CF-NO for iptel-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 02:42:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14308 for ; Fri, 9 Apr 2004 02:42:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBpiU-0006pL-00 for iptel-web-archive@ietf.org; Fri, 09 Apr 2004 02:42:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBpgh-0006f0-00 for iptel-web-archive@ietf.org; Fri, 09 Apr 2004 02:40:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBpfL-0006Wy-00 for iptel-web-archive@ietf.org; Fri, 09 Apr 2004 02:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBpfJ-00070K-VV; Fri, 09 Apr 2004 02:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjRw-0000a0-Gt for iptel@optimus.ietf.org; Thu, 08 Apr 2004 20:00:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12573 for ; Thu, 8 Apr 2004 20:00:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjRu-00008l-00 for iptel@ietf.org; Thu, 08 Apr 2004 20:00:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiVv-0001OJ-00 for iptel@ietf.org; Thu, 08 Apr 2004 19:00:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BBh25-0005gI-00 for iptel@ietf.org; Thu, 08 Apr 2004 17:25:57 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 08 Apr 2004 14:22:05 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i38LPJcr010855 for ; Thu, 8 Apr 2004 17:25:21 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHL98940; Thu, 8 Apr 2004 17:25:18 -0400 (EDT) Message-ID: <4075C33E.6010603@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@ietf.org References: <200404082020.QAA18439@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Iptel] Re:draft-ietf-iptel-rfc2806bis-06.txt Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Apr 2004 17:25:18 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning, This generally looks good. I have a couple of nits: The identifier approach described in this document has the disadvantage that certain services, such as electronic banking or voicemail, cannot be specified in a URI. This overstates the case. Its not that they can't be represented in a URI (they almost certainly can). It is that they can't be specified in a *tel* URL. In following: If a recipient of the URI intends to place a call to the local number, it MUST verify that it is within the same context as one of the descriptors. If it is not within the same context, it MUST NOT initiate the call and treat the URI like an invalid destination. I think this is leftover from when multiple contexts were permitted. Since they no longer are, "as one of the descriptors" seems wrong. Also, I don't think the recipient must be within the context - it is sufficient that it understand the context and be able use that knowledge to place the call. Section 9.2 even gives an example of this case. Thats all, Paul _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Fri Apr 9 12:59:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08051 for ; Fri, 9 Apr 2004 12:59:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzLk-000180-P5 for iptel-archive@odin.ietf.org; Fri, 09 Apr 2004 12:59:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39GxSVR004336 for iptel-archive@odin.ietf.org; Fri, 9 Apr 2004 12:59:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzLk-00017r-KD for iptel-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 12:59:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08030 for ; Fri, 9 Apr 2004 12:59:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBzLh-0001Tq-00 for iptel-web-archive@ietf.org; Fri, 09 Apr 2004 12:59:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBzKJ-0001Ii-00 for iptel-web-archive@ietf.org; Fri, 09 Apr 2004 12:58:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBzJS-0001BW-00 for iptel-web-archive@ietf.org; Fri, 09 Apr 2004 12:57:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzJN-0000oT-Ra; Fri, 09 Apr 2004 12:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzJG-0000lm-BR for iptel@optimus.ietf.org; Fri, 09 Apr 2004 12:56:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07908 for ; Fri, 9 Apr 2004 12:56:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBzJE-0001B3-00 for iptel@ietf.org; Fri, 09 Apr 2004 12:56:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBzHk-0000xw-00 for iptel@ietf.org; Fri, 09 Apr 2004 12:55:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BBzGL-0000ib-00 for iptel@ietf.org; Fri, 09 Apr 2004 12:53:53 -0400 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i39GrWus009100 for ; Fri, 9 Apr 2004 12:53:32 -0400 (EDT) Message-ID: <4076D4FB.3030102@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: list iptel Content-Type: multipart/mixed; boundary="------------000508080007050003040605" Subject: [Iptel] [Fwd: I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt] Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Apr 2004 12:53:15 -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.1 required=5.0 tests=AWL,MIME_SUSPECT_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. --------------000508080007050003040605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Folks, You may have noticed that the IANA registry has been removed from -06. Generally speaking, the purpose of IANA registries is to avoid conflicts that may arise if two different groups/users select the same name for a parameter. This is clearly an issue for things like BGP AS numbers, which are actually allocated by IANA. For parameters in protocol specifications, problems only arise when different specifications accidentally use the same name. This is less likely to happen, and its likelihood depends on how much extensibility is expeted for the protocol. For SIP headers, we deemed it useful because of the large number of extensions that were anticipated. However, I do not expect a lot of extensions to the tel URI, and thus the IANA registry doesnt add a lot of value. Indeed, it is likely to slow up publication of 2806bis and add additional load on an already-busy IANA. Thus, I think it makes sense to drop the iana registry. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com --------------000508080007050003040605 Content-Type: message/rfc822; name="I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt" Content-Disposition: inline; filename="I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt" Received: from proofpoint-02.dynamicsoft.com ([63.113.44.101]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 10KYSJCP; Thu, 8 Apr 2004 16:21:24 -0400 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by proofpoint-02.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i38KLN4K003250; Thu, 8 Apr 2004 16:21:23 -0400 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i38KLH8w012766; Thu, 8 Apr 2004 16:21:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBg1M-00011z-Eg; Thu, 08 Apr 2004 16:21:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBg0Z-0000Eu-Hx for i-d-announce@optimus.ietf.org; Thu, 08 Apr 2004 16:20:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18439; Thu, 8 Apr 2004 16:20:17 -0400 (EDT) Message-Id: <200404082020.QAA18439@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: iptel@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt Date: Thu, 08 Apr 2004 16:20:16 -0400 Sender: i-d-announce-admin@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Proofpoint-Spam-Score: 0 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : The tel URI for Telephone Calls Author(s) : H. Schulzrinne Filename : draft-ietf-iptel-rfc2806bis-06.txt Pages : 18 Date : 2004-4-8 This document specifies the URI (Uniform Resource Identifier) scheme 'tel'. The 'tel' URI describes resources identified by telephone numbers A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-rfc2806bis-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-rfc2806bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-rfc2806bis-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-8164325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-rfc2806bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-rfc2806bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" --OtherAccess-- --NextPart-- --------------000508080007050003040605-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Mon Apr 12 17:53:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17219 for ; Mon, 12 Apr 2004 17:53:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD9MY-0008Gf-9I for iptel-archive@odin.ietf.org; Mon, 12 Apr 2004 17:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CLr6m5031780 for iptel-archive@odin.ietf.org; Mon, 12 Apr 2004 17:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD9MY-0008GV-5i for iptel-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 17:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17188 for ; Mon, 12 Apr 2004 17:53:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD9MV-0005Xw-00 for iptel-web-archive@ietf.org; Mon, 12 Apr 2004 17:53:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD8qr-0003WK-00 for iptel-web-archive@ietf.org; Mon, 12 Apr 2004 17:20:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD8TY-0001hf-00 for iptel-web-archive@ietf.org; Mon, 12 Apr 2004 16:56:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD7LQ-0003EX-0n; Mon, 12 Apr 2004 15:43:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD7A7-0004X6-UT for iptel@optimus.ietf.org; Mon, 12 Apr 2004 15:32:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08740; Mon, 12 Apr 2004 15:32:05 -0400 (EDT) Message-Id: <200404121932.PAA08740@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: iptel@ietf.org From: Internet-Drafts@ietf.org Subject: [Iptel] I-D ACTION:draft-ietf-iptel-rfc2806bis-07.txt Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Apr 2004 15:32:05 -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.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : The tel URI for Telephone Numbers Author(s) : H. Schulzrinne Filename : draft-ietf-iptel-rfc2806bis-07.txt Pages : 18 Date : 2004-4-12 This document specifies the URI (Uniform Resource Identifier) scheme 'tel'. The 'tel' URI describes resources identified by telephone numbers A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-rfc2806bis-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-rfc2806bis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-rfc2806bis-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-12154017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-rfc2806bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-rfc2806bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-12154017.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Mon Apr 12 19:05:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23867 for ; Mon, 12 Apr 2004 19:05:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDAUQ-0004XH-Iw for iptel-archive@odin.ietf.org; Mon, 12 Apr 2004 19:05:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CN5INW017431 for iptel-archive@odin.ietf.org; Mon, 12 Apr 2004 19:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDAUQ-0004X4-Ep for iptel-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 19:05:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23838 for ; Mon, 12 Apr 2004 19:05:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDAUN-0002fY-00 for iptel-web-archive@ietf.org; Mon, 12 Apr 2004 19:05:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDA8i-0000o7-00 for iptel-web-archive@ietf.org; Mon, 12 Apr 2004 18:42:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD9c2-0006aR-00 for iptel-web-archive@ietf.org; Mon, 12 Apr 2004 18:09:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD9bx-0005Z2-8O; Mon, 12 Apr 2004 18:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD9bi-0005Uk-SM for iptel@optimus.ietf.org; Mon, 12 Apr 2004 18:08:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18614 for ; Mon, 12 Apr 2004 18:08:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD9bb-0006Yl-00 for iptel@ietf.org; Mon, 12 Apr 2004 18:08:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD93f-0004WN-00 for iptel@ietf.org; Mon, 12 Apr 2004 17:33:37 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BD8fj-0002Y1-00 for iptel@ietf.org; Mon, 12 Apr 2004 17:08:52 -0400 Received: from cisco.com (sjc-vpn2-137.cisco.com [10.21.112.137]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3CL88BB014767; Mon, 12 Apr 2004 14:08:08 -0700 (PDT) Message-ID: <407B0537.1B62F557@cisco.com> From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: list iptel Subject: Re: [Iptel] [Fwd: I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt] References: <4076D4FB.3030102@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Apr 2004 17:08:07 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > You may have noticed that the IANA registry has been removed from -06. > > Generally speaking, the purpose of IANA registries is to avoid conflicts > that may arise if two different groups/users select the same name for a > parameter. This is clearly an issue for things like BGP AS numbers, > which are actually allocated by IANA. For parameters in protocol > specifications, problems only arise when different specifications > accidentally use the same name. This is less likely to happen, and its > likelihood depends on how much extensibility is expeted for the > protocol. For SIP headers, we deemed it useful because of the large > number of extensions that were anticipated. However, I do not expect a > lot of extensions to the tel URI, and thus the IANA registry doesnt add > a lot of value. Indeed, it is likely to slow up publication of 2806bis > and add additional load on an already-busy IANA. > Thus, I think it makes sense to drop the iana registry. > I've heard this argument a couple of times lately, and I find it hard to accept. Whenever you have an extensible name space, there is a risk for collissions in that name space. An IANA registry is the way to avoid those collissions (not to mention that it provides a convenient way for people to find out what extensions are defined). Relying on some set of people to "just know" what extensions are already defined is neither good engineering practice, nor likely to work well in the long run IMO, and hence I'd much rather that we keep it. Dropping IANA registries as a way of speeding up things seems like fixing the sympton rather than the problem. -- Flemming > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > ------------------------------------------------------------------------ > > Subject: I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt > Date: Thu, 08 Apr 2004 16:20:16 -0400 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: iptel@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Telephony Working Group of the IETF. > > Title : The tel URI for Telephone Calls > Author(s) : H. Schulzrinne > Filename : draft-ietf-iptel-rfc2806bis-06.txt > Pages : 18 > Date : 2004-4-8 > > This document specifies the URI (Uniform Resource Identifier) scheme > 'tel'. The 'tel' URI describes resources identified by telephone > numbers > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-iptel-rfc2806bis-06.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-iptel-rfc2806bis-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-iptel-rfc2806bis-06.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. > > ------------------------------------------------------------------------ _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Mon Apr 12 20:33:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27957 for ; Mon, 12 Apr 2004 20:33:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDBri-0002Mr-Ce for iptel-archive@odin.ietf.org; Mon, 12 Apr 2004 20:33:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D0XQn5009097 for iptel-archive@odin.ietf.org; Mon, 12 Apr 2004 20:33:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDBri-0002Me-7g for iptel-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 20:33:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27931 for ; Mon, 12 Apr 2004 20:33:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDBrf-0001yI-00 for iptel-web-archive@ietf.org; Mon, 12 Apr 2004 20:33:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDBmL-0001I3-00 for iptel-web-archive@ietf.org; Mon, 12 Apr 2004 20:27:54 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDBeg-0000ce-00 for iptel-web-archive@ietf.org; Mon, 12 Apr 2004 20:19:58 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDBay-0003VV-De for iptel-web-archive@ietf.org; Mon, 12 Apr 2004 20:16:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDBas-0001DS-IK; Mon, 12 Apr 2004 20:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDBan-0001CF-UP for iptel@optimus.ietf.org; Mon, 12 Apr 2004 20:15:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27054 for ; Mon, 12 Apr 2004 20:15:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDBal-0000MS-00 for iptel@ietf.org; Mon, 12 Apr 2004 20:15:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDBPK-00074y-00 for iptel@ietf.org; Mon, 12 Apr 2004 20:04:08 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BDBBB-0005Xc-00 for iptel@ietf.org; Mon, 12 Apr 2004 19:49:29 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <2M80L8W5>; Tue, 13 Apr 2004 00:48:51 +0100 Received: from [127.0.0.1] (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2M89N0RY; Tue, 13 Apr 2004 00:48:40 +0100 From: "Conroy, Lawrence (SMTP)" To: Flemming Andreasen Cc: Jonathan Rosenberg , list iptel In-Reply-To: <407B0537.1B62F557@cisco.com> References: <4076D4FB.3030102@dynamicsoft.com> <407B0537.1B62F557@cisco.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Iptel] [Fwd: I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt] X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 00:48:41 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Flemming, folks, I fully agree with Jonathon. Please let's avoid an IANA time trap. I also sympathise with Flemming - this is fixing the symptom, not the problem. However... we know there's a problem; we know that the problem needs to be fixed. We also live in the real world (i.e. we're Engineers :), and I can't be the only one who believes that RFC2806bis is a major clarification - it's needed NOW. Thus, let's get this thing "out the door", and *in parallel* fix the problem. Do you really think that there will be a lot of parameter specification RFCs that "update" RFC2806bis? If so, then a future task (once IANA has been taught how to set up a registry in less than several years) could be to pull in all the updates and refresh with an IANA considerations section - but, please, don't hold this one hostage (and any that depend on it), unless that's the intent. all the best from an impatient Lawrence On 12 Apr 2004, at 10:08 pm, Flemming Andreasen wrote: > > > Jonathan Rosenberg wrote: > >> Folks, >> >> You may have noticed that the IANA registry has been removed from -06. >> >> Generally speaking, the purpose of IANA registries is to avoid >> conflicts >> that may arise if two different groups/users select the same name for >> a >> parameter. This is clearly an issue for things like BGP AS numbers, >> which are actually allocated by IANA. For parameters in protocol >> specifications, problems only arise when different specifications >> accidentally use the same name. This is less likely to happen, and its >> likelihood depends on how much extensibility is expeted for the >> protocol. For SIP headers, we deemed it useful because of the large >> number of extensions that were anticipated. However, I do not expect a >> lot of extensions to the tel URI, and thus the IANA registry doesnt >> add >> a lot of value. Indeed, it is likely to slow up publication of 2806bis >> and add additional load on an already-busy IANA. > >> Thus, I think it makes sense to drop the iana registry. >> > > I've heard this argument a couple of times lately, and I find it hard > to accept. > Whenever you have an extensible name space, there is a risk for > collissions in that > name space. An IANA registry is the way to avoid those collissions > (not to mention that > it provides a convenient way for people to find out what extensions > are defined). > Relying on some set of people to "just know" what extensions are > already defined is > neither good engineering practice, nor likely to work well in the long > run IMO, and > hence I'd much rather that we keep it. Dropping IANA registries as a > way of speeding up > things seems like fixing the sympton rather than the problem. > > -- Flemming > >> >> Thanks, >> Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Chief Technology Officer Parsippany, NJ 07054-2711 >> dynamicsoft >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.com >> >> >> ---------------------------------------------------------------------- >> -- >> >> Subject: I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt >> Date: Thu, 08 Apr 2004 16:20:16 -0400 >> From: Internet-Drafts@ietf.org >> To: i-d-announce@ietf.org >> CC: iptel@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IP Telephony Working Group of the >> IETF. >> >> Title : The tel URI for Telephone Calls >> Author(s) : H. Schulzrinne >> Filename : draft-ietf-iptel-rfc2806bis-06.txt >> Pages : 18 >> Date : 2004-4-8 >> >> This document specifies the URI (Uniform Resource Identifier) scheme >> 'tel'. The 'tel' URI describes resources identified by telephone >> numbers >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-iptel-rfc2806bis-06.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body >> of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-iptel-rfc2806bis-06.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-iptel-rfc2806bis-06.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. >> >> >> ---------------------------------------------------------------------- >> -- > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Tue Apr 13 18:22:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15211 for ; Tue, 13 Apr 2004 18:22:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWBU-0002hq-F2 for iptel-archive@odin.ietf.org; Tue, 13 Apr 2004 18:15:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DMFCvl010400 for iptel-archive@odin.ietf.org; Tue, 13 Apr 2004 18:15:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVxl-0003tc-SG for iptel-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 18:01:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12497 for ; Tue, 13 Apr 2004 18:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVxi-0000Iu-00 for iptel-web-archive@ietf.org; Tue, 13 Apr 2004 18:00:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDVkx-0006a8-00 for iptel-web-archive@ietf.org; Tue, 13 Apr 2004 17:47:49 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDVXZ-0005JU-00 for iptel-web-archive@ietf.org; Tue, 13 Apr 2004 17:33:57 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDVSW-0003il-QU for iptel-web-archive@ietf.org; Tue, 13 Apr 2004 17:28:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVGr-0005Vt-Px; Tue, 13 Apr 2004 17:16:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDUPZ-0007nw-GD for iptel@optimus.ietf.org; Tue, 13 Apr 2004 16:21:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04822 for ; Tue, 13 Apr 2004 16:21:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDUPW-0005jy-00 for iptel@ietf.org; Tue, 13 Apr 2004 16:21:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDUJt-00059D-00 for iptel@ietf.org; Tue, 13 Apr 2004 16:15:46 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDUEi-0004VI-00 for iptel@ietf.org; Tue, 13 Apr 2004 16:10:24 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 13 Apr 2004 12:20:02 +0000 Received: from cisco.com (sjc-vpn4-493.cisco.com [10.21.81.237]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3DK9kKj008815; Tue, 13 Apr 2004 13:09:47 -0700 (PDT) Message-ID: <407C4909.6368B013@cisco.com> From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: list iptel Subject: Re: [Iptel] [Fwd: I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt] References: <4076D4FB.3030102@dynamicsoft.com> <407B0537.1B62F557@cisco.com> <407C470C.6010107@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 16:09:46 -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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Thus, unless you or someone else really strongly objects, I'd lack to > pass -07 to IESG so we can declare this one done. > I'm not going to object, but I think we are setting a poor precedent here. Can we perhaps get an area on the softarmor site where we can list these (unofficially of course) ? -- Flemming _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Tue Apr 13 18:22:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15237 for ; Tue, 13 Apr 2004 18:22:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWCG-00033G-F2 for iptel-archive@odin.ietf.org; Tue, 13 Apr 2004 18:16:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DMG0GG011726 for iptel-archive@odin.ietf.org; Tue, 13 Apr 2004 18:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVxt-0003ys-8Q for iptel-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 18:01:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12516 for ; Tue, 13 Apr 2004 18:01:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVxp-0000JV-00 for iptel-web-archive@ietf.org; Tue, 13 Apr 2004 18:01:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDVl1-0006az-00 for iptel-web-archive@ietf.org; Tue, 13 Apr 2004 17:47:54 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDVXc-0005JU-00 for iptel-web-archive@ietf.org; Tue, 13 Apr 2004 17:34:00 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDVSE-0003he-0z for iptel-web-archive@ietf.org; Tue, 13 Apr 2004 17:28:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVFG-0004AB-JT; Tue, 13 Apr 2004 17:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDUDi-00040N-85 for iptel@optimus.ietf.org; Tue, 13 Apr 2004 16:09:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03793 for ; Tue, 13 Apr 2004 16:09:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDUDf-0004Rn-00 for iptel@ietf.org; Tue, 13 Apr 2004 16:09:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDU9l-0003tn-00 for iptel@ietf.org; Tue, 13 Apr 2004 16:05:18 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BDU6b-0003Rl-00 for iptel@ietf.org; Tue, 13 Apr 2004 16:02:02 -0400 Received: from dynamicsoft.com ([63.113.46.137]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i3DK1Wus010735; Tue, 13 Apr 2004 16:01:32 -0400 (EDT) Message-ID: <407C470C.6010107@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Flemming Andreasen CC: list iptel Subject: Re: [Iptel] [Fwd: I-D ACTION:draft-ietf-iptel-rfc2806bis-06.txt] References: <4076D4FB.3030102@dynamicsoft.com> <407B0537.1B62F557@cisco.com> In-Reply-To: <407B0537.1B62F557@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 16:01:16 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: > > Jonathan Rosenberg wrote: > > >>Folks, >> >>You may have noticed that the IANA registry has been removed from -06. >> >>Generally speaking, the purpose of IANA registries is to avoid conflicts >>that may arise if two different groups/users select the same name for a >>parameter. This is clearly an issue for things like BGP AS numbers, >>which are actually allocated by IANA. For parameters in protocol >>specifications, problems only arise when different specifications >>accidentally use the same name. This is less likely to happen, and its >>likelihood depends on how much extensibility is expeted for the >>protocol. For SIP headers, we deemed it useful because of the large >>number of extensions that were anticipated. However, I do not expect a >>lot of extensions to the tel URI, and thus the IANA registry doesnt add >>a lot of value. Indeed, it is likely to slow up publication of 2806bis >>and add additional load on an already-busy IANA. > > >>Thus, I think it makes sense to drop the iana registry. >> > > > I've heard this argument a couple of times lately, and I find it hard to accept. > Whenever you have an extensible name space, there is a risk for collissions in that > name space. An IANA registry is the way to avoid those collissions (not to mention that > it provides a convenient way for people to find out what extensions are defined). > Relying on some set of people to "just know" what extensions are already defined is > neither good engineering practice, nor likely to work well in the long run IMO, and > hence I'd much rather that we keep it. This is true in theory, but I'm not sure it will really be an issue here, for this spec, in practice. I dont see lots of extensions, and I don't see lack of communications amongst authors on extensions. After all, the extensions are documented in RFCs - years later someone can still find the tel URI extensions and then make sure to define their extension to use a different name. Thus, the registry is primarily a convenience, and given the latency it will add, it doesnt seem worth it. Further, as Lawrence points out, it can easily be added later. Thus, unless you or someone else really strongly objects, I'd lack to pass -07 to IESG so we can declare this one done. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Apr 14 10:32:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28201 for ; Wed, 14 Apr 2004 10:32:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlKr-00088M-6Q for iptel-archive@odin.ietf.org; Wed, 14 Apr 2004 10:25:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EEPrtN031266 for iptel-archive@odin.ietf.org; Wed, 14 Apr 2004 10:25:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlG0-00074I-Hf for iptel-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 10:20:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27741 for ; Wed, 14 Apr 2004 10:20:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlFy-00041e-00 for iptel-web-archive@ietf.org; Wed, 14 Apr 2004 10:20:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlEu-0003u1-00 for iptel-web-archive@ietf.org; Wed, 14 Apr 2004 10:19:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDlEa-0003mZ-00 for iptel-web-archive@ietf.org; Wed, 14 Apr 2004 10:19:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDl8X-0003GS-6Y; Wed, 14 Apr 2004 10:13:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkzF-0003ng-U9 for iptel@optimus.ietf.org; Wed, 14 Apr 2004 10:03:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25720 for ; Wed, 14 Apr 2004 10:03:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDkzD-0001Uw-00 for iptel@ietf.org; Wed, 14 Apr 2004 10:03:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkyH-0001Nd-00 for iptel@ietf.org; Wed, 14 Apr 2004 10:02:33 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BDkxM-00019A-00 for iptel@ietf.org; Wed, 14 Apr 2004 10:01:36 -0400 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i3EE1Lus011185 for ; Wed, 14 Apr 2004 10:01:21 -0400 (EDT) Message-ID: <407D4421.6050907@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: list iptel Content-Type: multipart/mixed; boundary="------------030405010701090004070108" Subject: [Iptel] [Fwd: I-D ACTION:draft-ietf-iptel-rfc2806bis-07.txt] Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 10:01:05 -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.1 required=5.0 tests=AWL,MIME_SUSPECT_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. --------------030405010701090004070108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Folks, I passed this draft onto IESG today to request publication as proposed standard. Thanks for everyone's patience, persistence and work in producing this important spec. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com --------------030405010701090004070108 Content-Type: message/rfc822; name="I-D ACTION:draft-ietf-iptel-rfc2806bis-07.txt" Content-Disposition: inline; filename="I-D ACTION:draft-ietf-iptel-rfc2806bis-07.txt" Received: from proofpoint-01.dynamicsoft.com ([63.113.45.180]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2XJCT8BA; Mon, 12 Apr 2004 15:45:09 -0400 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by proofpoint-01.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i3CJj7pv019262; Mon, 12 Apr 2004 15:45:07 -0400 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i3CJiN54005122; Mon, 12 Apr 2004 15:44:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD7KQ-0001Ul-SW; Mon, 12 Apr 2004 15:42:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD7A7-0004X6-RW for i-d-announce@optimus.ietf.org; Mon, 12 Apr 2004 15:32:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08740; Mon, 12 Apr 2004 15:32:05 -0400 (EDT) Message-Id: <200404121932.PAA08740@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: iptel@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-iptel-rfc2806bis-07.txt Date: Mon, 12 Apr 2004 15:32:05 -0400 Sender: i-d-announce-admin@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Proofpoint-Spam-Score: 0 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : The tel URI for Telephone Numbers Author(s) : H. Schulzrinne Filename : draft-ietf-iptel-rfc2806bis-07.txt Pages : 18 Date : 2004-4-12 This document specifies the URI (Uniform Resource Identifier) scheme 'tel'. The 'tel' URI describes resources identified by telephone numbers A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-rfc2806bis-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-rfc2806bis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-rfc2806bis-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-12154017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-rfc2806bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-rfc2806bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" --OtherAccess-- --NextPart-- --------------030405010701090004070108-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Apr 14 11:12:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00393 for ; Wed, 14 Apr 2004 11:12:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm26-00005X-MU for iptel-archive@odin.ietf.org; Wed, 14 Apr 2004 11:10:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EFAYLQ000334 for iptel-archive@odin.ietf.org; Wed, 14 Apr 2004 11:10:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDluq-0006no-E8 for iptel-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 11:03:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29742 for ; Wed, 14 Apr 2004 11:03:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlun-0000dY-00 for iptel-web-archive@ietf.org; Wed, 14 Apr 2004 11:03:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDltv-0000bm-00 for iptel-web-archive@ietf.org; Wed, 14 Apr 2004 11:02:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDltG-0000Zu-00 for iptel-web-archive@ietf.org; Wed, 14 Apr 2004 11:01:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDll8-0004ne-Cz; Wed, 14 Apr 2004 10:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlf6-0003nM-6i for iptel@optimus.ietf.org; Wed, 14 Apr 2004 10:46:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28724 for ; Wed, 14 Apr 2004 10:46:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlf3-00075N-00 for iptel@ietf.org; Wed, 14 Apr 2004 10:46:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDleD-0006xf-00 for iptel@ietf.org; Wed, 14 Apr 2004 10:45:55 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1BDldf-0006o9-00; Wed, 14 Apr 2004 10:45:19 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F162233CC5@oefeg-s02.oefeg.loc> Thread-Topic: Additional Information in ENUM and the tel: PSTN-Indicator Thread-Index: AcQiLvm75iM9YeSrSH6zMpncqxkKbA== From: "Stastny Richard" To: , Content-Transfer-Encoding: quoted-printable Subject: [Iptel] Additional Information in ENUM and the tel: PSTN-Indicator Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 16:44:49 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Colleagues, I apologize in advance for posting this to both lists, but I think both ENUM and IPTEL are involved. I would suggest posting any replies only on the ENUM list. Abstract: This e-mail describes a solution to issues discussed on this list regarding putting additional information in ENUM (e164.arpa). The solution is required for ENUM-driven numbers, but may also be used for additional purposes. The solution may also be used in other ENUM-like applications. The solution may either be submitted as a separate ID or may be included in the currently work-in-progress BCP on ENUM. This proposal will also be submitted to ETSI to be included in V2 of TS 102 172. The solution contains also a proposed change to the NAPTR syntax (the "v" or *void* flag) and an additional parameter for the=20 tel: URI (;pstn) Problem statement: In RFC2916bis, RFC3403 and ETSI TS 102 172 it is well defined how an ENUM client should react if an E.164 number is queried in ENUM DNS (e164.arpa) for NAPTR and how this NAPTR should be processed.=20 On the other hand, it is currently not clearly defined what should happen if the result of the query is NXDOMAIN. The current assumption is that if the UAC wants to establish a=20 voice call, the call is routed by default to the PSTN, if the UAC or server is capable of doing so.=20 The underlying assumption here is the following: since ENUM is opt-in, the number dialed may either exist on the PSTN or the PSTN will know that the number does not exist. This may not be very efficient in all cases, but it works. This is no longer true with *ENUM-driven* E.164 numbers. =20 ENUM-driven E.164 numbers are defined in number ranges=20 existing only in ENUM. Numbers within of these number-ranges are not terminated on the PSTN, but routed forward to an ENUM-enabled=20 gateway. The ENUM-enabled gateways are querying ENUM to route the call further to its termination on the Internet. Within these number-ranges numbers may not be assigned (yet), but the gateway has in this case not the option to route the call further (back) to the PSTN.=20 It is therefore required in this case to provide the ENUM clients (at least the ENUM-clients in the gateways) with an additional information, to prevent them from routing these calls to the PSTN. Note: Since ENUM-enabled clients may route the call immediately to the PSTN (e.g. via an FXO-port), the solution must be simple, related or near to ENUM (e164.arpa) and using=20 similar algorithms (e.g. using NAPTR records). In addition, it would be nice to be able to signal=20 the found-out facts to other servers during the signalling path,=20 to prevent them from making unnecessary queries to ENUM. It would also be nice to be able to re-use possible=20 solutions for other purposes. So what are the requirements? The basic requirement is the following: If an ENUM client queries ENUM for a given fully qualified E.164 number and this number is not contained within e164.arpa, the DNS query returns NXDOMAIN. For ENUM-driven number ranges it SHALL be possible to provide the ENUM client with an additional information how to handle the call (that is: the number is not assigned) For ENUM opt-in number ranges it would be nice in some cases to be able provide additional information. These cases could be (not taxative): - the number is a DDI number out of a number range assigned to a PBX (the additional information may point to the switchboard). - the number range is also not existing on the PSTN=20 (number not assigned). - the number range is operated by telephony service provider providing a gateway (border element) to the public Internet. (the additional information may point to this gateway) - the number range is operated via a LNP or 800 database (ffs). Note: It was also proposed to use these solutions to point to carrier or infrastructure ENUM trees. IMHO this should not be done, considering that we are talking only about User ENUM. User clients will not be able to access carrier ENUM. In addition, it is not clear yet if and how carrier ENUM will be implemented. This issue it therefore=20 currently out-of-scope or ffs. The following questions need to be answered: 1.How and where to place the information in ENUM? 2.In which format the information is placed in ENUM? 3.How the signal this information to other servers? Possible solutions: 1. How and where to place the information in ENUM? During the discussion on the list several proposals have been brought forward: - use wild cards - populate the ENUM database with all possible numbers - create one or more additional trees (shadow tree) - use the SOA response given back with NXDOAMIN I do not want to repeat the full discussion here, but the essence of the discussion was: -wildcards do not work as intended and necessary -populating ENUM with all possible numbers is not a good idea=20 and also would not work in cases with variable number length. -creating more then one shadow tree and placing pointers to these trees in e164.arpa would also not solve the primary problem: where to put these pointers and how to find them. -creating one second shadow tree is a valid option, allowing to wildcard NAPTRs in the second tree for a given number range, but it would not allow to nest this information. In addition, a second tree was considered *nasty* by some participants and it would also require a global agreement, stirring up all bodies again concerned with e164.arpa. -this leaves the usage of the SOA response in NXDOMAIN.=20 This solution also would require only minor changes in ENUM administration and also in the clients. Where and how is the additional information derived from ENUM? This proposal (from Jim Reed) uses the additional information that's in=20 the NXDOMAIN response. This response will include the SOA record=20 for the zone enclosing the name that was looked up. The name=20 of that zone can be looked up to get a NAPTR for a default SIP gateway or whatever.=20 An example might clarify this. Consider the non-existent phone number 1234567890. An ENUM lookup of 0.9.8.7.6.5.4.3.2.1.e164.arpa returns NXDOMAIN.=20 The response includes a SOA record for 5.4.3.2.1.e164.arpa -- the=20 enclosing zone for this name. This will be in the Authority Section=20 of the reply. In other words, the name servers for 5.4.3.2.1.e164.arpa=20 are saying 0.9.8.7.6.5.4.3.2.1.e164.arpa doesn't exist. If I then lookup 5.4.3.2.1.e164.arpa, this could have a NAPTR that gives me the name of a SIP gateway that will do the Right Thing for 1234567890. It can also be used for number-ranges like 800 and 900 numbers or DDI blocks.=20 Calls to these numbers will get shunted to the right "gateway".=20 This does of course make things a little bit trickier for a Tier-1 registry that delegates every individual E.164 number. Below is a complete example how such a query may be=20 implemented in an ENUM client. 2. In which format the information is placed in ENUM? Basic requirement: all information shall use NAPTR records What kind of information could be provided: A. This E.164 number does not exist. Proposal: use the "v" flag (for void) Example: IN NAPTR 10 10 "v" "E2U" In this case the call is not routed further and "No-such number" is returned by the client B. Use a normal NAPTR pointing to a sip: or h323: URI This could be used either to point to the switchboard of a PBX or to a gateway provided for a numbering block by an service provider. Note: if e.g. only a NAPTR is provided for h323 and the=20 client is only capable of doing SIP, the call may also be forwarded to the "PSTN". 3. How does the UAC or server signal this information to other servers? Discussion: If a client or server has queried ENUM for an E.164 number,=20 the following outcomes are possible: a.the client has found a sip: or h323: URI, so the next proxy sees an address-of-record anyway. b.the query has returned a tel: URI and the client has done a second ENUM query for this E.164 number, also retrieving an address-of-Record (or has got an indication in the tel: URI to route the call to the "PSTN", see below). c. the client has queried ENUM, found no result and has DECIDED to route the call to the PSTN. d. the client has NOT done an ENUM query, because the end-user has explicitly prohibited this, e.g. by entering a special service (access) code. So the client (or server) is sending either a=20 sip: or h323: URI to the next proxy or an E.164 number only with the intention to forward it to the PSTN. Only if the client is not capable of doing an ENUM query, it may send an E.164 number otherwise. So sending an enum-dip-indicator seems not very useful. What is required instead is sending a "force-to-pstn" indicator. It is therefore proposed to add a ;pstn indicator to the tel: URI.=20 The ;pstn indicator is attached to a tel: URI (or an equivalent sip: URI in the following cases: 1.The user has explicitly entered an agreed upon access code to force the call to the PSTN 2. The ENUM query has retrieved a tel: URI with a ;pstn indicator 3. The ENUM query has retrieved no result (NXDOMAIN) in all above cases. A server receiving such a tel: URI MUST forward the call to a server capable of PSTN routing or MUST be able to=20 to PSTN routing by itself (either via carrier ENUM or by routing the call to the PSTN via a gateway). If the server or the UA is not capable of doing so, it must return *no such service* So what is finally the new procedure for an ENUM client? Complete walkthrough: =20 For sake of simplicity, let's assume a pure voice call, e.g. from a phone on a terminal adapter: =20 Assumptions: the system (server or TA) is able to: A. set up a voice call B. respond with "no such service" (e.g trunk busy) C: respond with "no such number" (e.g. SIT) =20 Start: The user is dialing a number, the UAC is normalizing this number into an E.164 number and the ENUM client is querying the=20 E.164 number in e164.arpa: 1. It gets back one or more NAPTRs, one of them is usable to set up a voice call -> done. =20 2. It gets back some NAPTRs, none of the is usable to set up a voice call -> response: "no such service" =20 3. It gets back NODATA -> response: "no such service" Note1: 2. and 3. is currently handled in a different way: the system tries to set up a call to the PSTN! (I myself used this to force a call to my mobile phone) Note2: The only way in future to force a call to the PSTN in this case would be to explicitly provide a NAPTR with voice:tel and a tel: URI pointing to the same (or a different number), preferable with tel:+xxx;pstn, (which makes sense anyway) =20 4. It gets back NXDOMAIN 4a. It now queries the domain given back in the SOA response for NAPTR. 4b. It does not get the enclosing domain back in the SOA response because of a broken or out-date DNS implementation -> the call is routed to the PSTN. =20 5. It gets back a NAPTR: 5a. the flag field is "v" -> response: "no such number" Note3: this implies that ENUM-driven number ranges SHALL contain always a NAPTR with flag "v" on top!! 5b. the NAPTR is not usable for voice calls -> response: "no such service"? 5c: the NAPTR is usable for voice and is a simple URI=20 (no regexp) -> set up call, done 5d. the NAPTR is usable for voice and contains a regexp (no comes the tricky part) the regexp has to be evaluated with the original AUS from the first query! -> set up call, done =20 6. It gets back NODATA -> set up call with tel:+xxx;pstn, where xxx is the AUS from the original ENUM query Note4: this would be equivalent if a NAPTR containg enumservice E2U+voice:tel and tel:/1;pstn was retrieved. =20 7. It gets back NXDOMAIN -> something is=20 seriously wrong ;-) Final remark: There is a minor problem with this approach indofar, that some (very out-dated) DNS applications still do not support this feature. Quote from Jim Reed: [Any sane DNS implementation will return a SOA record in the Authority Section of an NXDOMAIN reply. This is required by RFC2308. > > 3 - Negative Answers from Authoritative Servers > > Name servers authoritative for a zone MUST include the SOA record of > the zone in the authority section of the response when reporting an > NXDOMAIN or indicating that no data of the requested type exists. > A DNS implementation that doesn't implement RFC2308 is broken and/or very, very old. These should not be found or deployed in the ENUM system. - end quote] =20 On the other hand the procedure is designed in such a way that as a default (if the enclosing domain is not returned) the call is forwarded to the PSTN. =20 This does not really hurt in the most cases, only in case of=20 ENUM-driven number ranges. In this case the mandatory requirement would be that at least the generic gateways must live in a DNS-foodchain capable of returning the enclosing domain, which should be doable. Summary: What needs to be done: Include the above procedure in a BCP Define the *void* flag in an RFC Define the ;pstn indicator for tel: in an RFC Best regards Richard > Richard Stastny OFEG Osterreichische Fernmeldetechnische Entwicklungs- und Forderungsgesellschaft mbH Buroadresse: Arsenal Objekt 24, 7. Stock, Bauteil Ost, A-1030 Wien Postadresse: Postfach 147, A-1103 Wien Telefon: +43 664 420 4100 Telefax: +43 1 79780 13 E-Mail: =20 Web: Die in dieser Mitteilung und Anhangen enthaltenen Informationen sind ausschlie?lich fur den Adressaten bestimmt und konnen geheime, vertrauliche oder vor Weitergabe geschutzte Informationen enthalten. Falls es sich beim Leser dieses Absatzes nicht um den beabsichtigten Empfanger oder dessen Vertretung handelt, wird er hiermit in Kenntnis gesetzt, dass jegliche Weitergabe, Verteilung oder Vervielfaltigung dieser Mitteilung verboten ist. Sollte dieses Schreiben irrtumlich zugestellt worden sein, wird gebeten, den Absender zu benachrichtigen und die Mitteilung zu loschen, ohne Kopien einzubehalten. Danke. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Apr 14 11:23:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01325 for ; Wed, 14 Apr 2004 11:23:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm2w-0000TA-Qb for iptel-archive@odin.ietf.org; Wed, 14 Apr 2004 11:11:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EFBQKM001800 for iptel-archive@odin.ietf.org; Wed, 14 Apr 2004 11:11:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlwy-00078O-7e for iptel-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 11:05:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29952 for ; Wed, 14 Apr 2004 11:05:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlwv-0000nH-00 for iptel-web-archive@ietf.org; Wed, 14 Apr 2004 11:05:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlw6-0000kG-00 for iptel-web-archive@ietf.org; Wed, 14 Apr 2004 11:04:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDlvd-0000fy-00 for iptel-web-archive@ietf.org; Wed, 14 Apr 2004 11:03:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlo1-0005OO-Ad; Wed, 14 Apr 2004 10:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDljF-0004fy-NS for iptel@optimus.ietf.org; Wed, 14 Apr 2004 10:51:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28872 for ; Wed, 14 Apr 2004 10:51:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDljD-0007eO-00 for iptel@ietf.org; Wed, 14 Apr 2004 10:51:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlim-0007XH-00 for iptel@ietf.org; Wed, 14 Apr 2004 10:50:37 -0400 Received: from email10.etsi.org ([212.234.161.112] helo=email10.etsihq.org) by ietf-mx with esmtp (Exim 4.12) id 1BDlhm-0007Kd-00; Wed, 14 Apr 2004 10:49:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <4091553999CBE4409CC2B562152B5A3302DFB197@email10.etsihq.org> Thread-Topic: Start of maintenance activity on VoIP test specification at ETSI Thread-Index: AcQiL6DkSaf2slKYR3uBd3Dtu79Ddg== From: =?iso-8859-1?Q?Fran=E7ois_Fischer?= To: , , Content-Transfer-Encoding: quoted-printable Subject: [Iptel] Start of maintenance activity on VoIP test specification at ETSI Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 16:49:03 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear all, I would like to inform you that ETSI has just started a maintenance = activity on the Test specification for: SIP, H.225 and H.248. In order to improve as much as possible these Test Specifications, ETSI = needs to collect feedback and comments on the current version. The release of these Test Specifications will be produced as following = (for SIP, H.225 and H.248): PICS : 11 June 2004 TSS&TP : 23 July 2004 ATS&PIXIT : 17 September 2004 We would appreciate you to look at these test specification releases and = to make comments latest 4 weeks before the corresponding dates above. Please consider the Test specification as a critical part of the quality = process to ensure Interoperability and reliability of equipments. Furthermore, test specifications, when used by the test labs, operator = and vendors will give confidence in VoIP and Internet Telephony = protocols. For more information on Testing of VoIP Protocols, and TTCN3, please = visit: http://www.etsi.org/ptcc/home.htm You will also find the current release of the Test Specification in the = following links: Links to H.225: PICS: http://docbox.etsi.org/MTS/MTS/07-Drafts/00095-1/v1.0.0/ TSS&TP: http://docbox.etsi.org/MTS/MTS/07-Drafts/00095-2/v1.0.0/ ATS: http://docbox.etsi.org/MTS/MTS/07-Drafts/00095-3/ Links to H.248: PICS: http://docbox.etsi.org/MTS/MTS/07-Drafts/00096-1/v1.0.0/ TSS&TP: http://docbox.etsi.org/MTS/MTS/07-Drafts/00096-2/ ATS: http://docbox.etsi.org/MTS/MTS/07-Drafts/00096-3/ Links to SIP: PICS: http://docbox.etsi.org/MTS/MTS/07-Drafts/00097-1/v1.0.0/ TSS&TP: http://docbox.etsi.org/MTS/MTS/07-Drafts/00097-2/v1.0.0/ ATS: http://docbox.etsi.org/MTS/MTS/07-Drafts/00097-3/ In order to transmit your comments please use the dedicated Email = exploder list: H.323 : MTS-IPT-H323 H.248 : MTS-IPT-H248 SIP : MTS-IPT-SIP. You will subscribe these lists independantly by sending an email to: = listserv@list.etsi.org with the following command in the message body: subscribe "listname" (firstname lastname) eg subcribe MTS-IPT-SIP (firstname lastname) Please contribute in maintening these specifications, which enable VoIP = actors to ensure the right level of quality for VoIP and Internet = Telephony items. Many thanks in advance. Francois FISCHER - STF expert ************************************************* ETSI Einstein Building - 650 route des Lucioles F-06560 Sophia Antipolis cedex, FRANCE ************************************************* Tel: +33 (0)4 92944330 - Fax: +33 (0)4 92385244 Email: francois.fischer@etsi.org _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Tue Apr 20 12:53:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03639 for ; Tue, 20 Apr 2004 12:53:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyGL-0000wZ-4T for iptel-archive@odin.ietf.org; Tue, 20 Apr 2004 12:38:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KGcL08003613 for iptel-archive@odin.ietf.org; Tue, 20 Apr 2004 12:38:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxiX-0000UB-Cq for iptel-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 12:03:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29272 for ; Tue, 20 Apr 2004 12:03:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxiW-0006T4-6e for iptel-web-archive@ietf.org; Tue, 20 Apr 2004 12:03:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFxh1-0005nr-00 for iptel-web-archive@ietf.org; Tue, 20 Apr 2004 12:01:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BFxfD-00056x-01 for iptel-web-archive@ietf.org; Tue, 20 Apr 2004 11:59:59 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BFxR3-0005Uc-R9 for iptel-web-archive@ietf.org; Tue, 20 Apr 2004 11:45:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwmB-00036X-4H; Tue, 20 Apr 2004 11:03:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwfx-0000L3-9X for iptel@optimus.ietf.org; Tue, 20 Apr 2004 10:56:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23347; Tue, 20 Apr 2004 10:56:37 -0400 (EDT) Message-Id: <200404201456.KAA23347@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: iptel@ietf.org From: Internet-Drafts@ietf.org Subject: [Iptel] I-D ACTION:draft-ietf-iptel-tel-np-02.txt Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 10:56:37 -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.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : New Parameters for the 'tel' URI to Support Number Portability Author(s) : J. Yu Filename : draft-ietf-iptel-tel-np-02.txt Pages : 12 Date : 2004-4-19 This document defines several new parameters in the 'tel' Uniform Resource Identifier (URI) to support number portability (NP) for geographical telephone numbers and freephone numbers. The 'rn' parameter carries the routing number for a ported geographical telephone number. The presence of the 'npdi' parameter indicates that NP database dip has been performed on a geographical telephone number. The 'cic' parameter identifies the freephone service provider for a freephone number. The 'rn-context' and 'cic-context' parameters describe the 'rn' and 'cic' parameters respectively when the 'rn' and 'cic' parameters contain information in the 'local' format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-np-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-tel-np-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-tel-np-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-20111736.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-tel-np-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-tel-np-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20111736.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Mon Apr 26 18:07:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27873 for ; Mon, 26 Apr 2004 18:07:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEDd-0003v4-F2 for iptel-archive@odin.ietf.org; Mon, 26 Apr 2004 18:04:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QM4rUQ015054 for iptel-archive@odin.ietf.org; Mon, 26 Apr 2004 18:04:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIE1R-00082x-V5 for iptel-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26474 for ; Mon, 26 Apr 2004 17:52:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIE1P-00000O-DK for iptel-web-archive@ietf.org; Mon, 26 Apr 2004 17:52:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIE0Q-0007k7-00 for iptel-web-archive@ietf.org; Mon, 26 Apr 2004 17:51:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDzX-0007fK-00 for iptel-web-archive@ietf.org; Mon, 26 Apr 2004 17:50:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDtX-00065P-3q; Mon, 26 Apr 2004 17:44:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDbe-0001b5-G3 for iptel@optimus.ietf.org; Mon, 26 Apr 2004 17:25:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24659 for ; Mon, 26 Apr 2004 17:25:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDbc-0005h2-1q for iptel@ietf.org; Mon, 26 Apr 2004 17:25:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDaB-0005OW-00 for iptel@ietf.org; Mon, 26 Apr 2004 17:24:07 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 1BIDY9-00051M-00; Mon, 26 Apr 2004 17:22:01 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i3QLLMSt004289; Mon, 26 Apr 2004 21:21:22 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Apr 2004 17:21:22 -0400 Message-ID: <4F29BE4689992A4B994A440C3EC924DB012D5450@stntexch01.cis.neustar.com> From: "Yu, James" To: "'Deepak.Pant@utstar.com'" Cc: sipping@ietf.org, iptel@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Iptel] RE: Question about draft-yu-tel-url-08.txt Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 17:21:21 -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.6 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Deepak, Sorry that I saw your questions just now. Please see responses below. James -----Original Message----- From: Deepak.Pant@utstar.com [mailto:Deepak.Pant@utstar.com] Sent: Friday, March 19, 2004 8:53 AM To: sipping@ietf.org; iptel@ietf.org; james.yu@neustar.biz Subject: Question about draft-yu-tel-url-08.txt I have the following questions about conveying carrier identitification code in SIP. On the ISUP side we get three information 1. Type of network identification 2. Network identification plan(3 digits or 4 digits) 3. Digits 1-3 or 1-4 Q1. The draft draft-yu-tel-url-08.txt provides a mechanism to convey the digit information on the sip network. However how do we convey the type of network identification information on the SIP network. [YU] I guess that you were referring to the carrier selection info. parameter. I'm working with other co-authors to propose tel URI parameters such as the dail around indicator (dai) that would indicate the type of cic. Q2. On a UAS receiving an INVITE message with cic=+11234 or cic=1234, what is the difference between the two cic information. Does this mean something different needs to be conveyed on the ISUP side. [YU] If the cic does not begin with "+" it should have a "cic-content=+1" if cic=1234. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Thu Apr 29 17:18:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02546 for ; Thu, 29 Apr 2004 17:18:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJInj-0003CG-BN for iptel-archive@odin.ietf.org; Thu, 29 Apr 2004 17:10:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TLAZxk012288 for iptel-archive@odin.ietf.org; Thu, 29 Apr 2004 17:10:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJIYs-00035F-Rk for iptel-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 16:55:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00065 for ; Thu, 29 Apr 2004 16:55:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJIYl-0004Wf-Mt for iptel-web-archive@ietf.org; Thu, 29 Apr 2004 16:55:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJIX3-0004E6-00 for iptel-web-archive@ietf.org; Thu, 29 Apr 2004 16:53:22 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJIVs-00043W-01 for iptel-web-archive@ietf.org; Thu, 29 Apr 2004 16:52:08 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJIMr-0000Wp-FM for iptel-web-archive@ietf.org; Thu, 29 Apr 2004 16:42:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHhb-00072n-EZ; Thu, 29 Apr 2004 16:00:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHYc-0004eS-Cv for iptel@optimus.ietf.org; Thu, 29 Apr 2004 15:50:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24456; Thu, 29 Apr 2004 15:50:50 -0400 (EDT) Message-Id: <200404291950.PAA24456@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: iptel@ietf.org From: Internet-Drafts@ietf.org Subject: [Iptel] I-D ACTION:draft-ietf-iptel-cpl-09.txt Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 15:50:50 -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.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : CPL: A Language for User Control of Internet Telephony Services Author(s) : J. Lennox, et al. Filename : draft-ietf-iptel-cpl-09.txt,.ps,.pdf Pages : 83 Date : 2004-4-29 The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agent servers. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. This document is a product of the IP Telephony (IPTEL) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at iptel@ietf.org and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-cpl-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-cpl-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-29154412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-cpl-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-cpl-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-29154412.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel