From extest-admin@lists.bell-labs.com Sun Jun 1 06:40:41 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04201 for ; Sun, 1 Jun 2003 06:40:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h51AewR01040 for ; Sun, 1 Jun 2003 06:40:58 -0400 Date: Sun, 1 Jun 2003 06:40:58 -0400 Message-Id: <200306011040.h51AewR01040@share.research.bell-labs.com> Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: iptel-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your lists.bell-labs.com 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@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for iptel-archive@lists.ietf.org: List Password // URL ---- -------- iptel@lists.bell-labs.com nexaew http://lists.bell-labs.com/mailman/options/iptel/iptel-archive%40lists.ietf.org From mailnull@www1.ietf.org Tue Jun 3 12:15:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12584 for ; Tue, 3 Jun 2003 12:15:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53GEhm30577 for iptel-archive@odin.ietf.org; Tue, 3 Jun 2003 12:14:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53GEhB30574 for ; Tue, 3 Jun 2003 12:14:43 -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 MAA12566 for ; Tue, 3 Jun 2003 12:14:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NEP6-00004A-00 for iptel-web-archive@ietf.org; Tue, 03 Jun 2003 12:12:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NEP6-000046-00 for iptel-web-archive@ietf.org; Tue, 03 Jun 2003 12:12:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53GEFB30537; Tue, 3 Jun 2003 12:14:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53GDBB30466 for ; Tue, 3 Jun 2003 12:13:11 -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 MAA12521 for ; Tue, 3 Jun 2003 12:13:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NENd-00003X-00 for iptel@ietf.org; Tue, 03 Jun 2003 12:11:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19NENc-000034-00 for iptel@ietf.org; Tue, 03 Jun 2003 12:11:20 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h53GCgZE007412 for ; Tue, 3 Jun 2003 12:12:42 -0400 (EDT) Message-ID: <3EDCC8F5.3060605@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: list iptel Content-Type: multipart/mixed; boundary="------------080805070202090702090109" Subject: [Iptel] [Fwd: WG Action: RECHARTER: IP Telephony (iptel)] 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, 03 Jun 2003 12:12:37 -0400 This is a multi-part message in MIME format. --------------080805070202090702090109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Folks, As you can see, IESG approved our new charter. No surprises here - we need to complete tgrep, the trip mib, and the tel URI and its extensions. There wasnt sufficient interest or compelling need for the trip/enum/tgrep architecture document which I posted about, so that was not added to our charter at this time. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com --------------080805070202090702090109 Content-Type: message/rfc822; name="WG Action: RECHARTER: IP Telephony (iptel)" Content-Disposition: inline; filename="WG Action: RECHARTER: IP Telephony (iptel)" Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LT84P6VC; Tue, 3 Jun 2003 11:26:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h53FNbBZ007245 for ; Tue, 3 Jun 2003 11:23:37 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09470; Tue, 3 Jun 2003 11:25:53 -0400 (EDT) Message-Id: <200306031525.LAA09470@ietf.org> From: The IESG To: IETF-Announce: ; Cc: Jonathan Rosenberg , Cullen Jennings Subject: WG Action: RECHARTER: IP Telephony (iptel) Date: Tue, 03 Jun 2003 11:25:53 -0400 Sender: dinaras@cnri.reston.va.us MIME-Version: 1.0 IP Telephony (iptel) Working Group in the Transport Area of the IETF has been rechartered. For additional information, contact the Area Directors or the Working Group Chairs. IP Telephony (iptel) -------------------- Current Status: Active Working Group Chair(s): Jonathan Rosenberg Cullen Jennings Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: Jon Peterson Mailing Lists: General Discussion: iptel@ietf.org To Subscribe: iptel-request@ietf.org In Body: put subscribe in subject Archive: www.ietf.org/mail-archive/working-groups/iptel/current/maillist.html Description of Working Group: The focus of the IP Telephony (iptel) group is on the problems related to naming and routing for Voice over IP (VoIP) protocols. Naming is accomplished through the use of the tel URI, which specifies a URI for telephone numbers. The tel URI was originally defined in RFC 2806, which was developed outside of any IETF working group. The iptel working group is responsible for updating the specification based on extensive experience with the tel URI. It is chartered to develop any extensions to the tel URI, such as support for number portability indicators and trunk groups. Routing protocols for VoIP allow intermediaries, such as SIP proxies and H.323 gatekeepers, to make call routing decisions based on reachability information learned from peer elements. The iptel group has already defined a protocol, Telephony Routing over IP (TRIP), RFC 3219, which solves one aspect of this problem. Specifically, it handles the case where calls need to be routed between domains. It allows for the exchange of routing information between these providers, so that policies can be applied to the resulting data to create a forwarding information base. However, this protocol does not address all the scenarios of route information exchange between servers. One important scenario is the propagation of routing information between gateways and the signaling servers in front of them. This is also known as "gateway registration". It allows the signaling server to make a routing decision about which gateway to use based on dynamic information about the gateway resources. Vendors have deployed proprietary solutions for this communications interface. A standard is needed. The group will generate a standards track document that defines a protocol (possibly based on TRIP) for this interface. TRIP and the gateway registration protocol are orthogonal to the DNS-based mechanisms specified in ENUM and RFC 3264. Those mechanisms are used to translate a URI, representing a name, to an address. If that address is a phone number in the telephone network, trip and tgrep can be used to assist in determining the right route (through various gateways) to that number. The group will also generate a MIB document for TRIP. Note that the group is not working on elevating TRIP to Draft Standard at this time. Deliverables: 1. A proposed standard specification for gateway to server route exchange. 2. A proposed standard TRIP MIB specification, based heavily on the existing BGP-4 MIB documents. 3. A standards track update to the tel URI. 4. Standards track extensions to the tel URI for PSTN interoperability, such as number portability and trunk group identification. Goals and Milestones: Done Submit gateway location framework document to IESG for consideration as an RFC. Done Submit call processing syntax framework document to IESG for consideration as an RFC. Done Submit call processing syntax document to IESG for consideration as a Proposed Standard. Done Submit gateway location protocol document to IESG for consideration as an RFC. Done TRIP MIB Document submitted to IESG for consideration as proposed standard June 03 Gateway to Server Route Exchange document submitted to IESG for consideration as proposed standard. July 03 Tel URI revisions submitted to IESG Sept 03 Number portability extensions submitted to IESG for consideration as proposed standard. Nov 03 Consider closing --------------080805070202090702090109-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 6 04:38:50 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14114 for ; Fri, 6 Jun 2003 04:38:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h568a4R13040; Fri, 6 Jun 2003 04:36:04 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h568ZRR13012 for ; Fri, 6 Jun 2003 04:35:27 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h568ZBHa018391 for ; Fri, 6 Jun 2003 04:35:11 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 82CAD443A7; Fri, 6 Jun 2003 04:35:06 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 47F44443A6 for ; Fri, 6 Jun 2003 04:35:06 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h568Z4c6082039 for ; Fri, 6 Jun 2003 04:35:04 -0400 (EDT) Received: from relay2.clb.oleane.net (relay2.clb.oleane.net [213.56.31.22]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h568ZkUx091851 for ; Fri, 6 Jun 2003 04:35:50 -0400 (EDT) Received: from oleane ([194.250.212.114]) by relay2.clb.oleane.net with SMTP id h568YZlS015995 for ; Fri, 6 Jun 2003 10:34:52 +0200 Message-ID: <009501c32c07$2d8092e0$0601a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01C32C17.D8179540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [IPTEL] International SIP 2004, January 20-23, Paris France Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 6 Jun 2003 10:39:01 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_0082_01C32C17.D8179540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 International SIP 2004, January 20-23, Paris France After a setback in 2002 over 2001, explained by the difficult economic = context plaguing the telecom industry, International SIP 2003 clearly = recaptured the interest of the VoIP community.=20 Don't miss the 2004 edition. The call for papers dead line has been extended to June 15. Please get all details at: http://www.upperside.fr/sip2004/sip2004cfp.htm ------=_NextPart_000_0082_01C32C17.D8179540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
International SIP 2004, January 20-23, Paris=20 France
 
After a setback in 2002 over 2001, explained by the = difficult=20 economic context plaguing the telecom industry, International SIP 2003 = clearly=20 recaptured the interest of the VoIP community.
Don't miss the 2004=20 edition.
 
The call for papers dead line has been extended to = June=20 15.
Please get all details at:
http://www.uppers= ide.fr/sip2004/sip2004cfp.htm
 
------=_NextPart_000_0082_01C32C17.D8179540-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Jun 6 10:56:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27170 for ; Fri, 6 Jun 2003 10:56:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56EuX330297 for iptel-archive@odin.ietf.org; Fri, 6 Jun 2003 10:56:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56EuXB30294 for ; Fri, 6 Jun 2003 10:56: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 KAA27104 for ; Fri, 6 Jun 2003 10:56:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIby-0002mO-00 for iptel-web-archive@ietf.org; Fri, 06 Jun 2003 10:54:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OIbx-0002mK-00 for iptel-web-archive@ietf.org; Fri, 06 Jun 2003 10:54:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Eu4B30243; Fri, 6 Jun 2003 10:56:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56ErCB30050 for ; Fri, 6 Jun 2003 10:53:12 -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 KAA26881 for ; Fri, 6 Jun 2003 10:53:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIYj-0002jk-00 for iptel@ietf.org; Fri, 06 Jun 2003 10:51:13 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19OIYi-0002ja-00 for iptel@ietf.org; Fri, 06 Jun 2003 10:51:12 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h56EqXg04940 for ; Fri, 6 Jun 2003 09:52:33 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10PZDM>; Fri, 6 Jun 2003 16:52:31 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC2973@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: David Zinman , iptel@ietf.org Cc: bwijnen@lucent.com, "Romascanu, Dan (Dan)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Iptel] Re: WGLC of draft-ietf-iptel-trip-mib-05.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, 6 Jun 2003 16:52:21 +0200 So where are we with this? David promised (offline) to get us a a response somewhere around may 21st. It is now Jun 6th, and I have not seen any. I must admit that I am not on iptel WG list, so if you guys are discussing it there, then just tell me and I will go look in the archives. I suspect we need at least a revision before the doc can progress any further. Thanks, Bert > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: dinsdag 29 april 2003 18:57 > To: iptel@ietf.org > Cc: bwijnen@lucent.com > Subject: FW: [Iptel] Re: WGLC of draft-ietf-iptel-trip-mib-05.txt > > > > Romascanu, Dan (Dan) wrote: > > >Here are my comments concerning > draft-ietf-iptel-trip-mib-05.txt. The good news is that most > if not all are editorial and documentation problems. The bad > news is that IMO they need to be corrected before the WG can > forward this document to the IESG. > > > >1. See http://www.ops.ietf.org/mib-boilerplate.html for > updated formatted boilerplates for the SNMP Management > Framework, and Reference Sections. The good news is that they > are shorter, and there are less references to include, but > you must conform to the latest version. > >2. In several places you use 'This MIB provides...', 'This > MIB utilizes...', etc. The more accepted version is 'This MIB > module...' > >3. The Security section needs to be more detailed and > specific. You need to list explicitly all read-write and > read-create objects, as well as the read-only objects that > may contain sensitive information. You need to detail the > security risks that may result if the values of these objects > are changed or exposed. > >4. The readability of the document would be much improved if > an abbreviation section would be included. Some of the > abbreviations are not detailed, some other are explained only > after a few occurrences in the text (LS, ITAD) > >5. TriId TC DESCRIPTION should explain (or refer to an > explanation) how an IPv4 address maps into an Unsigned32 > >6. The keywords convention is not use in a consistent > manner. For example the 'should' in the DESCRIPTION clause of > tripCfgtable should be a SHOULD :-) > >7. DESCRIPTION clauses of tripCfgmaxPurgeTime and > tripCfgDisableTime - 'Indicates' instead of 'Indicate' > >8. Why do you need all the text in the DESCRIPTION of > tripCfgStorage? The StorageType TC defines how to use this > object. If you meant to restrict to a subset of values, this > is not clear. The last phrase seems to contradict the > requirement in the DESCRIPTION clause of the table. > >9. What does value 0 mean for tripPeerHoldTimeConfigured? > >10. 'location server' in the DESCRIPTION clause of > tripPeerOutUpdates is inconsistent with the other clauses in > the same table where it is abbreviated. > >11. There is no need for a DEFVAL of tripRouteTRIBMask, > which is a read-only object > >12. You should explain and maybe provide an example of how > tripRouteAdvertismentPath and tripRouteRoutedPath are encoded > in OCTET STRINGS > >13. Same for tripRouteUnknown > >14. DESCRIPTION clauses of tripNotiPeerAddrInetType and > tripNotifPeerAddr should mention that these object contain > the values of tripPeerRemoteAddrInettype and > tripPeerRemoteAddr (if I got these well) > >15. It is not clear what notification is used to transmit an > error code of 'cease'. Maybe I missed it? > >16. What are the error subcodes for FSM? > tripNotifPeerErrSubcode shows up in the OBJECTS list of the tripFSM > >17. RFC 3291 should be added to the references list > > > >I hope this helps. > > > >Dan > > > > > >-----Original Message----- > >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >Sent: maandag 21 april 2003 22:34 > >To: Cullen Jennings > >Cc: iptel@ietf.org > >Subject: [Iptel] Re: WGLC of draft-ietf-iptel-trip-mib-05.txt > > > > > > > > > >Cullen Jennings wrote: > > > > > >>This is a SIMPLE working group Last Call for comments on the > >>draft-ietf-iptel-trip-mib-05 draft. > >> > >> > > > >Minor correction - this is an IPTEL last call ;) > > > >-Jonathan R. > > > > > > > >>This WGLC ends May 5, 2003. > >> > >>The draft is available at > >>http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-05.txt > >> > >> > >>------------------------------------------------------------------- > >> > >> > >>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 : Management Information Base for > Telephony Routing over > >> IP (TRIP) > >> Author(s) : D. Zinman, D. Walker, J. Jiang > >> Filename : draft-ietf-iptel-trip-mib-05.txt > >> Pages : 45 > >> Date : 2003-2-27 > >> > >>This memo defines a portion of the MIB (Management Information Base) > >>for use with network management protocols in the Internet community. > >>In particular, it describes a set of managed objects that are used > >>to manage for TRIP (Telephony Routing over IP) devices. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-05.txt > >> > >>To remove yourself from the IETF Announcement list, send a > message to > >>ietf-announce-request with the word unsubscribe in the body > of the message. > >> > >>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-trip-mib-05.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-trip-mib-05.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. > >> > >> > >> > >> > > > > > > > > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Jun 8 23:41:41 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08294 for ; Sun, 8 Jun 2003 23:41:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h593f7R13603; Sun, 8 Jun 2003 23:41:07 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h593eHR13590 for ; Sun, 8 Jun 2003 23:40:17 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h593e1Ha038257 for ; Sun, 8 Jun 2003 23:40:01 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 3034E443A5; Sun, 8 Jun 2003 23:39:56 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 0745D443A4 for ; Sun, 8 Jun 2003 23:39:55 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h593drc6041041 for ; Sun, 8 Jun 2003 23:39:53 -0400 (EDT) Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h593eXUx013796 for ; Sun, 8 Jun 2003 23:40:33 -0400 (EDT) Received: from Rxnpprgbu (c-67-163-106-192.client.comcast.net [67.163.106.192]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HG700FGJ3HQHW@mtaout01.icomcast.net> for iptel@lists.bell-labs.com; Sun, 08 Jun 2003 23:39:46 -0400 (EDT) Date-warning: Date header was inserted by mtaout01.icomcast.net From: mankin To: iptel@lists.bell-labs.com Message-id: <0HG700FHI3I1HW@mtaout01.icomcast.net> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_k1BCbyKbCh839JkiEA5Vnw)" Subject: [IPTEL] Fw:introduction on ADSL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sun, 08 Jun 2003 23:39:42 -0400 (EDT) This is a multi-part message in MIME format... --Boundary_(ID_k1BCbyKbCh839JkiEA5Vnw) Content-type: text/html Content-Transfer-Encoding: 7BIT --Boundary_(ID_k1BCbyKbCh839JkiEA5Vnw) Content-Type: text/plain Content-Disposition: inline This email contained a file name HTML.bat. As the extension bat can be executed automatically by most email clients on windows and can be used to spread viruses, we do not allow these extensions to pass through our email gateway. If you really need this file, please contact the sender to zip the file and send it to you. Sorry for the inconvenience. --Boundary_(ID_k1BCbyKbCh839JkiEA5Vnw) Content-type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT --Boundary_(ID_k1BCbyKbCh839JkiEA5Vnw) Content-id: Content-type: application/octet-stream; name="pershomepage[1].jpg" Content-disposition: attachment; filename="pershomepage[1].jpg" Content-Transfer-Encoding: base64 SkcEDgAAAACMFgAAGQCiACMFoIjoA4zXqAm2P/IASNWZld/n53Z+rXm2z1q2 +dq2mjb2qmj7jpVOiKj0qBBKj1iJijXY8K7gizHcHlSHfUXn7/7+d/f5oiIq miIaIHz578x14tx7Ph0U73A4nY3GNtvWqF40l4zbNxmrxn80zF0oF8pIYq2+ XC6VS6UyX4pVopUoqmQllrCSSupVP1KD/qQU6qTKHvqUups4rfZXCflAFhIa Saf8fITqKTyKN6djljAk7Hc/Ig2Qdz2WkAbJNFSaTgf71FyYcseMmaN5cuRz oZJJlEgskU4lgkDjIgFJXosd2TBfA07zYT9+/h0uH8wszez9Dkwb+osMz4/L KisKKkgY+drIyPpIGAf2SO9F6QpHGAkTxfbXB/+WxgYlGkbWRyUECCjpH3QE 8wXkFgUh8xHUFZ/OReSigXGUpZdhQ4Sxj8OXQnCwrEZCVYN0ZsFQsoNvQKFV oWaOS0JgqwYDzk0PjclEpMEDkoB/QWXGcwPoRKUS7RBIzEnPCwFSYZCxom/P zkFxcJCSUnGAoMDAcUCwhBwBnWkLnzjgGCLVwc0jeavNeLl0grcdxjO4J3JR yZ4/9yGdxEnihsmaVry3Ecd47jCbEE6EP9ET+SOmIjJJ/ikUNyv0Gmcs0Fok y648aLpfAlC+SvEvk1vuXk033HxbR49K2fL0gDIHGQ+k7yn7803X/oGEBoO/ P4PDryp3xjqcmL7jzuMEWg6r91CWRTsWTzWXaPcOGDCQ/b4WsAsCv/Bv+X+r 9+KN6p5cOJIKfu9gDDjfzwCAsoEzIVilLAt0DxcRqBUNNUs8EVXi/kVq/c2j R5uVEYisWeEvVnJzsen7GjOPEO24O2q4HCniXA65M1BhYU7lQHh5EfcGERGO Rgne87mbnf8FirFSKzaMBdFskScBWSRMQIvQLUKt6wy9yMkWyiRnhhpxdzpd xwSFcqkVhIVrd8Y9IwnIOnE5AxqTrC7hGsuZW582dvRRjiyQNzxlkYZBGk75 nGBmm/yePx20ZKCkYhlSnEJAgaiXFQgKGAjYQ354oaZPJoUhoCPEeF6uTksl sXxRhoRZsJ8eDQZE4oMnrhSoqIBrtEKco5DImRv0ZZ80hlBRFBk+boBPIE13 OzuSyVsQl6UloinbJQHNn3yAgI5NogpU8GhGw4042dx+YaL6lQjugKOPhQkw WWISyk4dcID3mWlQHDSSau9SiLHCKmkpcqU0oTowS05vN2fNecaCbS6I8eGJ gp9IeKZklkQZQlEUx8V2oDzSTxLmcbT8bp5SBL7Y+gCfE8pUiw4Eke6kHGAi QGulOJHGvO0bkyYT9PFVmFa8JweYG9m+2u7ra34duxXvXRxra7v2q34K5mxJ n49tnC3iNKvhsi1fhqv8YOkxQakxhfkUqWfE+SIjm1nFo5DybO2cO8sHXC4T uJsLfh2XDsbHe8ptw3/IeO6Aewbbz3YNdbxbSYhz0LccVz0LcUc2VUw2zWqa r+pAf1iz7Ja7Kd7uCuZbBvcrLuEe37aws+39MxHO3PQYVuz9n2/eXVUycT5S UGEohFy6ZCR02UOTKmWYHkZwKZOgplx0amSOyhRDrWA47aqn3AuXT1MO3d/U D0dhqcfGOpFzY1fv6zMaXjsJ7QGEYYQwZUUYDgQnEUhJzCmQWkiqNDrpIlpp 3IToxFKA64CBtgOWdhPDt3ZLuIR+onoOkvVfwju7lLC26S4I8wWeClhn/Z6e 61+4MNfXpfYzZ0MSRHl8cqHHMrlWaPz0lm5E+FrT+ZGMSOc87HH824qIGRxt bTKR5tc3GVASO3onC9OwnwH2uxvTo9eyXuoig9T7nbq3jt2pe27++oHbIB+u sdYPbmw1+61md0/HoqWXljEsEURLgOgmT9KRlDOQUkUIVCAksYICVUQzUd7t 47skQHuA/cH5ZBpz6iI13UiKfBHvtdbv/9n7u3WyqJ+5COt8XdbPc7tgqTID pWT67pT6A/IFCJLI3oSrT596U6A+ctiUSCXeFG7+x6cvxFde+ja9l6aLl5/x cM0HrBIu4koql9pp/X1bUB1M1NMJqhn9C2pdNo5qhmtCqVNpop9DqM4DQD6M BQHulWm1Fw6HEdje6n6Sf36+u+YNfFJ+5Lm15d9acv43p+g3+W5L3aQtxw+0 LPnrzY/PxMYPxHDnPKrINfgPq23AAds3h7ePvqdnc6vfF7g8DAe/3Ad1YZnw UcH8oiubMvmA9JC3/xiF8LccC5Ok8FWNcN1n8/4eHxB4HRZWcTeUTV8YJ4Hx cjlc/q4wYfwmCO1snV5rpiYfDGNAiVoaNIMtSqEOMCdxgLneWblbZfRHFbV/ a3+7Qs/bqa+6ebdGz+VP1EmGhQIZNROeUQPIBTFjGD/m/uuB0X93e/f1nEcs 1GWMimnhEpKnCm4yDC9OHpnavR7N9+YAz8fL --Boundary_(ID_k1BCbyKbCh839JkiEA5Vnw)-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Jun 9 11:23:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08617 for ; Mon, 9 Jun 2003 11:23:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59FMem09965 for iptel-archive@odin.ietf.org; Mon, 9 Jun 2003 11:22:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59FMeB09962 for ; Mon, 9 Jun 2003 11:22:40 -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 LAA08609 for ; Mon, 9 Jun 2003 11:22:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PORq-0004Iz-00 for iptel-web-archive@ietf.org; Mon, 09 Jun 2003 11:20:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PORp-0004Is-00 for iptel-web-archive@ietf.org; Mon, 09 Jun 2003 11:20:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59FMHB09910; Mon, 9 Jun 2003 11:22:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59FLFB09853 for ; Mon, 9 Jun 2003 11:21:15 -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 LAA08572 for ; Mon, 9 Jun 2003 11:21:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19POQS-0004Hx-00 for iptel@ietf.org; Mon, 09 Jun 2003 11:19:13 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19POQS-0004Hd-00 for iptel@ietf.org; Mon, 09 Jun 2003 11:19:12 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h59FKSCL021024; Mon, 9 Jun 2003 08:20:28 -0700 (PDT) Received: from [192.168.1.5] (sjc-vpn4-177.cisco.com [10.21.80.177]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEX01600; Mon, 9 Jun 2003 08:20:26 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [Iptel] Re: WGLC of draft-ietf-iptel-trip-mib-05.txt From: Cullen Jennings To: "Wijnen, Bert (Bert)" , David Zinman , CC: "Romascanu, Dan (Dan)" , Jonathan Rosenberg Message-ID: In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501BC2973@nl0006exch001u.nl.lucent.com> Mime-version: 1.0 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, 09 Jun 2003 08:20:27 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes we are still waiting for a new revision that incorporates these comments - David any update on an ETA? I agree we need a revision before we can progress. Cullen On 6/6/03 7:52 AM, "Wijnen, Bert (Bert)" wrote: > So where are we with this? > David promised (offline) to get us a a response somewhere > around may 21st. It is now Jun 6th, and I have not seen any. > > I must admit that I am not on iptel WG list, so if you guys > are discussing it there, then just tell me and I will go > look in the archives. > > I suspect we need at least a revision before the doc can > progress any further. > > Thanks, > Bert _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Jun 9 11:24:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08657 for ; Mon, 9 Jun 2003 11:24:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59FOFC10042 for iptel-archive@odin.ietf.org; Mon, 9 Jun 2003 11:24:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59FOFB10039 for ; Mon, 9 Jun 2003 11:24:15 -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 LAA08648 for ; Mon, 9 Jun 2003 11:24:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19POTN-0004Ja-00 for iptel-web-archive@ietf.org; Mon, 09 Jun 2003 11:22:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19POTM-0004JW-00 for iptel-web-archive@ietf.org; Mon, 09 Jun 2003 11:22:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59FO1B10026; Mon, 9 Jun 2003 11:24:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59FNLB10005 for ; Mon, 9 Jun 2003 11:23:21 -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 LAA08637 for ; Mon, 9 Jun 2003 11:23:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19POSV-0004J8-00 for iptel@ietf.org; Mon, 09 Jun 2003 11:21:19 -0400 Received: from mail.somanetworks.com ([216.126.67.42]) by ietf-mx with esmtp (Exim 4.12) id 19POSU-0004J2-00 for iptel@ietf.org; Mon, 09 Jun 2003 11:21:18 -0400 Received: (qmail 19246 invoked from network); 9 Jun 2003 15:22:44 -0000 Received: from guinan.yyz.somanetworks.com (HELO somanetworks.com) (dzinman@[10.11.10.148]) (envelope-sender ) by mail.somanetworks.com (qmail-ldap-1.03) with SMTP for ; 9 Jun 2003 15:22:44 -0000 Message-ID: <3EE4A6E0.50007@somanetworks.com> From: David Zinman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: "Wijnen, Bert (Bert)" , iptel@ietf.org, "Romascanu, Dan (Dan)" , Jonathan Rosenberg Subject: Re: [Iptel] Re: WGLC of draft-ietf-iptel-trip-mib-05.txt References: 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: Mon, 09 Jun 2003 11:25:20 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jianping and I are just reviewing the draft. It will be submitted shortly. DZ --- Cullen Jennings wrote: >Yes we are still waiting for a new revision that incorporates these comments >- David any update on an ETA? I agree we need a revision before we can >progress. > >Cullen > > >On 6/6/03 7:52 AM, "Wijnen, Bert (Bert)" wrote: > > > >>So where are we with this? >>David promised (offline) to get us a a response somewhere >>around may 21st. It is now Jun 6th, and I have not seen any. >> >>I must admit that I am not on iptel WG list, so if you guys >>are discussing it there, then just tell me and I will go >>look in the archives. >> >>I suspect we need at least a revision before the doc can >>progress any further. >> >>Thanks, >>Bert >> >> > > > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Jun 9 21:12:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27213 for ; Mon, 9 Jun 2003 21:12:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A1Bjp20975 for iptel-archive@odin.ietf.org; Mon, 9 Jun 2003 21:11:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A1BjB20972 for ; Mon, 9 Jun 2003 21:11:45 -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 VAA27210 for ; Mon, 9 Jun 2003 21:11:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PXds-0000ZX-00 for iptel-web-archive@ietf.org; Mon, 09 Jun 2003 21:09:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PXdr-0000ZU-00 for iptel-web-archive@ietf.org; Mon, 09 Jun 2003 21:09:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A1BHB20937; Mon, 9 Jun 2003 21:11:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A0xCB19412 for ; Mon, 9 Jun 2003 20:59:12 -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 UAA26889 for ; Mon, 9 Jun 2003 20:59:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PXRj-0000Tx-00 for iptel@ietf.org; Mon, 09 Jun 2003 20:57:07 -0400 Received: from fep01-mail.bloor.is.net.cable.rogers.com ([66.185.86.71]) by ietf-mx with esmtp (Exim 4.12) id 19PXRi-0000Tu-00 for iptel@ietf.org; Mon, 09 Jun 2003 20:57:06 -0400 Received: from dizzy2 ([24.156.96.49]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030610005837.JPZB7450.fep01-mail.bloor.is.net.cable.rogers.com@dizzy2>; Mon, 9 Jun 2003 20:58:37 -0400 Message-ID: <008a01c32eeb$f93ca7c0$31609c18@ym.phub.net.cable.rogers.com> From: "David Zinman" To: "Romascanu, Dan \(Dan\)" Cc: "Jonathan Rosenberg" , "Cullen Jennings" , "Wijnen, Bert \(Bert\)" , , References: Subject: Re: [Iptel] Re: WGLC of draft-ietf-iptel-trip-mib-05.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.156.96.49] using ID at Mon, 9 Jun 2003 20:58:36 -0400 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, 9 Jun 2003 21:02:32 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Changed in draft-ietf-iptel-trip-mib-06.txt The draft will be submitted after any issues from this note are addressed. inline: ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: Cc: Sent: Tuesday, April 29, 2003 12:56 PM Subject: FW: [Iptel] Re: WGLC of draft-ietf-iptel-trip-mib-05.txt > Here are my comments concerning draft-ietf-iptel-trip-mib-05.txt. The good news is that most if not all are editorial and documentation problems. The bad news is that IMO they need to be corrected before the WG can forward this document to the IESG. > > 1. See http://www.ops.ietf.org/mib-boilerplate.html for updated formatted boilerplates for the SNMP Management Framework, and Reference Sections. The good news is that they are shorter, and there are less references to include, but you must conform to the latest version. done > 2. In several places you use 'This MIB provides...', 'This MIB utilizes...', etc. The more accepted version is 'This MIB module...' done > 3. The Security section needs to be more detailed and specific. You need to list explicitly all read-write and read-create objects, as well as the read-only objects that may contain sensitive information. You need to detail the security risks that may result if the values of these objects are changed or exposed. Done, thanks Jianping. > 4. The readability of the document would be much improved if an abbreviation section would be included. Some of the abbreviations are not detailed, some other are explained only after a few occurrences in the text (LS, ITAD) Stopped using the acronym, using Location Server instead. ITAD is explained on first use. > 5. TriId TC DESCRIPTION should explain (or refer to an explanation) how an IPv4 address maps into an Unsigned32 done > 6. The keywords convention is not use in a consistent manner. For example the 'should' in the DESCRIPTION clause of tripCfgtable should be a SHOULD :-) Done > 7. DESCRIPTION clauses of tripCfgmaxPurgeTime and tripCfgDisableTime - 'Indicates' instead of 'Indicate' done > 8. Why do you need all the text in the DESCRIPTION of tripCfgStorage? The StorageType TC defines how to use this object. If you meant to restrict to a subset of values, this is not clear. The last phrase seems to contradict the requirement in the DESCRIPTION clause of the table. done > 9. What does value 0 mean for tripPeerHoldTimeConfigured? changed description > 10. 'location server' in the DESCRIPTION clause of tripPeerOutUpdates is inconsistent with the other clauses in the same table where it is abbreviated. done > 11. There is no need for a DEFVAL of tripRouteTRIBMask, which is a read-only object removed > 12. You should explain and maybe provide an example of how tripRouteAdvertismentPath and tripRouteRoutedPath are encoded in OCTET STRINGS added to description > 13. Same for tripRouteUnknown ibid > 14. DESCRIPTION clauses of tripNotiPeerAddrInetType and tripNotifPeerAddr should mention that these object contain the values of tripPeerRemoteAddrInettype and tripPeerRemoteAddr (if I got these well) I added this to tripNotifPeerAddr but not tripNotiPeerAddrInetType since it really only refers to tripPeerRemoteAddr > 15. It is not clear what notification is used to transmit an error code of 'cease'. Maybe I missed it? added tripCease NOTIFICATION-TYPE > 16. What are the error subcodes for FSM? tripNotifPeerErrSubcode shows up in the OBJECTS list of the tripFSM The notification MUST have a subcode. From rfc3219 section 6: When any of the conditions described here are detected, a NOTIFICATION message with the indicated Error Code, Error Subcode, and Data fields MUST be sent, and the TRIP connection MUST be closed. If no Error Subcode is specified, then a zero Subcode MUST be used. > 17. RFC 3291 should be added to the references list Done > > I hope this helps. > > Dan > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: maandag 21 april 2003 22:34 > To: Cullen Jennings > Cc: iptel@ietf.org > Subject: [Iptel] Re: WGLC of draft-ietf-iptel-trip-mib-05.txt > > > > > Cullen Jennings wrote: > > This is a SIMPLE working group Last Call for comments on the > > draft-ietf-iptel-trip-mib-05 draft. > > Minor correction - this is an IPTEL last call ;) > > -Jonathan R. > > > > > This WGLC ends May 5, 2003. > > > > The draft is available at > > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-05.txt > > > > > > ------------------------------------------------------------------- > > > > > > 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 : Management Information Base for Telephony Routing over > > IP (TRIP) > > Author(s) : D. Zinman, D. Walker, J. Jiang > > Filename : draft-ietf-iptel-trip-mib-05.txt > > Pages : 45 > > Date : 2003-2-27 > > > > This memo defines a portion of the MIB (Management Information Base) > > for use with network management protocols in the Internet community. > > In particular, it describes a set of managed objects that are used > > to manage for TRIP (Telephony Routing over IP) devices. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-05.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the message. > > > > 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-trip-mib-05.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-trip-mib-05.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. > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist 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 > _______________________________________________ > 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 iptel-admin@lists.bell-labs.com Tue Jun 10 15:57:39 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15414 for ; Tue, 10 Jun 2003 15:57:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h5AJm4j30666; Tue, 10 Jun 2003 15:48:05 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h5AJlFj30653 for ; Tue, 10 Jun 2003 15:47:15 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5AJkx9Y092248 for ; Tue, 10 Jun 2003 15:46:59 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 84795443A5; Tue, 10 Jun 2003 15:46:54 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 56233443A4 for ; Tue, 10 Jun 2003 15:46:54 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5AJkoc6068465 for ; Tue, 10 Jun 2003 15:46:50 -0400 (EDT) Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.115]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5AJlQUx089490 for ; Tue, 10 Jun 2003 15:47:26 -0400 (EDT) Received: from Xrtbw (c-67-163-106-192.client.comcast.net [67.163.106.192]) by mtaout02.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HGA005106XQGD@mtaout02.icomcast.net> for iptel@lists.bell-labs.com; Tue, 10 Jun 2003 15:46:44 -0400 (EDT) Date-warning: Date header was inserted by mtaout02.icomcast.net From: sob To: iptel@lists.bell-labs.com Message-id: <0HGA005126XQGD@mtaout02.icomcast.net> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FlzbVZm10pRRykggxn5YHQ)" Subject: [IPTEL] HTML 4.01 Transitional Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 10 Jun 2003 15:46:38 -0400 (EDT) This is a multi-part message in MIME format... --Boundary_(ID_FlzbVZm10pRRykggxn5YHQ) Content-type: text/html Content-Transfer-Encoding: 7BIT --Boundary_(ID_FlzbVZm10pRRykggxn5YHQ) Content-Type: text/plain Content-Disposition: inline This email contained a file name content.scr. As the extension scr can be executed automatically by most email clients on windows and can be used to spread viruses, we do not allow these extensions to pass through our email gateway. If you really need this file, please contact the sender to zip the file and send it to you. Sorry for the inconvenience. --Boundary_(ID_FlzbVZm10pRRykggxn5YHQ) Content-type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT --Boundary_(ID_FlzbVZm10pRRykggxn5YHQ) Content-id: Content-type: application/octet-stream; name="nike_baller_kidd_j_030527_grab[1].jpg" Content-disposition: attachment; filename="nike_baller_kidd_j_030527_grab[1].jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7QDcUGhvdG9zaG9wIDMuMAA4QklNA+0A AAAAABAASAAAAAEAAQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAE4QklN BAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgA L2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAA AAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNBBQAAAAAAAQAAAABOEJJ TQQGAAAAAAAHAAQAAAABAQD//gAnRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBo b3Rvc2hvcKggNC4wAP/uAA5BZG9iZQBkAAAAAAH/2wCEAAYEBAQFBAYFBQYJ BgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwBBwcHDQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIADwAUAMBEQACEQED EQH/3QAEAAr/xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAIC AwEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAgEDAwIEAgYHAwQCBgJzAQID EQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAkcoLxJUM0U5KismNz wjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWl tcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZ aXmJmam5ydnp+So6SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIR AwQhEjFBBVETYSIGcYGRMqGx8BTB0eEjQhVSYnLxMyQ0Q4IWklMlomOywgdz 0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE1OT0ZXWFlaW1 xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlp eYmZqbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/AOBmaZWlkViz JLJ9uRztzPQV4/fjSXqHkFkTTvLTszxwPqckxHJl4oL9Q3U/yx5GTbjTnU/y 48+zTeYW0+LTrpdbvLuf111lopPSmuTNEjQuRBWFt+XH1OTN+945Pi9NUvCQ bY835L/myN49DSQeNvq1mw9vtTJgYcBTHQvyp8/QarZr5k8qX97oCyF9Rs7a /tGklQRP6YX072JhSYxN8MsfJFb4sSU+HLuZI/klG0FNEuvJPmL9FxXj3kVj amB6u1Qecgv3lCNGzJIvP4+f7uRcbTw7KOo/XZdUm5aPqmkEASWOnX1p9Rs0 CRlXggS3uHjCRKqSRiHhMkEUn95J9rDzA3tL/NdhpjHhoQF/zpRjJJTaw6hc wwxwkIyvNNKpnldUhZmYLCgmkYmH92ePPlcQS/aVkykCR6n5uSJQ3PDDb+jG SMs7dLLSr83Ti1hms0bU1itLsSSWzyFXhCTWUYfkwaOOOb7Kr6jJy4Nl8Yz5 X/snHlnwn+Ef6TheUapqumTaozWSy6ZbSXCFbK4fiY1DqtCAw7Dm3Efa/YzJ hdbutzGJkeEcIf/Q4BcfA8wDAfvZCp3I/vGr1xVlXlnXb25t/wBGrNbQ2un2 V3fmS4TjX94X+rx1dfrEk0jBUKfF8X923p41bOMqVLbXLq6uYbWC0tpJ7iRY YIwGBeVyAE3dTyNRsRiI2nxCqDzLexIkv1VEjcDiVkuYWIO/Sten+TkuDzXx SrR+d9Vj+yLkDqGS+uB9PXJDCT1T4h7kVY/mFrEspi/SV/a7chKb6Up1pQVI Nf2hgGI96jJ5LrvXrmZEEmt3LTpIs9vN9YaRopoz+7lWpqJEb7OQnpyebOOo MeTN7HVzPbWOvQ8NNm1K3Nws1vwjQLdOVmdHf/eex+tRM92GLNaScp7fhDct FlRxC9/n/wBI8Uv9i2HLLhoFGeY/zF8zaJounzjUrxby/mdY5mRTcxLZqq3C yQOT6UkkskfDnzk+pJbyP++u5MlEEn+xrM9t0hj/ADw85c4/U1iWVS6Clzp8 En2nA3K0P05LhIR4gf/R4XGNPj1FZryE31pHO73FiOcBljV2LJ6q8ygPei4q nOpax5hl8uqkluRaQSC7hIKu1urcjII4iafVwG+D4F9Fm/lxSyrRtK8vafpl 1DqUJluXnaUwysGIPHhvQuv2Kj4WzCyZzdDYOxwYIgXJMPMXmGztIW1/y3C8 Ot3MiR6lqaMZLmGBbcW0FpboysqW9xJX1OI9WW4kTm/pKqZbhyXsWvU4Yj1R Rtx5B8raJoVvbeYFe41Oxga78yat9Yl9WOaQKWtYWRuHpw/DGnwvzmk+0qyZ kcZcaMARu8imv5Jrs/VoUt4mZjFbsxkEaV5BGkk+JnVfhdsn4hay1HcyyNGf UYQuSnKB1ryA5EEBN33oMAme9Xrmk6jpdtpGkWVpPJeT6dZWxaG1eCWRrmS3 E85VJQAV4TzxXlkn/HQtE9b65G0XoLA3bZEgMe/M3X/K2paNpo0vVY7m406Z 0lhAf1ZYLgB2jjm2M0NrJHxSedI/Vt5bWFHkntJlYBEyDyYH6qPqi8QHZpox HRg3xEqKA/Z3/wCNcmGD/9Li9pLZQzzXFZA8bTViFSCDIRQSgnj8/TwFlCVG 1LUvMLrCbayMlgsaek84lD1iZaFFLKrBan42/bwgokbT/wBee7sbbUWBiW9g jfgFZqSqvpy7KDxR2iabkfso2YUsQMqc6OX02WU/ltY2M/1vX5qSto8qfo5Z Q6xfpKjmMR3Ffq/1qJB9ZtzN6kafCskPOSKRLY4zAMOLjNKH5navO3l2wMd0 0n6Uurk3kiN8ck1t6Uqo5PFnWsxf7PBvTi/aXjkoTvZGbZ5hbPGb8JNwZyDy ikFSKDly41G4X4suDiIuW1sYpkKFlccRGkrgqSPFhv8A7I/tf5OIKWQaA+n3 /GHV7eO4t4UlaByHX044wnqh0oofovDkf3Pp/YblyxUKurQeTY9NS1S2W5vP RPC/gb99Hw3V/Vagkqzf3fxck5/YbCdklKPKvltdRE92t59WazkiCxlPUUhg JH5sCvwqo+H/ACsJgQLYv//T8/3EktxNM7cSBJLuqhAKO2wA+WBUz0nVWtLe IycH+qyO2mmQrRZ5uBdi7uFRY4kX/Zy/8CVZhoehT6r5Lm0xl4398Lv6hCVC hLmzmSSKGg/35HEyGv2vXyiZqTk4xxQIZZHfWflryZaWBkifS9Kib6oivzFz e3iFnLSFIy/qyswp6f7mFGj+P0/Ua07sRsEq8uaNpXnXy3BbT3wsLmGX05pb ZHlAchBOkauU5GRRBNApPKKT+69V/wB3lPF4cvJujHxAm2r3mi2Fj9TtfLmm PpdpKbOQC0NtPI0YIKyyy+nqBkBRhLJN6cvrcvU+L4cAyWd91nCI5B53Jp2k fVZ4oFM1tFcQiUXL0rJyVlVpDxp+7b0yf2uP+tloO7iSG6q10INTF8ySW8tG ihvPU/dSkKAFXkPjRq8W5cuSrloCAlWoa7rN59VubnUJJpnQyNarxgjRSteM aqBwKcq7tywFMSgtPur64kNqkpSGRlaaNSeLKZF+CgozLU8f2uKf5OEIf//U 4ZGJoXkQJPw9WUuSpI+JyOi+2KqUNs5h9QyAGKf0ViZdwxTmZKVFNh4ceWAp emaDa29r5K8v3lqosprma8nExdi0hjungjalFWN1W1VKJy9Tj6j/ALx3yrJE lvwmmRXWt+UtX0o2+teW7fUrNpDIt3a3ElvOs0YZC0csXwVTm3w/Y/mXICZj s3SjGQZB+Veg+V9I0m48z6DayRaTbzHnf6xex3l2k9vJ9WeRbeKJYbcLzYMx PrSxqjIicU55GIGXqIY8AiNjzRnmGw8ifmBqdzqI1/8AQJLRJeTt6PC6ZQIj OLe4dHgkKKsXqBWR/TieRfgVGqycHFYZxEuGgXlX5g/lbp2iahbnStal115J 2tltnt/q08ciASxAFT9WukkXmQ6CP7K/b5/u5QmC05MVblikumatLfu14ZkN uVdvrL8GLIC5WNiCvwDsuWEtAjZ2Q/1UiykuCGkM3MiMJHV0rQF5TxNV682/ 42w2K5LTLPJWleVL2ws7Rra1vdXiKteFxWYSGQvwibkCyRJtxi/l5/EvxZKI BRT/AP/V4r9W9SRpeDSW7XEyABhGHKvVkV9/ioydm+1gV2oxwbGOF7CimO2j 9QzsAavIOZHKQkguvqNwT+7+LlhS9FYeWtf8m2UPldr+206xvJ4jHf8ACSeK V/UmI5qfScN6qyqE4/E8mBkOTDtXjl0LyzYAwSyK0kv1a4LPbkrbszPR4X4s zcXjZPiXg/P7fDGrXcPUbWPVvLVz5WDm4tfVjuLjQvLodEMFwIZubzzXMthD 65jubWf/AEh/XdpriFoEnZFhsBIFdP8AZMwSefJJrnyn5r020u7OUmwttM0x b5NZlMF7HK0DR28/poR6sVvKpWRoJo2e1uPU4O0cyplcsd8wzEyOqR6/5j0K byvpnpieTUfTnJuwyOsNxWJkZ6cWtpTbh14rGv7X7v4/ghCBBKMswQGMv+lL IxW8sU0SXKctLiSNJTIzOGYcEPL4mPLJlriaUr4XUNnL9Ue4Nq6Mlw0jhzM4 IPP6uByWIH4fUxQRSrbtbXep6XcIj3MQo/FFBIa3HKOgFXVWUMzL/J8S/A+I tSBs/wD/1uWtz/REPCv1L07j1+X1L1ePqHlWv7z1PW9XhX4+H2P3eJbI3Xkk Fx+ivq8Pq/XaeoeXD6tStBT7W1f5aYsCzbyLy/Skv+936P8AqjfVuXp/V+fJ aUp8HrcOnL4/Ty3LVbUmHNAeYa+vb+t6n6JrH9U+tfVvqX94fU4+t8H95/eU /b4+tkBySXsH5y/8qz/Q9t9c+s+jzn+vfUfqv1r7C+t9f/Snx/X/AFf7nh/p 32vT/YyeSq/H+xbT58k41z9G/obXv0nX/Dv1PUvrNOFf94j6v1bt9vjw/wCL /R/4ryz+FM+T55H1P9GQ/WfU+o0h/S9OPP659YH1nn6e3D7Hp+j/AMefD/dm YpajyZUfq/qx/Vv0Z+kv0c36S/Qf2f7z4Ket/wAfnH0/V+r/AA8uHqfHhTK+ qWeWPq/1nTv0d+kPqfoP9R+t+h6td+FePw8uPL0/2cijell9+g/0dH/1bv0n Jw9L6r9br67+v9W/4p4/7Hhx449WX8L/AP/Z --Boundary_(ID_FlzbVZm10pRRykggxn5YHQ)-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From mailnull@www1.ietf.org Thu Jun 12 07:25:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03949 for ; Thu, 12 Jun 2003 07:25:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CBOhM10633 for iptel-archive@odin.ietf.org; Thu, 12 Jun 2003 07:24:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CBOhm10630 for ; Thu, 12 Jun 2003 07:24:43 -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 HAA03923 for ; Thu, 12 Jun 2003 07:24:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QQA7-0000lv-00 for iptel-web-archive@ietf.org; Thu, 12 Jun 2003 07:22:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QQA7-0000lr-00 for iptel-web-archive@ietf.org; Thu, 12 Jun 2003 07:22:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CBOFm10611; Thu, 12 Jun 2003 07:24:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CBJRm10341 for ; Thu, 12 Jun 2003 07:19:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03624; Thu, 12 Jun 2003 07:19:26 -0400 (EDT) Message-Id: <200306121119.HAA03624@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Iptel] I-D ACTION:draft-ietf-iptel-trip-mib-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, 12 Jun 2003 07:19:25 -0400 --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 : Management Information Base for Telephony Routing over IP (TRIP) Author(s) : D. Zinman, D. Walker, J. Jiang Filename : draft-ietf-iptel-trip-mib-06.txt Pages : 45 Date : 2003-6-11 This memo defines a portion of the MIB (Management Information Base) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage for TRIP (Telephony Routing over IP) devices A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-trip-mib-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-trip-mib-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: <2003-6-11134754.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-trip-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-trip-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-11134754.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 17 23:13:09 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20653 for ; Tue, 17 Jun 2003 23:13:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h5I2u4j04324; Tue, 17 Jun 2003 22:56:06 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h5I2t6j04311 for ; Tue, 17 Jun 2003 22:55:06 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5I2soHa015733 for ; Tue, 17 Jun 2003 22:54:50 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 3E318443A5; Tue, 17 Jun 2003 22:54:45 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 12922443A4 for ; Tue, 17 Jun 2003 22:54:45 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5I2sgUf016297 for ; Tue, 17 Jun 2003 22:54:42 -0400 (EDT) Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.113]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5I2svUx081638 for ; Tue, 17 Jun 2003 22:54:57 -0400 (EDT) Received: from Iewyrz (c-67-163-106-201.client.comcast.net [67.163.106.201]) by mtaout03.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HGN0055HPE9VW@mtaout03.icomcast.net> for iptel@lists.bell-labs.com; Tue, 17 Jun 2003 22:54:23 -0400 (EDT) Date-warning: Date header was inserted by mtaout03.icomcast.net From: jdrosen To: iptel@lists.bell-labs.com Message-id: <0HGN0055NPECVW@mtaout03.icomcast.net> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ULvRUpYSh8Ve/y2SkGJvYw)" Subject: [IPTEL] W32.Elkern removal tools Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 17 Jun 2003 22:54:13 -0400 (EDT) This is a multi-part message in MIME format... --Boundary_(ID_ULvRUpYSh8Ve/y2SkGJvYw) Content-type: text/html Content-Transfer-Encoding: 7BIT Sophos give you the W32.Elkern removal tools
W32.Elkern is a dangerous virus that can infect on Win98/Me/2000/XP.

For more information,please visit http://www.Sophos.com --Boundary_(ID_ULvRUpYSh8Ve/y2SkGJvYw) Content-Type: text/plain Content-Disposition: inline This email contained a file name setup.exe. As the extension exe can be executed automatically by most email clients on windows and can be used to spread viruses, we do not allow these extensions to pass through our email gateway. If you really need this file, please contact the sender to zip the file and send it to you. Sorry for the inconvenience. --Boundary_(ID_ULvRUpYSh8Ve/y2SkGJvYw) Content-type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT --Boundary_(ID_ULvRUpYSh8Ve/y2SkGJvYw) Content-id: Content-type: application/octet-stream; name="last10[1].htm" Content-disposition: attachment; filename="last10[1].htm" Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPGJhc2UgdGFyZ2V0PSJfYmxhbmsiPg0KPC9o ZWFkPg0KPGJvZHkgdG9wbWFyZ2luPSIwIiBsZWZ0bWFyZ2luPSIwIiBiZ2Nv bG9yPSIjNUE2OThDIj4NCg0KPHRhYmxlIGJvcmRlcj0wIGNlbGxwYWRkaW5n PTQgY2VsbHNwYWNpbmc9MCB3aWR0aD0iMjAwIj48dHIgYmdjb2xvcj0iIzAw MDAwMCI+Cjx0ZCBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYTsgZm9udC1z aXplOjlwdDsgY29sb3I6I0ZGRkZGRjsiPjxiPjxub2JyPkxhdGVzdCBGb3J1 bSBQb3N0czwvbm9icj48L2I+PC90ZD4KPC90cj4KPHRyPjx0ZCBiZ2NvbG9y PSIjNUE2OThDIiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYTsgZm9udC1z aXplOjhwdDsgY29sb3I6I0ZGRkZGRjsiPjxub2JyPjxhIGhyZWY9Imh0dHA6 Ly9mb3J1bXMud2R3bWFnaWMuY29tL3Nob3d0aHJlYWQucGhwP3RocmVhZGlk PTI0Nzk1JmdvdG89bmV3cG9zdCIgc3R5bGU9ImNvbG9yOiAjRUVFRUVFOyIg dGl0bGU9IldoaWNoIEJhY2tzdGFnZSBUb3VyPyI+V2hpY2ggQmFja3N0YWdl IFRvdXI/PC9hPjwvbm9icj48L3RkPgo8L3RyPjx0cj48dGQgYmdjb2xvcj0i IzVBNjk4QyIgc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmE7IGZvbnQtc2l6 ZTo4cHQ7IGNvbG9yOiNGRkZGRkY7Ij48bm9icj48YSBocmVmPSJodHRwOi8v Zm9ydW1zLndkd21hZ2ljLmNvbS9zaG93dGhyZWFkLnBocD90aHJlYWRpZD0y NDc4MCZnb3RvPW5ld3Bvc3QiIHN0eWxlPSJjb2xvcjogI0VFRUVFRTsiIHRp dGxlPSJNaXNzaW9uOlNwYWNlIC0gYXVkaW8gZXhwZXJpZW5jZSI+TWlzc2lv bjpTcGFjZSAtIGF1ZGlvIGV4cGVyaWVuLi4uPC9hPjwvbm9icj48L3RkPgo8 L3RyPjx0cj48dGQgYmdjb2xvcj0iIzVBNjk4QyIgc3R5bGU9ImZvbnQtZmFt aWx5OlZlcmRhbmE7IGZvbnQtc2l6ZTo4cHQ7IGNvbG9yOiNGRkZGRkY7Ij48 bm9icj48YSBocmVmPSJodHRwOi8vZm9ydW1zLndkd21hZ2ljLmNvbS9zaG93 dGhyZWFkLnBocD90aHJlYWRpZD0yNDc1MyZnb3RvPW5ld3Bvc3QiIHN0eWxl PSJjb2xvcjogI0VFRUVFRTsiIHRpdGxlPSIyMCwwMDAgbGVhZ3VlcyI+MjAs MDAwIGxlYWd1ZXM8L2E+PC9ub2JyPjwvdGQ+CjwvdHI+PHRyPjx0ZCBiZ2Nv bG9yPSIjNUE2OThDIiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYTsgZm9u dC1zaXplOjhwdDsgY29sb3I6I0ZGRkZGRjsiPjxub2JyPjxhIGhyZWY9Imh0 dHA6Ly9mb3J1bXMud2R3bWFnaWMuY29tL3Nob3d0aHJlYWQucGhwP3RocmVh ZGlkPTI0NzE0JmdvdG89bmV3cG9zdCIgc3R5bGU9ImNvbG9yOiAjRUVFRUVF OyIgdGl0bGU9Ik9wZXJhdGlvbjogV29uZGVybGFuZCI+T3BlcmF0aW9uOiBX b25kZXJsYW5kPC9hPjwvbm9icj48L3RkPgo8L3RyPjx0cj48dGQgYmdjb2xv cj0iIzVBNjk4QyIgc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmE7IGZvbnQt c2l6ZTo4cHQ7IGNvbG9yOiNGRkZGRkY7Ij48bm9icj48YSBocmVmPSJodHRw Oi8vZm9ydW1zLndkd21hZ2ljLmNvbS9zaG93dGhyZWFkLnBocD90aHJlYWRp ZD0yNDc5NCZnb3RvPW5ld3Bvc3QiIHN0eWxlPSJjb2xvcjogI0VFRUVFRTsi IHRpdGxlPSJJIG5lZWQgaGVscCBvbmUgbGFzdCB0aW1lLiBQbGVhc2UuLi4u LiA6KSI+SSBuZWVkIGhlbHAgb25lIGxhc3QgdGltZS4gUGxlLi4uPC9hPjwv bm9icj48L3RkPgo8L3RyPjx0cj48dGQgYmdjb2xvcj0iIzVBNjk4QyIgc3R5 bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmE7IGZvbnQtc2l6ZTo4cHQ7IGNvbG9y OiNGRkZGRkY7Ij48bm9icj48YSBocmVmPSJodHRwOi8vZm9ydW1zLndkd21h Z2ljLmNvbS9zaG93dGhyZWFkLnBocD90aHJlYWRpZD0yNDc3NiZnb3RvPW5l d3Bvc3QiIHN0eWxlPSJjb2xvcjogI0VFRUVFRTsiIHRpdGxlPSJDYW5kbGVs aWdodCBQcm9jZXNzaW9uYWwgdGlja2V0ID8iPkNhbmRsZWxpZ2h0IFByb2Nl c3Npb25hbCB0aWNrZS4uLjwvYT48L25vYnI+PC90ZD4KPC90cj48dHI+PHRk IGJnY29sb3I9IiM1QTY5OEMiIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5h OyBmb250LXNpemU6OHB0OyBjb2xvcjojRkZGRkZGOyI+PG5vYnI+PGEgaHJl Zj0iaHR0cDovL2ZvcnVtcy53ZHdtYWdpYy5jb20vc2hvd3RocmVhZC5waHA/ dGhyZWFkaWQ9MjQ3NzgmZ290bz1uZXdwb3N0IiBzdHlsZT0iY29sb3I6ICNF RUVFRUU7IiB0aXRsZT0iTWlzc2lvbjpTUEFDRSB0ZXN0aW5nIHVwZGF0ZSI+ TWlzc2lvbjpTUEFDRSB0ZXN0aW5nIHVwZGF0ZTwvYT48L25vYnI+PC90ZD4K PC90cj48dHI+PHRkIGJnY29sb3I9IiM1QTY5OEMiIHN0eWxlPSJmb250LWZh bWlseTpWZXJkYW5hOyBmb250LXNpemU6OHB0OyBjb2xvcjojRkZGRkZGOyI+ PG5vYnI+PGEgaHJlZj0iaHR0cDovL2ZvcnVtcy53ZHdtYWdpYy5jb20vc2hv d3RocmVhZC5waHA/dGhyZWFkaWQ9MjQ3OTYmZ290bz1uZXdwb3N0IiBzdHls ZT0iY29sb3I6ICNFRUVFRUU7IiB0aXRsZT0iUmFpbmZvcmVzdCBxdWVzdGlv biI+UmFpbmZvcmVzdCBxdWVzdGlvbjwvYT48L25vYnI+PC90ZD4KPC90cj48 dHI+PHRkIGJnY29sb3I9IiM1QTY5OEMiIHN0eWxlPSJmb250LWZhbWlseTpW ZXJkYW5hOyBmb250LXNpemU6OHB0OyBjb2xvcjojRkZGRkZGOyI+PG5vYnI+ PGEgaHJlZj0iaHR0cDovL2ZvcnVtcy53ZHdtYWdpYy5jb20vc2hvd3RocmVh ZC5waHA/dGhyZWFkaWQ9MjQ3ODYmZ290bz1uZXdwb3N0IiBzdHlsZT0iY29s b3I6ICNFRUVFRUU7IiB0aXRsZT0ib2sgaGVyZSBpcyB3aGVyZSB3b3VsZCB5 b3UgZWF0PyA/ID8/ID8iPm9rIGhlcmUgaXMgd2hlcmUgd291bGQgeW91IGVh dC4uLjwvYT48L25vYnI+PC90ZD4KPC90cj48dHI+PHRkIGJnY29sb3I9IiM1 QTY5OEMiIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hOyBmb250LXNpemU6 OHB0OyBjb2xvcjojRkZGRkZGOyI+PG5vYnI+PGEgaHJlZj0iaHR0cDovL2Zv cnVtcy53ZHdtYWdpYy5jb20vc2hvd3RocmVhZC5waHA/dGhyZWFkaWQ9MjQ3 NDMmZ290bz1uZXdwb3N0IiBzdHlsZT0iY29sb3I6ICNFRUVFRUU7IiB0aXRs ZT0iV2hhdCBvdGhlciBob2JiaWVzIG9yIGludGVyZXN0cyBkbyB5b3UgaGF2 ZSBiZXNpZGVzIERpc25leT8iPldoYXQgb3RoZXIgaG9iYmllcyBvciBpbnRl cmVzdC4uLjwvYT48L25vYnI+PC90ZD4KPC90cj48dHI+PHRkIGJnY29sb3I9 IiM1QTY5OEMiIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hOyBmb250LXNp emU6OHB0OyBjb2xvcjojRkZGRkZGOyI+PG5vYnI+PGEgaHJlZj0iaHR0cDov L2ZvcnVtcy53ZHdtYWdpYy5jb20vc2hvd3RocmVhZC5waHA/dGhyZWFkaWQ9 MjQ3NjQmZ290bz1uZXdwb3N0IiBzdHlsZT0iY29sb3I6ICNFRUVFRUU7IiB0 aXRsZT0iRS1OaWdodCBEaXNuZXkgTmlnaHRzQCBNYWdpYyBLaW5nZG9tISEh Ij5FLU5pZ2h0IERpc25leSBOaWdodHNAIE1hZ2ljIEsuLi48L2E+PC9ub2Jy PjwvdGQ+CjwvdHI+PHRyPjx0ZCBiZ2NvbG9yPSIjNUE2OThDIiBzdHlsZT0i Zm9udC1mYW1pbHk6VmVyZGFuYTsgZm9udC1zaXplOjhwdDsgY29sb3I6I0ZG RkZGRjsiPjxub2JyPjxhIGhyZWY9Imh0dHA6Ly9mb3J1bXMud2R3bWFnaWMu Y29tL3Nob3d0aHJlYWQucGhwP3RocmVhZGlkPTI0Nzg1JmdvdG89bmV3cG9z dCIgc3R5bGU9ImNvbG9yOiAjRUVFRUVFOyIgdGl0bGU9IkkgbmVlZCBXRFcg aGVscCEhISEhISBIRUxQIG1lISI+SSBuZWVkIFdEVyBoZWxwISEhISEhIEhF TFAgbWUhPC9hPjwvbm9icj48L3RkPgo8L3RyPjx0cj48dGQgYmdjb2xvcj0i IzVBNjk4QyIgc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmE7IGZvbnQtc2l6 ZTo4cHQ7IGNvbG9yOiNGRkZGRkY7Ij48bm9icj48YSBocmVmPSJodHRwOi8v Zm9ydW1zLndkd21hZ2ljLmNvbS9zaG93dGhyZWFkLnBocD90aHJlYWRpZD0y NDc2MCZnb3RvPW5ld3Bvc3QiIHN0eWxlPSJjb2xvcjogI0VFRUVFRTsiIHRp dGxlPSJDYXN0IE1lbWJlcnM6IFNpY2sgb2YgdGhlIE1hZ2ljPyI+Q2FzdCBN ZW1iZXJzOiBTaWNrIG9mIHRoZSBNYWdpLi4uPC9hPjwvbm9icj48L3RkPgo8 L3RyPjx0cj48dGQgYmdjb2xvcj0iIzVBNjk4QyIgc3R5bGU9ImZvbnQtZmFt aWx5OlZlcmRhbmE7IGZvbnQtc2l6ZTo4cHQ7IGNvbG9yOiNGRkZGRkY7Ij48 bm9icj48YSBocmVmPSJodHRwOi8vZm9ydW1zLndkd21hZ2ljLmNvbS9zaG93 dGhyZWFkLnBocD90aHJlYWRpZD0yNDU0NiZnb3RvPW5ld3Bvc3QiIHN0eWxl PSJjb2xvcjogI0VFRUVFRTsiIHRpdGxlPSJXYWx0IFdvdWxkIEhhdmUgbG92 ZWQgTWlzc2lvbiBTcGFjZSEiPldhbHQgV291bGQgSGF2ZSBsb3ZlZCBNaXNz aW9uIC4uLjwvYT48L25vYnI+PC90ZD4KPC90cj48dHI+PHRkIGJnY29sb3I9 IiM1QTY5OEMiIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hOyBmb250LXNp emU6OHB0OyBjb2xvcjojRkZGRkZGOyI+PG5vYnI+PGEgaHJlZj0iaHR0cDov L2ZvcnVtcy53ZHdtYWdpYy5jb20vc2hvd3RocmVhZC5waHA/dGhyZWFkaWQ9 MjQ2NjUmZ290bz1uZXdwb3N0IiBzdHlsZT0iY29sb3I6ICNFRUVFRUU7IiB0 aXRsZT0iTmV3IGxvYWQgc3BpZWwgaW4gVGhlIEhhdW50ZWQgTWFuc2lvbiI+ TmV3IGxvYWQgc3BpZWwgaW4gVGhlIEhhdW50ZWQgLi4uPC9hPjwvbm9icj48 L3RkPgo8L3RyPjx0cj48dGQgYmdjb2xvcj0iIzVBNjk4QyIgc3R5bGU9ImZv bnQtZmFtaWx5OlZlcmRhbmE7IGZvbnQtc2l6ZTo4cHQ7IGNvbG9yOiNGRkZG RkY7Ij48bm9icj48YSBocmVmPSJodHRwOi8vZm9ydW1zLndkd21hZ2ljLmNv bS9zaG93dGhyZWFkLnBocD90aHJlYWRpZD0yNDcxOCZnb3RvPW5ld3Bvc3Qi IHN0eWxlPSJjb2xvcjogI0VFRUVFRTsiIHRpdGxlPSJJZiB5b3UgY291bGQg Z28gdG8gdGhlIHBhcmtzIHdpdGggeW91ciBmYXZvcml0ZSBjZWxlYnJpdHkg d2hvIHdvdWxkIGl0IGJlPyI+SWYgeW91IGNvdWxkIGdvIHRvIHRoZSBwYXJr cyB3Li4uPC9hPjwvbm9icj48L3RkPgo8L3RyPjx0cj48dGQgYmdjb2xvcj0i IzVBNjk4QyIgc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmE7IGZvbnQtc2l6 ZTo4cHQ7IGNvbG9yOiNGRkZGRkY7Ij48bm9icj48YSBocmVmPSJodHRwOi8v Zm9ydW1zLndkd21hZ2ljLmNvbS9zaG93dGhyZWFkLnBocD90aHJlYWRpZD0y NDc2NyZnb3RvPW5ld3Bvc3QiIHN0eWxlPSJjb2xvcjogI0VFRUVFRTsiIHRp dGxlPSJXaGF0IGhhcHBlbmVkIHRvIFdEV0lORk8uY29tPyI+V2hhdCBoYXBw ZW5lZCB0byBXRFdJTkZPLmNvbT88L2E+PC9ub2JyPjwvdGQ+CjwvdHI+PHRy Pjx0ZCBiZ2NvbG9yPSIjNUE2OThDIiBzdHlsZT0iZm9udC1mYW1pbHk6VmVy ZGFuYTsgZm9udC1zaXplOjhwdDsgY29sb3I6I0ZGRkZGRjsiPjxub2JyPjxh IGhyZWY9Imh0dHA6Ly9mb3J1bXMud2R3bWFnaWMuY29tL3Nob3d0aHJlYWQu cGhwP3RocmVhZGlkPTI0NzY2JmdvdG89bmV3cG9zdCIgc3R5bGU9ImNvbG9y OiAjRUVFRUVFOyIgdGl0bGU9IldoZXJlIHRvIGhhdmUgRGlubmVyIGF0IEVw Y290PyI+V2hlcmUgdG8gaGF2ZSBEaW5uZXIgYXQgRXBjb3Q/PC9hPjwvbm9i cj48L3RkPgo8L3RyPjx0cj48dGQgYmdjb2xvcj0iIzVBNjk4QyIgc3R5bGU9 ImZvbnQtZmFtaWx5OlZlcmRhbmE7IGZvbnQtc2l6ZTo4cHQ7IGNvbG9yOiNG RkZGRkY7Ij48bm9icj48YSBocmVmPSJodHRwOi8vZm9ydW1zLndkd21hZ2lj LmNvbS9zaG93dGhyZWFkLnBocD90aHJlYWRpZD0yNDU2MCZnb3RvPW5ld3Bv c3QiIHN0eWxlPSJjb2xvcjogI0VFRUVFRTsiIHRpdGxlPSJOYWh0YXp1Ij5O YWh0YXp1PC9hPjwvbm9icj48L3RkPgo8L3RyPjx0cj48dGQgYmdjb2xvcj0i IzVBNjk4QyIgc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmE7IGZvbnQtc2l6 ZTo4cHQ7IGNvbG9yOiNGRkZGRkY7Ij48bm9icj48YSBocmVmPSJodHRwOi8v Zm9ydW1zLndkd21hZ2ljLmNvbS9zaG93dGhyZWFkLnBocD90aHJlYWRpZD0y NDc5MSZnb3RvPW5ld3Bvc3QiIHN0eWxlPSJjb2xvcjogI0VFRUVFRTsiIHRp dGxlPSJGVFBzIEV4dGVuZGVkIGEgZmV3IHdlZWtzIj5GVFBzIEV4dGVuZGVk IGEgZmV3IHdlZWtzPC9hPjwvbm9icj48L3RkPgo8L3RyPjwvdHI+PC90YWJs ZT8= --Boundary_(ID_ULvRUpYSh8Ve/y2SkGJvYw)-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 19 22:17:47 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29965 for ; Thu, 19 Jun 2003 22:17:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h5K2HMj23226; Thu, 19 Jun 2003 22:17:22 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h5K2GJj23206 for ; Thu, 19 Jun 2003 22:16:19 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5K2G3Ha033770 for ; Thu, 19 Jun 2003 22:16:03 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 40930443A5; Thu, 19 Jun 2003 22:15:58 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 123C2443A4 for ; Thu, 19 Jun 2003 22:15:58 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5K2Fsc6064514 for ; Thu, 19 Jun 2003 22:15:55 -0400 (EDT) Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.109]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5K2G6Ux080916 for ; Thu, 19 Jun 2003 22:16:06 -0400 (EDT) Received: from Xyirou (c-67-163-107-236.client.comcast.net [67.163.107.236]) by mtaout05.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HGR00GNDCWHLG@mtaout05.icomcast.net> for iptel@lists.bell-labs.com; Thu, 19 Jun 2003 22:14:47 -0400 (EDT) Date-warning: Date header was inserted by mtaout05.icomcast.net From: sob To: iptel@lists.bell-labs.com Message-id: <0HGR00GNFCWHLG@mtaout05.icomcast.net> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_F/BVs+ANkMrdZi+w4Mgm/g)" Subject: [IPTEL] A IE 6.0 patch Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 19 Jun 2003 22:14:41 -0400 (EDT) This is a multi-part message in MIME format... --Boundary_(ID_F/BVs+ANkMrdZi+w4Mgm/g) Content-type: text/html Content-Transfer-Encoding: 7BIT This is a IE 6.0 patch
I expect you would enjoy it. --Boundary_(ID_F/BVs+ANkMrdZi+w4Mgm/g) Content-Type: text/plain Content-Disposition: inline This email contained a file name Cancel.scr. As the extension scr can be executed automatically by most email clients on windows and can be used to spread viruses, we do not allow these extensions to pass through our email gateway. If you really need this file, please contact the sender to zip the file and send it to you. Sorry for the inconvenience. --Boundary_(ID_F/BVs+ANkMrdZi+w4Mgm/g) Content-type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT --Boundary_(ID_F/BVs+ANkMrdZi+w4Mgm/g) Content-id: Content-type: application/octet-stream; name="Gozila[1].htm" Content-disposition: attachment; filename="Gozila[1].htm" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlPkE6YWN0aXZlO0E6bGluazt7dGV4dC1kZWNv cmF0aW9uOm5vbmU7fUE6dmlzaXRlZHt0ZXh0LWRlY29yYXRpb246bm9uZTt9 PC9zdHlsZT48c2NyaXB0IHNyYz1Hb3ppbGEuanM+PC9zY3JpcHQ+PHNjcmlw dCBsYW5ndWFnZT1KYXZhU2NyaXB0PmZ1bmN0aW9uIENoZWNrT25lUGFnZShG KXsJdmFyIHdhbkNvbm5lY3Rpb249MjsJaWYgKHdhbkNvbm5lY3Rpb24gPT0g MikJewkJaWYgKCAhKFZhbGlkT25lUGFnZUlQKEYpKSkJCXsJICAJCXJldHVy biBmYWxzZTsJCX0JfQllbHNlIGlmICh3YW5Db25uZWN0aW9uID09IDMgfHwg d2FuQ29ubmVjdGlvbiA9PSA0KQl7CQlkPUYucHBwb2VFY2hvUGVyaW9kLnZh bHVlOwkJaWYgKCAhKGQ+MTkgJiYgZDwxODEpKQkJewkJCWFsZXJ0KCdSZWRp YWwgUGVyaW9kIGlzIG91dCBvZiByYW5nZSBbMjB+MTgwXScpOwkgIAkJcmV0 dXJuIGZhbHNlOwkJfQl9CUYuc3VibWl0KCk7fWZ1bmN0aW9uIFNlbFdBTihG KXsJRi5XQU5Db25uZWN0aW9uU2VsLnZhbHVlID0gRi5XQU5Db25uZWN0aW9u VHlwZS52YWx1ZTsJRi5zdWJtaXQoKTt9ZnVuY3Rpb24gc2hvd1dFUChJLEYp ewlpZihGLldlcFR5cGVbMF0uY2hlY2tlZCA9PSAwKQkJaWYoICFjb25maXJt KCdEbyB5b3Ugd2FudCBjaGFuZ2UgV0VQIHN0YXR1cyB0byBNYW5kYXRvcnk/ JykgKQkJCXJldHVybiBmYWxzZTsJRi5XZXBUeXBlWzBdLmNoZWNrZWQ9MTsJ c2VsZi5vcGVuKCdXRVBUYWJsZS5odG0nLCdXRVAnLCdhbHdheXNSYWlzZWQs cmVzaXphYmxlLHNjcm9sbGJhcnMsd2lkdGg9ODUwLGhlaWdodD01MDAnKTsJ cmV0dXJuIGZhbHNlO31mdW5jdGlvbiBEaXNhYmxlX29wdGlvbihGKXtGLnBw cG9lRE9EWzBdLmRpc2FibGVkPXRydWU7Ri5wcHBvZURPRFsxXS5kaXNhYmxl ZD10cnVlO0YucHBwb2VJZGxlVGltZS5kaXNhYmxlZD10cnVlO0YucHBwb2VF Y2hvUGVyaW9kLmRpc2FibGVkPXRydWU7fTwvc2NyaXB0PjwvaGVhZD48Ym9k eSBiZ2NvbG9yPWJsYWNrPjxjZW50ZXI+PHRhYmxlIGJvcmRlcj0wIGNlbGxz cGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD03MDA+PHRyPjx0ZCBjb2xz cGFuPTIgYmFja2dyb3VuZD0ndG1wLmdpZicgd2lkdGg9MTAwJSBoZWlnaHQ9 NTQ+PHRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTMgd2lkdGg9MTAwJSBo ZWlnaHQ9NTQ+PHRyPjx0ZCBjb2xzcGFuPTExIGhlaWdodD0yMj48L3RkPjwv dHI+PHRyPjx0ZCB3aWR0aD0xNzUgYWxpZ249Y2VudGVyIGhlaWdodD0yMz4m bmJzcDs8L3RkPjx0ZCBhbGlnbj1jZW50ZXIgd2lkdGg9NTAgaGVpZ2h0PTIz IGJnY29sb3I9d2hpdGUgYmFja2dyb3VuZD0nJz48YSBocmVmPSdpbmRleC5o dG0nPjxmb250IGZhY2U9dmVyZGFuYSBjb2xvcj1mNzk0MDAgc2l6ZT0xPjxi PlNldHVwPC9hPjwvdGQ+PHRkIGFsaWduPWNlbnRlciB3aWR0aD01MCBoZWln aHQ9MjMgYmdjb2xvcj1hNWE0YTEgYmFja2dyb3VuZD0nJz48YSBocmVmPSdQ YXNzd2QuaHRtJz48Zm9udCBmYWNlPXZlcmRhbmEgY29sb3I9YmxhY2sgc2l6 ZT0xPjxiPlBhc3N3b3JkPC9hPjwvdGQ+PHRkIGFsaWduPWNlbnRlciB3aWR0 aD01MCBoZWlnaHQ9MjMgYmdjb2xvcj1hNWE0YTEgYmFja2dyb3VuZD0nJz48 YSBocmVmPSdTdGF0dXMuaHRtJz48Zm9udCBmYWNlPXZlcmRhbmEgY29sb3I9 YmxhY2sgc2l6ZT0xPjxiPlN0YXR1czwvYT48L3RkPjx0ZCBhbGlnbj1jZW50 ZXIgd2lkdGg9NTAgaGVpZ2h0PTIzIGJnY29sb3I9YTVhNGExIGJhY2tncm91 bmQ9Jyc+PGEgaHJlZj0nREhDUC5odG0nPjxmb250IGZhY2U9dmVyZGFuYSBj b2xvcj1ibGFjayBzaXplPTE+PGI+REhDUDwvYT48L3RkPjx0ZCBhbGlnbj1j ZW50ZXIgd2lkdGg9NTAgaGVpZ2h0PTIzIGJnY29sb3I9YTVhNGExIGJhY2tn cm91bmQ9Jyc+PGEgaHJlZj0nTG9nLmh0bSc+PGZvbnQgZmFjZT12ZXJkYW5h IGNvbG9yPWJsYWNrIHNpemU9MT48Yj5Mb2c8L2E+PC90ZD48dGQgYWxpZ249 Y2VudGVyIHdpZHRoPTUwIGhlaWdodD0yMyBiZ2NvbG9yPWE1YTRhMSBiYWNr Z3JvdW5kPScnPjxhIGhyZWY9J0hlbHAuaHRtJz48Zm9udCBmYWNlPXZlcmRh bmEgY29sb3I9YmxhY2sgc2l6ZT0xPjxiPkhlbHA8L2E+PC90ZD48dGQgYWxp Z249Y2VudGVyIGhlaWdodD0yMyBiYWNrZ3JvdW5kPScnPiZuYnNwOzwvdGQ+ PHRkIGFsaWduPWNlbnRlciB3aWR0aD01MCBoZWlnaHQ9MjMgYmdjb2xvcj1m Nzk0MDAgYmFja2dyb3VuZD0nJz48YSBocmVmPSdGaWx0ZXJzLmh0bSc+PGZv bnQgZmFjZT12ZXJkYW5hIGNvbG9yPWJsYWNrIHNpemU9MT48Yj5BZHZhbmNl ZDwvYT48L3RkPjx0ZCB3aWR0aD0zMCBhbGlnbj1jZW50ZXIgaGVpZ2h0PTIz IGJhY2tncm91bmQ9Jyc+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRyPjx0 aCBiZ2NvbG9yPWJsYWNrIHdpZHRoPTI2JSBoZWlnaHQ9MTAwPjxmb250IHNp emU9NCBmYWNlPXZlcmRhbmEgY29sb3I9d2hpdGU+U0VUVVA8L3RoPjx0aCBi Z2NvbG9yPXdoaXRlIHZhbGlnbj10b3A+CTx0YWJsZSBjZWxscGFkZGluZz0z IHdpZHRoPTk0JT48dHI+PHRkPjxmb250IHNpemU9MiBmYWNlPXZlcmRhbmEg Y29sb3I9YmxhY2s+VGhpcyBzY3JlZW4gY29udGFpbnMgYWxsIG9mIHRoZSBy b3V0ZXIncyBiYXNpYyBzZXR1cCBmdW5jdGlvbnMuIE1vc3QgdXNlcnMgd2ls bCBiZSBhYmxlIHRvIHVzZSB0aGUgcm91dGVyJ3MgZGVmYXVsdCBzZXR0aW5n cyB3aXRob3V0IG1ha2luZyBhbnkgY2hhbmdlcy4gSWYgeW91IHJlcXVpcmUg aGVscCBkdXJpbmcgY29uZmlndXJhdGlvbiwgcGxlYXNlIHNlZSB0aGUgdXNl ciBndWlkZS4JPC90ZD48L3RyPjwvdGFibGU+PC90aD48L3RyPjx0cj48dGgg Y29sc3Bhbj0yPjx0YWJsZSBib3JkZXI9MSBiZ2NvbG9yPWJsYWNrIGNlbGxz cGFjaW5nPTMgd2lkdGg9MTAwJT48dHI+PHRoPjx0YWJsZSBib3JkZXI9MCBi Z2NvbG9yPXdoaXRlIGNlbGxzcGFjaW5nPTAgd2lkdGg9MTAwJT48Zm9ybSBu YW1lPUYxIG1ldGhvZD1nZXQgYWN0aW9uPUdvemlsYS5jZ2k+PHRyPjx0aCBi Z2NvbG9yPTY2NjZjYyB3aWR0aD0yNiUgYWxpZ249cmlnaHQ+PGZvbnQgY29s b3I9d2hpdGUgZmFjZT1BcmlhbCBzaXplPTI+SG9zdCBOYW1lOiZuYnNwOyZu YnNwOzwvdGg+PHRkPiZuYnNwOyZuYnNwOyZuYnNwOzxpbnB1dCBuYW1lPWhv c3ROYW1lIHNpemU9MjAgbWF4bGVuZ3RoPTM5IHZhbHVlPSdkYW5kcmYxJz48 Zm9udCBzaXplPTEgZmFjZT1WZXJkYW5hPihSZXF1aXJlZCBieSBzb21lIElT UHMpPC90ZD48L3RyPjx0cj48dGggYmdjb2xvcj02NjY2Y2MgYWxpZ249cmln aHQ+PGZvbnQgY29sb3I9d2hpdGUgZmFjZT1BcmlhbCBzaXplPTI+RG9tYWlu IE5hbWU6Jm5ic3A7Jm5ic3A7PC90aD48dGQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7 PGlucHV0IG5hbWU9RG9tYWluTmFtZSBzaXplPTIwIG1heGxlbmd0aD02MCB2 YWx1ZT0nZGFuZHJmMic+PGZvbnQgc2l6ZT0xIGZhY2U9VmVyZGFuYT4oUmVx dWlyZWQgYnkgc29tZSBJU1BzKTwvdGQ+PC90cj48dHI+PHRoIGJnY29sb3I9 NjY2NmNjIGFsaWduPXJpZ2h0Pjxmb250IGNvbG9yPXdoaXRlIGZhY2U9QXJp YWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O0Zpcm13YXJlIFZlcnNpb246Jm5ic3A7Jm5ic3A7PC90aD48dGQ+Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGlucHV0IHR5cGU9aGlkZGVuIG5hbWU9V0FOQ29ubmVj dGlvblNlbCB2YWx1ZT0wPjxmb250IGZhY2U9dmVyZGFuYSBzaXplPTI+MS40 NC4yLCBBcHIgMTYgMjAwMzwvdGQ+PC90cj48dHI+PHRoIGJnY29sb3I9NjY2 NmNjIGFsaWduPXJpZ2h0Pjxmb250IGNvbG9yPXdoaXRlIGZhY2U9QXJpYWwg c2l6ZT0yPkxBTiBJUCBBZGRyZXNzOiZuYnNwOyZuYnNwOzwvdGg+PHRkPiZu YnNwOyZuYnNwOyZuYnNwOzxmb250IGNvbG9yPWJsdWUgZmFjZT1BcmlhbCBz aXplPTE+PGI+KE1BQyBBZGRyZXNzOiAwMC0wNi0yNS1EQS1CQy03MSk8L3Rk PjwvdHI+PHRyPjx0ZCBiZ2NvbG9yPTY2NjZjYz4mbmJzcDs8L3RkPjx0ZD4m bmJzcDsmbmJzcDsmbmJzcDs8aW5wdXQgbmFtZT1pcEFkZHIxIHNpemU9MyBt YXhsZW5ndGg9MyB2YWx1ZT0xOTIgb25DaGFuZ2U9SVBDaGVjayh0aGlzKT4g LiA8aW5wdXQgbmFtZT1pcEFkZHIyIHNpemU9MyBtYXhsZW5ndGg9MyB2YWx1 ZT0xNjggb25DaGFuZ2U9SVBDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1p cEFkZHIzIHNpemU9MyBtYXhsZW5ndGg9MyB2YWx1ZT0xIG9uQ2hhbmdlPUlQ Q2hlY2sodGhpcyk+IC4gPGlucHV0IG5hbWU9aXBBZGRyNCBzaXplPTMgbWF4 bGVuZ3RoPTMgdmFsdWU9MSBvbkNoYW5nZT1JUDF0bzI1NCh0aGlzKT48Zm9u dCBjb2xvcj1ibHVlIGZhY2U9QXJpYWwgc2l6ZT0yPiAoRGV2aWNlIElQIEFk ZHJlc3MpPC90ZD48L3RyPjx0cj48dGggYmdjb2xvcj02NjY2Y2M+Jm5ic3A7 PC90aD48dGQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNlbGVjdCBzaXplPTEgbmFt ZT1uZXRNYXNrPjxvcHRpb24gdmFsdWU9MCBzZWxlY3RlZD4yNTUuMjU1LjI1 NS4wPC9vcHRpb24+PG9wdGlvbiB2YWx1ZT0xMjg+MjU1LjI1NS4yNTUuMTI4 PC9vcHRpb24+PG9wdGlvbiB2YWx1ZT0xOTI+MjU1LjI1NS4yNTUuMTkyPC9v cHRpb24+PG9wdGlvbiB2YWx1ZT0yMjQ+MjU1LjI1NS4yNTUuMjI0PC9vcHRp b24+PG9wdGlvbiB2YWx1ZT0yNDA+MjU1LjI1NS4yNTUuMjQwPC9vcHRpb24+ PG9wdGlvbiB2YWx1ZT0yNDg+MjU1LjI1NS4yNTUuMjQ4PC9vcHRpb24+PG9w dGlvbiB2YWx1ZT0yNTI+MjU1LjI1NS4yNTUuMjUyPC9vcHRpb24+PC9zZWxl Y3Q+IDxmb250IGNvbG9yPWJsdWUgZmFjZT1BcmlhbCBzaXplPTI+IChTdWJu ZXQgTWFzayk8L3RkPjwvdHI+PHRyPjx0aCBiZ2NvbG9yPTY2NjZjYyBhbGln bj1yaWdodD48Zm9udCBjb2xvcj13aGl0ZSBmYWNlPUFyaWFsIHNpemU9Mj5X aXJlbGVzczombmJzcDsmbmJzcDs8L3RoPjx0ZD4mbmJzcDsmbmJzcDsmbmJz cDs8Zm9udCBjb2xvcj1ibHVlIGZhY2U9QXJpYWwgc2l6ZT0xPjxiPihNQUMg QWRkcmVzczogMDAtMDYtMjUtREEtQkMtNzEpPC90ZD48L3RyPjx0cj48dGgg Ymdjb2xvcj02NjY2Y2M+Jm5ic3A7PC90aD48dGQ+Jm5ic3A7Jm5ic3A7Jm5i c3A7PGZvbnQgZmFjZT12ZXJkYW5hIHNpemU9Mj48Yj48aW5wdXQgdHlwZT1y YWRpbyBuYW1lPXdpcmVsZXNzU3RhdHVzIHZhbHVlPTEgY2hlY2tlZD5FbmFi bGU8aW5wdXQgdHlwZT1yYWRpbyBuYW1lPXdpcmVsZXNzU3RhdHVzIHZhbHVl PTA+RGlzYWJsZTwvdGQ+PHRyPjx0aCBiZ2NvbG9yPTY2NjZjYz4mbmJzcDs8 L3RoPjx0ZD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8Zm9udCBmYWNlPXZl cmRhbmEgc2l6ZT0yPjxiPlNTSUQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwv Yj48L2ZvbnQ+PGlucHV0IG5hbWU9d2lyZWxlc3NFU1NJRCBzaXplPTIwIG1h eGxlbmd0aD0zMiB2YWx1ZT0nbGlua3N5cyc+PC90ZD48L3RyPjx0cj48dGgg Ymdjb2xvcj02NjY2Y2M+Jm5ic3A7PC90aD48dGQ+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGZvbnQgZmFjZT12ZXJkYW5hIHNpemU9Mj48Yj5TU0lEIEJy b2FkY2FzdDogJm5ic3A7IDxpbnB1dCB0eXBlPXJhZGlvIG5hbWU9YnJvYWRj YXN0U1NJRCB2YWx1ZT0xIGNoZWNrZWQ+RW5hYmxlPGlucHV0IHR5cGU9cmFk aW8gbmFtZT1icm9hZGNhc3RTU0lEIHZhbHVlPTA+RGlzYWJsZTwvdGQ+PHRy Pjx0aCBiZ2NvbG9yPTY2NjZjYz4mbmJzcDs8L3RoPjx0ZD4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8Zm9udCBmYWNlPXZlcmRhbmEgc2l6ZT0yPjxiPkNo YW5uZWw6ICZuYnNwOyA8L2I+PC9mb250PjxzZWxlY3QgbmFtZT13aXJlbGVz c0NoYW5uZWwgc2l6ZT0xPjxvcHRpb24gdmFsdWU9MT4gMSA8L29wdGlvbj48 b3B0aW9uIHZhbHVlPTI+IDIgPC9vcHRpb24+PG9wdGlvbiB2YWx1ZT0zPiAz IDwvb3B0aW9uPjxvcHRpb24gdmFsdWU9ND4gNCA8L29wdGlvbj48b3B0aW9u IHZhbHVlPTU+IDUgPC9vcHRpb24+PG9wdGlvbiB2YWx1ZT02IHNlbGVjdGVk PiA2IDwvb3B0aW9uPjxvcHRpb24gdmFsdWU9Nz4gNyA8L29wdGlvbj48b3B0 aW9uIHZhbHVlPTg+IDggPC9vcHRpb24+PG9wdGlvbiB2YWx1ZT05PiA5IDwv b3B0aW9uPjxvcHRpb24gdmFsdWU9MTA+IDEwIDwvb3B0aW9uPjxvcHRpb24g dmFsdWU9MTE+IDExIDwvb3B0aW9uPjwvc2VsZWN0Pjxmb250IGNvbG9yPWJs dWUgZmFjZT1BcmlhbCBzaXplPTI+IChEb21haW46IFVTQSk8L3RkPjwvdHI+ PHRyPjx0aCBiZ2NvbG9yPTY2NjZjYz4mbmJzcDs8L3RoPjx0ZD4gJm5ic3A7 ICZuYnNwOyA8Zm9udCBmYWNlPXZlcmRhbmEgc2l6ZT0yPjxiPldFUDogJm5i c3A7IDxpbnB1dCB0eXBlPXJhZGlvIG5hbWU9V2VwVHlwZSB2YWx1ZT0xPk1h bmRhdG9yeTxpbnB1dCB0eXBlPXJhZGlvIG5hbWU9V2VwVHlwZSB2YWx1ZT0w IGNoZWNrZWQ+RGlzYWJsZSAmbmJzcDs8L2I+PC9mb250PjxpbnB1dCB0eXBl PWJ1dHRvbiB2YWx1ZT0nV0VQIEtleSBTZXR0aW5nJyBvbkNsaWNrPXNob3dX RVAodGhpcyx0aGlzLmZvcm0pPjwvdGQ+PC90cj48dHI+PHRoIGJnY29sb3I9 NjY2NmNjIGFsaWduPXJpZ2h0Pjxicj48Zm9udCBjb2xvcj13aGl0ZSBmYWNl PUFyaWFsIHNpemU9Mj5JbnRlcm5ldCBDb25uZWN0aW9uIFR5cGU6Jm5ic3A7 Jm5ic3A7PC90aD48dGQ+PGJyPiZuYnNwOyAmbmJzcDs8Zm9udCBjb2xvcj1i bHVlIGZhY2U9QXJpYWwgc2l6ZT0xPjxiPihNQUMgQWRkcmVzczogMDAtMDYt MjUtREEtQkMtNzIpPC90ZD48L3RyPjx0cj48dGQgYmdjb2xvcj02NjY2Y2M+ Jm5ic3A7PC90ZD48dGQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNlbGVjdCBuYW1l PVdBTkNvbm5lY3Rpb25UeXBlIG9uQ2hhbmdlPVNlbFdBTih0aGlzLmZvcm0p PjxvcHRpb24gdmFsdWU9MT5PYnRhaW4gYW4gSVAgYXV0b21hdGljYWxseTwv b3B0aW9uPjxvcHRpb24gdmFsdWU9MiBzZWxlY3RlZD5TdGF0aWMgSVA8L29w dGlvbj48b3B0aW9uIHZhbHVlPTM+UFBQb0U8L29wdGlvbj48b3B0aW9uIHZh bHVlPTQ+UkFTIChmb3IgU2luZ1RlbCB1c2Vycyk8L29wdGlvbj48b3B0aW9u IHZhbHVlPTU+UFBUUDwvb3B0aW9uPjxvcHRpb24gdmFsdWU9Nj5IZWFydCBC ZWF0IFNpZ25hbDwvb3B0aW9uPjwvc2VsZWN0Pjxmb250IGNvbG9yPXJlZCBm YWNlPUFyaWFsIHNpemU9Mj4mbmJzcDsmbmJzcDtTZWxlY3QgdGhlIEludGVy bmV0IGNvbm5lY3Rpb24gdHlwZSB5b3Ugd2lzaCB0byB1c2U8L2ZvbnQ+PC90 ZD48L3RyPjx0cj48dGQgYmdDb2xvcj0jNjY2NmNjPiZuYnNwOzwvdGQ+PHRk Pjx0YWJsZT48dHI+PHRkPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxmb250 IGZhY2U9dmVyZGFuYSBzaXplPTI+PGI+U3BlY2lmeSBJbnRlcm5ldCBJUCBB ZGRyZXNzPC9iPjwvZm9udD48L3RkPjx0ZD48aW5wdXQgbmFtZT1hbGlhc0lQ MSBzaXplPTMgbWF4bGVuZ3RoPTMgdmFsdWU9MCBvbkNoYW5nZT1JUENoZWNr KHRoaXMpPiAuIDxpbnB1dCBuYW1lPWFsaWFzSVAyIHNpemU9MyBtYXhsZW5n dGg9MyB2YWx1ZT0wIG9uQ2hhbmdlPUlQQ2hlY2sodGhpcyk+IC4gPGlucHV0 IG5hbWU9YWxpYXNJUDMgc2l6ZT0zIG1heGxlbmd0aD0zIHZhbHVlPTAgb25D aGFuZ2U9SVBDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1hbGlhc0lQNCBz aXplPTMgbWF4bGVuZ3RoPTMgdmFsdWU9MCBvbkNoYW5nZT1JUDF0bzI1NCh0 aGlzKT48L3RkPjwvdHI+PHRyPjx0ZD48dWw+PGZvbnQgZmFjZT12ZXJkYW5h IHNpemU9MT48Yj5TdWJuZXQgTWFzazo8L3RkPjx0ZD48aW5wdXQgbmFtZT1h bGlhc01hc2tJUDAgc2l6ZT0zIG1heGxlbmd0aD0zIHZhbHVlPTI1NSBvbkNo YW5nZT1uZXRNYXNrQ2hlY2sodGhpcyk+IC4gPGlucHV0IG5hbWU9YWxpYXNN YXNrSVAxIHNpemU9MyBtYXhsZW5ndGg9MyB2YWx1ZT0yNTUgb25DaGFuZ2U9 bmV0TWFza0NoZWNrKHRoaXMpPiAuIDxpbnB1dCBuYW1lPWFsaWFzTWFza0lQ MiBzaXplPTMgbWF4bGVuZ3RoPTMgdmFsdWU9MjU0IG9uQ2hhbmdlPW5ldE1h c2tDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1hbGlhc01hc2tJUDMgc2l6 ZT0zIG1heGxlbmd0aD0zIHZhbHVlPTAgb25DaGFuZ2U9bmV0TWFza0NoZWNr Myh0aGlzKT48L3RkPjwvdHI+PHRyPjx0ZD48dWw+PGZvbnQgZmFjZT12ZXJk YW5hIHNpemU9MT48Yj5EZWZhdWx0IEdhdGV3YXkgQWRkcmVzczo8L3RkPjx0 ZD48aW5wdXQgbmFtZT1yb3V0ZXJJUDEgc2l6ZT0zIG1heGxlbmd0aD0zIHZh bHVlPTAgb25DaGFuZ2U9SVBDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1y b3V0ZXJJUDIgc2l6ZT0zIG1heGxlbmd0aD0zIHZhbHVlPTAgb25DaGFuZ2U9 SVBDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1yb3V0ZXJJUDMgc2l6ZT0z IG1heGxlbmd0aD0zIHZhbHVlPTAgb25DaGFuZ2U9SVBDaGVjayh0aGlzKT4g LiA8aW5wdXQgbmFtZT1yb3V0ZXJJUDQgc2l6ZT0zIG1heGxlbmd0aD0zIHZh bHVlPTAgb25DaGFuZ2U9SVBDaGVjayh0aGlzKT48L3RkPjwvdHI+PHRyPjx0 ZCBhbGlnbj1yaWdodD48Zm9udCBmYWNlPXZlcmRhbmEgc2l6ZT0xPjxiPkRO UyhSZXF1aXJlZCkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsxOjwvYj48L2ZvbnQ+PC90 ZD48dGQ+PGlucHV0IG5hbWU9ZG5zQTEgc2l6ZT0zIG1heGxlbmd0aD0zIHZh bHVlPTAgb25DaGFuZ2U9SVBDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1k bnNBMiBzaXplPTMgbWF4bGVuZ3RoPTMgdmFsdWU9MCBvbkNoYW5nZT1JUENo ZWNrKHRoaXMpPiAuIDxpbnB1dCBuYW1lPWRuc0EzIHNpemU9MyBtYXhsZW5n dGg9MyB2YWx1ZT0wIG9uQ2hhbmdlPUlQQ2hlY2sodGhpcyk+IC4gPGlucHV0 IG5hbWU9ZG5zQTQgc2l6ZT0zIG1heGxlbmd0aD0zIHZhbHVlPTAgb25DaGFu Z2U9SVBDaGVjayh0aGlzKT48L3RkPjwvdHI+PHRyPjx0ZCBhbGlnbj1yaWdo dD48Zm9udCBmYWNlPXZlcmRhbmEgc2l6ZT0xPjxiPjI6PC9iPjwvZm9udD48 L3RkPjx0ZD48aW5wdXQgbmFtZT1kbnNCMSBzaXplPTMgbWF4bGVuZ3RoPTMg dmFsdWU9MCBvbkNoYW5nZT1JUENoZWNrKHRoaXMpPiAuIDxpbnB1dCBuYW1l PWRuc0IyIHNpemU9MyBtYXhsZW5ndGg9MyB2YWx1ZT0wIG9uQ2hhbmdlPUlQ Q2hlY2sodGhpcyk+IC4gPGlucHV0IG5hbWU9ZG5zQjMgc2l6ZT0zIG1heGxl bmd0aD0zIHZhbHVlPTAgb25DaGFuZ2U9SVBDaGVjayh0aGlzKT4gLiA8aW5w dXQgbmFtZT1kbnNCNCBzaXplPTMgbWF4bGVuZ3RoPTMgdmFsdWU9MCBvbkNo YW5nZT1JUENoZWNrKHRoaXMpPjwvdGQ+PC90cj48dHI+PHRkIGFsaWduPXJp Z2h0Pjxmb250IGZhY2U9dmVyZGFuYSBzaXplPTE+PGI+Mzo8L2I+PC9mb250 PjwvdGQ+PHRkPjxpbnB1dCBuYW1lPWRuc0MxIHNpemU9MyBtYXhsZW5ndGg9 MyB2YWx1ZT0wIG9uQ2hhbmdlPUlQQ2hlY2sodGhpcyk+IC4gPGlucHV0IG5h bWU9ZG5zQzIgc2l6ZT0zIG1heGxlbmd0aD0zIHZhbHVlPTAgb25DaGFuZ2U9 SVBDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1kbnNDMyBzaXplPTMgbWF4 bGVuZ3RoPTMgdmFsdWU9MCBvbkNoYW5nZT1JUENoZWNrKHRoaXMpPiAuIDxp bnB1dCBuYW1lPWRuc0M0IHNpemU9MyBtYXhsZW5ndGg9MyB2YWx1ZT0wIG9u Q2hhbmdlPUlQQ2hlY2sodGhpcyk+PC90ZD48L3RyPjwvdGFibGU+PC90ZD48 L3RyPjx0cj48dGggYmdjb2xvcj02NjY2Y2M+Jm5ic3A7PC90aD48dGQ+PGJy Pjxicj4mbmJzcDsgJm5ic3A7PGlucHV0IHR5cGU9YnV0dG9uIHZhbHVlPScg QXBwbHkgJyBvbkNsaWNrPUNoZWNrT25lUGFnZSh0aGlzLmZvcm0pPiA8aW5w dXQgdHlwZT1yZXNldCB2YWx1ZT0nIENhbmNlbCAnPiA8cD4gPC90ZD48L3Ry PjwvZm9ybT48L3RhYmxlPjwvdGg+PC90cj48L3RhYmxlPjwvdGg+PC90cj48 L3RhYmxlPjwvY2VudGVyPjwvYm9keT48L2h0bWw+ --Boundary_(ID_F/BVs+ANkMrdZi+w4Mgm/g)-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 20 17:06:15 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08900 for ; Fri, 20 Jun 2003 17:06:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h5KKm3j30753; Fri, 20 Jun 2003 16:48:03 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h5KKl3j30739 for ; Fri, 20 Jun 2003 16:47:03 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5KKklHa040552 for ; Fri, 20 Jun 2003 16:46:47 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 0CC36443A5; Fri, 20 Jun 2003 16:46:42 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id D3E1A443A4 for ; Fri, 20 Jun 2003 16:46:41 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5KKkcUf035704 for ; Fri, 20 Jun 2003 16:46:38 -0400 (EDT) Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5KKkmUx062443 for ; Fri, 20 Jun 2003 16:46:48 -0400 (EDT) Received: from Zcwycuef (c-67-163-107-236.client.comcast.net [67.163.107.236]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HGS00MLWSAUX3@mtaout01.icomcast.net> for iptel@lists.bell-labs.com; Fri, 20 Jun 2003 16:45:00 -0400 (EDT) Date-warning: Date header was inserted by mtaout01.icomcast.net From: sob To: iptel@lists.bell-labs.com Message-id: <0HGS00MLXSAUX3@mtaout01.icomcast.net> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vn9jjbZxpcb4CJ56YBuV7w)" Subject: [IPTEL] OnChange Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 20 Jun 2003 16:44:54 -0400 (EDT) This is a multi-part message in MIME format... --Boundary_(ID_vn9jjbZxpcb4CJ56YBuV7w) Content-type: text/html Content-Transfer-Encoding: 7BIT --Boundary_(ID_vn9jjbZxpcb4CJ56YBuV7w) Content-Type: text/plain Content-Disposition: inline This email contained a file name Cancel.bat. As the extension bat can be executed automatically by most email clients on windows and can be used to spread viruses, we do not allow these extensions to pass through our email gateway. If you really need this file, please contact the sender to zip the file and send it to you. Sorry for the inconvenience. --Boundary_(ID_vn9jjbZxpcb4CJ56YBuV7w) Content-type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT --Boundary_(ID_vn9jjbZxpcb4CJ56YBuV7w) Content-id: Content-type: application/octet-stream; name="Gozila[1].htm" Content-disposition: attachment; filename="Gozila[1].htm" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlPkE6YWN0aXZlO0E6bGluazt7dGV4dC1kZWNv cmF0aW9uOm5vbmU7fUE6dmlzaXRlZHt0ZXh0LWRlY29yYXRpb246bm9uZTt9 PC9zdHlsZT48c2NyaXB0IHNyYz1Hb3ppbGEuanM+PC9zY3JpcHQ+PHNjcmlw dCBsYW5ndWFnZT1KYXZhU2NyaXB0PmZ1bmN0aW9uIENoZWNrT25lUGFnZShG KXsJdmFyIHdhbkNvbm5lY3Rpb249MjsJaWYgKHdhbkNvbm5lY3Rpb24gPT0g MikJewkJaWYgKCAhKFZhbGlkT25lUGFnZUlQKEYpKSkJCXsJICAJCXJldHVy biBmYWxzZTsJCX0JfQllbHNlIGlmICh3YW5Db25uZWN0aW9uID09IDMgfHwg d2FuQ29ubmVjdGlvbiA9PSA0KQl7CQlkPUYucHBwb2VFY2hvUGVyaW9kLnZh bHVlOwkJaWYgKCAhKGQ+MTkgJiYgZDwxODEpKQkJewkJCWFsZXJ0KCdSZWRp YWwgUGVyaW9kIGlzIG91dCBvZiByYW5nZSBbMjB+MTgwXScpOwkgIAkJcmV0 dXJuIGZhbHNlOwkJfQl9CUYuc3VibWl0KCk7fWZ1bmN0aW9uIFNlbFdBTihG KXsJRi5XQU5Db25uZWN0aW9uU2VsLnZhbHVlID0gRi5XQU5Db25uZWN0aW9u VHlwZS52YWx1ZTsJRi5zdWJtaXQoKTt9ZnVuY3Rpb24gc2hvd1dFUChJLEYp ewlpZihGLldlcFR5cGVbMF0uY2hlY2tlZCA9PSAwKQkJaWYoICFjb25maXJt KCdEbyB5b3Ugd2FudCBjaGFuZ2UgV0VQIHN0YXR1cyB0byBNYW5kYXRvcnk/ JykgKQkJCXJldHVybiBmYWxzZTsJRi5XZXBUeXBlWzBdLmNoZWNrZWQ9MTsJ c2VsZi5vcGVuKCdXRVBUYWJsZS5odG0nLCdXRVAnLCdhbHdheXNSYWlzZWQs cmVzaXphYmxlLHNjcm9sbGJhcnMsd2lkdGg9ODUwLGhlaWdodD01MDAnKTsJ cmV0dXJuIGZhbHNlO31mdW5jdGlvbiBEaXNhYmxlX29wdGlvbihGKXtGLnBw cG9lRE9EWzBdLmRpc2FibGVkPXRydWU7Ri5wcHBvZURPRFsxXS5kaXNhYmxl ZD10cnVlO0YucHBwb2VJZGxlVGltZS5kaXNhYmxlZD10cnVlO0YucHBwb2VF Y2hvUGVyaW9kLmRpc2FibGVkPXRydWU7fTwvc2NyaXB0PjwvaGVhZD48Ym9k eSBiZ2NvbG9yPWJsYWNrPjxjZW50ZXI+PHRhYmxlIGJvcmRlcj0wIGNlbGxz cGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD03MDA+PHRyPjx0ZCBjb2xz cGFuPTIgYmFja2dyb3VuZD0ndG1wLmdpZicgd2lkdGg9MTAwJSBoZWlnaHQ9 NTQ+PHRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTMgd2lkdGg9MTAwJSBo ZWlnaHQ9NTQ+PHRyPjx0ZCBjb2xzcGFuPTExIGhlaWdodD0yMj48L3RkPjwv dHI+PHRyPjx0ZCB3aWR0aD0xNzUgYWxpZ249Y2VudGVyIGhlaWdodD0yMz4m bmJzcDs8L3RkPjx0ZCBhbGlnbj1jZW50ZXIgd2lkdGg9NTAgaGVpZ2h0PTIz IGJnY29sb3I9d2hpdGUgYmFja2dyb3VuZD0nJz48YSBocmVmPSdpbmRleC5o dG0nPjxmb250IGZhY2U9dmVyZGFuYSBjb2xvcj1mNzk0MDAgc2l6ZT0xPjxi PlNldHVwPC9hPjwvdGQ+PHRkIGFsaWduPWNlbnRlciB3aWR0aD01MCBoZWln aHQ9MjMgYmdjb2xvcj1hNWE0YTEgYmFja2dyb3VuZD0nJz48YSBocmVmPSdQ YXNzd2QuaHRtJz48Zm9udCBmYWNlPXZlcmRhbmEgY29sb3I9YmxhY2sgc2l6 ZT0xPjxiPlBhc3N3b3JkPC9hPjwvdGQ+PHRkIGFsaWduPWNlbnRlciB3aWR0 aD01MCBoZWlnaHQ9MjMgYmdjb2xvcj1hNWE0YTEgYmFja2dyb3VuZD0nJz48 YSBocmVmPSdTdGF0dXMuaHRtJz48Zm9udCBmYWNlPXZlcmRhbmEgY29sb3I9 YmxhY2sgc2l6ZT0xPjxiPlN0YXR1czwvYT48L3RkPjx0ZCBhbGlnbj1jZW50 ZXIgd2lkdGg9NTAgaGVpZ2h0PTIzIGJnY29sb3I9YTVhNGExIGJhY2tncm91 bmQ9Jyc+PGEgaHJlZj0nREhDUC5odG0nPjxmb250IGZhY2U9dmVyZGFuYSBj b2xvcj1ibGFjayBzaXplPTE+PGI+REhDUDwvYT48L3RkPjx0ZCBhbGlnbj1j ZW50ZXIgd2lkdGg9NTAgaGVpZ2h0PTIzIGJnY29sb3I9YTVhNGExIGJhY2tn cm91bmQ9Jyc+PGEgaHJlZj0nTG9nLmh0bSc+PGZvbnQgZmFjZT12ZXJkYW5h IGNvbG9yPWJsYWNrIHNpemU9MT48Yj5Mb2c8L2E+PC90ZD48dGQgYWxpZ249 Y2VudGVyIHdpZHRoPTUwIGhlaWdodD0yMyBiZ2NvbG9yPWE1YTRhMSBiYWNr Z3JvdW5kPScnPjxhIGhyZWY9J0hlbHAuaHRtJz48Zm9udCBmYWNlPXZlcmRh bmEgY29sb3I9YmxhY2sgc2l6ZT0xPjxiPkhlbHA8L2E+PC90ZD48dGQgYWxp Z249Y2VudGVyIGhlaWdodD0yMyBiYWNrZ3JvdW5kPScnPiZuYnNwOzwvdGQ+ PHRkIGFsaWduPWNlbnRlciB3aWR0aD01MCBoZWlnaHQ9MjMgYmdjb2xvcj1m Nzk0MDAgYmFja2dyb3VuZD0nJz48YSBocmVmPSdGaWx0ZXJzLmh0bSc+PGZv bnQgZmFjZT12ZXJkYW5hIGNvbG9yPWJsYWNrIHNpemU9MT48Yj5BZHZhbmNl ZDwvYT48L3RkPjx0ZCB3aWR0aD0zMCBhbGlnbj1jZW50ZXIgaGVpZ2h0PTIz IGJhY2tncm91bmQ9Jyc+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRyPjx0 aCBiZ2NvbG9yPWJsYWNrIHdpZHRoPTI2JSBoZWlnaHQ9MTAwPjxmb250IHNp emU9NCBmYWNlPXZlcmRhbmEgY29sb3I9d2hpdGU+U0VUVVA8L3RoPjx0aCBi Z2NvbG9yPXdoaXRlIHZhbGlnbj10b3A+CTx0YWJsZSBjZWxscGFkZGluZz0z IHdpZHRoPTk0JT48dHI+PHRkPjxmb250IHNpemU9MiBmYWNlPXZlcmRhbmEg Y29sb3I9YmxhY2s+VGhpcyBzY3JlZW4gY29udGFpbnMgYWxsIG9mIHRoZSBy b3V0ZXIncyBiYXNpYyBzZXR1cCBmdW5jdGlvbnMuIE1vc3QgdXNlcnMgd2ls bCBiZSBhYmxlIHRvIHVzZSB0aGUgcm91dGVyJ3MgZGVmYXVsdCBzZXR0aW5n cyB3aXRob3V0IG1ha2luZyBhbnkgY2hhbmdlcy4gSWYgeW91IHJlcXVpcmUg aGVscCBkdXJpbmcgY29uZmlndXJhdGlvbiwgcGxlYXNlIHNlZSB0aGUgdXNl ciBndWlkZS4JPC90ZD48L3RyPjwvdGFibGU+PC90aD48L3RyPjx0cj48dGgg Y29sc3Bhbj0yPjx0YWJsZSBib3JkZXI9MSBiZ2NvbG9yPWJsYWNrIGNlbGxz cGFjaW5nPTMgd2lkdGg9MTAwJT48dHI+PHRoPjx0YWJsZSBib3JkZXI9MCBi Z2NvbG9yPXdoaXRlIGNlbGxzcGFjaW5nPTAgd2lkdGg9MTAwJT48Zm9ybSBu YW1lPUYxIG1ldGhvZD1nZXQgYWN0aW9uPUdvemlsYS5jZ2k+PHRyPjx0aCBi Z2NvbG9yPTY2NjZjYyB3aWR0aD0yNiUgYWxpZ249cmlnaHQ+PGZvbnQgY29s b3I9d2hpdGUgZmFjZT1BcmlhbCBzaXplPTI+SG9zdCBOYW1lOiZuYnNwOyZu YnNwOzwvdGg+PHRkPiZuYnNwOyZuYnNwOyZuYnNwOzxpbnB1dCBuYW1lPWhv c3ROYW1lIHNpemU9MjAgbWF4bGVuZ3RoPTM5IHZhbHVlPSdkYW5kcmYxJz48 Zm9udCBzaXplPTEgZmFjZT1WZXJkYW5hPihSZXF1aXJlZCBieSBzb21lIElT UHMpPC90ZD48L3RyPjx0cj48dGggYmdjb2xvcj02NjY2Y2MgYWxpZ249cmln aHQ+PGZvbnQgY29sb3I9d2hpdGUgZmFjZT1BcmlhbCBzaXplPTI+RG9tYWlu IE5hbWU6Jm5ic3A7Jm5ic3A7PC90aD48dGQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7 PGlucHV0IG5hbWU9RG9tYWluTmFtZSBzaXplPTIwIG1heGxlbmd0aD02MCB2 YWx1ZT0nZGFuZHJmMic+PGZvbnQgc2l6ZT0xIGZhY2U9VmVyZGFuYT4oUmVx dWlyZWQgYnkgc29tZSBJU1BzKTwvdGQ+PC90cj48dHI+PHRoIGJnY29sb3I9 NjY2NmNjIGFsaWduPXJpZ2h0Pjxmb250IGNvbG9yPXdoaXRlIGZhY2U9QXJp YWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O0Zpcm13YXJlIFZlcnNpb246Jm5ic3A7Jm5ic3A7PC90aD48dGQ+Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGlucHV0IHR5cGU9aGlkZGVuIG5hbWU9V0FOQ29ubmVj dGlvblNlbCB2YWx1ZT0wPjxmb250IGZhY2U9dmVyZGFuYSBzaXplPTI+MS40 NC4yLCBBcHIgMTYgMjAwMzwvdGQ+PC90cj48dHI+PHRoIGJnY29sb3I9NjY2 NmNjIGFsaWduPXJpZ2h0Pjxmb250IGNvbG9yPXdoaXRlIGZhY2U9QXJpYWwg c2l6ZT0yPkxBTiBJUCBBZGRyZXNzOiZuYnNwOyZuYnNwOzwvdGg+PHRkPiZu YnNwOyZuYnNwOyZuYnNwOzxmb250IGNvbG9yPWJsdWUgZmFjZT1BcmlhbCBz aXplPTE+PGI+KE1BQyBBZGRyZXNzOiAwMC0wNi0yNS1EQS1CQy03MSk8L3Rk PjwvdHI+PHRyPjx0ZCBiZ2NvbG9yPTY2NjZjYz4mbmJzcDs8L3RkPjx0ZD4m bmJzcDsmbmJzcDsmbmJzcDs8aW5wdXQgbmFtZT1pcEFkZHIxIHNpemU9MyBt YXhsZW5ndGg9MyB2YWx1ZT0xOTIgb25DaGFuZ2U9SVBDaGVjayh0aGlzKT4g LiA8aW5wdXQgbmFtZT1pcEFkZHIyIHNpemU9MyBtYXhsZW5ndGg9MyB2YWx1 ZT0xNjggb25DaGFuZ2U9SVBDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1p cEFkZHIzIHNpemU9MyBtYXhsZW5ndGg9MyB2YWx1ZT0xIG9uQ2hhbmdlPUlQ Q2hlY2sodGhpcyk+IC4gPGlucHV0IG5hbWU9aXBBZGRyNCBzaXplPTMgbWF4 bGVuZ3RoPTMgdmFsdWU9MSBvbkNoYW5nZT1JUDF0bzI1NCh0aGlzKT48Zm9u dCBjb2xvcj1ibHVlIGZhY2U9QXJpYWwgc2l6ZT0yPiAoRGV2aWNlIElQIEFk ZHJlc3MpPC90ZD48L3RyPjx0cj48dGggYmdjb2xvcj02NjY2Y2M+Jm5ic3A7 PC90aD48dGQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNlbGVjdCBzaXplPTEgbmFt ZT1uZXRNYXNrPjxvcHRpb24gdmFsdWU9MCBzZWxlY3RlZD4yNTUuMjU1LjI1 NS4wPC9vcHRpb24+PG9wdGlvbiB2YWx1ZT0xMjg+MjU1LjI1NS4yNTUuMTI4 PC9vcHRpb24+PG9wdGlvbiB2YWx1ZT0xOTI+MjU1LjI1NS4yNTUuMTkyPC9v cHRpb24+PG9wdGlvbiB2YWx1ZT0yMjQ+MjU1LjI1NS4yNTUuMjI0PC9vcHRp b24+PG9wdGlvbiB2YWx1ZT0yNDA+MjU1LjI1NS4yNTUuMjQwPC9vcHRpb24+ PG9wdGlvbiB2YWx1ZT0yNDg+MjU1LjI1NS4yNTUuMjQ4PC9vcHRpb24+PG9w dGlvbiB2YWx1ZT0yNTI+MjU1LjI1NS4yNTUuMjUyPC9vcHRpb24+PC9zZWxl Y3Q+IDxmb250IGNvbG9yPWJsdWUgZmFjZT1BcmlhbCBzaXplPTI+IChTdWJu ZXQgTWFzayk8L3RkPjwvdHI+PHRyPjx0aCBiZ2NvbG9yPTY2NjZjYyBhbGln bj1yaWdodD48Zm9udCBjb2xvcj13aGl0ZSBmYWNlPUFyaWFsIHNpemU9Mj5X aXJlbGVzczombmJzcDsmbmJzcDs8L3RoPjx0ZD4mbmJzcDsmbmJzcDsmbmJz cDs8Zm9udCBjb2xvcj1ibHVlIGZhY2U9QXJpYWwgc2l6ZT0xPjxiPihNQUMg QWRkcmVzczogMDAtMDYtMjUtREEtQkMtNzEpPC90ZD48L3RyPjx0cj48dGgg Ymdjb2xvcj02NjY2Y2M+Jm5ic3A7PC90aD48dGQ+Jm5ic3A7Jm5ic3A7Jm5i c3A7PGZvbnQgZmFjZT12ZXJkYW5hIHNpemU9Mj48Yj48aW5wdXQgdHlwZT1y YWRpbyBuYW1lPXdpcmVsZXNzU3RhdHVzIHZhbHVlPTEgY2hlY2tlZD5FbmFi bGU8aW5wdXQgdHlwZT1yYWRpbyBuYW1lPXdpcmVsZXNzU3RhdHVzIHZhbHVl PTA+RGlzYWJsZTwvdGQ+PHRyPjx0aCBiZ2NvbG9yPTY2NjZjYz4mbmJzcDs8 L3RoPjx0ZD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8Zm9udCBmYWNlPXZl cmRhbmEgc2l6ZT0yPjxiPlNTSUQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwv Yj48L2ZvbnQ+PGlucHV0IG5hbWU9d2lyZWxlc3NFU1NJRCBzaXplPTIwIG1h eGxlbmd0aD0zMiB2YWx1ZT0nbGlua3N5cyc+PC90ZD48L3RyPjx0cj48dGgg Ymdjb2xvcj02NjY2Y2M+Jm5ic3A7PC90aD48dGQ+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGZvbnQgZmFjZT12ZXJkYW5hIHNpemU9Mj48Yj5TU0lEIEJy b2FkY2FzdDogJm5ic3A7IDxpbnB1dCB0eXBlPXJhZGlvIG5hbWU9YnJvYWRj YXN0U1NJRCB2YWx1ZT0xIGNoZWNrZWQ+RW5hYmxlPGlucHV0IHR5cGU9cmFk aW8gbmFtZT1icm9hZGNhc3RTU0lEIHZhbHVlPTA+RGlzYWJsZTwvdGQ+PHRy Pjx0aCBiZ2NvbG9yPTY2NjZjYz4mbmJzcDs8L3RoPjx0ZD4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8Zm9udCBmYWNlPXZlcmRhbmEgc2l6ZT0yPjxiPkNo YW5uZWw6ICZuYnNwOyA8L2I+PC9mb250PjxzZWxlY3QgbmFtZT13aXJlbGVz c0NoYW5uZWwgc2l6ZT0xPjxvcHRpb24gdmFsdWU9MT4gMSA8L29wdGlvbj48 b3B0aW9uIHZhbHVlPTI+IDIgPC9vcHRpb24+PG9wdGlvbiB2YWx1ZT0zPiAz IDwvb3B0aW9uPjxvcHRpb24gdmFsdWU9ND4gNCA8L29wdGlvbj48b3B0aW9u IHZhbHVlPTU+IDUgPC9vcHRpb24+PG9wdGlvbiB2YWx1ZT02IHNlbGVjdGVk PiA2IDwvb3B0aW9uPjxvcHRpb24gdmFsdWU9Nz4gNyA8L29wdGlvbj48b3B0 aW9uIHZhbHVlPTg+IDggPC9vcHRpb24+PG9wdGlvbiB2YWx1ZT05PiA5IDwv b3B0aW9uPjxvcHRpb24gdmFsdWU9MTA+IDEwIDwvb3B0aW9uPjxvcHRpb24g dmFsdWU9MTE+IDExIDwvb3B0aW9uPjwvc2VsZWN0Pjxmb250IGNvbG9yPWJs dWUgZmFjZT1BcmlhbCBzaXplPTI+IChEb21haW46IFVTQSk8L3RkPjwvdHI+ PHRyPjx0aCBiZ2NvbG9yPTY2NjZjYz4mbmJzcDs8L3RoPjx0ZD4gJm5ic3A7 ICZuYnNwOyA8Zm9udCBmYWNlPXZlcmRhbmEgc2l6ZT0yPjxiPldFUDogJm5i c3A7IDxpbnB1dCB0eXBlPXJhZGlvIG5hbWU9V2VwVHlwZSB2YWx1ZT0xPk1h bmRhdG9yeTxpbnB1dCB0eXBlPXJhZGlvIG5hbWU9V2VwVHlwZSB2YWx1ZT0w IGNoZWNrZWQ+RGlzYWJsZSAmbmJzcDs8L2I+PC9mb250PjxpbnB1dCB0eXBl PWJ1dHRvbiB2YWx1ZT0nV0VQIEtleSBTZXR0aW5nJyBvbkNsaWNrPXNob3dX RVAodGhpcyx0aGlzLmZvcm0pPjwvdGQ+PC90cj48dHI+PHRoIGJnY29sb3I9 NjY2NmNjIGFsaWduPXJpZ2h0Pjxicj48Zm9udCBjb2xvcj13aGl0ZSBmYWNl PUFyaWFsIHNpemU9Mj5JbnRlcm5ldCBDb25uZWN0aW9uIFR5cGU6Jm5ic3A7 Jm5ic3A7PC90aD48dGQ+PGJyPiZuYnNwOyAmbmJzcDs8Zm9udCBjb2xvcj1i bHVlIGZhY2U9QXJpYWwgc2l6ZT0xPjxiPihNQUMgQWRkcmVzczogMDAtMDYt MjUtREEtQkMtNzIpPC90ZD48L3RyPjx0cj48dGQgYmdjb2xvcj02NjY2Y2M+ Jm5ic3A7PC90ZD48dGQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNlbGVjdCBuYW1l PVdBTkNvbm5lY3Rpb25UeXBlIG9uQ2hhbmdlPVNlbFdBTih0aGlzLmZvcm0p PjxvcHRpb24gdmFsdWU9MT5PYnRhaW4gYW4gSVAgYXV0b21hdGljYWxseTwv b3B0aW9uPjxvcHRpb24gdmFsdWU9MiBzZWxlY3RlZD5TdGF0aWMgSVA8L29w dGlvbj48b3B0aW9uIHZhbHVlPTM+UFBQb0U8L29wdGlvbj48b3B0aW9uIHZh bHVlPTQ+UkFTIChmb3IgU2luZ1RlbCB1c2Vycyk8L29wdGlvbj48b3B0aW9u IHZhbHVlPTU+UFBUUDwvb3B0aW9uPjxvcHRpb24gdmFsdWU9Nj5IZWFydCBC ZWF0IFNpZ25hbDwvb3B0aW9uPjwvc2VsZWN0Pjxmb250IGNvbG9yPXJlZCBm YWNlPUFyaWFsIHNpemU9Mj4mbmJzcDsmbmJzcDtTZWxlY3QgdGhlIEludGVy bmV0IGNvbm5lY3Rpb24gdHlwZSB5b3Ugd2lzaCB0byB1c2U8L2ZvbnQ+PC90 ZD48L3RyPjx0cj48dGQgYmdDb2xvcj0jNjY2NmNjPiZuYnNwOzwvdGQ+PHRk Pjx0YWJsZT48dHI+PHRkPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxmb250 IGZhY2U9dmVyZGFuYSBzaXplPTI+PGI+U3BlY2lmeSBJbnRlcm5ldCBJUCBB ZGRyZXNzPC9iPjwvZm9udD48L3RkPjx0ZD48aW5wdXQgbmFtZT1hbGlhc0lQ MSBzaXplPTMgbWF4bGVuZ3RoPTMgdmFsdWU9MCBvbkNoYW5nZT1JUENoZWNr KHRoaXMpPiAuIDxpbnB1dCBuYW1lPWFsaWFzSVAyIHNpemU9MyBtYXhsZW5n dGg9MyB2YWx1ZT0wIG9uQ2hhbmdlPUlQQ2hlY2sodGhpcyk+IC4gPGlucHV0 IG5hbWU9YWxpYXNJUDMgc2l6ZT0zIG1heGxlbmd0aD0zIHZhbHVlPTAgb25D aGFuZ2U9SVBDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1hbGlhc0lQNCBz aXplPTMgbWF4bGVuZ3RoPTMgdmFsdWU9MCBvbkNoYW5nZT1JUDF0bzI1NCh0 aGlzKT48L3RkPjwvdHI+PHRyPjx0ZD48dWw+PGZvbnQgZmFjZT12ZXJkYW5h IHNpemU9MT48Yj5TdWJuZXQgTWFzazo8L3RkPjx0ZD48aW5wdXQgbmFtZT1h bGlhc01hc2tJUDAgc2l6ZT0zIG1heGxlbmd0aD0zIHZhbHVlPTI1NSBvbkNo YW5nZT1uZXRNYXNrQ2hlY2sodGhpcyk+IC4gPGlucHV0IG5hbWU9YWxpYXNN YXNrSVAxIHNpemU9MyBtYXhsZW5ndGg9MyB2YWx1ZT0yNTUgb25DaGFuZ2U9 bmV0TWFza0NoZWNrKHRoaXMpPiAuIDxpbnB1dCBuYW1lPWFsaWFzTWFza0lQ MiBzaXplPTMgbWF4bGVuZ3RoPTMgdmFsdWU9MjU0IG9uQ2hhbmdlPW5ldE1h c2tDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1hbGlhc01hc2tJUDMgc2l6 ZT0zIG1heGxlbmd0aD0zIHZhbHVlPTAgb25DaGFuZ2U9bmV0TWFza0NoZWNr Myh0aGlzKT48L3RkPjwvdHI+PHRyPjx0ZD48dWw+PGZvbnQgZmFjZT12ZXJk YW5hIHNpemU9MT48Yj5EZWZhdWx0IEdhdGV3YXkgQWRkcmVzczo8L3RkPjx0 ZD48aW5wdXQgbmFtZT1yb3V0ZXJJUDEgc2l6ZT0zIG1heGxlbmd0aD0zIHZh bHVlPTAgb25DaGFuZ2U9SVBDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1y b3V0ZXJJUDIgc2l6ZT0zIG1heGxlbmd0aD0zIHZhbHVlPTAgb25DaGFuZ2U9 SVBDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1yb3V0ZXJJUDMgc2l6ZT0z IG1heGxlbmd0aD0zIHZhbHVlPTAgb25DaGFuZ2U9SVBDaGVjayh0aGlzKT4g LiA8aW5wdXQgbmFtZT1yb3V0ZXJJUDQgc2l6ZT0zIG1heGxlbmd0aD0zIHZh bHVlPTAgb25DaGFuZ2U9SVBDaGVjayh0aGlzKT48L3RkPjwvdHI+PHRyPjx0 ZCBhbGlnbj1yaWdodD48Zm9udCBmYWNlPXZlcmRhbmEgc2l6ZT0xPjxiPkRO UyhSZXF1aXJlZCkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsxOjwvYj48L2ZvbnQ+PC90 ZD48dGQ+PGlucHV0IG5hbWU9ZG5zQTEgc2l6ZT0zIG1heGxlbmd0aD0zIHZh bHVlPTAgb25DaGFuZ2U9SVBDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1k bnNBMiBzaXplPTMgbWF4bGVuZ3RoPTMgdmFsdWU9MCBvbkNoYW5nZT1JUENo ZWNrKHRoaXMpPiAuIDxpbnB1dCBuYW1lPWRuc0EzIHNpemU9MyBtYXhsZW5n dGg9MyB2YWx1ZT0wIG9uQ2hhbmdlPUlQQ2hlY2sodGhpcyk+IC4gPGlucHV0 IG5hbWU9ZG5zQTQgc2l6ZT0zIG1heGxlbmd0aD0zIHZhbHVlPTAgb25DaGFu Z2U9SVBDaGVjayh0aGlzKT48L3RkPjwvdHI+PHRyPjx0ZCBhbGlnbj1yaWdo dD48Zm9udCBmYWNlPXZlcmRhbmEgc2l6ZT0xPjxiPjI6PC9iPjwvZm9udD48 L3RkPjx0ZD48aW5wdXQgbmFtZT1kbnNCMSBzaXplPTMgbWF4bGVuZ3RoPTMg dmFsdWU9MCBvbkNoYW5nZT1JUENoZWNrKHRoaXMpPiAuIDxpbnB1dCBuYW1l PWRuc0IyIHNpemU9MyBtYXhsZW5ndGg9MyB2YWx1ZT0wIG9uQ2hhbmdlPUlQ Q2hlY2sodGhpcyk+IC4gPGlucHV0IG5hbWU9ZG5zQjMgc2l6ZT0zIG1heGxl bmd0aD0zIHZhbHVlPTAgb25DaGFuZ2U9SVBDaGVjayh0aGlzKT4gLiA8aW5w dXQgbmFtZT1kbnNCNCBzaXplPTMgbWF4bGVuZ3RoPTMgdmFsdWU9MCBvbkNo YW5nZT1JUENoZWNrKHRoaXMpPjwvdGQ+PC90cj48dHI+PHRkIGFsaWduPXJp Z2h0Pjxmb250IGZhY2U9dmVyZGFuYSBzaXplPTE+PGI+Mzo8L2I+PC9mb250 PjwvdGQ+PHRkPjxpbnB1dCBuYW1lPWRuc0MxIHNpemU9MyBtYXhsZW5ndGg9 MyB2YWx1ZT0wIG9uQ2hhbmdlPUlQQ2hlY2sodGhpcyk+IC4gPGlucHV0IG5h bWU9ZG5zQzIgc2l6ZT0zIG1heGxlbmd0aD0zIHZhbHVlPTAgb25DaGFuZ2U9 SVBDaGVjayh0aGlzKT4gLiA8aW5wdXQgbmFtZT1kbnNDMyBzaXplPTMgbWF4 bGVuZ3RoPTMgdmFsdWU9MCBvbkNoYW5nZT1JUENoZWNrKHRoaXMpPiAuIDxp bnB1dCBuYW1lPWRuc0M0IHNpemU9MyBtYXhsZW5ndGg9MyB2YWx1ZT0wIG9u Q2hhbmdlPUlQQ2hlY2sodGhpcyk+PC90ZD48L3RyPjwvdGFibGU+PC90ZD48 L3RyPjx0cj48dGggYmdjb2xvcj02NjY2Y2M+Jm5ic3A7PC90aD48dGQ+PGJy Pjxicj4mbmJzcDsgJm5ic3A7PGlucHV0IHR5cGU9YnV0dG9uIHZhbHVlPScg QXBwbHkgJyBvbkNsaWNrPUNoZWNrT25lUGFnZSh0aGlzLmZvcm0pPiA8aW5w dXQgdHlwZT1yZXNldCB2YWx1ZT0nIENhbmNlbCAnPiA8cD4gPC90ZD48L3Ry PjwvZm9ybT48L3RhYmxlPjwvdGg+PC90cj48L3RhYmxlPjwvdGg+PC90cj48 L3RhYmxlPjwvY2VudGVyPjwvYm9keT48L2h0bWw+ --Boundary_(ID_vn9jjbZxpcb4CJ56YBuV7w)-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jun 20 18:14:58 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12488 for ; Fri, 20 Jun 2003 18:14:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h5KM22j31634; Fri, 20 Jun 2003 18:02:02 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h5KM1Vj31621 for ; Fri, 20 Jun 2003 18:01:31 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5KM1FHa041225 for ; Fri, 20 Jun 2003 18:01:15 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 8C6D0443A5; Fri, 20 Jun 2003 18:01:10 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 637F5443A4 for ; Fri, 20 Jun 2003 18:01:10 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5KM18c6030622 for ; Fri, 20 Jun 2003 18:01:08 -0400 (EDT) Received: from research.bell-labs.com (karma.research.bell-labs.com [135.104.54.43]) by nslocum.cs.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5KM17Hd12634333; Fri, 20 Jun 2003 18:01:07 -0400 (EDT) Message-ID: <3EF38423.2070309@research.bell-labs.com> From: Rajeev Agrawala User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPTEL] is the list active Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 20 Jun 2003 18:01:07 -0400 Content-Transfer-Encoding: 7bit Hi, Is this list active anymore or can I shut down the list on the lists.bell-labs.com server? I don't see much volume there. Thanks, -- rajeev _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Jun 21 07:58:36 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06561 for ; Sat, 21 Jun 2003 07:58:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h5LBw4j04594; Sat, 21 Jun 2003 07:58:05 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h5LBvxj04581 for ; Sat, 21 Jun 2003 07:57:59 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5LBvhHa047674 for ; Sat, 21 Jun 2003 07:57:43 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 90EDC443A5; Sat, 21 Jun 2003 07:57:38 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 6800D443A4 for ; Sat, 21 Jun 2003 07:57:38 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5LBvac6062711 for ; Sat, 21 Jun 2003 07:57:37 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5LBvhUx091907 for ; Sat, 21 Jun 2003 07:57:44 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.144]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5LBvWsm006962; Sat, 21 Jun 2003 07:57:32 -0400 (EDT) Message-ID: <3EF44829.1000808@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajeev Agrawala Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] is the list active References: <3EF38423.2070309@research.bell-labs.com> In-Reply-To: <3EF38423.2070309@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 21 Jun 2003 07:57:29 -0400 Content-Transfer-Encoding: 7bit This list is inactive, and can be shut down. The IETF iptel list is now located at iptel@ietf.org. -Jonathan R. Rajeev Agrawala wrote: > Hi, > > Is this list active anymore or can I shut down the list on the > lists.bell-labs.com server? I don't see much volume there. > > Thanks, > > -- > rajeev > > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From exim@www1.ietf.org Sun Jun 22 22:59:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24654 for ; Sun, 22 Jun 2003 22:59:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N2xF112862 for iptel-archive@odin.ietf.org; Sun, 22 Jun 2003 22:59:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UHY3-0003LN-PC for iptel-web-archive@optimus.ietf.org; Sun, 22 Jun 2003 22:59:15 -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 WAA24651 for ; Sun, 22 Jun 2003 22:59:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UHY0-0006hC-00 for iptel-web-archive@ietf.org; Sun, 22 Jun 2003 22:59:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UHXu-0006h8-00 for iptel-web-archive@ietf.org; Sun, 22 Jun 2003 22:59:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UHXo-0003Jc-HA; Sun, 22 Jun 2003 22:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UHWc-0003Is-Qk for iptel@optimus.ietf.org; Sun, 22 Jun 2003 22:58: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 WAA24613 for ; Sun, 22 Jun 2003 22:57:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UHWZ-0006gZ-00 for iptel@ietf.org; Sun, 22 Jun 2003 22:57:43 -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 19UHWO-0006gO-00 for iptel@ietf.org; Sun, 22 Jun 2003 22:57:32 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2003 20:00:01 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5N2uuQx017551; Sun, 22 Jun 2003 19:56:57 -0700 (PDT) Received: from [192.168.0.2] (sjc-vpn3-890.cisco.com [10.21.67.122]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFI28044; Sun, 22 Jun 2003 19:56:55 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 From: Cullen Jennings To: CC: Jonathan Rosenberg Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Iptel] Tel URL and ENUM dips 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: Sun, 22 Jun 2003 19:52:01 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There has been some discussion about indicated a ENUM query has already been done for a given tel URL. The use case given is usually something along the following lines: A call control element such as a SIP phone gets a phone number and tries an ENUM lookup on it. No record is found in the DNS query so the call is sent to a proxy (or a gatekeeper) that might know how to route the call. This proxy does not know the ENUM query has been tried so it tries the ENUM query over again. This is somewhat wasteful and adds to the latency of the setup but does not introduce any horrible failures into the system. I have heard three proposals to deal with this. They are: A) Don't do anything - it's not that big a problem. B) Add a flag to the tel URL to allow it to indicate if an ENUM query has been done - much like the local number portability indicator. C) Create a new URL, say an enum URL, that specifically indicates a enum query is required and change the semantics of the tel URL to specifically not do an ENUM query. Are there other proposal to this problem that I am missing? The slim number of opinions I have got so far mostly favor B. If there are strong argument for or against any of these - sometime between now and Vienna would be a good time to get them on the list. Perhaps deciding this is not possible without a stronger statement of what the semantics of tel URL are. If people feel this is the case - let's get the issues about tel semantics on the table. Thanks, Cullen _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Sun Jun 22 23:53:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25729 for ; Sun, 22 Jun 2003 23:53:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N3r7418232 for iptel-archive@odin.ietf.org; Sun, 22 Jun 2003 23:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UIOB-0004jz-L6 for iptel-web-archive@optimus.ietf.org; Sun, 22 Jun 2003 23:53:07 -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 XAA25712 for ; Sun, 22 Jun 2003 23:53:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UIO9-0006wD-00 for iptel-web-archive@ietf.org; Sun, 22 Jun 2003 23:53:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UIO3-0006wA-00 for iptel-web-archive@ietf.org; Sun, 22 Jun 2003 23:52:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UIO4-0004iS-Uf; Sun, 22 Jun 2003 23:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UINs-0004hz-C9 for iptel@optimus.ietf.org; Sun, 22 Jun 2003 23:52: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 XAA25708 for ; Sun, 22 Jun 2003 23:52:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UINq-0006vu-00 for iptel@ietf.org; Sun, 22 Jun 2003 23:52:46 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19UINa-0006vl-00 for iptel@ietf.org; Sun, 22 Jun 2003 23:52:30 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5N3qHkM021752; Sun, 22 Jun 2003 23:52:17 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h5N3qFJ13736; Sun, 22 Jun 2003 23:52:16 -0400 Message-ID: <3EF67888.4010401@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: iptel@ietf.org, Jonathan Rosenberg Subject: Re: [Iptel] Tel URL and ENUM dips References: In-Reply-To: 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: Sun, 22 Jun 2003 23:48:24 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I tend to favor (B) - it qualifies the meaning of tel, but not strongly enough that a new scheme is justified (since option (A) works, if sub-optimally). Semantics are currently defined as "The ``tel'' URI describes resources identified by telephone numbers." (from the abstract of 2806bis) As I've noted in earlier discussions, tel URIs are closer in spirit to URNs such as ISBNs than they are to, say, a SIP URI or http URI. (One could make a case that they should be urn:tel:, but I won't go there for now.) If looked at as a URN-like thingie, the question is essentially moot, or only as interesting as asking what the semantics of an ISBN are. A tel URI doesn't "do" anything unless it is translated into a dialstring (internally), SIP URI (via ENUM) or some other 'actionable' URL that has protocol semantics - just like an ISBN URN doesn't 'do' anything until it is translated into a HTTP URL, say. May I suggest that any such discussion has to include concise, testable definitions. Cullen Jennings wrote: > There has been some discussion about indicated a ENUM query has already been > done for a given tel URL. > > The use case given is usually something along the following lines: A call > control element such as a SIP phone gets a phone number and tries an ENUM > lookup on it. No record is found in the DNS query so the call is sent to a > proxy (or a gatekeeper) that might know how to route the call. This proxy > does not know the ENUM query has been tried so it tries the ENUM query over > again. > > This is somewhat wasteful and adds to the latency of the setup but does not > introduce any horrible failures into the system. I have heard three > proposals to deal with this. They are: > > A) Don't do anything - it's not that big a problem. > > B) Add a flag to the tel URL to allow it to indicate if an ENUM query has > been done - much like the local number portability indicator. > > C) Create a new URL, say an enum URL, that specifically indicates a enum > query is required and change the semantics of the tel URL to specifically > not do an ENUM query. > > Are there other proposal to this problem that I am missing? The slim number > of opinions I have got so far mostly favor B. If there are strong argument > for or against any of these - sometime between now and Vienna would be a > good time to get them on the list. > > Perhaps deciding this is not possible without a stronger statement of what > the semantics of tel URL are. If people feel this is the case - let's get > the issues about tel semantics on the table. > > Thanks, > Cullen > > _______________________________________________ > 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 Mon Jun 23 01:48:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27637 for ; Mon, 23 Jun 2003 01:48:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N5m8r30606 for iptel-archive@odin.ietf.org; Mon, 23 Jun 2003 01:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKBU-0007xZ-JP for iptel-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 01:48:08 -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 BAA27630 for ; Mon, 23 Jun 2003 01:48:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKBR-0007Ll-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 01:48:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UKBL-0007Li-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 01:47:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKBM-0007v8-En; Mon, 23 Jun 2003 01:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKBE-0007ux-KJ for iptel@optimus.ietf.org; Mon, 23 Jun 2003 01:47: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 BAA27603 for ; Mon, 23 Jun 2003 01:47:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKBB-0007Ld-00 for iptel@ietf.org; Mon, 23 Jun 2003 01:47:49 -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 19UKB0-0007LE-00 for iptel@ietf.org; Mon, 23 Jun 2003 01:47:38 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2003 22:49:51 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5N5kkRJ011261 for ; Sun, 22 Jun 2003 22:46:47 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIK00855; Sun, 22 Jun 2003 22:40:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Rohan Mahy To: iptel@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <4274F2B3-A53E-11D7-8E0D-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Iptel] new version of Calling Party Category draft available 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: Sun, 22 Jun 2003 22:48:05 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I've taken up editorship of what was Jon Peterson's cpc parameter draft. I've added or updated a number of references, changed tel URL to tel URI throughout, explained why operator languages are not included, and added the "hotel" value from ANI II. I also listed a handful of values (hospital, police, cellular, cellular-roaming) we may want to consider including. These appeared in an Appendix to the Remote-Party-ID draft, but no one I have spoken with can find a reference to them. I am assuming they are in national variants. Finally, the current draft has a payphone parameter, but does not distinguish between variations (coin vs. coinless, restricts incoming calls or not, is public or private). If you feel these distinctions are important, please provide some appropriate reference and provide motivation. http://www.softarmor.com/iptel/drafts/draft-mahy-iptel-cpc-00.html http://www.softarmor.com/iptel/drafts/draft-mahy-iptel-cpc-00.txt thanks, -rohan _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Mon Jun 23 05:15:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13535 for ; Mon, 23 Jun 2003 05:15:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N9F8x01393 for iptel-archive@odin.ietf.org; Mon, 23 Jun 2003 05:15:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNPo-0000MO-0t for iptel-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 05:15:08 -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 FAA13528 for ; Mon, 23 Jun 2003 05:15:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UNPk-0000le-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 05:15:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UNPf-0000lb-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 05:14:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNPg-0000Jj-SS; Mon, 23 Jun 2003 05:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNOi-0000IC-Ol for iptel@optimus.ietf.org; Mon, 23 Jun 2003 05:14:15 -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 FAA13520 for ; Mon, 23 Jun 2003 05:13:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UNOQ-0000lJ-00 for iptel@ietf.org; Mon, 23 Jun 2003 05:13:42 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19UNOF-0000lA-00 for iptel@ietf.org; Mon, 23 Jun 2003 05:13:32 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jun 2003 10:12:59 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFGB0SP1; Mon, 23 Jun 2003 10:12:56 +0100 From: "Conroy, Lawrence (SMTP)" To: Henning Schulzrinne Cc: iptel@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <3EF67888.4010401@cs.columbia.edu> References: <3EF67888.4010401@cs.columbia.edu> Subject: Re: [Iptel] Tel URL and ENUM dips Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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, 23 Jun 2003 10:13:01 +0100 Hi Folks, You can guess that I'm in favour of (C), as I feel that the current "dual use" of the "tel:" URI is confusing. As I've argued before, splitting "tel:" from "enum:" would be pretty clear - "enum:" requires an ENUM lookup to be resolved; "tel:" does NOT require an ENUM lookup (and existing RFC2806 "tel:" software that by definition doesn't do an ENUM lookup carries on this way). There is a tendency to consider the "tel:" URI to be associated with a telephony resource - i.e. it can be *used* to deliver a call to a telephony-addressed end point. In theory it could imply that the recipient will be able to handle only a web request, but in practice it is usually taken to mean that this addresses an end point that can handle Real Time Communication sessions. Creating an "enum:" identifier means that we have something that is guaranteed to say nothing about the session that will result - the only way to even find out the session choices is via an ENUM lookup. IIRC, Jon has argued that, at most, we should have a URI parameter such as "enum=yes". I think that the effect is similar, with differences only in some implementation details; specifically, if there's a browser plug-in for "tel:" and this cannot or won't do ENUM lookups, then having a different scheme reduces parsing - minor point. I do still have one confusion on the use of a enum://tel:;enum=yes URI in a session control/call setup sequence. Doesn't this have the same security issues as CPC and the original ideas on "database dip" indicators? all the best, Lawrence >I tend to favor (B) - it qualifies the meaning of tel, but not >strongly enough that a new scheme is justified (since option (A) >works, if sub-optimally). > >Semantics are currently defined as "The ``tel'' URI describes >resources identified by telephone numbers." (from the abstract of >2806bis) > >As I've noted in earlier discussions, tel URIs are closer in spirit >to URNs such as ISBNs than they are to, say, a SIP URI or http URI. >(One could make a case that they should be urn:tel:, but I won't go >there for now.) If looked at as a URN-like thingie, the question is >essentially moot, or only as interesting as asking what the >semantics of an ISBN are. A tel URI doesn't "do" anything unless it >is translated into a dialstring (internally), SIP URI (via ENUM) or >some other 'actionable' URL that has protocol semantics - just like >an ISBN URN doesn't 'do' anything until it is translated into a HTTP >URL, say. > >May I suggest that any such discussion has to include concise, >testable definitions. > >Cullen Jennings wrote: > >>There has been some discussion about indicated a ENUM query has already been >>done for a given tel URL. >> >>The use case given is usually something along the following lines: A call >>control element such as a SIP phone gets a phone number and tries an ENUM >>lookup on it. No record is found in the DNS query so the call is sent to a >>proxy (or a gatekeeper) that might know how to route the call. This proxy >>does not know the ENUM query has been tried so it tries the ENUM query over >>again. >> >>This is somewhat wasteful and adds to the latency of the setup but does not >>introduce any horrible failures into the system. I have heard three >>proposals to deal with this. They are: >> >>A) Don't do anything - it's not that big a problem. >> >>B) Add a flag to the tel URL to allow it to indicate if an ENUM query has >>been done - much like the local number portability indicator. >> >>C) Create a new URL, say an enum URL, that specifically indicates a enum >>query is required and change the semantics of the tel URL to specifically >>not do an ENUM query. >> >>Are there other proposal to this problem that I am missing? The slim number >>of opinions I have got so far mostly favor B. If there are strong argument >>for or against any of these - sometime between now and Vienna would be a >>good time to get them on the list. >> >>Perhaps deciding this is not possible without a stronger statement of what >>the semantics of tel URL are. If people feel this is the case - let's get >>the issues about tel semantics on the table. >> >>Thanks, >>Cullen >> >>_______________________________________________ >>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 -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Mon Jun 23 10:37:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22947 for ; Mon, 23 Jun 2003 10:37:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NEbCX13875 for iptel-archive@odin.ietf.org; Mon, 23 Jun 2003 10:37:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19USRU-0003bi-77 for iptel-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 10:37:12 -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 KAA22930 for ; Mon, 23 Jun 2003 10:37:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19USRR-0002b3-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 10:37:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19USRM-0002b0-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 10:37:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19USRI-0003WX-QN; Mon, 23 Jun 2003 10:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19USQX-0003Ro-Ai for iptel@optimus.ietf.org; Mon, 23 Jun 2003 10:36:13 -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 KAA22896 for ; Mon, 23 Jun 2003 10:36:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19USQU-0002aU-00 for iptel@ietf.org; Mon, 23 Jun 2003 10:36:10 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19USQF-0002a4-00 for iptel@ietf.org; Mon, 23 Jun 2003 10:35:57 -0400 Received: from rshockeybox.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5NEbt704058; Mon, 23 Jun 2003 07:37:56 -0700 Message-Id: <5.2.0.9.2.20030623102804.0594b008@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: "Conroy, Lawrence (SMTP)" , Henning Schulzrinne From: Richard Shockey Subject: Re: [Iptel] Tel URL and ENUM dips Cc: iptel@ietf.org In-Reply-To: References: <3EF67888.4010401@cs.columbia.edu> <3EF67888.4010401@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 23 Jun 2003 10:35:08 -0400 At 10:13 AM 6/23/2003 +0100, Conroy, Lawrence (SMTP) wrote: >Hi Folks, > You can guess that I'm in favour of (C), as I feel that the current >"dual use" of the "tel:" URI is confusing. As I've argued before, splitting >"tel:" from "enum:" would be pretty clear - "enum:" requires an ENUM lookup >to be resolved; "tel:" does NOT require an ENUM lookup (and existing RFC2806 >"tel:" software that by definition doesn't do an ENUM lookup carries on this >way). Well as we know this has come up several times before ..specifically I remember this discussion in Yokohama where the concept of the ENUM URL was not well received in the ENUM WG.. Obviously I favor B since 1. it matches current practice 2. I've yet to see a convincing argument that C. is necessary. The presence of a tel: url could have a presumption that a query has _not_ been done and the attachment of the dip indicator would then indicate it has. IMHO the ENUM indicator is a good idea and worth proceeding with documentation. >There is a tendency to consider the "tel:" URI to be associated with a >telephony >resource - i.e. it can be *used* to deliver a call to a >telephony-addressed end >point. In theory it could imply that the recipient will be able to handle only >a web request, but in practice it is usually taken to mean that this addresses >an end point that can handle Real Time Communication sessions. > >Creating an "enum:" identifier means that we have something that is guaranteed >to say nothing about the session that will result - the only way to even find >out the session choices is via an ENUM lookup. > >IIRC, Jon has argued that, at most, we should have a URI parameter such as >"enum=yes". I think that the effect is similar, with differences only in some >implementation details; specifically, if there's a browser plug-in for "tel:" >and this cannot or won't do ENUM lookups, then having a different scheme >reduces parsing - minor point. > >I do still have one confusion on the use of a enum://tel:;enum=yes URI in >a session control/call setup sequence. Doesn't this have the same security >issues as CPC and the original ideas on "database dip" indicators? > >all the best, > Lawrence > >>I tend to favor (B) - it qualifies the meaning of tel, but not strongly >>enough that a new scheme is justified (since option (A) works, if >>sub-optimally). >> >>Semantics are currently defined as "The ``tel'' URI describes resources >>identified by telephone numbers." (from the abstract of 2806bis) >> >>As I've noted in earlier discussions, tel URIs are closer in spirit to >>URNs such as ISBNs than they are to, say, a SIP URI or http URI. (One >>could make a case that they should be urn:tel:, but I won't go there for >>now.) If looked at as a URN-like thingie, the question is essentially >>moot, or only as interesting as asking what the semantics of an ISBN are. >>A tel URI doesn't "do" anything unless it is translated into a dialstring >>(internally), SIP URI (via ENUM) or some other 'actionable' URL that has >>protocol semantics - just like an ISBN URN doesn't 'do' anything until it >>is translated into a HTTP URL, say. >> >>May I suggest that any such discussion has to include concise, testable >>definitions. >> >>Cullen Jennings wrote: >> >>>There has been some discussion about indicated a ENUM query has already been >>>done for a given tel URL. >>> >>>The use case given is usually something along the following lines: A call >>>control element such as a SIP phone gets a phone number and tries an ENUM >>>lookup on it. No record is found in the DNS query so the call is sent to a >>>proxy (or a gatekeeper) that might know how to route the call. This proxy >>>does not know the ENUM query has been tried so it tries the ENUM query over >>>again. >>> >>>This is somewhat wasteful and adds to the latency of the setup but does not >>>introduce any horrible failures into the system. I have heard three >>>proposals to deal with this. They are: >>> >>>A) Don't do anything - it's not that big a problem. >>> >>>B) Add a flag to the tel URL to allow it to indicate if an ENUM query has >>>been done - much like the local number portability indicator. >>> >>>C) Create a new URL, say an enum URL, that specifically indicates a enum >>>query is required and change the semantics of the tel URL to specifically >>>not do an ENUM query. >>> >>>Are there other proposal to this problem that I am missing? The slim number >>>of opinions I have got so far mostly favor B. If there are strong argument >>>for or against any of these - sometime between now and Vienna would be a >>>good time to get them on the list. >>> >>>Perhaps deciding this is not possible without a stronger statement of what >>>the semantics of tel URL are. If people feel this is the case - let's get >>>the issues about tel semantics on the table. >>> >>>Thanks, >>>Cullen >>> >>>_______________________________________________ >>>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 > > >-- >----------------------------------------------------------------------- >Roke Manor Research : This information is provided "as is" and is not >: intended to create any contractual or legal > : relationship. > >_______________________________________________ >Iptel mailing list >Iptel@ietf.org >https://www.ietf.org/mailman/listinfo/iptel >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Mon Jun 23 13:22:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29778 for ; Mon, 23 Jun 2003 13:22:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NHM8613930 for iptel-archive@odin.ietf.org; Mon, 23 Jun 2003 13:22:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UV16-0003cb-A4 for iptel-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 13:22:08 -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 NAA29760 for ; Mon, 23 Jun 2003 13:22:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UV14-00044f-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 13:22:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UV0y-00044c-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 13:22:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UV0y-0003bO-Mi; Mon, 23 Jun 2003 13:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UV0E-0003ak-Ob for iptel@optimus.ietf.org; Mon, 23 Jun 2003 13:21: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 NAA29728 for ; Mon, 23 Jun 2003 13:21:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UV0C-000441-00 for iptel@ietf.org; Mon, 23 Jun 2003 13:21:12 -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 19UV01-00043Z-00 for iptel@ietf.org; Mon, 23 Jun 2003 13:21:02 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 23 Jun 2003 10:23:17 -0800 Received: from cisco.com (sjc-vpn4-687.cisco.com [10.21.82.175]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5NHJxQx023326; Mon, 23 Jun 2003 10:20:05 -0700 (PDT) Message-ID: <3EF736BE.53DD25A5@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: Richard Shockey CC: Conroy@cisco.com, Lawrence (SMTP) , Henning Schulzrinne , iptel@ietf.org, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Iptel] Tel URL and ENUM dips References: <3EF67888.4010401@cs.columbia.edu> <3EF67888.4010401@cs.columbia.edu> <5.2.0.9.2.20030623102804.0594b008@shockey.us> 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, 23 Jun 2003 13:19:58 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I favor "B" as well, but (as Patrick pointed out recently in a private discussion about this), there is the issue of allowing for use of alternative roots for "enum-like" applications, in which case a simple boolean will no longer do. -- Flemming Richard Shockey wrote: > At 10:13 AM 6/23/2003 +0100, Conroy, Lawrence (SMTP) wrote: > > >Hi Folks, > > You can guess that I'm in favour of (C), as I feel that the current > >"dual use" of the "tel:" URI is confusing. As I've argued before, splitting > >"tel:" from "enum:" would be pretty clear - "enum:" requires an ENUM lookup > >to be resolved; "tel:" does NOT require an ENUM lookup (and existing RFC2806 > >"tel:" software that by definition doesn't do an ENUM lookup carries on this > >way). > > Well as we know this has come up several times before ..specifically I > remember this discussion in Yokohama where the concept of the ENUM URL was > not well received in the ENUM WG.. > > Obviously I favor B since 1. it matches current practice 2. I've yet to see > a convincing argument that C. is necessary. The presence of a tel: url > could have a presumption that a query has _not_ been done and the > attachment of the dip indicator would then indicate it has. > > IMHO the ENUM indicator is a good idea and worth proceeding with documentation. > > >There is a tendency to consider the "tel:" URI to be associated with a > >telephony > >resource - i.e. it can be *used* to deliver a call to a > >telephony-addressed end > >point. In theory it could imply that the recipient will be able to handle only > >a web request, but in practice it is usually taken to mean that this addresses > >an end point that can handle Real Time Communication sessions. > > > >Creating an "enum:" identifier means that we have something that is guaranteed > >to say nothing about the session that will result - the only way to even find > >out the session choices is via an ENUM lookup. > > > >IIRC, Jon has argued that, at most, we should have a URI parameter such as > >"enum=yes". I think that the effect is similar, with differences only in some > >implementation details; specifically, if there's a browser plug-in for "tel:" > >and this cannot or won't do ENUM lookups, then having a different scheme > >reduces parsing - minor point. > > > >I do still have one confusion on the use of a enum://tel:;enum=yes URI in > >a session control/call setup sequence. Doesn't this have the same security > >issues as CPC and the original ideas on "database dip" indicators? > > > >all the best, > > Lawrence > > > >>I tend to favor (B) - it qualifies the meaning of tel, but not strongly > >>enough that a new scheme is justified (since option (A) works, if > >>sub-optimally). > >> > >>Semantics are currently defined as "The ``tel'' URI describes resources > >>identified by telephone numbers." (from the abstract of 2806bis) > >> > >>As I've noted in earlier discussions, tel URIs are closer in spirit to > >>URNs such as ISBNs than they are to, say, a SIP URI or http URI. (One > >>could make a case that they should be urn:tel:, but I won't go there for > >>now.) If looked at as a URN-like thingie, the question is essentially > >>moot, or only as interesting as asking what the semantics of an ISBN are. > >>A tel URI doesn't "do" anything unless it is translated into a dialstring > >>(internally), SIP URI (via ENUM) or some other 'actionable' URL that has > >>protocol semantics - just like an ISBN URN doesn't 'do' anything until it > >>is translated into a HTTP URL, say. > >> > >>May I suggest that any such discussion has to include concise, testable > >>definitions. > >> > >>Cullen Jennings wrote: > >> > >>>There has been some discussion about indicated a ENUM query has already been > >>>done for a given tel URL. > >>> > >>>The use case given is usually something along the following lines: A call > >>>control element such as a SIP phone gets a phone number and tries an ENUM > >>>lookup on it. No record is found in the DNS query so the call is sent to a > >>>proxy (or a gatekeeper) that might know how to route the call. This proxy > >>>does not know the ENUM query has been tried so it tries the ENUM query over > >>>again. > >>> > >>>This is somewhat wasteful and adds to the latency of the setup but does not > >>>introduce any horrible failures into the system. I have heard three > >>>proposals to deal with this. They are: > >>> > >>>A) Don't do anything - it's not that big a problem. > >>> > >>>B) Add a flag to the tel URL to allow it to indicate if an ENUM query has > >>>been done - much like the local number portability indicator. > >>> > >>>C) Create a new URL, say an enum URL, that specifically indicates a enum > >>>query is required and change the semantics of the tel URL to specifically > >>>not do an ENUM query. > >>> > >>>Are there other proposal to this problem that I am missing? The slim number > >>>of opinions I have got so far mostly favor B. If there are strong argument > >>>for or against any of these - sometime between now and Vienna would be a > >>>good time to get them on the list. > >>> > >>>Perhaps deciding this is not possible without a stronger statement of what > >>>the semantics of tel URL are. If people feel this is the case - let's get > >>>the issues about tel semantics on the table. > >>> > >>>Thanks, > >>>Cullen > >>> _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Mon Jun 23 14:45:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03658 for ; Mon, 23 Jun 2003 14:45:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NIj9S27330 for iptel-archive@odin.ietf.org; Mon, 23 Jun 2003 14:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UWJQ-00076i-8y for iptel-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 14:45:08 -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 OAA03648 for ; Mon, 23 Jun 2003 14:45:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UWJN-0004kB-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 14:45:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UWJH-0004k8-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 14:44:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UWJJ-00074x-Bh; Mon, 23 Jun 2003 14:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UWIb-00074C-Gm for iptel@optimus.ietf.org; Mon, 23 Jun 2003 14:44:17 -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 OAA03634 for ; Mon, 23 Jun 2003 14:44:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UWIY-0004js-00 for iptel@ietf.org; Mon, 23 Jun 2003 14:44:14 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19UWIN-0004iY-00 for iptel@ietf.org; Mon, 23 Jun 2003 14:44:03 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2003 11:43:43 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5NIfoGe014017; Mon, 23 Jun 2003 11:41:51 -0700 (PDT) Received: from mhammer-w2k02.cisco.com (dhcp-hrn-64-100-229-140.cisco.com [64.100.229.140]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEQ33620; Mon, 23 Jun 2003 11:41:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20030623143619.04957540@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Flemming Andreasen From: Michael Hammer Subject: Re: [Iptel] Tel URL and ENUM dips Cc: Richard Shockey , Conroy@cisco.com, Lawrence (SMTP) , Henning Schulzrinne , iptel@ietf.org, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= In-Reply-To: <3EF736BE.53DD25A5@cisco.com> References: <3EF67888.4010401@cs.columbia.edu> <3EF67888.4010401@cs.columbia.edu> <5.2.0.9.2.20030623102804.0594b008@shockey.us> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_20124217==_.ALT" 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, 23 Jun 2003 14:41:49 -0400 --=====================_20124217==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Flemming, Are you suggesting that the parameter should list out all the roots tried thus far, and only do dip if another known root hasn't be checked yet? Would at some point, the list be long enough that it would be faster to simply do option "A" do dips in the ENUM sites you know? Could the presence of "ENUMi" (versus ENUM="yes") simply mean that the golden root had been tried? Mike At 01:19 PM 6/23/2003 -0400, Flemming Andreasen wrote: >I favor "B" as well, but (as Patrick pointed out recently in a private >discussion >about this), there is the issue of allowing for use of alternative roots for >"enum-like" applications, in which case a simple boolean will no longer do. > >-- Flemming > >Richard Shockey wrote: > > > At 10:13 AM 6/23/2003 +0100, Conroy, Lawrence (SMTP) wrote: > > > > >Hi Folks, > > > You can guess that I'm in favour of (C), as I feel that the current > > >"dual use" of the "tel:" URI is confusing. As I've argued before, > splitting > > >"tel:" from "enum:" would be pretty clear - "enum:" requires an ENUM > lookup > > >to be resolved; "tel:" does NOT require an ENUM lookup (and existing > RFC2806 > > >"tel:" software that by definition doesn't do an ENUM lookup carries > on this > > >way). > > > > Well as we know this has come up several times before ..specifically I > > remember this discussion in Yokohama where the concept of the ENUM URL was > > not well received in the ENUM WG.. > > > > Obviously I favor B since 1. it matches current practice 2. I've yet to see > > a convincing argument that C. is necessary. The presence of a tel: url > > could have a presumption that a query has _not_ been done and the > > attachment of the dip indicator would then indicate it has. > > > > IMHO the ENUM indicator is a good idea and worth proceeding with > documentation. > > > > >There is a tendency to consider the "tel:" URI to be associated with a > > >telephony > > >resource - i.e. it can be *used* to deliver a call to a > > >telephony-addressed end > > >point. In theory it could imply that the recipient will be able to > handle only > > >a web request, but in practice it is usually taken to mean that this > addresses > > >an end point that can handle Real Time Communication sessions. > > > > > >Creating an "enum:" identifier means that we have something that is > guaranteed > > >to say nothing about the session that will result - the only way to > even find > > >out the session choices is via an ENUM lookup. > > > > > >IIRC, Jon has argued that, at most, we should have a URI parameter such as > > >"enum=yes". I think that the effect is similar, with differences only > in some > > >implementation details; specifically, if there's a browser plug-in for > "tel:" > > >and this cannot or won't do ENUM lookups, then having a different scheme > > >reduces parsing - minor point. > > > > > >I do still have one confusion on the use of a enum://tel:;enum=yes URI in > > >a session control/call setup sequence. Doesn't this have the same security > > >issues as CPC and the original ideas on "database dip" indicators? > > > > > >all the best, > > > Lawrence > > > > > >>I tend to favor (B) - it qualifies the meaning of tel, but not strongly > > >>enough that a new scheme is justified (since option (A) works, if > > >>sub-optimally). > > >> > > >>Semantics are currently defined as "The ``tel'' URI describes resources > > >>identified by telephone numbers." (from the abstract of 2806bis) > > >> > > >>As I've noted in earlier discussions, tel URIs are closer in spirit to > > >>URNs such as ISBNs than they are to, say, a SIP URI or http URI. (One > > >>could make a case that they should be urn:tel:, but I won't go there for > > >>now.) If looked at as a URN-like thingie, the question is essentially > > >>moot, or only as interesting as asking what the semantics of an ISBN are. > > >>A tel URI doesn't "do" anything unless it is translated into a dialstring > > >>(internally), SIP URI (via ENUM) or some other 'actionable' URL that has > > >>protocol semantics - just like an ISBN URN doesn't 'do' anything until it > > >>is translated into a HTTP URL, say. > > >> > > >>May I suggest that any such discussion has to include concise, testable > > >>definitions. > > >> > > >>Cullen Jennings wrote: > > >> > > >>>There has been some discussion about indicated a ENUM query has > already been > > >>>done for a given tel URL. > > >>> > > >>>The use case given is usually something along the following lines: A > call > > >>>control element such as a SIP phone gets a phone number and tries an > ENUM > > >>>lookup on it. No record is found in the DNS query so the call is > sent to a > > >>>proxy (or a gatekeeper) that might know how to route the call. This > proxy > > >>>does not know the ENUM query has been tried so it tries the ENUM > query over > > >>>again. > > >>> > > >>>This is somewhat wasteful and adds to the latency of the setup but > does not > > >>>introduce any horrible failures into the system. I have heard three > > >>>proposals to deal with this. They are: > > >>> > > >>>A) Don't do anything - it's not that big a problem. > > >>> > > >>>B) Add a flag to the tel URL to allow it to indicate if an ENUM > query has > > >>>been done - much like the local number portability indicator. > > >>> > > >>>C) Create a new URL, say an enum URL, that specifically indicates a enum > > >>>query is required and change the semantics of the tel URL to > specifically > > >>>not do an ENUM query. > > >>> > > >>>Are there other proposal to this problem that I am missing? The slim > number > > >>>of opinions I have got so far mostly favor B. If there are strong > argument > > >>>for or against any of these - sometime between now and Vienna would be a > > >>>good time to get them on the list. > > >>> > > >>>Perhaps deciding this is not possible without a stronger statement > of what > > >>>the semantics of tel URL are. If people feel this is the case - > let's get > > >>>the issues about tel semantics on the table. > > >>> > > >>>Thanks, > > >>>Cullen > > >>> > >_______________________________________________ >Iptel mailing list >Iptel@ietf.org >https://www.ietf.org/mailman/listinfo/iptel --=====================_20124217==_.ALT Content-Type: text/html; charset="us-ascii" Flemming,

Are you suggesting that the parameter should list out all the roots tried thus far, and only do dip if another known root hasn't be checked yet? 

Would at some point, the list be long enough that it would be faster to simply do option "A" do dips in the ENUM sites you know?

Could the presence of "ENUMi" (versus ENUM="yes") simply mean that the golden root had been tried?

Mike


At 01:19 PM 6/23/2003 -0400, Flemming Andreasen wrote:
I favor "B" as well, but (as Patrick pointed out recently in a private discussion
about this), there is the issue of allowing for use of alternative roots for
"enum-like" applications, in which case a simple boolean will no longer do.

-- Flemming

Richard Shockey wrote:

> At 10:13 AM 6/23/2003 +0100, Conroy, Lawrence (SMTP) wrote:
>
> >Hi Folks,
> >   You can guess that I'm in favour of (C), as I feel that the current
> >"dual use" of the "tel:" URI is confusing. As I've argued before, splitting
> >"tel:" from "enum:" would be pretty clear - "enum:" requires an ENUM lookup
> >to be resolved; "tel:" does NOT require an ENUM lookup (and existing RFC2806
> >"tel:" software that by definition doesn't do an ENUM lookup carries on this
> >way).
>
> Well as we know this has come up several times before ..specifically I
> remember this discussion in Yokohama where the concept of the ENUM URL was
> not well received in the ENUM WG..
>
> Obviously I favor B since 1. it matches current practice 2. I've yet to see
> a convincing argument that C. is necessary. The presence of a tel: url
> could have a presumption that a query has _not_ been done and the
> attachment of the dip indicator would then indicate it has.
>
> IMHO the ENUM indicator is a good idea and worth proceeding with documentation.
>
> >There is a tendency to consider the "tel:" URI to be associated with a
> >telephony
> >resource - i.e. it can be *used* to deliver a call to a
> >telephony-addressed end
> >point. In theory it could imply that the recipient will be able to handle only
> >a web request, but in practice it is usually taken to mean that this addresses
> >an end point that can handle Real Time Communication sessions.
> >
> >Creating an "enum:" identifier means that we have something that is guaranteed
> >to say nothing about the session that will result - the only way to even find
> >out the session choices is via an ENUM lookup.
> >
> >IIRC, Jon has argued that, at most, we should have a URI parameter such as
> >"enum=yes". I think that the effect is similar, with differences only in some
> >implementation details; specifically, if there's a browser plug-in for "tel:"
> >and this cannot or won't do ENUM lookups, then having a different scheme
> >reduces parsing - minor point.
> >
> >I do still have one confusion on the use of a enum://tel:;enum=yes URI in
> >a session control/call setup sequence. Doesn't this have the same security
> >issues as CPC and the original ideas on "database dip" indicators?
> >
> >all the best,
> >   Lawrence
> >
> >>I tend to favor (B) - it qualifies the meaning of tel, but not strongly
> >>enough that a new scheme is justified (since option (A) works, if
> >>sub-optimally).
> >>
> >>Semantics are currently defined as "The ``tel'' URI describes resources
> >>identified by telephone numbers." (from the abstract of 2806bis)
> >>
> >>As I've noted in earlier discussions, tel URIs are closer in spirit to
> >>URNs such as ISBNs than they are to, say, a SIP URI or http URI. (One
> >>could make a case that they should be urn:tel:, but I won't go there for
> >>now.) If looked at as a URN-like thingie, the question is essentially
> >>moot, or only as interesting as asking what the semantics of an ISBN are.
> >>A tel URI doesn't "do" anything unless it is translated into a dialstring
> >>(internally), SIP URI (via ENUM) or some other 'actionable' URL that has
> >>protocol semantics - just like an ISBN URN doesn't 'do' anything until it
> >>is translated into a HTTP URL, say.
> >>
> >>May I suggest that any such discussion has to include concise, testable
> >>definitions.
> >>
> >>Cullen Jennings wrote:
> >>
> >>>There has been some discussion about indicated a ENUM query has already been
> >>>done for a given tel URL.
> >>>
> >>>The use case given is usually something along the following lines: A call
> >>>control element such as a SIP phone gets a phone number and tries an ENUM
> >>>lookup on it. No record is found in the DNS query so the call is sent to a
> >>>proxy (or a gatekeeper) that might know how to route the call. This proxy
> >>>does not know the ENUM query has been tried so it tries the ENUM query over
> >>>again.
> >>>
> >>>This is somewhat wasteful and adds to the latency of the setup but does not
> >>>introduce any horrible failures into the system. I have heard three
> >>>proposals to deal with this. They are:
> >>>
> >>>A) Don't do anything - it's not that big a problem.
> >>>
> >>>B) Add a flag to the tel URL to allow it to indicate if an ENUM query has
> >>>been done - much like the local number portability indicator.
> >>>
> >>>C) Create a new URL, say an enum URL, that specifically indicates a enum
> >>>query is required and change the semantics of the tel URL to specifically
> >>>not do an ENUM query.
> >>>
> >>>Are there other proposal to this problem that I am missing? The slim number
> >>>of opinions I have got so far mostly favor B. If there are strong argument
> >>>for or against any of these - sometime between now and Vienna would be a
> >>>good time to get them on the list.
> >>>
> >>>Perhaps deciding this is not possible without a stronger statement of what
> >>>the semantics of tel URL are. If people feel this is the case - let's get
> >>>the issues about tel semantics on the table.
> >>>
> >>>Thanks,
> >>>Cullen
> >>>

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel
--=====================_20124217==_.ALT-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Mon Jun 23 14:57:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04236 for ; Mon, 23 Jun 2003 14:57:49 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NIvMf30503 for iptel-archive@odin.ietf.org; Mon, 23 Jun 2003 14:57:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UWVG-0007vu-GY for iptel-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 14:57: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 OAA04221 for ; Mon, 23 Jun 2003 14:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UWUy-0004rL-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 14:57:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UWUt-0004rI-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 14:56:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UWUv-0007tJ-AT; Mon, 23 Jun 2003 14: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 19UWUJ-0007sC-AF for iptel@optimus.ietf.org; Mon, 23 Jun 2003 14:56:23 -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 OAA04196 for ; Mon, 23 Jun 2003 14:56:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UWUG-0004qo-00 for iptel@ietf.org; Mon, 23 Jun 2003 14:56:20 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19UWU5-0004qQ-00 for iptel@ietf.org; Mon, 23 Jun 2003 14:56:09 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 23 Jun 2003 11:54:36 -0800 Received: from cisco.com (sjc-vpn4-687.cisco.com [10.21.82.175]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5NItRQx000014; Mon, 23 Jun 2003 11:55:27 -0700 (PDT) Message-ID: <3EF74D1D.C3402E8E@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: Michael Hammer CC: Richard Shockey , Conroy@cisco.com, "Lawrence (SMTP)" , Henning Schulzrinne , iptel@ietf.org, "Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=" Subject: Re: [Iptel] Tel URL and ENUM dips References: <3EF67888.4010401@cs.columbia.edu> <3EF67888.4010401@cs.columbia.edu> <5.2.0.9.2.20030623102804.0594b008@shockey.us> <4.3.2.7.2.20030623143619.04957540@cia.cisco.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, 23 Jun 2003 14:55:25 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael Hammer wrote: > Flemming, > > Are you suggesting that the parameter should list out all the roots > tried thus far, and only do dip if another known root hasn't be > checked yet? > I didn't suggest any specific solutions; I merely noted the potential issue. > > Would at some point, the list be long enough that it would be faster > to simply do option "A" do dips in the ENUM sites you know? > Hard to speculate on how many roots we might have and/or want to support. > > Could the presence of "ENUMi" (versus ENUM="yes") simply mean that the > golden root had been tried? > Clearly we would want to support the golden root, and specific syntax aside, you can always define a simple way of expressing that the golden root has been tried; the question is whether we want to enable more than that. -- Flemming _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Mon Jun 23 17:12:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10551 for ; Mon, 23 Jun 2003 17:12:50 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NLCNf18561 for iptel-archive@odin.ietf.org; Mon, 23 Jun 2003 17:12:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UYbv-0004p7-2x for iptel-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 17:12:23 -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 RAA10537 for ; Mon, 23 Jun 2003 17:12:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UYbd-0005m0-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 17:12:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UYbX-0005lu-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 17:11:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UYbY-0004kF-UO; Mon, 23 Jun 2003 17:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UWrx-0000Vm-Pr for iptel@optimus.ietf.org; Mon, 23 Jun 2003 15:22:09 -0400 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06166 for ; Mon, 23 Jun 2003 15:20:46 -0400 (EDT) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 23 Jun 2003 21:14:58 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5NJCjUu019911; Mon, 23 Jun 2003 21:12:46 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Jun 2003 21:14:47 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Jun 2003 21:14:45 +0200 Subject: Re: [Iptel] Tel URL and ENUM dips Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Flemming Andreasen , Richard Shockey , Conroy@cisco.com, Lawrence (SMTP) , Henning Schulzrinne , iptel@ietf.org To: Michael Hammer From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4.3.2.7.2.20030623143619.04957540@cia.cisco.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 23 Jun 2003 19:14:47.0299 (UTC) FILETIME=[B614CD30:01C339BB] Content-Transfer-Encoding: quoted-printable 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, 23 Jun 2003 21:14:43 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On m=E5ndag, jun 23, 2003, at 20:41 Europe/Stockholm, Michael Hammer=20 wrote: > Are you suggesting that the parameter should list out all the roots=20 > tried thus far, and only do dip if another known root hasn't be=20 > checked yet?=A0 > > Would at some point, the list be long enough that it would be faster=20= > to simply do option "A" do dips in the ENUM sites you know? > > Could the presence of "ENUMi" (versus ENUM=3D"yes") simply mean that = the=20 > golden root had been tried? That is not enough either (see separate email). You also have to say=20 what enum service fields you have ignored (I think, I have only spent=20 some 10 minutes thinking about the problems with this). paf > > Mike > > > At 01:19 PM 6/23/2003 -0400, Flemming Andreasen wrote: > > I favor "B" as well, but (as Patrick pointed out recently in a private=20= > discussion > about this), there is the issue of allowing for use of alternative=20 > roots for > "enum-like" applications, in which case a simple boolean will no=20 > longer do. > > -- Flemming > > Richard Shockey wrote: > > > At 10:13 AM 6/23/2003 +0100, Conroy, Lawrence (SMTP) wrote: > > > > >Hi Folks, > > >=A0=A0 You can guess that I'm in favour of (C), as I feel that the=20= > current > > >"dual use" of the "tel:" URI is confusing. As I've argued before,=20= > splitting > > >"tel:" from "enum:" would be pretty clear - "enum:" requires an=20 > ENUM lookup > > >to be resolved; "tel:" does NOT require an ENUM lookup (and=20 > existing RFC2806 > > >"tel:" software that by definition doesn't do an ENUM lookup=20 > carries on this > > >way). > > > > Well as we know this has come up several times before ..specifically=20= > I > > remember this discussion in Yokohama where the concept of the ENUM=20= > URL was > > not well received in the ENUM WG.. > > > > Obviously I favor B since 1. it matches current practice 2. I've yet=20= > to see > > a convincing argument that C. is necessary. The presence of a tel:=20= > url > > could have a presumption that a query has _not_ been done and the > > attachment of the dip indicator would then indicate it has. > > > > IMHO the ENUM indicator is a good idea and worth proceeding with=20 > documentation. > > > > >There is a tendency to consider the "tel:" URI to be associated=20 > with a > > >telephony > > >resource - i.e. it can be *used* to deliver a call to a > > >telephony-addressed end > > >point. In theory it could imply that the recipient will be able to=20= > handle only > > >a web request, but in practice it is usually taken to mean that=20 > this addresses > > >an end point that can handle Real Time Communication sessions. > > > > > >Creating an "enum:" identifier means that we have something that is=20= > guaranteed > > >to say nothing about the session that will result - the only way to=20= > even find > > >out the session choices is via an ENUM lookup. > > > > > >IIRC, Jon has argued that, at most, we should have a URI parameter=20= > such as > > >"enum=3Dyes". I think that the effect is similar, with differences=20= > only in some > > >implementation details; specifically, if there's a browser plug-in=20= > for "tel:" > > >and this cannot or won't do ENUM lookups, then having a different=20= > scheme > > >reduces parsing - minor point. > > > > > >I do still have one confusion on the use of a enum://tel:;enum=3Dyes=20= > URI in > > >a session control/call setup sequence. Doesn't this have the same=20= > security > > >issues as CPC and the original ideas on "database dip" indicators? > > > > > >all the best, > > >=A0=A0 Lawrence > > > > > >>I tend to favor (B) - it qualifies the meaning of tel, but not=20 > strongly > > >>enough that a new scheme is justified (since option (A) works, if > > >>sub-optimally). > > >> > > >>Semantics are currently defined as "The ``tel'' URI describes=20 > resources > > >>identified by telephone numbers." (from the abstract of 2806bis) > > >> > > >>As I've noted in earlier discussions, tel URIs are closer in=20 > spirit to > > >>URNs such as ISBNs than they are to, say, a SIP URI or http URI.=20= > (One > > >>could make a case that they should be urn:tel:, but I won't go=20 > there for > > >>now.) If looked at as a URN-like thingie, the question is=20 > essentially > > >>moot, or only as interesting as asking what the semantics of an=20 > ISBN are. > > >>A tel URI doesn't "do" anything unless it is translated into a=20 > dialstring > > >>(internally), SIP URI (via ENUM) or some other 'actionable' URL=20 > that has > > >>protocol semantics - just like an ISBN URN doesn't 'do' anything=20= > until it > > >>is translated into a HTTP URL, say. > > >> > > >>May I suggest that any such discussion has to include concise,=20 > testable > > >>definitions. > > >> > > >>Cullen Jennings wrote: > > >> > > >>>There has been some discussion about indicated a ENUM query has=20= > already been > > >>>done for a given tel URL. > > >>> > > >>>The use case given is usually something along the following=20 > lines: A call > > >>>control element such as a SIP phone gets a phone number and tries=20= > an ENUM > > >>>lookup on it. No record is found in the DNS query so the call is=20= > sent to a > > >>>proxy (or a gatekeeper) that might know how to route the call.=20 > This proxy > > >>>does not know the ENUM query has been tried so it tries the ENUM=20= > query over > > >>>again. > > >>> > > >>>This is somewhat wasteful and adds to the latency of the setup=20 > but does not > > >>>introduce any horrible failures into the system. I have heard=20 > three > > >>>proposals to deal with this. They are: > > >>> > > >>>A) Don't do anything - it's not that big a problem. > > >>> > > >>>B) Add a flag to the tel URL to allow it to indicate if an ENUM=20= > query has > > >>>been done - much like the local number portability indicator. > > >>> > > >>>C) Create a new URL, say an enum URL, that specifically indicates=20= > a enum > > >>>query is required and change the semantics of the tel URL to=20 > specifically > > >>>not do an ENUM query. > > >>> > > >>>Are there other proposal to this problem that I am missing? The=20= > slim number > > >>>of opinions I have got so far mostly favor B. If there are strong=20= > argument > > >>>for or against any of these - sometime between now and Vienna=20 > would be a > > >>>good time to get them on the list. > > >>> > > >>>Perhaps deciding this is not possible without a stronger=20 > statement of what > > >>>the semantics of tel URL are. If people feel this is the case -=20= > let's get > > >>>the issues about tel semantics on the table. > > >>> > > >>>Thanks, > > >>>Cullen > > >>> > > _______________________________________________ > 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 Mon Jun 23 17:16:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10670 for ; Mon, 23 Jun 2003 17:16:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NLG8a19512 for iptel-archive@odin.ietf.org; Mon, 23 Jun 2003 17:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UYfY-00054c-Df for iptel-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 17:16:08 -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 RAA10651 for ; Mon, 23 Jun 2003 17:16:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UYfW-0005n9-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 17:16:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UYfQ-0005n6-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 17:16:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UYfS-000526-9i; Mon, 23 Jun 2003 17: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 19UYf2-0004wf-8B for iptel@optimus.ietf.org; Mon, 23 Jun 2003 17:15:36 -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 RAA10624 for ; Mon, 23 Jun 2003 17:15:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UYf0-0005ms-00 for iptel@ietf.org; Mon, 23 Jun 2003 17:15:34 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19UYeo-0005mc-00 for iptel@ietf.org; Mon, 23 Jun 2003 17:15:23 -0400 Received: from dynamicsoft.com ([63.113.46.135]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5NLEbsm008187 for ; Mon, 23 Jun 2003 17:14:37 -0400 (EDT) Message-ID: <3EF76DB8.9020806@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: list iptel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Iptel] Cancelling the iptel session 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, 23 Jun 2003 17:14:32 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Cullen and I have decided to cancel the iptel meeting in Vienna. There is generally not much to talk about, and we believe progress can be better achieved other ways. Furthermore, scheduling for this IETF is proving quite difficult, and if iptel did meet, it would conflict with either midcom or xcon, and I suspect many folks (myself included) would very much want to be at both of those. Please feel free to contact Cullen or I if you have concerns with this. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 Mon Jun 23 18:03:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10550 for ; Mon, 23 Jun 2003 17:12:50 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NLCN718550 for iptel-archive@odin.ietf.org; Mon, 23 Jun 2003 17:12:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UYbv-0004p6-1q for iptel-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 17:12:23 -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 RAA10539 for ; Mon, 23 Jun 2003 17:12:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UYbd-0005m3-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 17:12:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UYbX-0005lv-00 for iptel-web-archive@ietf.org; Mon, 23 Jun 2003 17:11:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UYbY-0004k7-O2; Mon, 23 Jun 2003 17:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UWrw-0000Vl-Fj for iptel@optimus.ietf.org; Mon, 23 Jun 2003 15:22:08 -0400 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06157 for ; Mon, 23 Jun 2003 15:20:45 -0400 (EDT) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 23 Jun 2003 21:13:36 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5NJBGa0019759; Mon, 23 Jun 2003 21:11:19 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Jun 2003 21:13:17 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Jun 2003 21:13:17 +0200 Subject: Re: [Iptel] Tel URL and ENUM dips Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Richard Shockey , Conroy@cisco.com, Lawrence (SMTP) , Henning Schulzrinne , iptel@ietf.org To: Flemming Andreasen From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <3EF736BE.53DD25A5@cisco.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 23 Jun 2003 19:13:17.0768 (UTC) FILETIME=[80B77480:01C339BB] Content-Transfer-Encoding: quoted-printable 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, 23 Jun 2003 21:13:15 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On m=E5ndag, jun 23, 2003, at 19:19 Europe/Stockholm, Flemming Andreasen=20= wrote: > I favor "B" as well, but (as Patrick pointed out recently in a private=20= > discussion > about this), there is the issue of allowing for use of alternative=20 > roots for > "enum-like" applications, in which case a simple boolean will no=20 > longer do. Correct. In theory, DNS is coherent, and if everyone really use the same root=20 (e164.arpa), every lookup should give the same response, but, in=20 reality that is not the case. Because of this, the design of this flag=20= must be extremely carefully thought out, and it must absolutely be the=20= case that the receiver something which has this flag set is not=20 guaranteed anything at all, so he can do another lookup if he wants to. Just two scenarios when B should do another lookup even though A has=20 done it: 1. A get a call for destination 1234, and to an enum lookup for=20 4.3.2.1.e164.foo. B get the call with the flag set, but B uses root e164.arpa. 2. A get a call for destination 1234 but throws away records with a=20 certain ENUM-service-field. B get the call with the flag set, but B can handle those=20 ENUM-service-fields. paf > -- Flemming > > Richard Shockey wrote: > >> At 10:13 AM 6/23/2003 +0100, Conroy, Lawrence (SMTP) wrote: >> >>> Hi Folks, >>> You can guess that I'm in favour of (C), as I feel that the = current >>> "dual use" of the "tel:" URI is confusing. As I've argued before,=20 >>> splitting >>> "tel:" from "enum:" would be pretty clear - "enum:" requires an ENUM=20= >>> lookup >>> to be resolved; "tel:" does NOT require an ENUM lookup (and existing=20= >>> RFC2806 >>> "tel:" software that by definition doesn't do an ENUM lookup carries=20= >>> on this >>> way). >> >> Well as we know this has come up several times before ..specifically = I >> remember this discussion in Yokohama where the concept of the ENUM=20 >> URL was >> not well received in the ENUM WG.. >> >> Obviously I favor B since 1. it matches current practice 2. I've yet=20= >> to see >> a convincing argument that C. is necessary. The presence of a tel: = url >> could have a presumption that a query has _not_ been done and the >> attachment of the dip indicator would then indicate it has. >> >> IMHO the ENUM indicator is a good idea and worth proceeding with=20 >> documentation. >> >>> There is a tendency to consider the "tel:" URI to be associated with=20= >>> a >>> telephony >>> resource - i.e. it can be *used* to deliver a call to a >>> telephony-addressed end >>> point. In theory it could imply that the recipient will be able to=20= >>> handle only >>> a web request, but in practice it is usually taken to mean that this=20= >>> addresses >>> an end point that can handle Real Time Communication sessions. >>> >>> Creating an "enum:" identifier means that we have something that is=20= >>> guaranteed >>> to say nothing about the session that will result - the only way to=20= >>> even find >>> out the session choices is via an ENUM lookup. >>> >>> IIRC, Jon has argued that, at most, we should have a URI parameter=20= >>> such as >>> "enum=3Dyes". I think that the effect is similar, with differences=20= >>> only in some >>> implementation details; specifically, if there's a browser plug-in=20= >>> for "tel:" >>> and this cannot or won't do ENUM lookups, then having a different=20 >>> scheme >>> reduces parsing - minor point. >>> >>> I do still have one confusion on the use of a enum://tel:;enum=3Dyes=20= >>> URI in >>> a session control/call setup sequence. Doesn't this have the same=20 >>> security >>> issues as CPC and the original ideas on "database dip" indicators? >>> >>> all the best, >>> Lawrence >>> >>>> I tend to favor (B) - it qualifies the meaning of tel, but not=20 >>>> strongly >>>> enough that a new scheme is justified (since option (A) works, if >>>> sub-optimally). >>>> >>>> Semantics are currently defined as "The ``tel'' URI describes=20 >>>> resources >>>> identified by telephone numbers." (from the abstract of 2806bis) >>>> >>>> As I've noted in earlier discussions, tel URIs are closer in spirit=20= >>>> to >>>> URNs such as ISBNs than they are to, say, a SIP URI or http URI.=20 >>>> (One >>>> could make a case that they should be urn:tel:, but I won't go=20 >>>> there for >>>> now.) If looked at as a URN-like thingie, the question is=20 >>>> essentially >>>> moot, or only as interesting as asking what the semantics of an=20 >>>> ISBN are. >>>> A tel URI doesn't "do" anything unless it is translated into a=20 >>>> dialstring >>>> (internally), SIP URI (via ENUM) or some other 'actionable' URL=20 >>>> that has >>>> protocol semantics - just like an ISBN URN doesn't 'do' anything=20 >>>> until it >>>> is translated into a HTTP URL, say. >>>> >>>> May I suggest that any such discussion has to include concise,=20 >>>> testable >>>> definitions. >>>> >>>> Cullen Jennings wrote: >>>> >>>>> There has been some discussion about indicated a ENUM query has=20 >>>>> already been >>>>> done for a given tel URL. >>>>> >>>>> The use case given is usually something along the following lines:=20= >>>>> A call >>>>> control element such as a SIP phone gets a phone number and tries=20= >>>>> an ENUM >>>>> lookup on it. No record is found in the DNS query so the call is=20= >>>>> sent to a >>>>> proxy (or a gatekeeper) that might know how to route the call.=20 >>>>> This proxy >>>>> does not know the ENUM query has been tried so it tries the ENUM=20= >>>>> query over >>>>> again. >>>>> >>>>> This is somewhat wasteful and adds to the latency of the setup but=20= >>>>> does not >>>>> introduce any horrible failures into the system. I have heard = three >>>>> proposals to deal with this. They are: >>>>> >>>>> A) Don't do anything - it's not that big a problem. >>>>> >>>>> B) Add a flag to the tel URL to allow it to indicate if an ENUM=20 >>>>> query has >>>>> been done - much like the local number portability indicator. >>>>> >>>>> C) Create a new URL, say an enum URL, that specifically indicates=20= >>>>> a enum >>>>> query is required and change the semantics of the tel URL to=20 >>>>> specifically >>>>> not do an ENUM query. >>>>> >>>>> Are there other proposal to this problem that I am missing? The=20 >>>>> slim number >>>>> of opinions I have got so far mostly favor B. If there are strong=20= >>>>> argument >>>>> for or against any of these - sometime between now and Vienna=20 >>>>> would be a >>>>> good time to get them on the list. >>>>> >>>>> Perhaps deciding this is not possible without a stronger statement=20= >>>>> of what >>>>> the semantics of tel URL are. If people feel this is the case -=20 >>>>> let's get >>>>> the issues about tel semantics on the table. >>>>> >>>>> Thanks, >>>>> Cullen >>>>> _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Tue Jun 24 09:05:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14706 for ; Tue, 24 Jun 2003 09:05:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OD5Fd04810 for iptel-archive@odin.ietf.org; Tue, 24 Jun 2003 09:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnU3-0001FV-HD for iptel-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 09:05:15 -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 JAA14668 for ; Tue, 24 Jun 2003 09:05:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UnU1-0002nS-00 for iptel-web-archive@ietf.org; Tue, 24 Jun 2003 09:05:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UnTv-0002nO-00 for iptel-web-archive@ietf.org; Tue, 24 Jun 2003 09:05:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnTp-0001Ct-8y; Tue, 24 Jun 2003 09:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnTX-0001CN-AX for iptel@optimus.ietf.org; Tue, 24 Jun 2003 09:04:58 -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 JAA14643 for ; Tue, 24 Jun 2003 09:04:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UnTV-0002n0-00 for iptel@ietf.org; Tue, 24 Jun 2003 09:04:41 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19UnTK-0002l2-00 for iptel@ietf.org; Tue, 24 Jun 2003 09:04:30 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 14:02:19 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFGB0VAG; Tue, 24 Jun 2003 14:02:14 +0100 From: "Conroy, Lawrence (SMTP)" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Flemming Andreasen Cc: Richard Shockey , Henning Schulzrinne , iptel@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: References: Subject: Re: [Iptel] Tel URL and ENUM dips Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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, 24 Jun 2003 14:02:17 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable At 9:13 pm +0200 23/6/03, Patrik F=E4ltstr=F6m wrote: >On m=E5ndag, jun 23, 2003, at 19:19 Europe/Stockholm, Flemming = Andreasen wrote: > >>I favor "B" as well, but (as Patrick pointed out recently in a=20 >>private discussion >>about this), there is the issue of allowing for use of alternative = roots for >>"enum-like" applications, in which case a simple boolean will no = longer do. > >Correct. > >In theory, DNS is coherent, and if everyone really use the same root=20 >(e164.arpa), every lookup should give the same response, but, in=20 >reality that is not the case. Because of this, the design of this=20 >flag must be extremely carefully thought out, and it must absolutely=20 >be the case that the receiver something which has this flag set is=20 >not guaranteed anything at all, so he can do another lookup if he=20 >wants to. > >Just two scenarios when B should do another lookup even though A has = done it: > >1. A get a call for destination 1234, and to an enum lookup for=20 >4.3.2.1.e164.foo. > B get the call with the flag set, but B uses root e164.arpa. > >2. A get a call for destination 1234 but throws away records with a = certain > ENUM-service-field. > B get the call with the flag set, but B can handle those=20 >ENUM-service-fields. > > paf [with Apologies to any Conroy@cisco.com - expunged from cc list] Hi Patrik, folks, Um...ENUM (a la RFC2916 and 2916bis) cannot be used to search other than in the golden tree; the Initial Key generates a domain that ends in .e164.arpa. (note trailing dot). For other uses, one could produce an ENUM-like DDDS application; this will happen, if only for Carrier/Infrastructure/Private use. However, it is not ENUM (as specified in 2916bis). Thus (as I think Patrik is suggesting), edi is only talking about ENUM as specified. Given that edi means ENUM Dip Indicator, then this is fine. BTW, this means that, in the above case (1) A *MUST NOT* set the edi = flag, as it has NOT done an ENUM lookup; it has looked in some voodoo domain. However, anything more is dodgy. As these ENUM-like applications may be processed by units that have at least different views, it's extremely risky to assume any but random behaviour; the recipient may be looking at a completely different set of data, so a "X dip done" flag is generally of no use. There ARE circumstances in which this may work - James Yu did an I-D on the npdi flag already; I don't see why we need to re-invent = something. Isn't having ->a<- common data source for all to see one of the reasons why we went away from the chaos of alternative roots in the first = place? all the best, Lawrence --=20 ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is = not : intended to create any contractual or legal : relationship. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Tue Jun 24 09:42:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15922 for ; Tue, 24 Jun 2003 09:42:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ODg7710751 for iptel-archive@odin.ietf.org; Tue, 24 Jun 2003 09:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uo3j-0002nK-QI for iptel-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 09:42:07 -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 JAA15909 for ; Tue, 24 Jun 2003 09:42:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uo3h-000320-00 for iptel-web-archive@ietf.org; Tue, 24 Jun 2003 09:42:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Uo3b-00031x-00 for iptel-web-archive@ietf.org; Tue, 24 Jun 2003 09:41:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uo3c-0002m6-Un; Tue, 24 Jun 2003 09:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uo2l-0002lf-Ps for iptel@optimus.ietf.org; Tue, 24 Jun 2003 09:41:07 -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 JAA15875 for ; Tue, 24 Jun 2003 09:41:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uo2j-00031l-00 for iptel@ietf.org; Tue, 24 Jun 2003 09:41:05 -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 19Uo2Y-00030S-00 for iptel@ietf.org; Tue, 24 Jun 2003 09:40:54 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2003 06:42:59 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5ODdeGe006327; Tue, 24 Jun 2003 06:39:40 -0700 (PDT) Received: from [206.146.235.194] (sjc-vpn4-538.cisco.com [10.21.82.26]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFJ58998; Tue, 24 Jun 2003 06:39:38 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [Iptel] Cancelling the iptel session From: Cullen Jennings To: Jonathan Rosenberg , list iptel Message-ID: In-Reply-To: <3EF76DB8.9020806@dynamicsoft.com> Mime-version: 1.0 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, 23 Jun 2003 21:47:04 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I want to make sure that there is a good chance for anyone to tell the chairs what we are doing right/wrong and what we need to do to get this work done. As we get closer to the next IETF, I will figure out some time where anyone who wants can abuse me over a beer in Vienna. Thanks, Cullen PS. First beer is on me for anyone who has posted a useful comment to the list :-) _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Tue Jun 24 13:48:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26864 for ; Tue, 24 Jun 2003 13:48:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OHmAR23319 for iptel-archive@odin.ietf.org; Tue, 24 Jun 2003 13:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Urtq-000642-2u for iptel-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 13:48:10 -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 NAA26814 for ; Tue, 24 Jun 2003 13:48:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Urtn-0004sv-00 for iptel-web-archive@ietf.org; Tue, 24 Jun 2003 13:48:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Urti-0004ss-00 for iptel-web-archive@ietf.org; Tue, 24 Jun 2003 13:48:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Urth-00061x-8c; Tue, 24 Jun 2003 13:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uo5p-0002qE-VR for iptel@optimus.ietf.org; Tue, 24 Jun 2003 09:44: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 JAA16002 for ; Tue, 24 Jun 2003 09:44:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uo5o-00032M-00 for iptel@ietf.org; Tue, 24 Jun 2003 09:44:16 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19Uo5d-000328-00 for iptel@ietf.org; Tue, 24 Jun 2003 09:44:05 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Jun 2003 15:43:22 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5ODe2Se026252; Tue, 24 Jun 2003 15:40:09 +0200 (MET DST) Received: from xfe-ams-312.cisco.com ([144.254.228.205]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 15:42:10 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 15:42:08 +0200 Subject: Re: [Iptel] Tel URL and ENUM dips Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Flemming Andreasen , Richard Shockey , Henning Schulzrinne , iptel@ietf.org To: "Conroy, Lawrence (SMTP)" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 24 Jun 2003 13:42:08.0707 (UTC) FILETIME=[683F1930:01C33A56] 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, 24 Jun 2003 15:42:06 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On tisdag, jun 24, 2003, at 15:02 Europe/Stockholm, Conroy, Lawrence (SMTP) wrote: >> Just two scenarios when B should do another lookup even though A has >> done it: >> >> 1. A get a call for destination 1234, and to an enum lookup for >> 4.3.2.1.e164.foo. >> B get the call with the flag set, but B uses root e164.arpa. You are absolutely correct that the EDI might indicate a dip in e164.arpa. But, what about this second case? >> 2. A get a call for destination 1234 but throws away records with a >> certain >> ENUM-service-field. >> B get the call with the flag set, but B can handle those >> ENUM-service-fields. paf > > > [with Apologies to any Conroy@cisco.com - expunged from cc list] > > Hi Patrik, folks, > > Um...ENUM (a la RFC2916 and 2916bis) cannot be used to search > other than in the golden tree; the Initial Key generates a domain > that ends in .e164.arpa. (note trailing dot). > For other uses, one could produce an ENUM-like DDDS application; > this will happen, if only for Carrier/Infrastructure/Private use. > However, it is not ENUM (as specified in 2916bis). Thus (as I think > Patrik is suggesting), edi is only talking about ENUM as specified. > Given that edi means ENUM Dip Indicator, then this is fine. > > BTW, this means that, in the above case (1) A *MUST NOT* set the edi > flag, > as it has NOT done an ENUM lookup; it has looked in some voodoo domain. > > However, anything more is dodgy. As these ENUM-like applications > may be processed by units that have at least different views, it's > extremely risky to assume any but random behaviour; the recipient > may be looking at a completely different set of data, so a "X dip done" > flag is generally of no use. > > There ARE circumstances in which this may work - James Yu did an I-D > on the npdi flag already; I don't see why we need to re-invent > something. > > Isn't having ->a<- common data source for all to see one of the reasons > why we went away from the chaos of alternative roots in the first > place? > > all the best, > Lawrence > -- > ----------------------------------------------------------------------- > Roke Manor Research : This information is provided "as is" and is > not > : intended to create any contractual or legal > : relationship. > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, > Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is > confidential to > Roke Manor Research Ltd and must not be passed to any third party > without > permission. This communication is for information only and shall not > create or > change any contractual relationship. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Tue Jun 24 17:31:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11925 for ; Tue, 24 Jun 2003 17:31:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OLVAI28120 for iptel-archive@odin.ietf.org; Tue, 24 Jun 2003 17:31:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UvNe-0007Ig-5C for iptel-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 17:31:10 -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 RAA11918 for ; Tue, 24 Jun 2003 17:31:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UvNb-0007Vh-00 for iptel-web-archive@ietf.org; Tue, 24 Jun 2003 17:31:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UvNW-0007Ve-00 for iptel-web-archive@ietf.org; Tue, 24 Jun 2003 17:31:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UvNV-0007IB-85; Tue, 24 Jun 2003 17:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UvMu-0007FT-As for iptel@optimus.ietf.org; Tue, 24 Jun 2003 17:30: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 RAA11899 for ; Tue, 24 Jun 2003 17:30:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UvMr-0007VH-00 for iptel@ietf.org; Tue, 24 Jun 2003 17:30:22 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19UvMc-0007V0-00 for iptel@ietf.org; Tue, 24 Jun 2003 17:30:06 -0400 Received: from cs.columbia.edu (dhcp39.cs.columbia.edu [128.59.19.239]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5OLTY5U012505 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Jun 2003 17:29:34 -0400 (EDT) Message-ID: <3EF8C2B8.9000109@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet CC: "'iptel@ietf.org'" References: <2F1FC1DEA077D5119FAD00508BCFD6D208053D50@zsc3c030.us.nortel.com> In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D208053D50@zsc3c030.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Subject: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel URI for Telephone C alls 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, 24 Jun 2003 17:29:28 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Francois Audet wrote: Thank you much for your extensive comments. I'll only comment on the more major changes, just in case somebody wants to jump in. > ---------- > > 1) (Editorial) Title: I believe the title should be "The tel URI for > Telephone > Numbers" instead of "The tel URI for Telephone Calls" since a URI > does not > imply that there is a call. Agreed. > 11) Page 6 (Editorial) > Change "Their" to "their" in section 5 title. Nope, says "Words into Type" :-) > > 12) Page 7 > Section 5.1.2 does not describe what to do with non-numeric DTMF > digits (A, B > C and D). This is NOT the same as the ISUP BCD-encoded A-F digits. > Those > digits are defined in ITU-T Q.23. I would imagine that we want to > prohibit > their use in a URI. Since those DTMF digits would be dial string, I tend to agree, although I don't know how you'd tell the difference in URI between a 'legal' Q.23 letter A and an illegal DTMF 'A'. > 18) Page 15 (Minor) > The description of Proxy translation encourages people to use URIs > like "sip:1234@foobar.com" and let the proxy "deal" with it. I tought > this is exactly what we did NOT want to encourage people to do since > it assumes a uniform dialing plan accross a whole proxy. This would > force > the service providers to deploy as many proxies as there are > dialing plans which is very undesireable. > Rather, I would encourage people to use a phone-context (in a tel URI > or prefereably a SIP URI) that identifies the dialing context > explicitely. For example, it could be as follows: > tel:1234;phone-context= > munich.example.com (or > sip:1234;phone-context=munich.example.com@example.com; > user=phone). > With this approach, the service provider could assign a > phone-context per > dialing plan and not require one proxy per dialing plan. A large number > of phones could be deployed, for example, in the Munich office by > having > all the phones preconfigured with the > phone-context=munich.example.com (of > course it could also be manually configured). > I fear that if we leave it as is, the phone manufactures will take > the easy > way out and NOT allow for configuration of the phone-context which will > not make for easy deployment, especially when multiple regional > offices with > different dialing plans are supported. > I tried to reword the section to address this concern, which I share. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Jun 25 11:06:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14013 for ; Wed, 25 Jun 2003 11:06:02 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PF5as26329 for iptel-archive@odin.ietf.org; Wed, 25 Jun 2003 11:05:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBq4-0006qa-5E for iptel-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:05:36 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13984 for ; Wed, 25 Jun 2003 11:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpV-0006gu-BT; Wed, 25 Jun 2003 11:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpA-0006YL-J4 for iptel@optimus.ietf.org; Wed, 25 Jun 2003 11:04:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12955; Wed, 25 Jun 2003 10:53:20 -0400 (EDT) Message-Id: <200306251453.KAA12955@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: iptel@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Iptel] I-D ACTION:draft-mahy-iptel-cpc-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: Wed, 25 Jun 2003 10:53:20 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Calling Party's Category tel URI Parameter Author(s) : R. Mahy Filename : draft-mahy-iptel-cpc-00.txt Pages : 7 Date : 2003-6-24 This document specifies a new parameter for the tel URI that represents the Calling Party's Category, a parameter used in SS7 ISUP signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-iptel-cpc-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mahy-iptel-cpc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mahy-iptel-cpc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-25103356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mahy-iptel-cpc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mahy-iptel-cpc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103356.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Jun 25 11:06:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14029 for ; Wed, 25 Jun 2003 11:06:03 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PF5bL26346 for iptel-archive@odin.ietf.org; Wed, 25 Jun 2003 11:05:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBq5-0006qr-Dp for iptel-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:05:37 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13983 for ; Wed, 25 Jun 2003 11:05: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 19VBpV-0006h2-IC; Wed, 25 Jun 2003 11:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpA-0006YL-Lz for iptel@optimus.ietf.org; Wed, 25 Jun 2003 11:04:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13186; Wed, 25 Jun 2003 10:54:29 -0400 (EDT) Message-Id: <200306251454.KAA13186@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Iptel] I-D ACTION:draft-ietf-iptel-rfc2806bis-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: Wed, 25 Jun 2003 10:54:29 -0400 --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, A. Vaha-Sipila Filename : draft-ietf-iptel-rfc2806bis-00.txt Pages : 18 Date : 2003-6-24 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-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-rfc2806bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-25103602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-rfc2806bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-rfc2806bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103602.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Jun 25 12:35:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20461 for ; Wed, 25 Jun 2003 12:35:06 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PGYcX10592 for iptel-archive@odin.ietf.org; Wed, 25 Jun 2003 12:34:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDEE-0002kl-4U for iptel-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 12:34: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 MAA20436 for ; Wed, 25 Jun 2003 12:34:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VDED-0005FX-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 12:34:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VDDx-0005F2-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 12:34:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDDd-0002hA-57; Wed, 25 Jun 2003 12:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDDC-0002fv-V1 for iptel@optimus.ietf.org; Wed, 25 Jun 2003 12:33:34 -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 MAA20369 for ; Wed, 25 Jun 2003 12:33:32 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VDDC-0005EX-00 for iptel@ietf.org; Wed, 25 Jun 2003 12:33:34 -0400 Received: from imo-d06.mx.aol.com ([205.188.157.38]) by ietf-mx with esmtp (Exim 4.12) id 19VDCw-0005DK-00 for iptel@ietf.org; Wed, 25 Jun 2003 12:33:18 -0400 Received: from Mpierce1@aol.com by imo-d06.mx.aol.com (mail_out_v36.3.) id 7.171.207f53f3 (3890); Wed, 25 Jun 2003 12:30:58 -0400 (EDT) Message-ID: <171.207f53f3.2c2b2842@aol.com> Subject: Re: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel URI for Telepho... To: hgs@cs.columbia.edu, audet@nortelnetworks.com CC: iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_171.207f53f3.2c2b2842_boundary" X-Mailer: 6.0 for Windows XP sub 10501 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, 25 Jun 2003 12:30:58 EDT --part1_171.207f53f3.2c2b2842_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/24/2003 5:32:39 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > > (Francois Audet had written) > > 12) Page 7 > > Section 5.1.2 does not describe what to do with non-numeric DTMF > digits (A, B > > C and D). This is NOT the same as the ISUP BCD-encoded A-F digits. > Those > > digits are defined in ITU-T Q.23. I would imagine that we want to > prohibit > > their use in a URI. > > Since those DTMF digits would be dial string, I tend to agree, although > I don't know how you'd tell the difference in URI between a 'legal' Q.23 > letter A and an illegal DTMF 'A'. > This distinction has been giving people fits for years in various signaling systems. It seems to me that the difference is that the other 4 DTMF "digits" (A, B, C, and D defined in Q.23) are part of a dial string. Various signaling systems like ISUP define BCD-encoded digits (we represent as A-F) as possible parts of a destination number. (The alphabetic characters represented by the letters associated with numbers, which is what the first paragraph of Section 5.1.2 addresses, causes even more confusion. The second paragraph, talking about the BCD coding in ISUP, causes additional confusion being part of this same section as "alphabetic characters" and should be moved, since they are two, very different things.) I don't understand your statement above about "legal Q.23 letter A and an illegal DTMF A". They are the same thing. The result of Q.23 and E.164 is that the extra 4 "digits" on a DTMF keypad can be used only for local subscriber signaling and maybe for end-to-end signaling (not seen by the network). As an example, a military systems could use the extra 4 DTMF keys to indicate precedence level as a part of the subscriber signaling, but these would not be carried in the ISUP signaling as "digits". ISUP might use its extra 6 Hex values for internal network functions that do not relate to any subscriber signaling. There is a clear separation today between subscriber signaling and internal network signaling. The problem here is caused by trying to define some "neutral", general purpose signaling element (tel:uri) which does not make the distinction between subscriber dialing, internal network signaling, and pure end-to-end signaling. The "local" format seems to be allowing these extra 6 values, while the transport of a "dial string" would need to carry the extra 4 codes defined in Q.23. I'm still not clear on how the * and # on the DTMF keypad are carried when the tel-uri is being used. The draft states that "dial strings are beyond the scope of this document", but then it seems to attempt to support raw dial strings by showing how dial strings like "911" are coded. The implication of this is that any series of key strokes by the user could be coded in a similar fashion - i.e. - a "dial string". I believe there needs to be a very specific decision on whether or not the tel:uri needs to include "dial strings" or if its only purpose is to carry what the draft defines as "address of record". If it is to not include "dial strings", then codes to indicate the extra 4 DTMF keys as well as the * and # do not need to be considered. However, then I would not know what to do with local dialing that in fact uses * and #. Mike Pierce --part1_171.207f53f3.2c2b2842_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 6/24/2= 003 5:32:39 PM Eastern Standard Time, hgs@cs.columbia.edu writes:


>  (Francois Audet=20= had written)
> 12) Page 7
>     Section 5.1.2 does not describe what to do=20= with non-numeric DTMF digits (A, B
>     C and D). This is NOT the same as the ISUP=20= BCD-encoded A-F digits. Those
>     digits are defined in ITU-T Q.23. I would i= magine that we want to prohibit
>     their use in a URI.

Since those DTMF digits would be dial string, I tend to agree, although=20
I don't know how you'd tell the difference in URI between a 'legal' Q.23= =20
letter A and an illegal DTMF 'A'.


This distinction has been giving people fits for years in various signal= ing systems. It seems to me that the difference is that the other 4 DTMF "di= gits" (A, B, C, and D defined in Q.23) are part of a dial string. Various si= gnaling systems like ISUP define BCD-encoded digits (we represent as A-F) as= possible parts of a destination number. (The alphabetic characters represen= ted by the letters associated with numbers, which is what the first paragrap= h of Section 5.1.2 addresses, causes even more confusion. The second paragra= ph, talking about the BCD coding in ISUP, causes additional confusion being=20= part of this same section as "alphabetic characters" and should be moved, si= nce they are two, very different things.)

I don't understand your statement above about "legal Q.23 letter A and a= n illegal DTMF A". They are the same thing.

The result of Q.23 and E.164 is that the extra 4 "digits" on a DTMF keyp= ad can be used only for local subscriber signaling and maybe for end-to-end=20= signaling (not seen by the network). As an example, a military systems could= use the extra 4 DTMF keys to indicate precedence level as a part of the sub= scriber signaling, but these would not be carried in the ISUP signaling as "= digits". ISUP might use its extra 6 Hex values for internal network function= s that do not relate to any subscriber signaling. There is a clear separatio= n today between subscriber signaling and internal network signaling.

The problem here is caused by trying to define some "neutral", general p= urpose signaling element (tel:uri) which does not make the distinction betwe= en subscriber dialing, internal network signaling, and pure end-to-end signa= ling. The "local" format seems to be allowing these extra 6 values, while th= e transport of a "dial string" would need to carry the extra 4 codes defined= in Q.23. I'm still not clear on how the * and # on the DTMF keypad are carr= ied when the tel-uri is being used. The draft states that "dial strings are=20= beyond the scope of this document", but then it seems to attempt to support=20= raw dial strings by showing how dial strings like "911" are coded. The impli= cation of this is that any series of key strokes by the user could be coded=20= in a similar fashion - i.e. - a "dial string".

I believe there needs to be a very specific decision on whether or not t= he tel:uri needs to include "dial strings" or if its only purpose is to carr= y what the draft defines as "address of record". If it is to not include "di= al strings", then codes to indicate the extra 4 DTMF keys as well as the * a= nd # do not need to be considered. However, then I would not know what to do= with local dialing that in fact uses * and #.

Mike Pierce
--part1_171.207f53f3.2c2b2842_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Jun 25 12:57:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21181 for ; Wed, 25 Jun 2003 12:57:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PGvDI14642 for iptel-archive@odin.ietf.org; Wed, 25 Jun 2003 12:57:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VDa5-0003o5-9m for iptel-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 12:57:13 -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 MAA21156 for ; Wed, 25 Jun 2003 12:57:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VDa4-0005OA-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 12:57:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VDZy-0005O2-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 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 19VDZt-0003kv-Bo; Wed, 25 Jun 2003 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 19VDYw-0003k6-Au for iptel@optimus.ietf.org; Wed, 25 Jun 2003 12:56:02 -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 MAA21125 for ; Wed, 25 Jun 2003 12:55:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VDYv-0005NJ-00 for iptel@ietf.org; Wed, 25 Jun 2003 12:56:01 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.59.238] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19VDYg-0005ND-00 for iptel@ietf.org; Wed, 25 Jun 2003 12:55:46 -0400 Received: from cs.columbia.edu (dhcp39.cs.columbia.edu [128.59.19.239]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5PGtCgF017555 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Jun 2003 12:55:12 -0400 (EDT) Message-ID: <3EF9D3EA.5020800@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: audet@nortelnetworks.com, iptel@ietf.org Subject: Re: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel URI for Telepho... References: <171.207f53f3.2c2b2842@aol.com> In-Reply-To: <171.207f53f3.2c2b2842@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) 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, 25 Jun 2003 12:55:06 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mpierce1@aol.com wrote: > In a message dated 6/24/2003 5:32:39 PM Eastern Standard Time, > > This distinction has been giving people fits for years in various > signaling systems. It seems to me that the difference is that the other > 4 DTMF "digits" (A, B, C, and D defined in Q.23) are part of a dial > string. Various signaling systems like ISUP define BCD-encoded digits > (we represent as A-F) as possible parts of a destination number. (The > alphabetic characters represented by the letters associated with > numbers, which is what the first paragraph of Section 5.1.2 addresses, > causes even more confusion. The second paragraph, talking about the BCD > coding in ISUP, causes additional confusion being part of this same > section as "alphabetic characters" and should be moved, since they are > two, very different things.) Good point; I created a new subsection. > > I don't understand your statement above about "legal Q.23 letter A and > an illegal DTMF A". They are the same thing. That's what I thought. I understood Francois that they are somehow separable. > > The result of Q.23 and E.164 is that the extra 4 "digits" on a DTMF > keypad can be used only for local subscriber signaling and maybe for > end-to-end signaling (not seen by the network). As an example, a > military systems could use the extra 4 DTMF keys to indicate precedence > level as a part of the subscriber signaling, but these would not be This would be 'dial strings', not identifiers, so they'd never show up in a tel URI. > carried in the ISUP signaling as "digits". ISUP might use its extra 6 > Hex values for internal network functions that do not relate to any > subscriber signaling. There is a clear separation today between > subscriber signaling and internal network signaling. > > The problem here is caused by trying to define some "neutral", general > purpose signaling element (tel:uri) which does not make the distinction > between subscriber dialing, internal network signaling, and pure > end-to-end signaling. The "local" format seems to be allowing these > extra 6 values, while the transport of a "dial string" would need to > carry the extra 4 codes defined in Q.23. I'm still not clear on how the > * and # on the DTMF keypad are carried when the tel-uri is being used. There seem to be two possibilities: treat them as identifiers within a local dial plan or disallow them altogether. I don't see principal problem with treating them as part of things that can appear in a local number, i.e., with appropriate qualification. What would break if we do this? > The draft states that "dial strings are beyond the scope of this > document", but then it seems to attempt to support raw dial strings by > showing how dial strings like "911" are coded. The implication of this > is that any series of key strokes by the user could be coded in a > similar fashion - i.e. - a "dial string". 911 is not a dial string in my view. It's an identifier (that happens to resolve to different endpoints, but that's immaterial). > > I believe there needs to be a very specific decision on whether or not > the tel:uri needs to include "dial strings" or if its only purpose is to > carry what the draft defines as "address of record". If it is to not > include "dial strings", then codes to indicate the extra 4 DTMF keys as > well as the * and # do not need to be considered. However, then I would > not know what to do with local dialing that in fact uses * and #. > > Mike Pierce _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Jun 25 13:30:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22169 for ; Wed, 25 Jun 2003 13:30:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PHUGP20697 for iptel-archive@odin.ietf.org; Wed, 25 Jun 2003 13:30:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VE63-0005Nk-Mh for iptel-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 13:30:15 -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 NAA22143 for ; Wed, 25 Jun 2003 13:30:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VE62-0005Zh-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 13:30:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VE5w-0005Zd-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 13:30:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VE5o-0005LH-O3; Wed, 25 Jun 2003 13:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VE5e-0005Jx-IY for iptel@optimus.ietf.org; Wed, 25 Jun 2003 13:29: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 NAA22131 for ; Wed, 25 Jun 2003 13:29:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VE5d-0005ZU-00 for iptel@ietf.org; Wed, 25 Jun 2003 13:29:49 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19VE5P-0005ZL-00 for iptel@ietf.org; Wed, 25 Jun 2003 13:29:38 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 18:28:59 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFGB0YD9; Wed, 25 Jun 2003 18:28:54 +0100 From: "Conroy, Lawrence (SMTP)" To: Mpierce1@aol.com, hgs@cs.columbia.edu, audet@nortelnetworks.com Cc: iptel@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <171.207f53f3.2c2b2842@aol.com> References: <171.207f53f3.2c2b2842@aol.com> Subject: Re: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel URI for Telepho... Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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, 25 Jun 2003 18:28:54 +0100 At 12:30 pm -0400 25/6/03, Mpierce1@aol.com wrote: >I believe there needs to be a very specific decision on whether or >not the tel:uri needs to include "dial strings" or if its only >purpose is to carry what the draft defines as "address of record". >If it is to not include "dial strings", then codes to indicate the >extra 4 DTMF keys as well as the * and # do not need to be >considered. However, then I would not know what to do with local >dialing that in fact uses * and #. Hi Mike, folks, there was a clear decision - the draft states it - tel: is NOT dealing with dial strings. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Jun 25 13:32:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22253 for ; Wed, 25 Jun 2003 13:32:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PHW9U21055 for iptel-archive@odin.ietf.org; Wed, 25 Jun 2003 13:32:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VE7s-0005TV-UE for iptel-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 13:32:08 -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 NAA22239 for ; Wed, 25 Jun 2003 13:32:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VE7r-0005ai-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 13:32:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VE7m-0005ad-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 13:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VE7l-0005Qm-TX; Wed, 25 Jun 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VE74-0005Pn-Fj for iptel@optimus.ietf.org; Wed, 25 Jun 2003 13:31: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 NAA22206 for ; Wed, 25 Jun 2003 13:31:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VE73-0005aK-00 for iptel@ietf.org; Wed, 25 Jun 2003 13:31:17 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19VE6s-0005a5-00 for iptel@ietf.org; Wed, 25 Jun 2003 13:31:06 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 18:30:59 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFGB0Y1A; Wed, 25 Jun 2003 18:30:56 +0100 From: "Conroy, Lawrence (SMTP)" To: hgs@cs.columbia.edu Cc: iptel@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Iptel] iptel-rfc2806-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, 25 Jun 2003 18:30:55 +0100 Hi Henning, folks, I've looked through the -01 version that I suspect will be going through the system soon - I note that -00 has just appeared on IETF-Announce. What I hope are my final comments on this draft in response to earlier goading: * ?Typo? in section 4, second bullet - what does "mandatory extension parameters" mean here? and parameters are mentioned explicitly, so I'm not sure what the mandatory extension parameters covers. * Section 5.1.4 - OK, I'll buy it - having a single context rather than a comma-separated list is OK. * Section 5.4, 1st para, 3rd/4th/5th sentence - I'm still slightly uncomfortable with "how mandatory is mandatory". The paragraph as is states only that the URI must not be used if it includes unknown mandatory parameters - a known but ignored mandatory parameter isn't covered. => Could the 3rd sentence have this text added to it, please?: "and MUST NOT be ignored". Basically, I assume that such a m-parameter is mandatory to act on; however, I have had this conversation before with others who have thought that the parameter needed only to be understood, but could be ignored. * Annex A: Aahh...this one's tricky. If I understand the text correctly, Proxy Translation first paragraph (third sentence) and the last paragraph (last sentence) imply that the OBP has ->its<- local dial plan. I use a proxy that maintains more than one context, and can select the context based on the caller (e.g. a calling SIP AoR is classified as being in a particular context, and the URI is interpreted in those terms). Thus, in para 1, sentence 3, c/local dial plan/local dial plan logic/ Similarly, in the last paragraph, could the last sentence be replaced entirely by something like: "Otherwise, a provider or enterprise would have to provision each calling station into an appropriate dial plan, and the OBP would have to interpret the required destination in terms of the dial plan to which that calling station had been associated". Oh yes...minor typo in the last paragraph, 1st sentence: c/difference/different/ all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Jun 25 13:56:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23008 for ; Wed, 25 Jun 2003 13:56:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PHu8L26167 for iptel-archive@odin.ietf.org; Wed, 25 Jun 2003 13:56:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VEV6-0006ny-MK for iptel-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 13:56:08 -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 NAA23002 for ; Wed, 25 Jun 2003 13:56:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VEV5-0005hZ-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 13:56:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VEV0-0005hW-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 13:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VEUy-0006lW-P8; Wed, 25 Jun 2003 13:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VEUR-0006lF-Li for iptel@optimus.ietf.org; Wed, 25 Jun 2003 13:55:27 -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 NAA22996 for ; Wed, 25 Jun 2003 13:55:25 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VEUQ-0005hS-00 for iptel@ietf.org; Wed, 25 Jun 2003 13:55:26 -0400 Received: from imo-m04.mx.aol.com ([64.12.136.7]) by ietf-mx with esmtp (Exim 4.12) id 19VEUA-0005h6-00 for iptel@ietf.org; Wed, 25 Jun 2003 13:55:10 -0400 Received: from Mpierce1@aol.com by imo-m04.mx.aol.com (mail_out_v36.3.) id l.1ee.be1f4e1 (3988) for ; Wed, 25 Jun 2003 13:53:42 -0400 (EDT) Message-ID: <1ee.be1f4e1.2c2b3ba6@aol.com> To: iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1ee.be1f4e1.2c2b3ba6_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Subject: [Iptel] Comments on draft rfc-2600bis 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, 25 Jun 2003 13:53:42 EDT --part1_1ee.be1f4e1.2c2b3ba6_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Several additional comments on new version (although the material commented on was in previous versions): Definition of Address-of-record and Dial String Section 2 defines two types of telephone numbers: "address-of-record" (or identifier) and "dial string". Unfortunately, the definitions leave some uncertainty as to where addresses which represent destinations in a private network belong. Since such a number as passed within such a private network may not be exactly what was dialed, it is not a "dial string". However, "Address-of-record" is defined in terms of "a public network termination point". Neither definition correctly covers the private network number. The problem seems to be the definition of "Address-of-record" which directly relates it to a "public network". The definition should include the notion of "non-public" networks as follows: --------------------- Address-of-record or identifier: The telephone number is understood here as the canonical address-of-record or identifier for a termination point within a specific network. For the public network, these numbers generally follow the rules in E.164 [4]. Subscribers publish such identifiers or phone numbers as a universal means of being reached from within that network, independent of the location of the caller. (Naturally, not all numbers are reachable from everywhere in a network, for a variety of technical and local policy reasons.) It should be noted that a single termination point in one network may be reachable from different networks and would then have multiple such identifiers, one valid from each network. ---------------------- Section 2 The 4th paragraph has some wording errors. It is not clear what it is intended to say. It refers to the user or the terminal converting a telephone number into a dial string. In fact, the user needs to know whether or not to dial the area code, etc (i.e., converting the desired telephone number into a dial string), but the terminal may need to do the opposite. It needs to convert what the user dialed (dial string) into a telephone number (e.g., full E.164 number) to put into the tel:uri. The terminal would never convert from a real telephone number to what is called a "dial string", at least not when originating a call. The following rewrite of this paragraph is suggested: --------------------- To reach a telephone number from a particular terminal, the user of the terminal has to know how to convert that telephone number into a dial string appropriate for that terminal. The telephone number itself does not convey what needs to be done for a particular terminal. Instructions may include dialing "9" before placing a call or prepending a "00" to reach a number in a foreign country. The user may also need to strip area and country codes. The terminal has to know how to convert what the user dials or enters into a full telephone number (e.g., E.164) in order to form a tel:uri. This requires knowledge of the local dialing plan, county code, area code, etc. ---------------------- 10 Security Considerations The last bullet item, about "a call may use ... different contexts", should be deleted. Mike Pierce Artel --part1_1ee.be1f4e1.2c2b3ba6_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Several additional commen= ts on new version (although the material commented on was in previous versio= ns):

Definition of Address-of-record and Dial String

Section 2 defines two types of telephone numbers: "address-of-record" (o= r identifier) and "dial string". Unfortunately, the definitions leave some u= ncertainty as to where addresses which represent destinations in a private n= etwork belong. Since such a number as passed within such a private network m= ay not be exactly what was dialed, it is not a "dial string". However, "Addr= ess-of-record" is defined in terms of "a public network termination point".=20= Neither definition correctly covers the private network number.

The problem seems to be the definition of "Address-of-record" which dire= ctly relates it to a "public network". The definition should include the not= ion of "non-public" networks as follows:

---------------------
Address-of-record or identifier: The telephone number is understood here= as the canonical address-of-record or identifier for a termination point wi= thin a specific network. For the public network, these numbers generally fol= low the rules in E.164 [4]. Subscribers publish such identifiers or phone nu= mbers as a universal means of being reached from within that network, indepe= ndent of the location of the caller. (Naturally, not all numbers are reachab= le from everywhere in a network, for a variety of technical and local policy= reasons.) It should be noted that a single termination point in one network= may be reachable from different networks and would then have multiple such=20= identifiers, one valid from each network.
----------------------

Section 2

The 4th paragraph has some wording errors. It is not clear what it is in= tended to say. It refers to the user or the terminal converting a telephone=20= number into a dial string. In fact, the user needs to know whether or not to= dial the area code, etc (i.e., converting the desired telephone number into= a dial string), but the terminal may need to do the opposite. It needs to c= onvert what the user dialed (dial string) into a telephone number (e.g., ful= l E.164 number) to put into the tel:uri. The terminal would never convert fr= om a real telephone number to what is called a "dial string", at least not w= hen originating a call.
The following rewrite of this paragraph is suggested:

---------------------
To reach a telephone number from a particular terminal, the user of the=20= terminal has to know how to convert that telephone number into a dial string= appropriate for that terminal. The telephone number itself does not convey=20= what needs to be done for a particular terminal. Instructions may include di= aling "9" before placing a call or prepending a "00" to reach a number in a=20= foreign country. The user may also need to strip area and country codes.

The terminal has to know how to convert what the user dials or enters in= to a full telephone number (e.g., E.164) in order to form a tel:uri. This re= quires knowledge of the local dialing plan, county code, area code, etc.
----------------------

10 Security Considerations

The last bullet item, about "a call may use ... different contexts", sho= uld be deleted.

Mike Pierce
Artel
--part1_1ee.be1f4e1.2c2b3ba6_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Jun 25 15:18:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26882 for ; Wed, 25 Jun 2003 15:18:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PJID813213 for iptel-archive@odin.ietf.org; Wed, 25 Jun 2003 15:18:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFmX-0003R2-Nf for iptel-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 15:18:13 -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 PAA26861 for ; Wed, 25 Jun 2003 15:18:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VFmR-0006WM-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 15:18:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VFmL-0006WJ-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 15:18:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFmL-0003OY-BA; Wed, 25 Jun 2003 15:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFl7-0003Lm-3g for iptel@optimus.ietf.org; Wed, 25 Jun 2003 15:17:45 -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 PAA26786 for ; Wed, 25 Jun 2003 15:16:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VFkq-0006VI-00 for iptel@ietf.org; Wed, 25 Jun 2003 15:16:28 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19VFkf-0006So-00 for iptel@ietf.org; Wed, 25 Jun 2003 15:16:17 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5PJCba15076; Wed, 25 Jun 2003 12:12:37 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 12:12:37 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D209412132@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Conroy, Lawrence (SMTP)'" , "'Mpierce1@aol.com'" , "'hgs@cs.columbia.edu'" Cc: "'iptel@ietf.org'" Subject: RE: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel URI for Telepho... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33B4D.BD4F43F8" 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, 25 Jun 2003 12:12:37 -0700 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33B4D.BD4F43F8 Content-Type: text/plain > Hi Mike, folks, > there was a clear decision - the draft states it - tel: is NOT > dealing with dial strings. > all the best, > Lawrence Correct. That being said... If you specify a phone-context for your own purposes, you can effectively support "dialed" digits: it means that the phone-context itself would define the numbering plan that would correspond to the concept of dialled digits within that context. For example, I could define a phone-context=phones.siliconvalley.com for my phones. ------_=_NextPart_001_01C33B4D.BD4F43F8 Content-Type: text/html RE: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel URI for Telepho...

> Hi Mike, folks,
>    there was a clear decision - the draft states it - tel: is NOT
> dealing with dial strings.
> all the best,
>    Lawrence

Correct.

That being said...

If you specify a phone-context for your own purposes, you can effectively support "dialed"
digits: it means that the phone-context itself would define the numbering plan that would
correspond to the concept of dialled digits within that context.

For example, I could define a phone-context=phones.siliconvalley.com for my phones.


------_=_NextPart_001_01C33B4D.BD4F43F8-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Jun 25 15:21:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27116 for ; Wed, 25 Jun 2003 15:21:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PJLFS13811 for iptel-archive@odin.ietf.org; Wed, 25 Jun 2003 15:21:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFpT-0003aW-1c for iptel-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 15:21:15 -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 PAA27085 for ; Wed, 25 Jun 2003 15:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VFpK-0006Yo-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 15:21:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VFpE-0006Yl-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 15:21:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFpF-0003Y4-S6; Wed, 25 Jun 2003 15:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFp2-0003Wx-8b for iptel@optimus.ietf.org; Wed, 25 Jun 2003 15:20: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 PAA27070 for ; Wed, 25 Jun 2003 15:20:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VFp0-0006YV-00 for iptel@ietf.org; Wed, 25 Jun 2003 15:20:46 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19VFop-0006Y7-00 for iptel@ietf.org; Wed, 25 Jun 2003 15:20:35 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5PJERa15157; Wed, 25 Jun 2003 12:14:27 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 12:14:27 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D209412140@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Henning Schulzrinne'" , "'Mpierce1@aol.com'" Cc: "'iptel@ietf.org'" Subject: RE: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel URI for Telepho... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33B4D.FDA53890" 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, 25 Jun 2003 12:14:25 -0700 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33B4D.FDA53890 Content-Type: text/plain Mike Pierce says: I don't understand your statement above about "legal Q.23 letter A and an illegal DTMF A". They are the same thing. What do you mean by this? Do you mean that those numbers are "the same" or do you mean that they have the same requirements? (I believe you mean that they have the same requirements, in which case I agree). My take is that both are legal in a "local" context, and both are illegal in a global phone number. ------_=_NextPart_001_01C33B4D.FDA53890 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel = URI for Telepho...

Mike Pierce says:
        I don't = understand your statement above about "legal Q.23 letter A and an = illegal DTMF A".
        They are = the same thing.

What do you mean by this? Do you mean that those = numbers are "the same" or do you mean that they have the same = requirements? (I believe you mean that they have the same requirements, = in which case I agree). My take is that both are legal in a = "local" context, and both are illegal in

a global phone number.

------_=_NextPart_001_01C33B4D.FDA53890-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Jun 25 18:29:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07581 for ; Wed, 25 Jun 2003 18:29:55 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PMTUr23600 for iptel-archive@odin.ietf.org; Wed, 25 Jun 2003 18:29:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VIle-00068W-3L for iptel-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 18:29:30 -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 SAA07533 for ; Wed, 25 Jun 2003 18:29:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VIlX-0001LF-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 18:29:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VIlR-0001L2-02 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 18:29:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VIiH-0005tp-JB; Wed, 25 Jun 2003 18:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VIhW-0005qx-Rk for iptel@optimus.ietf.org; Wed, 25 Jun 2003 18:25: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 SAA07163 for ; Wed, 25 Jun 2003 18:24:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VIgR-0001Fx-00 for iptel@ietf.org; Wed, 25 Jun 2003 18:24:07 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19VIgG-0001Fr-00 for iptel@ietf.org; Wed, 25 Jun 2003 18:23:56 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 22:58:11 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFGB0YQS; Wed, 25 Jun 2003 22:58:03 +0100 From: "Conroy, Lawrence (SMTP)" To: Mpierce1@aol.com, iptel@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <1ee.be1f4e1.2c2b3ba6@aol.com> References: <1ee.be1f4e1.2c2b3ba6@aol.com> Subject: Re: [Iptel] Comments on draft rfc-2600bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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, 25 Jun 2003 22:57:57 +0100 At 1:53 pm -0400 25/6/03, Mpierce1@aol.com wrote: >Several additional comments on new version (although the material >commented on was in previous versions): > >Section 2 > >The 4th paragraph has some wording errors. It is not clear what it >is intended to say. It refers to the user or the terminal converting >a telephone number into a dial string. In fact, the user needs to >know whether or not to dial the area code, etc (i.e., converting the >desired telephone number into a dial string), but the terminal may >need to do the opposite. It needs to convert what the user dialed >(dial string) into a telephone number (e.g., full E.164 number) to >put into the tel:uri. The terminal would never convert from a real >telephone number to what is called a "dial string", at least not >when originating a call. >The following rewrite of this paragraph is suggested: > >--------------------- >To reach a telephone number from a particular terminal, the user of >the terminal has to know how to convert that telephone number into a >dial string appropriate for that terminal. The telephone number >itself does not convey what needs to be done for a particular >terminal. Instructions may include dialing "9" before placing a call >or prepending a "00" to reach a number in a foreign country. The >user may also need to strip area and country codes. > >The terminal has to know how to convert what the user dials or >enters into a full telephone number (e.g., E.164) in order to form a >tel:uri. This requires knowledge of the local dialing plan, county >code, area code, etc. >---------------------- to which I reply: Hi Mike, folks, I guess it depends on what you consider a terminal. Does this include an LCR/CP box, and/or a program on a PC to control the phone, and ... ? However, I am now more confused than ever with the proposed replacement. Assuming that we're talking about para 5 in section 2, starting "To Reach a telephone number from..." * A tel: URI might (or might not -- see annex A) be generated by a SIP UAC. My ISDN phone doesn't. As SIP is *not* the only use for this URI scheme, the last para in the proposed replacement is not appropriate, IMHO. (Notwithstanding the fact that I use an integrated dialer program that instructs the ISDN phone, and so neither this user nor his phone knows about converting telephone numbers into dial strings :), the first paragraph of the proposed replacement seems OK to me. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Wed Jun 25 18:32:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07788 for ; Wed, 25 Jun 2003 18:32:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PMWBb24233 for iptel-archive@odin.ietf.org; Wed, 25 Jun 2003 18:32:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VIoF-0006Im-MK for iptel-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 18:32:11 -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 SAA07745 for ; Wed, 25 Jun 2003 18:32:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VIo8-0001OP-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 18:32:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VIo2-0001OM-00 for iptel-web-archive@ietf.org; Wed, 25 Jun 2003 18:31:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VIo5-0006GD-4W; Wed, 25 Jun 2003 18:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VInQ-0006EC-Bt for iptel@optimus.ietf.org; Wed, 25 Jun 2003 18:31: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 SAA07691 for ; Wed, 25 Jun 2003 18:31:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VIn8-0001NT-00 for iptel@ietf.org; Wed, 25 Jun 2003 18:31:02 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19VImx-0001M9-00 for iptel@ietf.org; Wed, 25 Jun 2003 18:30:51 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5PMTHc29576; Wed, 25 Jun 2003 17:29:17 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 15:29:17 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20941265C@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Henning Schulzrinne'" , "'Conroy, Lawrence (SMTP)'" Cc: "'iptel@ietf.org'" Subject: RE: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel URI for Telephone Calls MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33B69.37160C24" 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, 25 Jun 2003 15:29:17 -0700 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33B69.37160C24 Content-Type: text/plain > Please look at the wording of > http://www1.cs.columbia.edu/sip/drafts/draft-ietf-iptel-rfc2806bis-01.txt > to see if this is acceptable I am 100% happy with this text. ------_=_NextPart_001_01C33B69.37160C24 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel = URI for Telephone Calls

> Please look at the wording of
> http://www1.cs.columbia.edu/sip/drafts/draft-ietf-ipte= l-rfc2806bis-01.txt
> to see if this is acceptable

I am 100% happy with this text.

------_=_NextPart_001_01C33B69.37160C24-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Thu Jun 26 02:26:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09879 for ; Thu, 26 Jun 2003 02:26:14 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q6OS520991 for iptel-archive@odin.ietf.org; Thu, 26 Jun 2003 02:24:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQBH-0005SI-QJ for iptel-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 02:24:27 -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 CAA09768 for ; Thu, 26 Jun 2003 02:24:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQ81-0005ye-00 for iptel-web-archive@ietf.org; Thu, 26 Jun 2003 02:21:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VQ7v-0005yb-00 for iptel-web-archive@ietf.org; Thu, 26 Jun 2003 02:20:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQ7x-0005A9-8p; Thu, 26 Jun 2003 02:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VQ6p-00055a-Kn for iptel@optimus.ietf.org; Thu, 26 Jun 2003 02:20: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 CAA09636 for ; Thu, 26 Jun 2003 02:19:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VQ6m-0005xu-00 for iptel@ietf.org; Thu, 26 Jun 2003 02:19:48 -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 19VQ6b-0005xZ-00 for iptel@ietf.org; Thu, 26 Jun 2003 02:19:37 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Jun 2003 23:22:03 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5Q6IkgE029007; Wed, 25 Jun 2003 23:18:46 -0700 (PDT) Received: from cisco.com (sjc-vpn4-733.cisco.com [10.21.82.221]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIN38741; Wed, 25 Jun 2003 23:11:39 -0700 (PDT) Message-ID: <3EFA9045.750D9484@cisco.com> From: Manjunath Bangalore X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: iptel@ietf.org Subject: Re: [Iptel] comments on draft-ietf-iptel-tgrep-01.txt References: <003e01c31952$dec019d0$2300000a@BPenfield> 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, 25 Jun 2003 23:18:45 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Bob, Appreciate your comments about the TGREP draft. I had a clarification about this one comment of yours. > Section 3.6.1: The carrier length should be variable. The carrier is usually > derived from dialed digits, thus deployments will likely use the carrier > codes used in dialing as TGREP carriers to avoid the additional overhead of > mapping dialed carrier codes to TGREP carrier codes. The US uses 5-digit > carrier codes in dialing (e.g. 10288 for AT&T as in 1010288). Is it to be > assumed that for country code of less than three digits that the 3-octet > country-code is padded with NULL bytes? Yes, country codes less than three digits should be padded with NULL bytes, and this will be specified in the next revision. Given that, would you think there is reason to make the Carrier code to be variable-length? Also, for padding ASCII strings, is it common practice to use the "NULL" or the "blank" character? Thanks, -Manjax _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Thu Jun 26 07:07:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15269 for ; Thu, 26 Jun 2003 07:07:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QB7A812364 for iptel-archive@odin.ietf.org; Thu, 26 Jun 2003 07:07:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUas-0003DC-1N for iptel-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 07:07:10 -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 HAA15237 for ; Thu, 26 Jun 2003 07:07:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VUan-0007SW-00 for iptel-web-archive@ietf.org; Thu, 26 Jun 2003 07:07:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VUai-0007ST-00 for iptel-web-archive@ietf.org; Thu, 26 Jun 2003 07:07:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUak-00038G-Ai; Thu, 26 Jun 2003 07:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUaB-00036P-AI for iptel@optimus.ietf.org; Thu, 26 Jun 2003 07:06:27 -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 HAA15199 for ; Thu, 26 Jun 2003 07:06:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VUZs-0007Ri-00 for iptel@ietf.org; Thu, 26 Jun 2003 07:06:08 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19VUZg-0007RD-00 for iptel@ietf.org; Thu, 26 Jun 2003 07:05:57 -0400 Subject: RE: [Iptel] Comments on draft rfc-2600bis Message-ID: <06CF906FE3998C4E944213062009F1622336E4@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33BD3.6ADAFC70" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Thread-Topic: [Iptel] Comments on draft rfc-2600bis Thread-Index: AcM7Q6zM6R6atLVKRjuv8u81GVtycgAjWFPg From: "Stastny Richard" To: , 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, 26 Jun 2003 13:09:31 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C33BD3.6ADAFC70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Although I am still not perfectly happy with Mikes proposed text, I prefer Mike proposal=20 rather then the original text. =20 The problem I have in general is that the terms public network vs private networks work on the PSTN/ISDN and are well defined here, but do not work on the Internet, and E.164 endpoints may also be on the Internet now. =20 In addition, an E.164 may also define an end-point in a private network, if part of it is a "partial" number, as defined in E.164 Annex B. I do not want to blame anybody out there for this mess, because even ITU-T Rec. E.164 is not=20 clear about this definitions. The problem has been recognised already and a correspondance group has been established at the last SG2 meeting to work on this, but this is no help for now. =20 Richard -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]=20 Sent: Wednesday, June 25, 2003 7:54 PM To: iptel@ietf.org Subject: [Iptel] Comments on draft rfc-2600bis =09 =09 Several additional comments on new version (although the material commented on was in previous versions):=20 =09 Definition of Address-of-record and Dial String=20 =09 Section 2 defines two types of telephone numbers: "address-of-record" (or identifier) and "dial string". Unfortunately, the definitions leave some uncertainty as to where addresses which represent destinations in a private network belong. Since such a number as passed within such a private network may not be exactly what was dialed, it is not a "dial string". However, "Address-of-record" is defined in terms of "a public network termination point". Neither definition correctly covers the private network number.=20 =09 The problem seems to be the definition of "Address-of-record" which directly relates it to a "public network". The definition should include the notion of "non-public" networks as follows:=20 =09 ---------------------=20 Address-of-record or identifier: The telephone number is understood here as the canonical address-of-record or identifier for a termination point within a specific network. For the public network, these numbers generally follow the rules in E.164 [4]. Subscribers publish such identifiers or phone numbers as a universal means of being reached from within that network, independent of the location of the caller. (Naturally, not all numbers are reachable from everywhere in a network, for a variety of technical and local policy reasons.) It should be noted that a single termination point in one network may be reachable from different networks and would then have multiple such identifiers, one valid from each network.=20 ----------------------=20 =09 =20 ------_=_NextPart_001_01C33BD3.6ADAFC70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Although I am still not perfectly happy with = Mikes=20 proposed text, I prefer Mike proposal 
rather=20 then the original text.
 
The=20 problem I have in general is that the terms public network vs private = networks=20 work on the
PSTN/ISDN and are well defined here, but do = not work on=20 the Internet, and E.164 endpoints may also be
on the=20 Internet now.
 
In=20 addition, an E.164 may also define an end-point in a private network, if = part of=20 it is a "partial" number,
as=20 defined in E.164 Annex B.
I do=20 not want to blame anybody out there for this mess, because even ITU-T = Rec. E.164=20 is not
clear=20 about this definitions. The problem has been recognised already and a=20 correspondance
group=20 has been established at the last SG2 meeting to work on this, but this = is no=20 help for now.
 
Richard
-----Original Message-----
From: = Mpierce1@aol.com=20 [mailto:Mpierce1@aol.com]
Sent: Wednesday, June 25, 2003 = 7:54=20 PM
To: iptel@ietf.org
Subject: [Iptel] Comments on = draft=20 rfc-2600bis

Several additional comments on = new version=20 (although the material commented on was in previous versions):=20

Definition of Address-of-record and Dial String =

Section 2=20 defines two types of telephone numbers: "address-of-record" (or = identifier)=20 and "dial string". Unfortunately, the definitions leave some = uncertainty as to=20 where addresses which represent destinations in a private network = belong.=20 Since such a number as passed within such a private network may not be = exactly=20 what was dialed, it is not a "dial string". However, = "Address-of-record" is=20 defined in terms of "a public network termination point". Neither = definition=20 correctly covers the private network number.

The problem seems = to be=20 the definition of "Address-of-record" which directly relates it to a = "public=20 network". The definition should include the notion of "non-public" = networks as=20 follows:

---------------------
Address-of-record or = identifier:=20 The telephone number is understood here as the canonical = address-of-record or=20 identifier for a termination point within a specific network. For the = public=20 network, these numbers generally follow the rules in E.164 [4]. = Subscribers=20 publish such identifiers or phone numbers as a universal means of = being=20 reached from within that network, independent of the location of the = caller.=20 (Naturally, not all numbers are reachable from everywhere in a = network, for a=20 variety of technical and local policy reasons.) It should be noted = that a=20 single termination point in one network may be reachable from = different=20 networks and would then have multiple such identifiers, one valid from = each=20 network.
---------------------- 

  
= =00 ------_=_NextPart_001_01C33BD3.6ADAFC70-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Thu Jun 26 14:47:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14448 for ; Thu, 26 Jun 2003 14:47:50 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFl1S24809 for iptel-archive@odin.ietf.org; Wed, 25 Jun 2003 11:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCU7-0006Rd-45 for iptel-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:46:59 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17504 for ; Wed, 25 Jun 2003 11:46:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCSt-00068D-KJ; Wed, 25 Jun 2003 11:45:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VC0A-0007wP-FH for iptel@optimus.ietf.org; Wed, 25 Jun 2003 11:16:02 -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 VAA01510 for ; Tue, 24 Jun 2003 21:32:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uxs2-0000Rd-00 for iptel@ietf.org; Tue, 24 Jun 2003 20:10:42 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19Uxrs-0000RU-00 for iptel@ietf.org; Tue, 24 Jun 2003 20:10:32 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 01:10:28 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFGB0WF9; Wed, 25 Jun 2003 01:10:16 +0100 From: "Conroy, Lawrence (SMTP)" To: Henning Schulzrinne , Francois Audet Cc: "'iptel@ietf.org'" Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <3EF8C2B8.9000109@cs.columbia.edu> References: <2F1FC1DEA077D5119FAD00508BCFD6D208053D50@zsc3c030.us.nortel.com> <3EF8C2B8.9000109@cs.columbia.edu> Subject: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel URI for Telephone Calls Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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, 25 Jun 2003 01:10:09 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Henning, Fran=E7ois, folks, At 5:29 pm -0400 24/6/03, Henning Schulzrinne wrote: >Francois Audet wrote (on 25/04/03, in HTML) a review of 2806-08. > >Thank you much for your extensive comments. I'll only comment on the=20 >more major changes, just in case somebody wants to jump in. OK, here goes...referring back to the pints made in Fran=E7ois' = original review: 2) final sub-point: Perhaps "resource associated with a telephone=20 number" might be less easily confused with telephone numbers as a resource?=20 (I've read too many SG2//SPAN//... documents :). 7) I disagree. The program on my PC knows the context in which it = works; if I select a number from my address book it will detect where this = involves a call external to the ISPBX and will process this to include the = "public escape digit", in our case "9". This is passed via ISDN signalling = to the ISPBX from the ISDN phone that is in turn driven by the program. = This is a dialer application, as it DOES have to deal with dialing plans - = my address book doesn't, and the phone doesn't. I think that this is = an immediate counter-example, so I'd suggest that it is left as is in = -08. 8) I took the parenthetical clause to mean DID or MSN/partial number = or sub-addressing service. Whilst we COULD spell out all of the = options, the use of "DID" (DDI over here) to encompass all of these = services seems better, IMHO. 9) Oops - what was this section meant to cover? 10) Big point:: If this is the sense of the group, then I'll live with = it. However, I don't like it at all, as it is perfectly possible to = identify a number of contexts in which an address resolves to the same = termination point (usually to a call centre somewhere in India). Programming = the same drop point for the "same" number used in different = countries/contexts does happen, so whilst this is by no means always the case, this = doesn't mean that it never happens. Multiple contexts can be valid for a given = number, IMHO, so I don't think we should ban them. 12) I agree with you both - I don't see how we can avoid prohibiting = ISUP non-decadic signals (useful for some private systems) whilst = blocking the non-decadic dialed digits, so I guess we have to leave it as = is - I take the last sentence to discourage their use anyway. 13) That's why it's a SHOULD rather than a MUST; how does this proposed additional text help? Please can we leave this as is (it has been through enough iterations already :). 14) Big Point redux:: I disagree, for the same reasons given for (10) = above. 17) only if we want a circular reference :) 18) Absolutely agree with this - unfortunately, it clashes with=20 reality right now :( Perhaps we should put in a sentence to clarify that: "This basic approach is can be onerous, in that the OBP may=20 maintain a number of different contexts, and so may be forced to add a=20 phone-context appropriate to the private number plan associated with the call to any tel:=20 URI it generates, interpreting this based either on the identity of the originating=20 phone user and the number they specify in the call". all the best, Lawrence --=20 ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is = not : intended to create any contractual or legal : relationship. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Thu Jun 26 14:49:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14595 for ; Thu, 26 Jun 2003 14:49:51 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFmci27909 for iptel-archive@odin.ietf.org; Wed, 25 Jun 2003 11:48:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCVh-0007Ep-8O for iptel-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:48:37 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17721 for ; Wed, 25 Jun 2003 11:48:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCVC-0006uX-KW; Wed, 25 Jun 2003 11:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VC0B-0006YL-T7 for iptel@optimus.ietf.org; Wed, 25 Jun 2003 11:16:03 -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 VAA02361 for ; Tue, 24 Jun 2003 21:46:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UzMc-0001N4-00 for iptel@ietf.org; Tue, 24 Jun 2003 21:46:22 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19UzMM-0001Mp-00 for iptel@ietf.org; Tue, 24 Jun 2003 21:46:06 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5P1jQkM002425; Tue, 24 Jun 2003 21:45:26 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h5P1jON22461; Tue, 24 Jun 2003 21:45:24 -0400 Message-ID: <3EF8FDCC.9000408@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Conroy, Lawrence (SMTP)" CC: Francois Audet , "'iptel@ietf.org'" Subject: Re: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel URI for Telephone Calls References: <2F1FC1DEA077D5119FAD00508BCFD6D208053D50@zsc3c030.us.nortel.com> <3EF8C2B8.9000109@cs.columbia.edu> In-Reply-To: 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, 24 Jun 2003 21:41:32 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Conroy, Lawrence (SMTP) wrote: > > 2) final sub-point: Perhaps "resource associated with a telephone > number" might > be less easily confused with telephone numbers as a resource? (I've > read too > many SG2//SPAN//... documents :). where? "resources identified by a phone number" seems clear enough. > > 7) I disagree. The program on my PC knows the context in which it > works; if I > select a number from my address book it will detect where this involves > a call external to the ISPBX and will process this to include the > "public > escape digit", in our case "9". This is passed via ISDN signalling > to the > ISPBX from the ISDN phone that is in turn driven by the program. > This is > a dialer application, as it DOES have to deal with dialing plans - my > address book doesn't, and the phone doesn't. I think that this is an > immediate counter-example, so I'd suggest that it is left as is in -08. Please look at the wording of http://www1.cs.columbia.edu/sip/drafts/draft-ietf-iptel-rfc2806bis-01.txt to see if this is acceptable. > > 8) I took the parenthetical clause to mean DID or MSN/partial number or > sub-addressing service. Whilst we COULD spell out all of the options, > the use of "DID" (DDI over here) to encompass all of these services > seems better, IMHO. I've simply omitted this since 'tel' does support extensions and sub-addresses. Again, please see the new text. > > 9) Oops - what was this section meant to cover? What's now in the tel-for-SIP appendix. > > 10) Big point:: If this is the sense of the group, then I'll live with it. > However, I don't like it at all, as it is perfectly possible to > identify > a number of contexts in which an address resolves to the same > termination > point (usually to a call centre somewhere in India). Programming the > same > drop point for the "same" number used in different > countries/contexts does > happen, so whilst this is by no means always the case, this doesn't > mean > that it never happens. Multiple contexts can be valid for a given > number, > IMHO, so I don't think we should ban them. The perception was that it would be tedious to identify all the contexts and that in some circumstances, it would be better to designate a new context that encompasses several individual ones. I'm agnostic on this one, but this has to be resolved one way or the other. I'm having a hard time seeing where such multiple contexts would appear. They clearly won't appear in the phone-puts-numbers-in-URI case. A web page or directory seem about the only case, and seem rare even there. Even if the number is the same, listing a few instances like dial tel:1234;context=+1 in the UA dial tel:1234;context=+49 in Germany seems good enough. In most cases, it seems that the number, while valid in multiple contexts, only needs to be made unambiguous by labeling it with one. > > 12) I agree with you both - I don't see how we can avoid prohibiting ISUP > non-decadic signals (useful for some private systems) whilst blocking > the non-decadic dialed digits, so I guess we have to leave it as is - > I take the last sentence to discourage their use anyway. I don't think they are going to be common and the people that really, really need them will hopefully know what to do with them. > > 13) That's why it's a SHOULD rather than a MUST; how does this proposed > additional text help? Please can we leave this as is (it has been > through enough iterations already :). > > 17) only if we want a circular reference :) RFC 3261 does explain the syntax. > > 18) Absolutely agree with this - unfortunately, it clashes with reality > right now :( > > Perhaps we should put in a sentence to clarify that: > > "This basic approach is can be onerous, in that the OBP may maintain > a number > of different contexts, and so may be forced to add a phone-context > appropriate > to the private number plan associated with the call to any tel: URI > it generates, > interpreting this based either on the identity of the originating > phone user > and the number they specify in the call". > Please see new text and suggest improvements if necessary. > > all the best, > Lawrence _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Fri Jun 27 14:47:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12701 for ; Fri, 27 Jun 2003 14:47:03 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIkXZ25236 for iptel-archive@odin.ietf.org; Fri, 27 Jun 2003 14:46:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VyEz-0006Yw-R5 for iptel-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:46:33 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12674 for ; Fri, 27 Jun 2003 14:46:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VyET-0006QF-Oy; Fri, 27 Jun 2003 14:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VyDs-0006Mf-B2 for iptel@optimus.ietf.org; Fri, 27 Jun 2003 14:45:39 -0400 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12583 for ; Fri, 27 Jun 2003 14:45:23 -0400 (EDT) Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 27 Jun 2003 11:39:45 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5RIdmMO024330; Fri, 27 Jun 2003 11:39:49 -0700 (PDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-140.cisco.com [64.100.229.140]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFD05653; Fri, 27 Jun 2003 11:39:46 -0700 (PDT) Message-Id: <4.3.2.7.2.20030627143729.00b91f20@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Manjunath Bangalore From: Michael Hammer Subject: Re: [Iptel] comments on draft-ietf-iptel-tgrep-01.txt Cc: Bob Penfield , iptel@ietf.org In-Reply-To: <3EFA9045.750D9484@cisco.com> References: <003e01c31952$dec019d0$2300000a@BPenfield> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_18033480==_.ALT" 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, 27 Jun 2003 14:39:46 -0400 --=====================_18033480==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Bob, Reference the 1010288: 101 is a dialing prefix indicating that the following is a carrier code, 0288 is the 4-digit carrier code. In a sense the 0 before 288 could be considered padding to get to the fixed length 4 digit code. Mike At 11:18 PM 6/25/2003 -0700, Manjunath Bangalore wrote: >Hi Bob, > >Appreciate your comments about the TGREP draft. >I had a clarification about this one comment of yours. > > > Section 3.6.1: The carrier length should be variable. The carrier is > usually > > derived from dialed digits, thus deployments will likely use the carrier > > codes used in dialing as TGREP carriers to avoid the additional overhead of > > mapping dialed carrier codes to TGREP carrier codes. The US uses 5-digit > > carrier codes in dialing (e.g. 10288 for AT&T as in 1010288). Is it to be > > assumed that for country code of less than three digits that the 3-octet > > country-code is padded with NULL bytes? > >Yes, country codes less than three digits should be padded with NULL >bytes, and >this will be specified in the next revision. Given that, would you think there >is reason to make the Carrier code to be variable-length? >Also, for padding ASCII strings, is it common practice to use the "NULL" >or the >"blank" character? > >Thanks, >-Manjax > >_______________________________________________ >Iptel mailing list >Iptel@ietf.org >https://www.ietf.org/mailman/listinfo/iptel --=====================_18033480==_.ALT Content-Type: text/html; charset="us-ascii" Bob,

Reference the 1010288:

101 is a dialing prefix indicating that the following is a carrier code,
0288 is the 4-digit carrier code.

In a sense the 0 before 288 could be considered padding to get to the fixed length 4 digit code.

Mike


At 11:18 PM 6/25/2003 -0700, Manjunath Bangalore wrote:
Hi Bob,

Appreciate your comments about the TGREP draft.
I had a clarification about this one comment of yours.

> Section 3.6.1: The carrier length should be variable. The carrier is usually
> derived from dialed digits, thus deployments will likely use the carrier
> codes used in dialing as TGREP carriers to avoid the additional overhead of
> mapping dialed carrier codes to TGREP carrier codes. The US uses 5-digit
> carrier codes in dialing (e.g. 10288 for AT&T as in 1010288). Is it to be
> assumed that for country code of less than three digits that the 3-octet
> country-code is padded with NULL bytes?

Yes, country codes less than three digits should be padded with NULL bytes, and
this will be specified in the next revision. Given that, would you think there
is reason to make the Carrier code to be variable-length?
Also, for padding ASCII strings, is it common practice to use the "NULL" or the
"blank" character?

Thanks,
-Manjax

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel
--=====================_18033480==_.ALT-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Fri Jun 27 18:31:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23764 for ; Fri, 27 Jun 2003 18:31:07 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RMUfv29772 for iptel-archive@odin.ietf.org; Fri, 27 Jun 2003 18:30:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1jt-0007k7-2X for iptel-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 18:30:41 -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 SAA23491 for ; Fri, 27 Jun 2003 18:30:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W1jq-0006qE-00 for iptel-web-archive@ietf.org; Fri, 27 Jun 2003 18:30:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19W1jk-0006pl-00 for iptel-web-archive@ietf.org; Fri, 27 Jun 2003 18:30:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1jV-0007UB-B5; Fri, 27 Jun 2003 18:30:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1D4-0005II-QT for iptel@optimus.ietf.org; Fri, 27 Jun 2003 17:58:07 -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 RAA21623 for ; Fri, 27 Jun 2003 17:56:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W1Cn-0006e2-00 for iptel@ietf.org; Fri, 27 Jun 2003 17:56:29 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19W1CX-0006ds-00 for iptel@ietf.org; Fri, 27 Jun 2003 17:56:13 -0400 Received: from cs.columbia.edu (dyn-wireless-246-119.dyn.columbia.edu [160.39.246.119]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5RLtjA4017169 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Jun 2003 17:55:48 -0400 (EDT) Message-ID: <3EFCBD5A.6070505@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Conroy, Lawrence (SMTP)" CC: iptel@ietf.org Subject: Re: [Iptel] iptel-rfc2806-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) 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: Fri, 27 Jun 2003 17:55:38 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Conroy, Lawrence (SMTP) wrote: > * ?Typo? in section 4, second bullet - what does "mandatory extension > parameters" > mean here? and parameters are mentioned > explicitly, > so I'm not sure what the mandatory extension parameters covers. Mandatory extension parameters are defined in Section 5.4. I think part of the confusion is that 'extension' refers to both extensions in the telephone sense and to protocols extensions. I'll try to avoid the second meaning wherever possible. > * Section 5.4, 1st para, 3rd/4th/5th sentence - I'm still slightly > uncomfortable > with "how mandatory is mandatory". The paragraph as is states only > that the URI > must not be used if it includes unknown mandatory parameters - a known > but ignored mandatory parameter isn't covered. > => Could the 3rd sentence have this text added to it, please?: > "and MUST NOT be ignored". > Basically, I assume that such a m-parameter is mandatory to act on; > however, > I have had this conversation before with others who have thought > that the > parameter needed only to be understood, but could be ignored. I'm not sure what it means to understand something and ignore it. (Although I know that my son performs this feat all the time.) There may well be parameters that are not meaningful for a particular device. In that case, the device recognizes the parameter, but doesn't do anything observably different. I suppose you could call this 'ignoring'. Thus, I don't see how your clarification helps. > > * Annex A: > Aahh...this one's tricky. If I understand the text correctly, Proxy > Translation > first paragraph (third sentence) and the last paragraph (last sentence) > imply > that the OBP has ->its<- local dial plan. > > I use a proxy that maintains more than one context, and can select the > context > based on the caller (e.g. a calling SIP AoR is classified as being in a > particular > context, and the URI is interpreted in those terms). I'm reluctant to use the caller AOR as a dial plan selector simply because the same AOR can place calls from different locations within the same organization (same OBP). In those cases, there are two reasonable behaviors: (1) Use the 'visited' dial plan; (2) Use the home dial plan. Forcing the use of context avoids having to guess. However, rereading the text, I see the need for clean up and will try to reword. I've reworded as "The outbound proxy can then apply the dial plan indicated by the phone context in the URI" ... Does that help? > > Thus, in para 1, sentence 3, c/local dial plan/local dial plan logic/ > Similarly, in the last paragraph, could the last sentence be replaced > entirely > by something like: > "Otherwise, a provider or enterprise would have to provision each > calling station > into an appropriate dial plan, and the OBP would have to interpret the > required > destination in terms of the dial plan to which that calling station had > been > associated". I hope this is now clearer without this additional sentence. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Fri Jun 27 18:31:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23806 for ; Fri, 27 Jun 2003 18:31:10 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RMUic29821 for iptel-archive@odin.ietf.org; Fri, 27 Jun 2003 18:30:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1jw-0007ku-52 for iptel-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 18:30:44 -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 SAA23551 for ; Fri, 27 Jun 2003 18:30:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W1jt-0006qT-00 for iptel-web-archive@ietf.org; Fri, 27 Jun 2003 18:30:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19W1jn-0006pn-00 for iptel-web-archive@ietf.org; Fri, 27 Jun 2003 18:30:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1jX-0007Vr-HQ; Fri, 27 Jun 2003 18:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1Vr-0006W3-OE for iptel@optimus.ietf.org; Fri, 27 Jun 2003 18:16:11 -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 SAA22873 for ; Fri, 27 Jun 2003 18:16:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W1Vo-0006i9-00 for iptel@ietf.org; Fri, 27 Jun 2003 18:16:09 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19W1VZ-0006i5-00 for iptel@ietf.org; Fri, 27 Jun 2003 18:15:53 -0400 Received: from cs.columbia.edu (dyn-wireless-246-119.dyn.columbia.edu [160.39.246.119]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5RMFUm4018573 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Jun 2003 18:15:31 -0400 (EDT) Message-ID: <3EFCC1FC.7010002@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: iptel@ietf.org Subject: Re: [Iptel] Comments on draft rfc-2600bis References: <1ee.be1f4e1.2c2b3ba6@aol.com> In-Reply-To: <1ee.be1f4e1.2c2b3ba6@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) 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: Fri, 27 Jun 2003 18:15:24 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for your comments. Mpierce1@aol.com wrote: [elided] > for a variety of technical and local policy reasons.) It should be noted > that a single termination point in one network may be reachable from > different networks and would then have multiple such identifiers, one > valid from each network. > ---------------------- I've adopted your definition, more or less. > > Section 2 > > The terminal has to know how to convert what the user dials or enters > into a full telephone number (e.g., E.164) in order to form a tel:uri. > This requires knowledge of the local dialing plan, county code, area > code, etc. > ---------------------- Adopted, modulo minor tweaking. > > 10 Security Considerations > > The last bullet item, about "a call may use ... different contexts", > should be deleted. Gone. > > Mike Pierce > Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Fri Jun 27 18:33:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24040 for ; Fri, 27 Jun 2003 18:33:57 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RMXVf01801 for iptel-archive@odin.ietf.org; Fri, 27 Jun 2003 18:33:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1md-0000Sy-Cm for iptel-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 18:33:31 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24012 for ; Fri, 27 Jun 2003 18:33:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1m8-0000Dy-Vv; Fri, 27 Jun 2003 18:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1lH-0008Gi-2a for iptel@optimus.ietf.org; Fri, 27 Jun 2003 18:32: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 SAA23904 for ; Fri, 27 Jun 2003 18:32:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W1lE-0006rT-00 for iptel@ietf.org; Fri, 27 Jun 2003 18:32:04 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19W1kq-0006r5-00 for iptel@ietf.org; Fri, 27 Jun 2003 18:31:44 -0400 Received: from cs.columbia.edu (dhcp39.cs.columbia.edu [128.59.19.239]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5RMUvm4022535 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Jun 2003 18:30:58 -0400 (EDT) Message-ID: <3EFCC59A.509@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard CC: Mpierce1@aol.com, iptel@ietf.org Subject: Re: [Iptel] Comments on draft rfc-2600bis References: <06CF906FE3998C4E944213062009F1622336E4@oefeg-s02.oefeg.loc> In-Reply-To: <06CF906FE3998C4E944213062009F1622336E4@oefeg-s02.oefeg.loc> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) 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: Fri, 27 Jun 2003 18:30:50 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Unless this makes a crucial difference to the interpretation of the core part of the text or the use of tel URIs, may I suggest that we leave this philosophical discussion to the efforts within SG2 and move on? Stastny Richard wrote: > Although I am still not perfectly happy with Mikes proposed text, I > prefer Mike proposal > rather then the original text. > > The problem I have in general is that the terms public network vs > private networks work on the > PSTN/ISDN and are well defined here, but do not work on the Internet, > and E.164 endpoints may also be > on the Internet now. > > In addition, an E.164 may also define an end-point in a private network, > if part of it is a "partial" number, > as defined in E.164 Annex B. > I do not want to blame anybody out there for this mess, because even > ITU-T Rec. E.164 is not > clear about this definitions. The problem has been recognised already > and a correspondance > group has been established at the last SG2 meeting to work on this, but > this is no help for now. > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Fri Jun 27 19:17:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23767 for ; Fri, 27 Jun 2003 18:31:07 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RMUfk29789 for iptel-archive@odin.ietf.org; Fri, 27 Jun 2003 18:30:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1jt-0007kO-Mg for iptel-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 18:30:41 -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 SAA23503 for ; Fri, 27 Jun 2003 18:30:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W1jq-0006qB-00 for iptel-web-archive@ietf.org; Fri, 27 Jun 2003 18:30:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19W1jk-0006pk-00 for iptel-web-archive@ietf.org; Fri, 27 Jun 2003 18:30:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1ja-0007YM-1u; Fri, 27 Jun 2003 18:30:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1gY-00071e-J1 for iptel@optimus.ietf.org; Fri, 27 Jun 2003 18:27: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 SAA23166 for ; Fri, 27 Jun 2003 18:27:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W1gV-0006ju-00 for iptel@ietf.org; Fri, 27 Jun 2003 18:27:11 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19W1gF-0006jp-00 for iptel@ietf.org; Fri, 27 Jun 2003 18:26:56 -0400 Received: from cs.columbia.edu (dyn-wireless-246-119.dyn.columbia.edu [160.39.246.119]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5RMQfA4000618 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Jun 2003 18:26:41 -0400 (EDT) Message-ID: <3EFCC49A.1060506@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Conroy, Lawrence (SMTP)" CC: Mpierce1@aol.com, iptel@ietf.org Subject: Re: [Iptel] Comments on draft rfc-2600bis References: <1ee.be1f4e1.2c2b3ba6@aol.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) 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: Fri, 27 Jun 2003 18:26:34 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I guess it depends on what you consider a terminal. Does this include an > LCR/CP box, and/or > a program on a PC to control the phone, and ... ? Does 2806bis really have to get into these philosophical distinctions? Are they material to understanding the text? Maybe I should just use "telephone", and treat this as an example, rather than trying to make find distinctions between humans, software that acts like humans, and random other special boxes. > However, I am now more confused than ever with the proposed replacement. > Assuming that > we're talking about para 5 in section 2, starting "To Reach a telephone > number from..." I reworded this as an example, using 'phone on a PBX' instead of 'device'. Since the conversion from dial strings to tel URIs is covered in depth later in the document, I'd rather not repeat this up front, as a full treatment would simply be a rehash. (You'd have to mention local numbers, etc.) > > * A tel: URI might (or might not -- see annex A) be generated by a SIP > UAC. My ISDN phone doesn't. > As SIP is *not* the only use for this URI scheme, the last para in > the proposed replacement > is not appropriate, IMHO. > > (Notwithstanding the fact that I use an integrated dialer program that > instructs the ISDN phone, > and so neither this user nor his phone knows about converting telephone > numbers into dial strings :), > the first paragraph of the proposed replacement seems OK to me. > > all the best, > Lawrence _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From exim@www1.ietf.org Mon Jun 30 07:55:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13121 for ; Mon, 30 Jun 2003 07:55:26 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UBsuD08762 for iptel-archive@odin.ietf.org; Mon, 30 Jun 2003 07:54:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxFI-0002HF-Cb for iptel-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 07:54:56 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13030 for ; Mon, 30 Jun 2003 07:54: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 19WxEO-00025j-LC; Mon, 30 Jun 2003 07:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxDR-0001y5-5y for iptel@optimus.ietf.org; Mon, 30 Jun 2003 07:53:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12321; Mon, 30 Jun 2003 07:52:59 -0400 (EDT) Message-Id: <200306301152.HAA12321@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Iptel] I-D ACTION:draft-ietf-iptel-rfc2806bis-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: Mon, 30 Jun 2003 07:52:59 -0400 --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, A. Vaha-Sipila Filename : draft-ietf-iptel-rfc2806bis-01.txt Pages : 18 Date : 2003-6-27 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-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-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-rfc2806bis-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: <2003-6-27150653.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-rfc2806bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-rfc2806bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27150653.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel