From extest-admin@lists.bell-labs.com Sun Dec 1 05:59:48 2002 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 FAA02625 for ; Sun, 1 Dec 2002 05:59:48 -0500 (EST) 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 gB1B2c201336 for ; Sun, 1 Dec 2002 06:02:38 -0500 Date: Sun, 1 Dec 2002 06:02:38 -0500 Message-Id: <200212011102.gB1B2c201336@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 Mon Dec 2 09:29:00 2002 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 JAA16360 for ; Mon, 2 Dec 2002 09:29:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2EVLB01736 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 09:31:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2EVLv01733 for ; Mon, 2 Dec 2002 09:31:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16336 for ; Mon, 2 Dec 2002 09:28:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2EVGv01723; Mon, 2 Dec 2002 09:31:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2EULv01664 for ; Mon, 2 Dec 2002 09:30:21 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16307 for ; Mon, 2 Dec 2002 09:27:29 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB2EUag8001366; Mon, 2 Dec 2002 09:30:36 -0500 (EST) Received: from mhammer-w2k01.cisco.com (hrn2-dhcp-161-44-87-85.cisco.com [161.44.87.85]) by cia.cisco.com (Mirapoint) with ESMTP id ABJ66719; Mon, 2 Dec 2002 09:20:01 -0500 (EST) Message-Id: <4.3.2.7.2.20021202092900.00b3fe30@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Henning Schulzrinne From: Michael Hammer Subject: Re: [Iptel] Another wrinkle: 700 numbers Cc: iptel@ietf.org In-Reply-To: <3DE905EB.3070900@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, 02 Dec 2002 09:30:06 -0500 Henning, Define rare. I believe that some of the 700 number space is used for the Government Emergency Telephone Service (GETS). Mike At 01:39 PM 11/30/2002 -0500, Henning Schulzrinne wrote: >This is another example of a barely-unique number, except that the >destination depends on the carrier. > >I don't think we need to worry about this, but it could make life >interesting if put on a web page... My perception is that 700 numbers are >rarely used these days. > > From the FAQ at http://www.nanpa.com/: > >What is area code 700 used for? > >Area code 700 was assigned in 1983 on the eve of the introduction of long >distance competition in the US. The intent was that interexchange carriers >could use 700 numbers to implement new services quickly. When a 700 number >is dialed, the local exchange carrier processing the call routes it to the >presubscribed interexchange carrier, unless the caller has overridden >presubscription by dialing 101XXXX before the number. Thus each >interexchange carrier has access to all 7.92 million 700 numbers. 700 >numbers are different from all other North American Numbering Plan numbers >because the destinations are not unique, and, in fact, depend on the >network the caller has selected. > >_______________________________________________ >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 mailnull@www1.ietf.org Mon Dec 2 09:36:49 2002 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 JAA16809 for ; Mon, 2 Dec 2002 09:36:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2EdBd02750 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 09:39:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2EdBv02747 for ; Mon, 2 Dec 2002 09:39:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16797 for ; Mon, 2 Dec 2002 09:36:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Ed5v02730; Mon, 2 Dec 2002 09:39:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2EcDv02698 for ; Mon, 2 Dec 2002 09:38:13 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16771 for ; Mon, 2 Dec 2002 09:35:20 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2Ec9l8007296 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 2 Dec 2002 09:38:10 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2Ec8dG026153 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 2 Dec 2002 09:38:09 -0500 (EST) Message-ID: <3DEB7043.6070209@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Iptel] 800# numbers 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, 02 Dec 2002 09:37:55 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I contacted SMS/800, the database manager for 800 numbers in the NANP. I received the following feedback: --- begin quote --- In SMS/800 you cannot assign one toll-free number to more than one Service Provider. One Service Provider for each toll-free. Thank you, Brooke SMS/800 Help Desk From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, December 02, 2002 8:27 AM To: Meyer, Brooke I'm asking about 800 number assignment rules. In particular, is it possible, that SMS/800 will assign a single 800 number, say, 800-555-1234, to two different RespOrgs by state or LATA. For example, RespOrg A would get this number for New York and RespOrg B would get the same number for use within New Jersey. --- end quote --- This does not quite settle the issue, since presumably each service provider (I gather they are called RespOrgs in 800 number lingo) could do a regional split ("weddings in PA, divorces in NV"). However, at this point, this seems highly unlikely since 800# are portable. The owner of the number (the divorce lawyer, say) could go national and switch service providers. Thus, I don't see how regional re-use of 800# is technically possible under the current regulatory regimen of 800# portability. Unless somebody can provide evidence to the contrary, maybe we should consider this issue settled and treat 800# as unique identifiers (that may not be resolvable everywhere). Henning _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 09:39:45 2002 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 JAA16961 for ; Mon, 2 Dec 2002 09:39:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2Eg7g02916 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 09:42:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Eg6v02913 for ; Mon, 2 Dec 2002 09:42:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16949 for ; Mon, 2 Dec 2002 09:39:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Eg1v02904; Mon, 2 Dec 2002 09:42:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Efgv02864 for ; Mon, 2 Dec 2002 09:41:42 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16913 for ; Mon, 2 Dec 2002 09:38:49 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB2EfriE004078; Mon, 2 Dec 2002 09:41:54 -0500 (EST) Received: from mhammer-w2k01.cisco.com (hrn2-dhcp-161-44-87-85.cisco.com [161.44.87.85]) by cia.cisco.com (Mirapoint) with ESMTP id ABJ66846; Mon, 2 Dec 2002 09:31:18 -0500 (EST) Message-Id: <4.3.2.7.2.20021202093627.00b11dd0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Henning Schulzrinne From: Michael Hammer Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion Cc: Scott Bradner , rohan@cisco.com, iptel@ietf.org In-Reply-To: <3DE91AF0.6050209@cs.columbia.edu> References: <200211301954.gAUJsNn6022405@newdev.harvard.edu> <200211301954.gAUJsNn6022405@newdev.harvard.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, 02 Dec 2002 09:41:24 -0500 All, I suspect that the routing of the call to multiple destinations, even though the same 1-800 number is used, has nothing to do with the 1-800 number and everything to do with other information contained in the signaling, and thus very much orthogonal. If sticking this other information into the tel: URL is the way independent information is bound to a phone number, so be it; but, then there are many pieces of information that could be bound in such fashion. Mike At 03:09 PM 11/30/2002 -0500, Henning Schulzrinne wrote: >Scott, > >trying to guess at the source of confusion here. I suspect that part of >the problem might be two meanings of the word 'context': > >- Context = 'resolve this identifier under this context' >(;context=+1-212-939-7000 = Pizza Hut as if dialed from 212-939-7000) > >- Context = 'this number is only valid if dialed from this context; it's >an error otherwise' (the number may still reach something or other, but >it's not the intended destination) > >I think most of us are thinking of the second use, not the first. Your >paragraph seems to hint at the first. Thus, for PizzaHut, there would be >no need for context (the number is valid, albeit routed differently >everywhere in the +1 context.) The problem I have with the first >interpretation is that the context is unknown, since the routing can >depend on any prefix and can never be known by the writer of a web page, say. > >I suspect that the PizzaHut routing problem is basically unsolvable as >soon as you have gateways; you'll always reach the PizzaHut closest to the >gateway, not the IP-based caller. The routing algorithm is presumably >based on more than just digits in the ANI phone number. The problem is >essentially the same as the 911 routing problem; maybe Intrado can start a >new line of business :-) > >However, I'm still not sure I understand your concern. > >Now, do I get a PizzaHut coupon? > >Scott Bradner wrote: > >> >I really do not want extra language in the spec to handle what I suspect >> >is a non-issue, because if folks don't know any better they will litter >> >all freephone numbers with context which in most cases is not only >> >extraneous, but also in some cases harmful to proper routing. >> >> >>I guess I must be confused about this issue - I would have thought that >>one needed locational context to resolve 1-800-hot-pizza (or >>whatever dominos country-wide number is) in order to direct a call >>to the right place (one on N-thousand local shops) >> >>it would seem to be a database loading issue if that number gets paid for >>by one or more organizations and not an issue of what information you >>need to get to the right place >> >>Scott > > >_______________________________________________ >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 mailnull@www1.ietf.org Mon Dec 2 10:13:55 2002 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 KAA18547 for ; Mon, 2 Dec 2002 10:13:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2FGFa05044 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 10:16:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FGFv05041 for ; Mon, 2 Dec 2002 10:16:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18511 for ; Mon, 2 Dec 2002 10:13:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FG4v05020; Mon, 2 Dec 2002 10:16:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FFlv05000 for ; Mon, 2 Dec 2002 10:15:47 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18490 for ; Mon, 2 Dec 2002 10:12:56 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB2FFwx5012110; Mon, 2 Dec 2002 10:15:59 -0500 (EST) Received: from mhammer-w2k01.cisco.com (hrn2-dhcp-161-44-87-85.cisco.com [161.44.87.85]) by cia.cisco.com (Mirapoint) with ESMTP id ABJ67246; Mon, 2 Dec 2002 10:05:23 -0500 (EST) Message-Id: <4.3.2.7.2.20021202101050.00b283e0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Michael Hammer Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers Cc: sob@harvard.edu, audet@nortelnetworks.com, hgs@cs.columbia.edu, iptel@ietf.org In-Reply-To: <12f.1c56204d.2b190703@aol.com> 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, 02 Dec 2002 10:15:29 -0500 Mike, I think it would be good to encourage the use of geo-location parameters if that is what is needed, rather than attempts to infer geo-location from telephone numbers. As for the 800 number, even if it is unique, that does not guarantee how it may be used within anyone's dialing plans. That is the monkey-wrench here. Non-owners of the number may not route it. Owners of the number may do unexpected things with it. Mike H. At 01:08 PM 11/29/2002 -0500, Mpierce1@aol.com wrote: >In a message dated 11/27/2002 4:23:11 PM Eastern Standard Time, >mhammer@cisco.com writes: > > >>By saying same number assigned in multiple areas, do you mean numbers >>without country code prefixes? > > >[MAP] I think there have been several different concepts mentioned related >to free-phone (e.g. 800) numbers: > >1. In the US (and Canada), 800 numbers have often been applicable for >calls originating only from certain areas, i.e., only US, a group of >states, a single state, etc. This (theoretically) allows the same number >to be assigned in different areas to completely different users with >completely separate routing. I suspect this is still allowed. > >2. An 800 number (in the US/Canada) can be assigned which uses >"Intelligent Network" capabilities with a data base lookup so that the >actual routing is a function of the originator's location (i.e., calling >party number). (Example: route to nearest Pizza Hut.) > >3. The same 800 number may be allocated to the same company for use in >multiple countries. I'm looking for examples. The use of the number >depends on the location of the calling party. It is normally called only >when in one of those countries (without dialing a Country Code). Dialing >from outside the country, using the Country Code, is theoretically >possible, if allowed by agreements between the countries. > >4. The "International Freephone Service" uses the "800" in place of the >Country Code followed by 8 digits, that is, the assigned "IFS" number is >truly "global", however there is certainly still no guarantee that it can >be called from everywhere in the globe. ITU-T only requires that it be >used "between two or more countries". Use of these numbers requires that >the user be located within the assigned countries. > >Of course, all of these uses are based on knowing the originator's >location (or more precisely, the location of the equipment handling the >call set-up). > >Mapping this to the Internet case where there is no knowledge of the >location of the caller is a real challenge. I think that one reason for >the "context" being applied with such "800" numbers in 2806bis was to get >around this problem - that is - for the originator to indicate more >information about their location or the desired destination. > >For example, a user who is in US (or who doesn't even care where they are) >wants to call an "800-234-567" number in Germany. They put in the "800" >number and separately code the "49" country code for Germany in "context". >They could just as well represent the desired number as >+49-800-234-567 (One could apply the same reasoning to a regular number >in the US and put in only the final 7 digits, and code +1 and area code in >"context", but I believe we agreed not to allow that.) > >Another example of the possible use of context: The user codes the >destination +49-800-234-567 (full number) and puts their own location >(e.g., +1-410) in "context, meaning where they are physically located >(independent from their "identity"). The destination could use this >"context" to decide whether or not it should handle the call. This is >similar to the use of "context" when dealing with "private" numbers in >which the originator codes their own, and the other end can use it as a check. > >Another example of the use of "context" which is implied in the draft is >the ability to codes multiple "context" values, for example, the >originator codes the number as +49-800-234-567 and codes the "context" >with both 49 for Germany and 44 for UK. While it is certainly possible for >the same number to be assigned to the same company in both countries, it >has never been clear to me what function (multiple contexts) this would >serve. Would an 800 number valid in the entire US then require the >"context" to include every possible area code? > > >Mike Pierce >Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 10:19:52 2002 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 KAA18856 for ; Mon, 2 Dec 2002 10:19:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2FMCF05469 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 10:22:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FMBv05466 for ; Mon, 2 Dec 2002 10:22:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18848 for ; Mon, 2 Dec 2002 10:19:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FM3v05439; Mon, 2 Dec 2002 10:22:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FLEv05386 for ; Mon, 2 Dec 2002 10:21:14 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18798 for ; Mon, 2 Dec 2002 10:18:23 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2FL6l8012243 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 2 Dec 2002 10:21:07 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2FL5dG029824 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Dec 2002 10:21:06 -0500 (EST) Message-ID: <3DEB7A4E.2040308@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: iptel@ietf.org Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers References: <4.3.2.7.2.20021202101050.00b283e0@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20021202101050.00b283e0@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Dec 2002 10:20:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I doubt you meant parameter as 'tel' parameter, but just in case: we already have the caller preferences mechanism, which allows the caller to provide this type of information that the callee can use to route the request. For example, rather than specifying your own current location (in either geo or number coordinates), you may actually want to say "route this request to whoever can provide good service in X", where X is the location where I actually want the pizza, rather than my current en-route location. Michael Hammer wrote: > Mike, > > I think it would be good to encourage the use of geo-location parameters > if that is what is needed, rather than attempts to infer geo-location > from telephone numbers. > > As for the 800 number, even if it is unique, that does not guarantee how > it may be used within anyone's dialing plans. That is the monkey-wrench > here. Non-owners of the number may not route it. Owners of the number > may do unexpected things with it. > > Mike H. > > > At 01:08 PM 11/29/2002 -0500, Mpierce1@aol.com wrote: > > > In a message dated 11/27/2002 4:23:11 PM Eastern Standard Time, > > mhammer@cisco.com writes: > > > > > >> By saying same number assigned in multiple areas, do you mean numbers > >> without country code prefixes? > > > > > > > > [MAP] I think there have been several different concepts mentioned > > related to free-phone (e.g. 800) numbers: > > > > 1. In the US (and Canada), 800 numbers have often been applicable for > > calls originating only from certain areas, i.e., only US, a group of > > states, a single state, etc. This (theoretically) allows the same > > number to be assigned in different areas to completely different users > > with completely separate routing. I suspect this is still allowed. > > > > 2. An 800 number (in the US/Canada) can be assigned which uses > > "Intelligent Network" capabilities with a data base lookup so that the > > actual routing is a function of the originator's location (i.e., > > calling party number). (Example: route to nearest Pizza Hut.) > > > > 3. The same 800 number may be allocated to the same company for use in > > multiple countries. I'm looking for examples. The use of the number > > depends on the location of the calling party. It is normally called > > only when in one of those countries (without dialing a Country Code). > > Dialing from outside the country, using the Country Code, is > > theoretically possible, if allowed by agreements between the countries. > > > > 4. The "International Freephone Service" uses the "800" in place of > > the Country Code followed by 8 digits, that is, the assigned "IFS" > > number is truly "global", however there is certainly still no > > guarantee that it can be called from everywhere in the globe. ITU-T > > only requires that it be used "between two or more countries". Use of > > these numbers requires that the user be located within the assigned > > countries. > > > > Of course, all of these uses are based on knowing the originator's > > location (or more precisely, the location of the equipment handling > > the call set-up). > > > > Mapping this to the Internet case where there is no knowledge of the > > location of the caller is a real challenge. I think that one reason > > for the "context" being applied with such "800" numbers in 2806bis was > > to get around this problem - that is - for the originator to indicate > > more information about their location or the desired destination. > > > > For example, a user who is in US (or who doesn't even care where they > > are) wants to call an "800-234-567" number in Germany. They put in the > > "800" number and separately code the "49" country code for Germany in > > "context". They could just as well represent the desired number as > > +49-800-234-567 (One could apply the same reasoning to a regular > > number in the US and put in only the final 7 digits, and code +1 and > > area code in "context", but I believe we agreed not to allow that.) > > > > Another example of the possible use of context: The user codes the > > destination +49-800-234-567 (full number) and puts their own location > > (e.g., +1-410) in "context, meaning where they are physically located > > (independent from their "identity"). The destination could use this > > "context" to decide whether or not it should handle the call. This is > > similar to the use of "context" when dealing with "private" numbers in > > which the originator codes their own, and the other end can use it as > > a check. > > > > Another example of the use of "context" which is implied in the draft > > is the ability to codes multiple "context" values, for example, the > > originator codes the number as +49-800-234-567 and codes the "context" > > with both 49 for Germany and 44 for UK. While it is certainly possible > > for the same number to be assigned to the same company in both > > countries, it has never been clear to me what function (multiple > > contexts) this would serve. Would an 800 number valid in the entire US > > then require the "context" to include every possible area code? > > > > > > Mike Pierce > > Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 10:26:01 2002 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 KAA19184 for ; Mon, 2 Dec 2002 10:26:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2FSLP05842 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 10:28:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FSLv05837 for ; Mon, 2 Dec 2002 10:28:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19162 for ; Mon, 2 Dec 2002 10:25:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FSBv05824; Mon, 2 Dec 2002 10:28:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FRpv05762 for ; Mon, 2 Dec 2002 10:27:51 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19129 for ; Mon, 2 Dec 2002 10:24:59 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB2FS8Zs014618; Mon, 2 Dec 2002 10:28:08 -0500 (EST) Received: from mhammer-w2k01.cisco.com (hrn2-dhcp-161-44-87-85.cisco.com [161.44.87.85]) by cia.cisco.com (Mirapoint) with ESMTP id ABJ67401; Mon, 2 Dec 2002 10:17:32 -0500 (EST) Message-Id: <4.3.2.7.2.20021202102649.03a2af08@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Henning Schulzrinne From: Michael Hammer Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers Cc: iptel@ietf.org In-Reply-To: <3DEB7A4E.2040308@cs.columbia.edu> References: <4.3.2.7.2.20021202101050.00b283e0@cia.cisco.com> <4.3.2.7.2.20021202101050.00b283e0@cia.cisco.com> 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, 02 Dec 2002 10:27:38 -0500 Correct. Whatever parameter explicitly describes location. Mike H. At 10:20 AM 12/2/2002 -0500, Henning Schulzrinne wrote: >I doubt you meant parameter as 'tel' parameter, but just in case: we >already have the caller preferences mechanism, which allows the caller to >provide this type of information that the callee can use to route the >request. For example, rather than specifying your own current location (in >either geo or number coordinates), you may actually want to say "route >this request to whoever can provide good service in X", where X is the >location where I actually want the pizza, rather than my current en-route >location. > >Michael Hammer wrote: > >>Mike, >> >>I think it would be good to encourage the use of geo-location parameters >>if that is what is needed, rather than attempts to infer geo-location >>from telephone numbers. >> >>As for the 800 number, even if it is unique, that does not guarantee how >>it may be used within anyone's dialing plans. That is the monkey-wrench >>here. Non-owners of the number may not route it. Owners of the number >>may do unexpected things with it. >> >>Mike H. >> >> >>At 01:08 PM 11/29/2002 -0500, Mpierce1@aol.com wrote: >> >> > In a message dated 11/27/2002 4:23:11 PM Eastern Standard Time, >> > mhammer@cisco.com writes: >> > >> > >> >> By saying same number assigned in multiple areas, do you mean numbers >> >> without country code prefixes? >> > >> > >> > >> > [MAP] I think there have been several different concepts mentioned >> > related to free-phone (e.g. 800) numbers: >> > >> > 1. In the US (and Canada), 800 numbers have often been applicable for >> > calls originating only from certain areas, i.e., only US, a group of >> > states, a single state, etc. This (theoretically) allows the same >> > number to be assigned in different areas to completely different users >> > with completely separate routing. I suspect this is still allowed. >> > >> > 2. An 800 number (in the US/Canada) can be assigned which uses >> > "Intelligent Network" capabilities with a data base lookup so that the >> > actual routing is a function of the originator's location (i.e., >> > calling party number). (Example: route to nearest Pizza Hut.) >> > >> > 3. The same 800 number may be allocated to the same company for use in >> > multiple countries. I'm looking for examples. The use of the number >> > depends on the location of the calling party. It is normally called >> > only when in one of those countries (without dialing a Country Code). >> > Dialing from outside the country, using the Country Code, is >> > theoretically possible, if allowed by agreements between the countries. >> > >> > 4. The "International Freephone Service" uses the "800" in place of >> > the Country Code followed by 8 digits, that is, the assigned "IFS" >> > number is truly "global", however there is certainly still no >> > guarantee that it can be called from everywhere in the globe. ITU-T >> > only requires that it be used "between two or more countries". Use of >> > these numbers requires that the user be located within the assigned >> > countries. >> > >> > Of course, all of these uses are based on knowing the originator's >> > location (or more precisely, the location of the equipment handling >> > the call set-up). >> > >> > Mapping this to the Internet case where there is no knowledge of the >> > location of the caller is a real challenge. I think that one reason >> > for the "context" being applied with such "800" numbers in 2806bis was >> > to get around this problem - that is - for the originator to indicate >> > more information about their location or the desired destination. >> > >> > For example, a user who is in US (or who doesn't even care where they >> > are) wants to call an "800-234-567" number in Germany. They put in the >> > "800" number and separately code the "49" country code for Germany in >> > "context". They could just as well represent the desired number as >> > +49-800-234-567 (One could apply the same reasoning to a regular >> > number in the US and put in only the final 7 digits, and code +1 and >> > area code in "context", but I believe we agreed not to allow that.) >> > >> > Another example of the possible use of context: The user codes the >> > destination +49-800-234-567 (full number) and puts their own location >> > (e.g., +1-410) in "context, meaning where they are physically located >> > (independent from their "identity"). The destination could use this >> > "context" to decide whether or not it should handle the call. This is >> > similar to the use of "context" when dealing with "private" numbers in >> > which the originator codes their own, and the other end can use it as >> > a check. >> > >> > Another example of the use of "context" which is implied in the draft >> > is the ability to codes multiple "context" values, for example, the >> > originator codes the number as +49-800-234-567 and codes the "context" >> > with both 49 for Germany and 44 for UK. While it is certainly possible >> > for the same number to be assigned to the same company in both >> > countries, it has never been clear to me what function (multiple >> > contexts) this would serve. Would an 800 number valid in the entire US >> > then require the "context" to include every possible area code? >> > >> > >> > Mike Pierce >> > Artel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 10:26:46 2002 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 KAA19295 for ; Mon, 2 Dec 2002 10:26:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2FT6n05954 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 10:29:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FT6v05951 for ; Mon, 2 Dec 2002 10:29:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19246 for ; Mon, 2 Dec 2002 10:26:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FT0v05925; Mon, 2 Dec 2002 10:29:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FSLv05839 for ; Mon, 2 Dec 2002 10:28:21 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19159 for ; Mon, 2 Dec 2002 10:25:28 -0500 (EST) content-class: urn:content-classes:message Subject: AW: [Iptel] Summary of +1-800 for tel URI discussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-ID: <06CF906FE3998C4E944213062009F1620DEE1C@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Iptel] Summary of +1-800 for tel URI discussion Thread-Index: AcKaEY7C/G7BXXofR4uTlJA16Ls4YgAAT03R From: "Stastny Richard" To: "Michael Hammer" , "Henning Schulzrinne" Cc: "Scott Bradner" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gB2FSLv05844 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, 2 Dec 2002 16:31:21 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit All, I have problems to follow this discussion: An 800 number is a service number and the routing is done within IN. So in the PSTN the 800 number is routed first to the service provider hosting the IN service (with a cic derived from NP translation - see yu drafts on np) and the service provider is then finding out the PSTN number where the call should terminate. Since this is an IN-service, it could be intelligent, so the PSTN number could be a bunch of numbers really, one for each hour of the day or one for each area or office code, and exactly this is the point where the context is coming into play. I need the originating context, e.g transmitted in the SIP message with the 800 number and match it with the context of the terminating number. Be aware, that the terminating number itself gives you NOT the context, because the call center may sit in Ireland or move around the globe with the sun ;-). So a PSTN number in Ireland may have the context +49 (germany) and a number in scotland the context +43 (Austria). And this example is not a joke, it is real, if you dial e.g an +43800 or +800 Number in Vienna, I sometimes end up in Holland, Ireland or Scotland (just chat a bit with the ladies). So what we need, is a clear definition what context means, and since there may be ambiguities, I strobly recommend to define at least e.g. orig-context and term-context. regards Richard -----Urspr체ngliche Nachricht----- Von: Michael Hammer [mailto:mhammer@cisco.com] Gesendet: Mo 02.12.2002 15:41 An: Henning Schulzrinne Cc: Scott Bradner; rohan@cisco.com; iptel@ietf.org Betreff: Re: [Iptel] Summary of +1-800 for tel URI discussion All, I suspect that the routing of the call to multiple destinations, even though the same 1-800 number is used, has nothing to do with the 1-800 number and everything to do with other information contained in the signaling, and thus very much orthogonal. If sticking this other information into the tel: URL is the way independent information is bound to a phone number, so be it; but, then there are many pieces of information that could be bound in such fashion. Mike At 03:09 PM 11/30/2002 -0500, Henning Schulzrinne wrote: >Scott, > >trying to guess at the source of confusion here. I suspect that part of >the problem might be two meanings of the word 'context': > >- Context = 'resolve this identifier under this context' >(;context=+1-212-939-7000 = Pizza Hut as if dialed from 212-939-7000) > >- Context = 'this number is only valid if dialed from this context; it's >an error otherwise' (the number may still reach something or other, but >it's not the intended destination) > >I think most of us are thinking of the second use, not the first. Your >paragraph seems to hint at the first. Thus, for PizzaHut, there would be >no need for context (the number is valid, albeit routed differently >everywhere in the +1 context.) The problem I have with the first >interpretation is that the context is unknown, since the routing can >depend on any prefix and can never be known by the writer of a web page, say. > >I suspect that the PizzaHut routing problem is basically unsolvable as >soon as you have gateways; you'll always reach the PizzaHut closest to the >gateway, not the IP-based caller. The routing algorithm is presumably >based on more than just digits in the ANI phone number. The problem is >essentially the same as the 911 routing problem; maybe Intrado can start a >new line of business :-) > >However, I'm still not sure I understand your concern. > >Now, do I get a PizzaHut coupon? > >Scott Bradner wrote: > >> >I really do not want extra language in the spec to handle what I suspect >> >is a non-issue, because if folks don't know any better they will litter >> >all freephone numbers with context which in most cases is not only >> >extraneous, but also in some cases harmful to proper routing. >> >> >>I guess I must be confused about this issue - I would have thought that >>one needed locational context to resolve 1-800-hot-pizza (or >>whatever dominos country-wide number is) in order to direct a call >>to the right place (one on N-thousand local shops) >> >>it would seem to be a database loading issue if that number gets paid for >>by one or more organizations and not an issue of what information you >>need to get to the right place >> >>Scott > > >_______________________________________________ >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 mailnull@www1.ietf.org Mon Dec 2 10:38:53 2002 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 KAA20188 for ; Mon, 2 Dec 2002 10:38:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2FfDK07576 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 10:41:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FfDv07573 for ; Mon, 2 Dec 2002 10:41:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20148 for ; Mon, 2 Dec 2002 10:38:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Ff6v07554; Mon, 2 Dec 2002 10:41:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FeTv07515 for ; Mon, 2 Dec 2002 10:40:29 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20106 for ; Mon, 2 Dec 2002 10:37:37 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2FeOl8014729 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 2 Dec 2002 10:40:25 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2FeNdG001206 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Dec 2002 10:40:24 -0500 (EST) Message-ID: <3DEB7ED0.6060504@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard CC: iptel@ietf.org Subject: Re: AW: [Iptel] Summary of +1-800 for tel URI discussion References: <06CF906FE3998C4E944213062009F1620DEE1C@oefeg-s02.oefeg.loc> In-Reply-To: <06CF906FE3998C4E944213062009F1620DEE1C@oefeg-s02.oefeg.loc> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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, 02 Dec 2002 10:40:00 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit The conclusion I reached from this whole discussion is a bit different. To summarize: - context is no more necessary for +1-800 than for "regular" E.164 numbers (after all, nothing keeps somebody from forwarding 900 or other regular numbers to different parts of the world) - context is to ensure semantic uniqueness, not to select among semantically equivalent locations operated by the owner of that identifier (after all, we don't add context to http URIs, even though they often end up in different locations; just try Google while you're visiting another country - you'll end up seeing a local-language version of their home page). - any routing preferences or indications should be provided in, say, caller preferences, not as part of the tel (or sip) URI. Thus, I don't intend to add additional context parameters to 2806bis. Henning Stastny Richard wrote: > All, > I have problems to follow this discussion: > An 800 number is a service number and the routing is done within IN. > > So in the PSTN the 800 number is routed first to the service provider > hosting > the IN service (with a cic derived from NP translation - see yu drafts > on np) and > the service provider is then finding out the PSTN number where the > call should terminate. > > Since this is an IN-service, it could be intelligent, so the PSTN > number could be a bunch > of numbers really, one for each hour of the day or one for each area > or office code, and > exactly this is the point where the context is coming into play. > > I need the originating context, e.g transmitted in the SIP message > with the 800 number > and match it with the context of the terminating number. > > Be aware, that the terminating number itself gives you NOT the > context, because the > call center may sit in Ireland or move around the globe with the sun > ;-). So a PSTN > number in Ireland may have the context +49 (germany) and a number in > scotland the > context +43 (Austria). And this example is not a joke, it is real, if > you dial e.g an > +43800 or +800 Number in Vienna, I sometimes end up in Holland, > Ireland or Scotland (just > chat a bit with the ladies). > > So what we need, is a clear definition what context means, and since > there may be ambiguities, > I strobly recommend to define at least e.g. orig-context and term-context. > > regards > Richard > > -----Urspr체ngliche Nachricht----- > Von: Michael Hammer [mailto:mhammer@cisco.com] > Gesendet: Mo 02.12.2002 15:41 > An: Henning Schulzrinne > Cc: Scott Bradner; rohan@cisco.com; iptel@ietf.org > Betreff: Re: [Iptel] Summary of +1-800 for tel URI discussion > > > > All, > > I suspect that the routing of the call to multiple destinations, even > though the same 1-800 number is used, has nothing to do with the 1-800 > number and everything to do with other information contained in the > signaling, and thus very much orthogonal. If sticking this other > information into the tel: URL is the way independent information is bound > to a phone number, so be it; but, then there are many pieces of > information > that could be bound in such fashion. > > Mike > > > At 03:09 PM 11/30/2002 -0500, Henning Schulzrinne wrote: > >Scott, > > > >trying to guess at the source of confusion here. I suspect that part of > >the problem might be two meanings of the word 'context': > > > >- Context = 'resolve this identifier under this context' > >(;context=+1-212-939-7000 = Pizza Hut as if dialed from 212-939-7000) > > > >- Context = 'this number is only valid if dialed from this context; it's > >an error otherwise' (the number may still reach something or other, but > >it's not the intended destination) > > > >I think most of us are thinking of the second use, not the first. Your > >paragraph seems to hint at the first. Thus, for PizzaHut, there would be > >no need for context (the number is valid, albeit routed differently > >everywhere in the +1 context.) The problem I have with the first > >interpretation is that the context is unknown, since the routing can > >depend on any prefix and can never be known by the writer of a web > page, say. > > > >I suspect that the PizzaHut routing problem is basically unsolvable as > >soon as you have gateways; you'll always reach the PizzaHut closest > to the > >gateway, not the IP-based caller. The routing algorithm is presumably > >based on more than just digits in the ANI phone number. The problem is > >essentially the same as the 911 routing problem; maybe Intrado can > start a > >new line of business :-) > > > >However, I'm still not sure I understand your concern. > > > >Now, do I get a PizzaHut coupon? > > > >Scott Bradner wrote: > > > >> >I really do not want extra language in the spec to handle what I > suspect > >> >is a non-issue, because if folks don't know any better they will > litter > >> >all freephone numbers with context which in most cases is not only > >> >extraneous, but also in some cases harmful to proper routing. > >> > >> > >>I guess I must be confused about this issue - I would have thought that > >>one needed locational context to resolve 1-800-hot-pizza (or > >>whatever dominos country-wide number is) in order to direct a call > >>to the right place (one on N-thousand local shops) > >> > >>it would seem to be a database loading issue if that number gets > paid for > >>by one or more organizations and not an issue of what information you > >>need to get to the right place > >> > >>Scott > > > > > >_______________________________________________ > >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 mailnull@www1.ietf.org Mon Dec 2 12:50:49 2002 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 MAA28743 for ; Mon, 2 Dec 2002 12:50:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2HrBf17793 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 12:53:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2HrAv17790 for ; Mon, 2 Dec 2002 12:53:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28686 for ; Mon, 2 Dec 2002 12:50:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Hr2v17729; Mon, 2 Dec 2002 12:53:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Hq1v17672 for ; Mon, 2 Dec 2002 12:52:01 -0500 Received: from imo-r03.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28626 for ; Mon, 2 Dec 2002 12:49:08 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r03.mx.aol.com (mail_out_v34.13.) id 7.11c.1b339d92 (25508); Mon, 2 Dec 2002 12:51:18 -0500 (EST) Message-ID: <11c.1b339d92.2b1cf796@aol.com> Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion To: hgs@cs.columbia.edu, iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_11c.1b339d92.2b1cf796_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 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, 2 Dec 2002 12:51:18 EST --part1_11c.1b339d92.2b1cf796_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/30/2002 6:09:43 AM Eastern Standard Time, hgs@cs.columbia.edu writes: > Thus, I will amend the 2806bis draft to say that freephone numbers in > countries that allow re-use by different organizations MUST use a > context indication unless it is known that the number is unique within > the whole country code. (It does not have to be valid in the whole > country code.) > [MAP] I do not agree with the above. I still believe that a freephone number we are talking about (e.g., 800 in the US) should always be represented in E.164 format without a context. If a country allows "re-use", that simply means that the interpretation and routing of that number depends on where the originator is located when they dial it. Besides, your above statement seems to tie the requirements for including a "context" with a 800 to something that the source would not know. A device on the other side of the world would need to know that a "context" was required to go with an 800 number in the US which is used for different destinations in different states, although it should be absolutely impossible to call any of these 800 numbers from that place on the other side of the world. This would make "context" required, and the destination could choose to ignore it. If there is any mention of "context", it needs to be explicitly defined. Note your reponse to Scott that there "might be two meanings of the word context". (I think there are more). Depending on which meaning is used, then: 1. If it is defined as being another way to identify the originator of the call, then we already have too many of those (and this would raise all the usual privacy and authentication issues again and we would probably end up with "context=anonymous"). 2. If it is defined as being a way to identify the location of the originator, that is a function of GEOPRIV and should not be in the tel:uri. 3. If it is defined as being the intended destination, that I can not imagine how that could be done to indicate an 800 number that is unique say, in New York with 14 area codes today (and growing). What would the context be? MIke Pierce Artel --part1_11c.1b339d92.2b1cf796_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/30/2002 6:09:43 AM Eastern Standard Time, hgs@cs.columbia.edu writes:


Thus, I will amend the 2806bis draft to say that freephone numbers in
countries that allow re-use by different organizations MUST use a
context indication unless it is known that the number is unique within
the whole country code. (It does not have to be valid in the whole
country code.)


[MAP] I do not agree with the above. I still believe that a freephone number we are talking about (e.g., 800 in the US) should always be represented in E.164 format without a context. If a country allows "re-use", that simply means that the interpretation and routing of that number depends on where the originator is located when they dial it.

Besides, your above statement seems to tie the requirements for including a "context" with a 800 to something that the source would not know. A device on the other side of the world would need to know that a "context" was required to go with an 800 number in the US which is used for different destinations in different states, although it should be absolutely impossible to call any of these 800 numbers from that place on the other side of the world. This would make "context" required, and the destination could choose to ignore it.

If there is any mention of "context", it needs to be explicitly defined. Note your reponse to Scott that there "might be two meanings of the word context". (I think there are more). Depending on which meaning is used, then:

1. If it is defined as being another way to identify the originator of the call, then we already have too many of those (and this would raise all the usual privacy and authentication issues again and we would probably end up with "context=anonymous").

2. If it is defined as being a way to identify the location of the originator, that is a function of GEOPRIV and should not be in the tel:uri.

3. If it is defined as being the intended destination, that I can not imagine how that could be done to indicate an 800 number that is unique say, in New York with 14 area codes today (and growing). What would the context be?

MIke Pierce
Artel
--part1_11c.1b339d92.2b1cf796_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 14:04:50 2002 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 OAA04043 for ; Mon, 2 Dec 2002 14:04:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2J7D823942 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 14:07:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2J7Dv23931 for ; Mon, 2 Dec 2002 14:07:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04005 for ; Mon, 2 Dec 2002 14:04:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2J75v23716; Mon, 2 Dec 2002 14:07:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2J6Sv23498 for ; Mon, 2 Dec 2002 14:06:28 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03933 for ; Mon, 2 Dec 2002 14:03:34 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2J6Kl8012655 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 2 Dec 2002 14:06:21 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2J6JdG019669 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Dec 2002 14:06:20 -0500 (EST) Message-ID: <3DEBAEF5.5080305@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: iptel@ietf.org Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion References: <11c.1b339d92.2b1cf796@aol.com> In-Reply-To: <11c.1b339d92.2b1cf796@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Dec 2002 14:05:25 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Best to read iptel messages most-recent-first :-) Given that there are no indications that 800# are re-used across distinct organizations, there is no need for a context. Mpierce1@aol.com wrote: > In a message dated 11/30/2002 6:09:43 AM Eastern Standard Time, > hgs@cs.columbia.edu writes: > > > > Thus, I will amend the 2806bis draft to say that freephone numbers in > > countries that allow re-use by different organizations MUST use a > > context indication unless it is known that the number is unique within > > the whole country code. (It does not have to be valid in the whole > > country code.) > > > > [MAP] I do not agree with the above. I still believe that a freephone > number we are talking about (e.g., 800 in the US) should always be > represented in E.164 format without a context. If a country allows > "re-use", that simply means that the interpretation and routing of that > number depends on where the originator is located when they dial it. > > Besides, your above statement seems to tie the requirements for > including a "context" with a 800 to something that the source would not > know. A device on the other side of the world would need to know that a > "context" was required to go with an 800 number in the US which is used > for different destinations in different states, although it should be > absolutely impossible to call any of these 800 numbers from that place > on the other side of the world. This would make "context" required, and > the destination could choose to ignore it. > > If there is any mention of "context", it needs to be explicitly defined. > Note your reponse to Scott that there "might be two meanings of the word > context". (I think there are more). Depending on which meaning is used, > then: > > 1. If it is defined as being another way to identify the originator of > the call, then we already have too many of those (and this would raise > all the usual privacy and authentication issues again and we would > probably end up with "context=anonymous"). > > 2. If it is defined as being a way to identify the location of the > originator, that is a function of GEOPRIV and should not be in the > tel:uri. > > 3. If it is defined as being the intended destination, that I can not > imagine how that could be done to indicate an 800 number that is unique > say, in New York with 14 area codes today (and growing). What would the > context be? > > MIke Pierce > Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 15:08:54 2002 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 PAA07585 for ; Mon, 2 Dec 2002 15:08:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2KBIO28884 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 15:11:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2KBIv28881 for ; Mon, 2 Dec 2002 15:11:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07572 for ; Mon, 2 Dec 2002 15:08:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2KB7v28856; Mon, 2 Dec 2002 15:11:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2KAMv28824 for ; Mon, 2 Dec 2002 15:10:22 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07553 for ; Mon, 2 Dec 2002 15:07:27 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2KA9l8019376 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 2 Dec 2002 15:10:10 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2KA6dG025045 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Dec 2002 15:10:08 -0500 (EST) Message-ID: <3DEBBDDF.50506@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: jdrosen@dynamicsoft.com, iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis References: <17c.1226d838.2b0c006d@aol.com> In-Reply-To: <17c.1226d838.2b0c006d@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Dec 2002 15:09:03 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > this syntax seemed a bit odd to me. I may have missed the discussion on > > why it was done. Why is global-par repeated twice? Perhaps the idea is > > to say that ordering is irrelevant, but you can have only one context > > parameter? No. The problem was that local phone numbers must have exactly one context parameter, which can be either preceded or be followed by zero or more global-par's. There might well be a better way to express this. Thus, tel:1234;globalA;context=x;globalB is allowed, as is tel:1234;context=x;globalA etc. > > > > > I'm not sure what the problem is here, but I agree that this seems a bit > odd. There was discussion before about have a single tel:uri contain > multiple numbers or multiple contexts, but I don't know if this is > related. In the above, "global-par" is defined in the ABNF to be made up > of "parameter" which is not defined. I thought the only thing needed > with "local-number" was the "context" (once) as in -05. Should be 'parameter', not 'param'. Fixed. > > > Mike Pierce > Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 15:18:46 2002 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 PAA07891 for ; Mon, 2 Dec 2002 15:18:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2KLAn29330 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 15:21:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2KL9v29327 for ; Mon, 2 Dec 2002 15:21:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07880 for ; Mon, 2 Dec 2002 15:18:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2KL4v29314; Mon, 2 Dec 2002 15:21:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2KKtv29283 for ; Mon, 2 Dec 2002 15:20:55 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07862 for ; Mon, 2 Dec 2002 15:17:55 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2KKil8020486 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 2 Dec 2002 15:20:45 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2KKedG025936 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 2 Dec 2002 15:20:43 -0500 (EST) Message-ID: <3DEBC056.1090107@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Iptel] Hex digits 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, 02 Dec 2002 15:19:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit E.164 doesn't mention hexadecimal digits (A-F), just "decimal digits". They currently appear in the BNF. Is there are a reason to keep A-F, then? _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 15:48:55 2002 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 PAA09470 for ; Mon, 2 Dec 2002 15:48:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2KpJ731418 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 15:51:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2KpJv31415 for ; Mon, 2 Dec 2002 15:51:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09447 for ; Mon, 2 Dec 2002 15:48:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2KpAv31404; Mon, 2 Dec 2002 15:51:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Konv31378 for ; Mon, 2 Dec 2002 15:50:49 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09399 for ; Mon, 2 Dec 2002 15:47:53 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB2KoI0J003881; Mon, 2 Dec 2002 12:50:18 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ07326; Mon, 2 Dec 2002 12:48:09 -0800 (PST) Subject: Re: [Iptel] Hex digits Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: iptel@ietf.org To: Henning Schulzrinne From: Rohan Mahy In-Reply-To: <3DEBC056.1090107@cs.columbia.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) 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, 2 Dec 2002 12:50:43 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning, "nondedactic" digits are in current use. they need to stay. for example many telephone company internal numbers in belgium begin with the "number" E. thanks, -rohan On Monday, December 2, 2002, at 12:19 PM, Henning Schulzrinne wrote: > E.164 doesn't mention hexadecimal digits (A-F), just "decimal digits". > They currently appear in the BNF. Is there are a reason to keep A-F, > then? > > _______________________________________________ > 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 mailnull@www1.ietf.org Mon Dec 2 15:58:46 2002 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 PAA09940 for ; Mon, 2 Dec 2002 15:58:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2L1Bw31878 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 16:01:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2L1Bv31874 for ; Mon, 2 Dec 2002 16:01:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09933 for ; Mon, 2 Dec 2002 15:58:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2L14v31863; Mon, 2 Dec 2002 16:01:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2L0Ov31821 for ; Mon, 2 Dec 2002 16:00:24 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09885 for ; Mon, 2 Dec 2002 15:57:28 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2L08l8025820 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 2 Dec 2002 16:00:08 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2KxxdG029468 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Dec 2002 16:00:05 -0500 (EST) Message-ID: <3DEBC987.6010109@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis - semantics References: <3DD9D7A5.5040503@dynamicsoft.com> In-Reply-To: <3DD9D7A5.5040503@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Dec 2002 15:58:47 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for the extensive comments. Comments on non-editorial items in-line. Split to simplify follow-up. Jonathan Rosenberg wrote: > My big comment is that the draft doesnt actually define any semantics > associated with the tel URI. There is nothing which says that I should > make a call, or that I should do an enum query, or that I should make a > sip call, etc. Even if there are multiple possibilities, we need a > section that describes the options, and what it basically means when you > encounter a tel URI in various contexts. I've tried to emphasize up front "URI scheme ``tel'' that describes resources identified by telephone numbers." Thus, I tend to think of it much more like a URN - it does not specify a protocol to get the resource ("dialing"), but rather there are several ways to resolve it to something real (a phone call, say). Thus, the semantics are similar to, say, an ISBN - identifies a book (or any object with such a number), but doesn't say anything more than that. Is this precise enough? The current text reads: This document defines the URI scheme ``tel'' that describes resources identified by telephone numbers. The telephone number can refer to terminals in the telephone network or the Internet, mobile and landline devices, voice, data and fax devices. The URI can refer to originators \begin{changebar} or targets of a telephone call. The ``tel'' URI is an identifier only; it does not describe the steps necessary to reach a particular number and does not imply dialing semantics. \end{changebar} _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 16:20:24 2002 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 QAA11023 for ; Mon, 2 Dec 2002 16:20:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2LMng01125 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 16:22:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2LMnv01121 for ; Mon, 2 Dec 2002 16:22:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10985 for ; Mon, 2 Dec 2002 16:19:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2LMRv01045; Mon, 2 Dec 2002 16:22:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2LKTv00822 for ; Mon, 2 Dec 2002 16:20:29 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10786 for ; Mon, 2 Dec 2002 16:17:32 -0500 (EST) Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0H6I00FKUGLLF4@firewall.wcom.com> for iptel@ietf.org; Mon, 02 Dec 2002 21:20:09 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H6I00G01GLKCC@pmismtp06.wcomnet.com>; Mon, 02 Dec 2002 21:20:08 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H6I00F36GLKZS@pmismtp06.wcomnet.com>; Mon, 02 Dec 2002 21:20:08 +0000 (GMT) From: Henry Sinnreich Subject: RE: [Iptel] Summary of +1-800 for tel URI discussion In-reply-to: <3DEBAEF5.5080305@cs.columbia.edu> To: "'Henning Schulzrinne'" , Mpierce1@aol.com Cc: iptel@ietf.org Message-id: <000e01c29a48$97398fd0$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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, 02 Dec 2002 15:20:08 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have tried to follow this important thread and believe now we need a new summary, or even a new I-D. Thanks, Henry > -----Original Message----- > From: iptel-admin@ietf.org [mailto:iptel-admin@ietf.org] On > Behalf Of Henning Schulzrinne > Sent: Monday, December 02, 2002 1:05 PM > To: Mpierce1@aol.com > Cc: iptel@ietf.org > Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion > > > Best to read iptel messages most-recent-first :-) Given that > there are > no indications that 800# are re-used across distinct organizations, > there is no need for a context. > > Mpierce1@aol.com wrote: > > > In a message dated 11/30/2002 6:09:43 AM Eastern Standard Time, > > hgs@cs.columbia.edu writes: > > > > > > > Thus, I will amend the 2806bis draft to say that > freephone numbers > > > in countries that allow re-use by different organizations > MUST use a > > > context indication unless it is known that the number is unique > > > within the whole country code. (It does not have to be > valid in the > > > whole country code.) > > > > > > > > [MAP] I do not agree with the above. I still believe that a > freephone > > number we are talking about (e.g., 800 in the US) should always be > > represented in E.164 format without a context. If a country allows > > "re-use", that simply means that the interpretation and routing of > > that number depends on where the originator is located when > they dial > > it. > > > > Besides, your above statement seems to tie the requirements for > > including a "context" with a 800 to something that the source would > > not know. A device on the other side of the world would > need to know > > that a "context" was required to go with an 800 number in > the US which > > is used for different destinations in different states, although it > > should be absolutely impossible to call any of these 800 > numbers from > > that place on the other side of the world. This would make > "context" > > required, and the destination could choose to ignore it. > > > > If there is any mention of "context", it needs to be explicitly > > defined. Note your reponse to Scott that there "might be > two meanings > > of the word context". (I think there are more). Depending on which > > meaning is used, > > then: > > > > 1. If it is defined as being another way to identify the > originator of > > the call, then we already have too many of those (and this > would raise > > all the usual privacy and authentication issues again and we would > > probably end up with "context=anonymous"). > > > > 2. If it is defined as being a way to identify the location of the > > originator, that is a function of GEOPRIV and should not be in the > > tel:uri. > > > > 3. If it is defined as being the intended destination, that > I can not > > imagine how that could be done to indicate an 800 number that is > > unique say, in New York with 14 area codes today (and > growing). What > > would the context be? > > > > MIke Pierce > > Artel > > > _______________________________________________ > 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 mailnull@www1.ietf.org Mon Dec 2 17:05:46 2002 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 RAA14098 for ; Mon, 2 Dec 2002 17:05:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2M8AF05042 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 17:08:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2M8Av05039 for ; Mon, 2 Dec 2002 17:08:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14066 for ; Mon, 2 Dec 2002 17:05:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2M84v05028; Mon, 2 Dec 2002 17:08:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2M7qv05010 for ; Mon, 2 Dec 2002 17:07:52 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14056 for ; Mon, 2 Dec 2002 17:04:58 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2M7cl8003067 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 2 Dec 2002 17:07:38 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2M7CdG005758 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Dec 2002 17:07:37 -0500 (EST) Message-ID: <3DEBD93E.5080301@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Sinnreich CC: Mpierce1@aol.com, iptel@ietf.org Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion References: <000e01c29a48$97398fd0$248823a6@hsinnreich2> In-Reply-To: <000e01c29a48$97398fd0$248823a6@hsinnreich2> 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, 02 Dec 2002 17:05:50 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As you can tell by my flurry of 2806bis messages, I'm in the midst of rev'ing the document. That might give us a new starting point for discussions. Henry Sinnreich wrote: > I have tried to follow this important thread and believe now we need a > new summary, or even a new I-D. > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 17:07:43 2002 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 RAA14207 for ; Mon, 2 Dec 2002 17:07:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2MA7x05212 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 17:10:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2MA7v05207 for ; Mon, 2 Dec 2002 17:10:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14189 for ; Mon, 2 Dec 2002 17:07:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2MA1v05181; Mon, 2 Dec 2002 17:10:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2M9hv05141 for ; Mon, 2 Dec 2002 17:09:43 -0500 Received: from imo-d03.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14160 for ; Mon, 2 Dec 2002 17:06:49 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d03.mx.aol.com (mail_out_v34.13.) id 7.179.1215466e (25508); Mon, 2 Dec 2002 17:09:12 -0500 (EST) Message-ID: <179.1215466e.2b1d3408@aol.com> Subject: Re: [Iptel] Hex digits To: hgs@cs.columbia.edu, iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_179.1215466e.2b1d3408_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 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, 2 Dec 2002 17:09:12 EST --part1_179.1215466e.2b1d3408_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/2/2002 3:27:40 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > E.164 doesn't mention hexadecimal digits (A-F), just "decimal digits". In a message dated 12/2/2002 3:55:20 PM Eastern Standard Time, rohan@cisco.com writes: > "nondedactic" digits are in current use. they need to stay. for > example many telephone company internal numbers in belgium begin with > the "number" E. > I suppose it doesn't hurt anything to leave HEX in, especially for the "local number". They certainly can't be used for the "global number". I can't imagine how "E" could be used for "internal numbers" in Belgium. Do you mean within their own private system, never to be dialed from outside? Mike Pierce Artel --part1_179.1215466e.2b1d3408_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/2/2002 3:27:40 PM Eastern Standard Time, hgs@cs.columbia.edu writes:


E.164 doesn't mention hexadecimal digits (A-F), just "decimal digits".


In a message dated 12/2/2002 3:55:20 PM Eastern Standard Time, rohan@cisco.com writes:


"nondedactic" digits are in current use.  they need to stay.  for
example many telephone company internal numbers in belgium begin with
the "number" E.


I suppose it doesn't hurt anything to leave HEX in, especially for the "local number". They certainly can't be used for the "global number".

I can't imagine how "E" could be used for "internal numbers" in Belgium. Do you mean within their own private system, never to be dialed from outside?

Mike Pierce
Artel
--part1_179.1215466e.2b1d3408_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 17:20:46 2002 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 RAA15000 for ; Mon, 2 Dec 2002 17:20:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2MNAh05994 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 17:23:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2MNAv05991 for ; Mon, 2 Dec 2002 17:23:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14963 for ; Mon, 2 Dec 2002 17:20:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2MN5v05954; Mon, 2 Dec 2002 17:23:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2MLJv05814 for ; Mon, 2 Dec 2002 17:21:19 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14837 for ; Mon, 2 Dec 2002 17:18:24 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2MLBl8004412 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 2 Dec 2002 17:21:11 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB2ML9dG007389 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Dec 2002 17:21:10 -0500 (EST) Message-ID: <3DEBDC82.4020600@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: iptel@ietf.org Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion References: <71.29bb19ca.2b1d3411@aol.com> In-Reply-To: <71.29bb19ca.2b1d3411@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Dec 2002 17:19:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > However, I thought that the "context" was also being suggested for the > "Pizza Hut" case in which one "organization" has a number, but it routes > to different places depending on where it is dialed from. Technically, > that is no different than if multiple organizations use the same number > in different areas for different purposes. As I've tried to make clear several times, apparently failing at it, is that in the context of tel URIs, this makes a big difference. The URI is an identifier for a logical resource. PizzaHut is one logical resource, "weddings in PA" and "divorces in NV" are, by any reasonable definition, two. > > > Unfortunately, I believe the answer you got from NANPA could be I got the answer from SMS/800, not NANPA. SMS/800 does the assignment to RespOrgs. > > misinterpeted. Their answer is that a particular number can only be > assigned to one Service Provider (i.e., AT&T, Sprint, etc.), which is > what they do. The question was whether a number could be used by > multiple RespOrgs ("weddings in PA, divorces in NV"). I don't believe > that NANPA cares how the service provider routes calls for that 800 > number. If AT&T wants to sell the same number is two different areas, I > suppose they could do it. They could, but since the 800# is portable, the NV lawyer can take his number and go nationwide, leaving the poor wedding organizer stranded. (The 1-800-LAWYER case is a bit different in that there's effectively an intermediate organization that hands out "franchises". The individual lawyer doesn't own a piece. Plus, by definition, this is for a service which is to be perceived as one service.) > > > How about other cases besides 800? The ongoing discussion in IEPREP is > based on GETS which uses a 710- number, dialed from anywhere in the US, > with routing to the "nearest" switch that understands what to do with > it. Based on the previous discussion on 800, one could argue that 710- > also needs a "context" to control routing. How about 900-? No, it doesn't. The 710 number always means the same thing ("go to GETS access gateway"), even if the routing differs. Same for 900. > > > I would just like to say that "context" never is used with an E.164 > number or anything that can properly be represented as one and is not > intended to tell routing logic anything about the source or destination > of a call. Its only purpose is to allow the destination to verify that a > private number it receives is one that it should be able to understand. That's what I've been arguing, yes... > > > That still leaves unclear the use of "context" for local dialing > "prefixs" and "codes" lilke 0, 911, 411, etc. That requires another > discussion line. I think either tel:911;context=+1 or tel:+1-911 would work, semantically. I suspect the former will elicit fewer groans. > > Mike Pierce > Artel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 17:21:46 2002 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 RAA15065 for ; Mon, 2 Dec 2002 17:21:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2MOAd06139 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 17:24:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2MOAv06136 for ; Mon, 2 Dec 2002 17:24:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15053 for ; Mon, 2 Dec 2002 17:21:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2MO4v06104; Mon, 2 Dec 2002 17:24:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2MNkv06029 for ; Mon, 2 Dec 2002 17:23:46 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15015 for ; Mon, 2 Dec 2002 17:20:51 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB2MNWK0019841; Mon, 2 Dec 2002 14:23:32 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ08652; Mon, 2 Dec 2002 14:21:08 -0800 (PST) Subject: Re: [Iptel] Hex digits Content-Type: multipart/alternative; boundary=Apple-Mail-23-431080014 Mime-Version: 1.0 (Apple Message framework v548) Cc: hgs@cs.columbia.edu, iptel@ietf.org To: Mpierce1@aol.com From: Rohan Mahy In-Reply-To: <179.1215466e.2b1d3408@aol.com> Message-Id: X-Mailer: Apple Mail (2.548) 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, 2 Dec 2002 14:23:42 -0800 --Apple-Mail-23-431080014 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, To clarify. the numbers beginning with E are for trusted (NNI) things=20= like operator stations. Like most 800 numbers, they are globally=20 unique, but obviously not dial-able from everywhere. thanks, -rohan On Monday, December 2, 2002, at 02:09 PM, Mpierce1@aol.com wrote: > In a message dated 12/2/2002 3:27:40 PM Eastern Standard Time,=20 > hgs@cs.columbia.edu writes: > > > E.164 doesn't mention hexadecimal digits (A-F), just "decimal digits". > > > > In a message dated 12/2/2002 3:55:20 PM Eastern Standard Time,=20 > rohan@cisco.com writes: > > > "nondedactic" digits are in current use. =A0they need to stay. =A0for > example many telephone company internal numbers in belgium begin with > the "number" E. > > > > I suppose it doesn't hurt anything to leave HEX in, especially for the=20= > "local number". They certainly can't be used for the "global number". > > I can't imagine how "E" could be used for "internal numbers" in=20 > Belgium. Do you mean within their own private system, never to be=20 > dialed from outside? > > Mike Pierce > Artel --Apple-Mail-23-431080014 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, To clarify. the numbers beginning with E are for trusted (NNI) things like operator stations. Like most 800 numbers, they are globally unique, but obviously not dial-able from everywhere. thanks, -rohan On Monday, December 2, 2002, at 02:09 PM, Mpierce1@aol.com wrote: ArialIn a message dated 12/2/2002 3:27:40 PM Eastern Standard Time, hgs@cs.columbia.edu writes: E.164 doesn't mention hexadecimal digits (A-F), just "decimal digits". = Arial0000,0000,0000In a message dated 12/2/2002 3:55:20 PM Eastern Standard Time, rohan@cisco.com writes: "nondedactic" digits are in current use. =A0they need to stay. =A0for example many telephone company internal numbers in belgium begin with the "number" E. I suppose it doesn't hurt anything to leave HEX in, especially for the "local number". They certainly can't be used for the "global number". I can't imagine how "E" could be used for "internal numbers" in Belgium. Do you mean within their own private system, never to be dialed from outside? Mike Pierce Artel = --Apple-Mail-23-431080014-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 17:54:37 2002 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 RAA14209 for ; Mon, 2 Dec 2002 17:07:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2MA7M05225 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 17:10:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2MA7v05211 for ; Mon, 2 Dec 2002 17:10:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14191 for ; Mon, 2 Dec 2002 17:07:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2MA2v05197; Mon, 2 Dec 2002 17:10:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2M9iv05145 for ; Mon, 2 Dec 2002 17:09:44 -0500 Received: from imo-r06.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14163 for ; Mon, 2 Dec 2002 17:06:50 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r06.mx.aol.com (mail_out_v34.13.) id 7.71.29bb19ca (25508); Mon, 2 Dec 2002 17:09:21 -0500 (EST) Message-ID: <71.29bb19ca.2b1d3411@aol.com> Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion To: hgs@cs.columbia.edu CC: iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_71.29bb19ca.2b1d3411_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 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, 2 Dec 2002 17:09:21 EST --part1_71.29bb19ca.2b1d3411_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/2/2002 2:07:58 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > Best to read iptel messages most-recent-first :-) Given that there are > no indications that 800# are re-used across distinct organizations, > there is no need for a context. > Agreed that it is sometimes best to read them in reverse order (or only read the last couple hours and delete the rest.) However, I thought that the "context" was also being suggested for the "Pizza Hut" case in which one "organization" has a number, but it routes to different places depending on where it is dialed from. Technically, that is no different than if multiple organizations use the same number in different areas for different purposes. Unfortunately, I believe the answer you got from NANPA could be misinterpeted. Their answer is that a particular number can only be assigned to one Service Provider (i.e., AT&T, Sprint, etc.), which is what they do. The question was whether a number could be used by multiple RespOrgs ("weddings in PA, divorces in NV"). I don't believe that NANPA cares how the service provider routes calls for that 800 number. If AT&T wants to sell the same number is two different areas, I suppose they could do it. How about other cases besides 800? The ongoing discussion in IEPREP is based on GETS which uses a 710- number, dialed from anywhere in the US, with routing to the "nearest" switch that understands what to do with it. Based on the previous discussion on 800, one could argue that 710- also needs a "context" to control routing. How about 900-? I would just like to say that "context" never is used with an E.164 number or anything that can properly be represented as one and is not intended to tell routing logic anything about the source or destination of a call. Its only purpose is to allow the destination to verify that a private number it receives is one that it should be able to understand. That still leaves unclear the use of "context" for local dialing "prefixs" and "codes" lilke 0, 911, 411, etc. That requires another discussion line. Mike Pierce Artel --part1_71.29bb19ca.2b1d3411_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/2/2002 2:07:58 PM Eastern Standard Time, hgs@cs.columbia.edu writes:


Best to read iptel messages most-recent-first :-) Given that there are
no indications that 800# are re-used across distinct organizations,
there is no need for a context.



Agreed that it is sometimes best to read them in reverse order (or only read the last couple hours and delete the rest.)

However, I thought that the "context" was also being suggested for the "Pizza Hut" case in which one "organization" has a number, but it routes to different places depending on where it is dialed from. Technically, that is no different than if multiple organizations use the same number in different areas for different purposes.

Unfortunately, I believe the answer you got from NANPA could be misinterpeted. Their answer is that a particular number can only be assigned to one Service Provider (i.e., AT&T, Sprint, etc.), which is what they do. The question was whether a number could be used by multiple RespOrgs ("weddings in PA, divorces in NV"). I don't believe that NANPA cares how the service provider routes calls for that 800 number. If AT&T wants to sell the same number is two different areas, I suppose they could do it.

How about other cases besides 800? The ongoing discussion in IEPREP is based on GETS which uses a 710- number, dialed from anywhere in the US, with routing to the "nearest" switch that understands what to do with it. Based on the previous discussion on 800, one could argue that 710- also needs a "context" to control routing. How about 900-?

I would just like to say that "context" never is used with an E.164 number or anything that can properly be represented as one and is not intended to tell routing logic anything about the source or destination of a call. Its only purpose is to allow the destination to verify that a private number it receives is one that it should be able to understand.

That still leaves unclear the use of "context" for local dialing "prefixs" and "codes" lilke 0, 911, 411, etc. That requires another discussion line.

Mike Pierce
Artel

--part1_71.29bb19ca.2b1d3411_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 18:05:47 2002 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 SAA16619 for ; Mon, 2 Dec 2002 18:05:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2N8BH09188 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 18:08:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2N8Bv09185 for ; Mon, 2 Dec 2002 18:08:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16575 for ; Mon, 2 Dec 2002 18:05:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2N83v09164; Mon, 2 Dec 2002 18:08:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2N7fv09145 for ; Mon, 2 Dec 2002 18:07:41 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16567 for ; Mon, 2 Dec 2002 18:04:46 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB2N7PK0014319; Mon, 2 Dec 2002 15:07:25 -0800 (PST) Received: from fluffyw2k (dhcp-128-107-142-55.cisco.com [128.107.142.55]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id DUF00074; Mon, 2 Dec 2002 15:07:46 -0800 (PST) From: "Cullen Jennings" To: "Rohan Mahy" , Cc: , Subject: RE: [Iptel] Hex digits Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CB_01C29A14.85002D80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-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: Mon, 2 Dec 2002 15:07:24 -0800 This is a multi-part message in MIME format. ------=_NextPart_000_00CB_01C29A14.85002D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Also used in Japan. -----Original Message----- From: iptel-admin@ietf.org [mailto:iptel-admin@ietf.org]On Behalf Of Rohan Mahy Sent: Monday, December 02, 2002 2:24 PM To: Mpierce1@aol.com Cc: hgs@cs.columbia.edu; iptel@ietf.org Subject: Re: [Iptel] Hex digits Hi, To clarify. the numbers beginning with E are for trusted (NNI) things like operator stations. Like most 800 numbers, they are globally unique, but obviously not dial-able from everywhere. thanks, -rohan On Monday, December 2, 2002, at 02:09 PM, Mpierce1@aol.com wrote: In a message dated 12/2/2002 3:27:40 PM Eastern Standard Time, hgs@cs.columbia.edu writes: E.164 doesn't mention hexadecimal digits (A-F), just "decimal digits". In a message dated 12/2/2002 3:55:20 PM Eastern Standard Time, rohan@cisco.com writes: "nondedactic" digits are in current use. they need to stay. for example many telephone company internal numbers in belgium begin with the "number" E. I suppose it doesn't hurt anything to leave HEX in, especially for the "local number". They certainly can't be used for the "global number". I can't imagine how "E" could be used for "internal numbers" in Belgium. Do you mean within their own private system, never to be dialed from outside? Mike Pierce Artel ------=_NextPart_000_00CB_01C29A14.85002D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Also=20 used in Japan.
 
-----Original Message-----
From: = iptel-admin@ietf.org=20 [mailto:iptel-admin@ietf.org]On Behalf Of Rohan = Mahy
Sent:=20 Monday, December 02, 2002 2:24 PM
To: = Mpierce1@aol.com
Cc:=20 hgs@cs.columbia.edu; iptel@ietf.org
Subject: Re: [Iptel] Hex = digits

Hi,

To clarify. the numbers = beginning with E=20 are for trusted (NNI) things like operator stations. Like most 800 = numbers,=20 they are globally unique, but obviously not dial-able from=20 everywhere.

thanks,
-rohan

On Monday, December 2, = 2002, at=20 02:09 PM, Mpierce1@aol.com wrote:

In a message dated=20 12/2/2002 3:27:40 PM Eastern Standard Time, hgs@cs.columbia.edu=20 writes:


E.164 doesn't mention=20 hexadecimal digits (A-F), just "decimal = digits".



In=20 a message dated 12/2/2002 3:55:20 PM Eastern Standard Time, = rohan@cisco.com=20 writes:


"nondedactic" digits are in current use. =  they need=20 to stay.  for
example many telephone company internal = numbers in=20 belgium begin with
the "number" E.



I suppose it = doesn't=20 hurt anything to leave HEX in, especially for the "local number". = They=20 certainly can't be used for the "global number".

I can't = imagine how=20 "E" could be used for "internal numbers" in Belgium. Do you mean = within=20 their own private system, never to be dialed from = outside?

Mike=20 = Pierce
Artel
------=_NextPart_000_00CB_01C29A14.85002D80-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 18:54:55 2002 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 SAA18379 for ; Mon, 2 Dec 2002 18:54:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2NvK812192 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 18:57:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2NvKv12189 for ; Mon, 2 Dec 2002 18:57:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18369 for ; Mon, 2 Dec 2002 18:54:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Nv5v12166; Mon, 2 Dec 2002 18:57:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2NuQv12127 for ; Mon, 2 Dec 2002 18:56:26 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18358 for ; Mon, 2 Dec 2002 18:53:30 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB2NuF903666; Mon, 2 Dec 2002 15:56:15 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB2NuPY23903; Mon, 2 Dec 2002 17:56:25 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 15:56:11 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D205426D35@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Rohan Mahy'" , "'Henning Schulzrinne'" Cc: "'iptel@ietf.org'" Subject: RE: [Iptel] Hex digits MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29A5E.635D742C" 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, 2 Dec 2002 15:56:10 -0800 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_01C29A5E.635D742C Content-Type: text/plain Yeah, but in that case they are not E.164 numbers: they are private numbers. > Henning, > > "nondedactic" digits are in current use. they need to stay. for > example many telephone company internal numbers in belgium begin with > the "number" E. > > thanks, > -rohan > > On Monday, December 2, 2002, at 12:19 PM, Henning Schulzrinne wrote: > > > E.164 doesn't mention hexadecimal digits (A-F), just > "decimal digits". > > They currently appear in the BNF. Is there are a reason to > keep A-F, > > then? > > > > _______________________________________________ > > 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 > ------_=_NextPart_001_01C29A5E.635D742C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Iptel] Hex digits

Yeah, but in that case they are not E.164 numbers: = they are private numbers.

 
> Henning,
>
> "nondedactic" digits are in current = use.  they need to stay.  for
> example many telephone company internal numbers = in belgium begin with
> the "number" E.
>
> thanks,
> -rohan
>
> On Monday, December 2, 2002, at 12:19 PM, = Henning Schulzrinne wrote:
>
> > E.164 doesn't mention hexadecimal digits = (A-F), just
> "decimal digits".
> > They currently appear in the BNF. Is there = are a reason to
> keep A-F,
> > then?
> >
> > = _______________________________________________
> > 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=
>

------_=_NextPart_001_01C29A5E.635D742C-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 20:08:49 2002 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 UAA20293 for ; Mon, 2 Dec 2002 20:08:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB31BF816990 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 20:11:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB31BFv16987 for ; Mon, 2 Dec 2002 20:11:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20265 for ; Mon, 2 Dec 2002 20:08:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB31B5v16967; Mon, 2 Dec 2002 20:11:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB31Ahv16936 for ; Mon, 2 Dec 2002 20:10:43 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20254 for ; Mon, 2 Dec 2002 20:07:46 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB31AXl8023194 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 2 Dec 2002 20:10:34 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB31AWdG021764 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Dec 2002 20:10:33 -0500 (EST) Message-ID: <3DEC041A.407@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis References: <3DD9D7A5.5040503@dynamicsoft.com> In-Reply-To: <3DD9D7A5.5040503@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Dec 2002 20:08:42 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Here is some new text: If the receiver of a ``tel'' URI uses the URI simply for identification, the receiver does not need to know anything about the context descriptor. It simply treats it as one part of a globally unique identifier, with the other being the local number. If a recipient of the URI intends to place a call to the local number, it {\MUST} verify that it is within the same context as one of the descriptors. Otherwise, it {\MUSTNOT} initiate the call and treat the URI like an invalid destination. Earlier, local numbers are given the SHOULDNOT tag; I added a bit of motivation why they are a bad idea. > > Related to this, the spec doesn't define any specific processing > associated with the phone-context. No where is there something like "the > client SHOULD compare the phone-context with its configured domain names > and prefixes, and if there is no match, discard the URI and inform the > user". That is needed. The draft should also talk more about the > configuration burdens and other problems associated with local numbers. > They would seem to require clients to know their phone contexts. Also, > what happens exactly if a client encounters one it doesnt know? What is > the right error reporting? _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 20:21:42 2002 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 UAA20704 for ; Mon, 2 Dec 2002 20:21:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB31O8j17793 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 20:24:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB31O8v17790 for ; Mon, 2 Dec 2002 20:24:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20695 for ; Mon, 2 Dec 2002 20:21:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB31O3v17673; Mon, 2 Dec 2002 20:24:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB31NSv17649 for ; Mon, 2 Dec 2002 20:23:28 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20681 for ; Mon, 2 Dec 2002 20:20:26 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB31N9l8023987 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 2 Dec 2002 20:23:10 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB31N8dG022863 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Dec 2002 20:23:09 -0500 (EST) Message-ID: <3DEC070C.3060102@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis - intro References: <3DD9D7A5.5040503@dynamicsoft.com> In-Reply-To: <3DD9D7A5.5040503@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Dec 2002 20:21:16 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > This document specifies the URI (Uniform Resource Identifier) scheme > > "tel" for specifying the address of a terminal in the phone network. > > > Are we only specifying terminals? It seems that with some of the recent > work on things like trunk groups, we are really specifying a wider range > of "telephony resources". These include terminals, but also appear to > include individual circuits, for example. Added 'circuits'. In general, it's probably hard to define exactly what a telephone number describes, since it may describe not just one terminal or circuit, but a whole logical grouping (see the 800# discussion). Maybe we should just leave it at the definition in E.164: Number: A string of decimal digits that uniquely indicates the public network termination point. The number contains the information necessary to route the call to this termination point. > > > > The tel URI is service-independent and describes voice calls (phone > > calls, answering machines and voice messaging systems), facsimile > > (telefax) calls and data calls, for landline, ISDN and mobile > > subscribers. > > > It doesn't really describe calls at all. A call has things like a start > and stop time, two endpoints, states, and so on. The tel URI identifies > resources that can be contact on the telephone network. Simplified to This document specifies the URI (Uniform Resource Identifier) scheme ``tel'' that describes resources identified by telephone numbers. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 20:25:40 2002 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 UAA20803 for ; Mon, 2 Dec 2002 20:25:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB31S6418009 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 20:28:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB31S6v18006 for ; Mon, 2 Dec 2002 20:28:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20797 for ; Mon, 2 Dec 2002 20:25:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB31S1v17998; Mon, 2 Dec 2002 20:28:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB31Rkv17982 for ; Mon, 2 Dec 2002 20:27:46 -0500 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20776 for ; Mon, 2 Dec 2002 20:24:49 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gB31R1ev001292; Mon, 2 Dec 2002 20:27:01 -0500 (EST) From: Scott Bradner Message-Id: <200212030127.gB31R1ev001292@newdev.harvard.edu> To: hgs@cs.columbia.edu, Mpierce1@aol.com Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion Cc: iptel@ietf.org In-Reply-To: <71.29bb19ca.2b1d3411@aol.com> 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, 2 Dec 2002 20:27:01 -0500 (EST) > However, I thought that the "context" was also being suggested for the "Pizza > Hut" case in which one "organization" has a number, but it routes to > different places depending on where it is dialed from. Technically, that is > no different than if multiple organizations use the same number in different > areas for different purposes. that is what I was trying to say Scott _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 2 22:30:48 2002 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 WAA24136 for ; Mon, 2 Dec 2002 22:30:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB33XFQ25198 for iptel-archive@odin.ietf.org; Mon, 2 Dec 2002 22:33:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB33XFv25195 for ; Mon, 2 Dec 2002 22:33:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24079 for ; Mon, 2 Dec 2002 22:30:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB33X7v25185; Mon, 2 Dec 2002 22:33:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB33WLv25155 for ; Mon, 2 Dec 2002 22:32:21 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23996 for ; Mon, 2 Dec 2002 22:29:22 -0500 (EST) Received: from cs.columbia.edu ([12.85.3.228]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021203033146.MXSY13909.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Tue, 3 Dec 2002 03:31:46 +0000 Message-ID: <3DEC2538.1000902@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis - grammar References: <3DD9D7A5.5040503@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 02 Dec 2002 22:30:00 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > The approach pursued here has the disadvantage that certain services, > > such as extensions on a PBX (when direct inward dialing is not used) > > or electronic banking, cannot be specified in a URI. > > I plead stupidity here. I don't see why you can't do PBX extensions with > a tel URI. Isnt this just a local number with an appropriate phone-context? But that local number would not be dialable outside the context (It is not sufficient to just prefix the context and create to create an E.164 number). Extensions do seem like a legitimate need, so there are two options: - treat them as the same thing as ISDN sub-addresses, i.e., as a common parameter; - add another parameter, say ;ext. This seems cleaner given that the allowable parameter values are different. This fits into the identifier model. Think of the extension as roughly equivalent to the #anchor notation in http URIs. >> URI comparisons are case-insensitive. However, all parameter names | >> and values SHOULD use lower-case characters since tel URIs may >> be | >> used within contexts where comparisons are case-sensitive. > > > Does that mean that: > > tel:+1-987-654-3210 > and > tel:+19876543210 > > are not equivalent? > > If so, we should explicitly state that. I elaborated on the comparison rules. I suppose it would be helpful if tel URIs were stripped of visual separators when they become user-parts in SIP URIs, to avoid spurious differences. >> Each parameter name ("pname"), the ISDN subaddress and the context >> MUST NOT appear more than once. > > > Hmm. You seemed to use this BNF trick above to specify one instance of > context, but not ISDN sub-address. Is there a reason its not consistent? Unfortunately, I don't see how I can specify 'at most one isub, but can appear anywhere' while specifying a single context. You'd have to enumerate all combinations, as in *par [isdn-subaddress] *par context *par *par context *par [isdn-subaddress] Any other ideas? > >> is compared character-by-character, such as SIP URIs [5], the ISDN | >> subaddress SHOULD appear first, if present, followed by the >> context, | >> if present, followed by any other parameters in alphabetical order. > > > Since paramchar can contain non-alphabetic characters, what is the > meaning of alphabetical order? I18N and canonicalization, here we come... I guess this would mean lexicographic ordering according to the character set, presumably UTF-8. (However, is there any reason that parameter names could not just be unreserved? They are protocol constants, not somebody's personal name.) _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 01:42:48 2002 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 BAA29423 for ; Tue, 3 Dec 2002 01:42:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB36jG204375 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 01:45:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB36jGv04371 for ; Tue, 3 Dec 2002 01:45:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29420 for ; Tue, 3 Dec 2002 01:42:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB36j8v04363; Tue, 3 Dec 2002 01:45:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB36ilv04330 for ; Tue, 3 Dec 2002 01:44:47 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29411 for ; Tue, 3 Dec 2002 01:41:47 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB36iQ0R018792; Mon, 2 Dec 2002 22:44:26 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id DVB00276; Mon, 2 Dec 2002 22:44:50 -0800 (PST) From: "Cullen Jennings" To: "Henning Schulzrinne" , Cc: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3DEBDC82.4020600@cs.columbia.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Iptel] Tel URI and 411 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, 2 Dec 2002 22:47:11 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > That still leaves unclear the use of "context" for local dialing > > "prefixs" and "codes" lilke 0, 911, 411, etc. That requires another > > discussion line. > > I think either > tel:911;context=+1 or > tel:+1-911 > would work, semantically. I suspect the former will elicit fewer groans. > We could consider something like 411 a user interface mnemonic that you dial to get a common service. On my cell phone 411 gets me a service that refuses to tell me the phone number of subscribers to the same cellular service and is perfectly happy to make restaurant reservation for me and give me driving instructions. Go figure. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 02:03:39 2002 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 CAA04785 for ; Tue, 3 Dec 2002 02:03:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3768w08401 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 02:06:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3768v08398 for ; Tue, 3 Dec 2002 02:06:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04094 for ; Tue, 3 Dec 2002 02:03:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3763v08369; Tue, 3 Dec 2002 02:06:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB375nv08277 for ; Tue, 3 Dec 2002 02:05:49 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03674 for ; Tue, 3 Dec 2002 02:02:49 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB375eYH011117 for ; Tue, 3 Dec 2002 02:05:41 -0500 (EST) Message-ID: <3DEC57C1.2090000@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Iptel] New charter items 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 Dec 2002 02:05:37 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, As I mentioned during the meeting, the iptel group has been asked to be the new home for telephony URI related work. This work encompasses a number of drafts which we need to formally adopt as working group items. I'd like to gauge general group interest in pursuing this work. Please comment (privately or on the list) on your desire to work on the following: 1. http://www.ietf.org/internet-drafts/draft-antti-rfc2806bis-06.txt We have formally been asked to own this document. We have already been actively working on it so I dont anticipate there will be any objections. 2. http://www.ietf.org/internet-drafts/draft-yu-tel-url-06.txt We have also formally been asked to own this document. Not many comments on it yet. 3. http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-00.txt This is a new draft. While I think the draft itself requires more work, the main question is whether the group is interested in specifying extensions to the tel URI for supporting trunk groups, and whether this document can serve as a useful starting point for that work. During the meeting, I pointed out that the h323 URL http://www.ietf.org/internet-drafts/draft-levin-iptel-h323-url-scheme-05.txt would also need to be added to our charter. However, in subsequent discussions with the author and Scott B., it turns out that the iptel group does not have change control over this work. It is therefore not appropriate for us to work on it, and it will be handled outside of the iptel group. On the subject of the enum URI, I believe there is not consensus on whether or not it even makes sense to have a separate URI for this. Its therefore inappropriate to make any charter decisions at this time. I'd like to see some more discussion of the specific problem, though. As I pointed out during the meeting, I believe it is closely related to the imprecise semantics of the tel URI itself. THus, I believe we own the general problem as part of the tel URI work. On the CPC work, I think there is even less consensus on that, with a lot more discussion needed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Tue Dec 3 02:09:40 2002 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 CAA09788 for ; Tue, 3 Dec 2002 02:09:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB37C8115473 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 02:12:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB37C8v15470 for ; Tue, 3 Dec 2002 02:12:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09772 for ; Tue, 3 Dec 2002 02:09:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB37C4v15387; Tue, 3 Dec 2002 02:12:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB37BUv15015 for ; Tue, 3 Dec 2002 02:11:30 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09757 for ; Tue, 3 Dec 2002 02:08:30 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB37BDYH011129; Tue, 3 Dec 2002 02:11:13 -0500 (EST) Message-ID: <3DEC590E.8020003@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet CC: "'Rohan Mahy'" , "'Henning Schulzrinne'" , "'iptel@ietf.org'" Subject: Re: [Iptel] Hex digits References: <2F1FC1DEA077D5119FAD00508BCFD6D205426D35@zsc3c030.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Dec 2002 02:11:10 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I would propose that the BNF be modified so that the E.164 numbers cannot contain A-F, and the private numbers can. -Jonathan R. Francois Audet wrote: > > Yeah, but in that case they are not E.164 numbers: they are private > numbers. > > > > Henning, > > > > "nondedactic" digits are in current use. they need to stay. for > > example many telephone company internal numbers in belgium begin with > > the "number" E. > > > > thanks, > > -rohan > > > > On Monday, December 2, 2002, at 12:19 PM, Henning Schulzrinne wrote: > > > > > E.164 doesn't mention hexadecimal digits (A-F), just > > "decimal digits". > > > They currently appear in the BNF. Is there are a reason to > > keep A-F, > > > then? > > > > > > _______________________________________________ > > > 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 > > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Tue Dec 3 02:09:40 2002 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 CAA09800 for ; Tue, 3 Dec 2002 02:09:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB37C9s15509 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 02:12:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB37C9v15506 for ; Tue, 3 Dec 2002 02:12:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09775 for ; Tue, 3 Dec 2002 02:09:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB37C3v15357; Tue, 3 Dec 2002 02:12:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB37BAv14829 for ; Tue, 3 Dec 2002 02:11:10 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09754 for ; Tue, 3 Dec 2002 02:08:10 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB37AY0J024784; Mon, 2 Dec 2002 23:10:34 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id DVD00049; Mon, 2 Dec 2002 23:11:11 -0800 (PST) From: "Cullen Jennings" To: Cc: "Jonathan Rosenberg" , "Cullen Jennings" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Iptel] FW: Draft IPTEL WG meeting minutes from the 55th IETF 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, 2 Dec 2002 23:13:31 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I merged Andrew's notes with a few others. If I do not get any comments on this before December 9th I will forward them as the official minutes. Thanks All, Cullen ------------------------------------------------ IPTEL meeting minutes from the 55th IETF Tuesday, November 19, 2002 1700-1800 Salon I Chairs: J. Rosenberg C. Jennings ---- Agenda ---- - Status - TGREP issues - 2806 bis issues - Trunk Group issues - CPC/OLI issues (ran out of time and did not cover this) ---- Administrative Stuff ---- Cullen Jennings has joined Jonathan Rosenberg as a co-chair of the WG. There is a new mailing list, iptel@ietf.org. You can subscribe via email or at http://www.ietf.org/mailman/listinfo/iptel. People have not been automatically migrated as we could not get the list of subscribers on the old list. The IESG has asked the working group to take on tel URI. We are likely to update the charter and schedule with more URI related items. ---- Status of current work items ---- TRIP MIB: Expert review has been conducted which produced a revised version of the draft. There have been more comments since the revision on the list. We expect that one more reversion of this draft will likely have it ready for IESG. Working group last call was already completed once. TGREP: A new version of this draft has just been submitted. It is in need of expert review. It solves an important problem of preregistering a block of DNs for a gateway. It also provides resource availability information from a single gateway to devices making routing decision about which gateway to use. New work: The IESG has given the working group the mandate to take on telephony related URL items. This could include: 2806bis, draft-yu-tel-url, draft-ietf-iptel-trunk-group, draft-peterson-tel-cpc, draft-brandner-enum-uri. Also discussing draft-levin-iptel-h323-url-scheme (more on this later). When we have reached group consensus on what will be taken on and which document will adopted, the chairs will update the charter. ---- TGREP Presentation by Dhaval Shah ----- TGREP has been changed to be an auxiliary protocol instead of a subset of TRIP. Country codes have been added to the CIC. Open Issue #1 - Thresholding Schemes. Leave them out of the draft or put in more detail? This is an detail implementation issue of a device that will effect how the TGREP protocol performs. There was some discussion of if this should be in a BCP but Jonathan pointed out that we don't have enough field experience to have any hope of knowing what the best practice is. After some discussion people seemed OK with not describing normative thresholding schemes in the draft. Open Issue #2 - Is 128 bytes enough for the trunk group label. Jon Peterson though that 30 bytes would likely be enough so 128 should be fine. No other views expressed. Open Issue #3 - Should carrier codes be ASCII or binary? A few people felt that ASCII would do fine. There were no objections to ASCII. Jon Peterson had done a review and offered to send his comments to the list, most have already been incorporated into the current draft. Chairs put in plea for comments on this draft so we do not have to assign reviewers. This draft seems close to being ready to go to the IESG. ---- 2806bis (tel URI) presentation by Henning Schulzrinne ----- This has undergone significant changes and is considerably narrowed in scope. URI comparisons should be case insensitive but implementation should use lower case letters. The BNF was cleaned up to remove order dependencies but a preferred ordering is specified. This draft is close to WGLC. The intent of the tel URI is to be an abstract address. It is not instructions on how to dial such that you reach a specific location. Open Issue #1 - Context. Is a context needed for a number and if so how is this represented. The classic example is a 800 service number. Ways to represent a context include a DNS domain, a E.164 style prefix, or a list of prefixes. Jon Peterson pointed out there are US 800 numbers that are scoped to bell operating companies, LATAs, countries, etc. Henning Schulzrinne said that he doesn't think it is realistic to generalize URIs to accommodate this. Jon has been uncomfortable with the idea of context and added that the PSTN doesn't have this. For example, a phone number found piece of paper has no context and may not work if you were to arbitrarily use it. Henning explained some of the difficulties in using prefixes to express ranges of numbers. Lawrence Conroy expressed that DNS is likely the "least bad" choice for how to do context but explained there could still be confusion on if the context ibm.com meant IBM's internal network or was an external context. Jonathan pointed out that this context problem exits in other places such as an HTTP URL. The practical solution has been, if you find a URL, you can only use it in a context in which it is valid. Henning wanted us to consider the more radical step of not allowing local scope URI. (the U part of the URI.) Always having context would eliminate much of the silliness that happens today. He brought up the example of the problems that happened with the tv: URL. Jonathan leant more towards not providing context in the tel URI and just making sure that you did not send URLs out of scope. This would still allow local scope. Dave Oran pointed out that "speed dial" configuration was the same problem. Dave thought we should punt on trying to figure out if a given thing was in the scope or not. Flemming Andreasen thought it would be useful to have a context. Henning commented that in many cases, the tel URI was more like a URN than a URI. This is especially true for service numbers. Jonathan argued this was not a tel URI specific problem and felt like a much bigger issue for someone else to solve. Jonathan said this draft is devoid of semantics on URI processing or any information on what you should do with one of these things. The meeting moved on to other topics but clearly this context topic needs more discussion on the list. Open Issue #2 - Global numbers - are they global? Global numbers are of the E.164 form. Some of them like +1-800-356-9733 look like global numbers but are not. It may not be possible to call them form many countries of states. [There has been significant discussion on the list since the meeting on this topic] Next steps: There was some short discussion on what it takes to get this to draft standard. One of the items needed with be an interoperability matrix. Henning would appreciate people contacting him if they have implemented tel URL. Lawrence Conroy talked about how all of this changes the expect behavior of clients from the behavior in RFC 2806. These changes are not backwards compatible and will break existing systems. At least one system that is used for internal use only would be broken by this. It is not a requirement that this bis draft has to be backwards compatible but the working group need to decide what we want to do. Another issue that came up about going to draft standard is the question of the status of the normative references. Allison Mankin confirmed that all normative references need to be draft standards before this can go to draft standard. There is only one normative reference, RFC 2396. There is a 2396bis in progress, and Jonathan will check as to whether this is going to draft standard or not. ---- Trunk Group presentation by Vijay Gurbani ---- The trunk group work has been motivated by the need to be able to indicate which of several different PSTN connections a single gateway should use for a given call. Open Issue #1 - Should the trunk group indicator be carried in a SIP or tel URI? Right now it is in a tel URI. Open Issue #2 - Should a trunk group label be in a local or global namespace? Discussion centered around the proposed double equal sign syntax in the draft. Henning thought this did not look like a good idea but Rohan Mahy pointed out the list of legal choices was small. Please, anyone, propose something better on the list. Open Issues #3 - How to represent both the originating and terminating trunk group in the same SIP message? The current proposal puts the terminating in the request URI and the originating in the Contact. Jonathan brought up that there are no semantics for the tel URI but here we are bringing up semantics for SIP. If the tel URI is defined well enough, then there will be no need to do anything special for SIP. Dave Oran's comment on this was that Jonathan is underestimating the perversity of the implementers. There were no objections to the idea of SIP having a trunk group indicator in a Contact header field value or a request URI. Open Issue #4 - Proxies should be able to change or add a destination trunk group to a request. ---- Items Moving Forward ---- Do we want to have a draft to extend the tel URI to include trunk groups? Richard Shockey requested the ENUM URI work be moved to the IPTEL group. We need to decide how/if we want to proceed with this. The draft-zhao-iptel-gwloc-slp draft is solving a somewhat different problem than the TGREP and TRIP works so it will continue to proceed as an individual work. Jon Peterson commended that he submitted the CPC draft for discussion only and he does not necessarily think it should be a charter item. Orit Levin has been working hard an getting a draft documenting the H323 URL scheme. This was in the RFC editors queue but pulled back. Rohan brought up that this draft is entangled with the Annex O work for H.323. After some discussion it came up that one of the issues on this draft is if the WG or IETF can make any changes given that this is already in competed ITU specifications. Jonathan is going to discuss this with the ADs and Orit before deciding how we can move forward on this. A more detailed version of the minutes was send to the list and is at http://www1.ietf.org/mail-archive/working-groups/iptel/current/msg00060.html Thank you Andrew for recording the minutes. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 02:58:47 2002 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 CAA10541 for ; Tue, 3 Dec 2002 02:58:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB381Hp18827 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 03:01:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB381Gv18824 for ; Tue, 3 Dec 2002 03:01:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10525 for ; Tue, 3 Dec 2002 02:58:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3818v18811; Tue, 3 Dec 2002 03:01:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB380Wv18779 for ; Tue, 3 Dec 2002 03:00:32 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10522 for ; Tue, 3 Dec 2002 02:57:31 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB380HYH011145; Tue, 3 Dec 2002 03:00:17 -0500 (EST) Message-ID: <3DEC648C.6010105@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Scott Bradner , rohan@cisco.com, iptel@ietf.org Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion References: <200211301954.gAUJsNn6022405@newdev.harvard.edu> <3DE91AF0.6050209@cs.columbia.edu> 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, 03 Dec 2002 03:00:12 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Scott, > > trying to guess at the source of confusion here. I suspect that part of > the problem might be two meanings of the word 'context': > > - Context = 'resolve this identifier under this context' > (;context=+1-212-939-7000 = Pizza Hut as if dialed from 212-939-7000) I believe this is out of scope. We are not trying to direct routing. > > - Context = 'this number is only valid if dialed from this context; it's > an error otherwise' (the number may still reach something or other, but > it's not the intended destination) This is what I believe we are talking about. I thought I heard someone suggest another usage during the meeting, to support things like VPNs: - Context: this number can only be interpreted by first routing the call to this context, and the interpreting it there For example, if a company has a PBX without DID, and its number is 973 555 1234, I would reach extension 33 this way: tel:33;context="+19735551234" THis is similar in concept to relative URI references. I don't think this is in scope either, and so perhaps I misinterpreted what was said during the iptel meeting. If someone does think we are supporting this, please speak up. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Tue Dec 3 03:09:42 2002 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 DAA10802 for ; Tue, 3 Dec 2002 03:09:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB38CBq19943 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 03:12:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB38CBv19940 for ; Tue, 3 Dec 2002 03:12:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10779 for ; Tue, 3 Dec 2002 03:09:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB38C6v19926; Tue, 3 Dec 2002 03:12:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB38Bhv19891 for ; Tue, 3 Dec 2002 03:11:43 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10753 for ; Tue, 3 Dec 2002 03:08:43 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB38BSYH011148; Tue, 3 Dec 2002 03:11:28 -0500 (EST) Message-ID: <3DEC672C.5070603@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: Henning Schulzrinne , iptel@ietf.org Subject: Re: [Iptel] Another wrinkle: 700 numbers References: <4.3.2.7.2.20021202092900.00b3fe30@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Dec 2002 03:11:24 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Let me restate a point I made during the meeting. There are lots of cases where a URI has a context, such that the URI has a different meaning depending on the context. The way in which that is handled in many other URI schemes is - its not. The URI doesn't indicate the context in which its valid. You simply don't pass that URI around, and if you do, its your problem. Thus, I asked whether we even needed context at all for the tel URI. After all, many other URI schemes don't provide it, and certainly the PSTN doesn;'t provide it. Do we need to do better? I think the answer was that in some cases we do. However, that doesn't mean we need to provide context for all numbers that might appear in a tel URI. For some, we are simply unable to provide context. Let the user beware. I think the 700 number is a case where we cannot provide context, and indeed, probably don't want to. -Jonathan R. Michael Hammer wrote: > Henning, > > Define rare. > > I believe that some of the 700 number space is used for the Government > Emergency Telephone Service (GETS). > > Mike > > > At 01:39 PM 11/30/2002 -0500, Henning Schulzrinne wrote: > >> This is another example of a barely-unique number, except that the >> destination depends on the carrier. >> >> I don't think we need to worry about this, but it could make life >> interesting if put on a web page... My perception is that 700 numbers >> are rarely used these days. >> >> From the FAQ at http://www.nanpa.com/: >> >> What is area code 700 used for? >> >> Area code 700 was assigned in 1983 on the eve of the introduction of >> long distance competition in the US. The intent was that interexchange >> carriers could use 700 numbers to implement new services quickly. When >> a 700 number is dialed, the local exchange carrier processing the call >> routes it to the presubscribed interexchange carrier, unless the >> caller has overridden presubscription by dialing 101XXXX before the >> number. Thus each interexchange carrier has access to all 7.92 million >> 700 numbers. 700 numbers are different from all other North American >> Numbering Plan numbers because the destinations are not unique, and, >> in fact, depend on the network the caller has selected. >> >> _______________________________________________ >> 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 > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Tue Dec 3 06:55:05 2002 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 GAA15533 for ; Tue, 3 Dec 2002 06:55:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3BvPL01682 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 06:57:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3BvPv01679 for ; Tue, 3 Dec 2002 06:57:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15523 for ; Tue, 3 Dec 2002 06:54:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Bv8v01670; Tue, 3 Dec 2002 06:57:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Bucv01642 for ; Tue, 3 Dec 2002 06:56:38 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15512 for ; Tue, 3 Dec 2002 06:53:47 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for iptel@ietf.org; Tue, 3 Dec 2002 12:54:31 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 12:54:30 +0100 Message-Id: From: "Alexeitsev, D" To: iptel@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Iptel] comments on rfc2806bis 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, 3 Dec 2002 12:54:23 +0100 Hello All, Just a few questions, comments for my clarification: The main scope of the tel URI is the publication on the web pages, how this URI is used by the SIP UAs (mail agents, ...) i.e. if it is converted to the SIP URI by adding the default outgoing proxy address as hostportion is out of scope for this document. Coming from the use scope the entities that tel URI will identify will be only those that are available to the regular telephone subscribers i.e. geographical nongeographical and service numbers, but not the network internal numbers that are not allowed for subscribers to dial anyway (hex digits, ...) If it is true then there is no need to allow the use of hex digits, if the scope is more then just the numbers that are allowed for subscribers input, then the 4 bit space for address digits as defined in Q.763 must be preserved. Greetings, Denis Alexeitsev _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 07:07:49 2002 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 HAA15857 for ; Tue, 3 Dec 2002 07:07:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3CA8002813 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 07:10:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3CA8v02810 for ; Tue, 3 Dec 2002 07:10:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15849 for ; Tue, 3 Dec 2002 07:07:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3CA4v02802; Tue, 3 Dec 2002 07:10:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3C9jv02776 for ; Tue, 3 Dec 2002 07:09:45 -0500 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15839 for ; Tue, 3 Dec 2002 07:06:54 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gB3C94E4002695; Tue, 3 Dec 2002 07:09:04 -0500 (EST) From: Scott Bradner Message-Id: <200212031209.gB3C94E4002695@newdev.harvard.edu> To: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion Cc: iptel@ietf.org, rohan@cisco.com, sob@harvard.edu In-Reply-To: <3DEC648C.6010105@dynamicsoft.com> 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, 3 Dec 2002 07:09:04 -0500 (EST) > - Context: this number can only be interpreted by first routing the call > to this context, and the interpreting it there not sure that is enough if the context is geographic since the "first routing node" may be half the world away Scott _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 08:09:48 2002 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 IAA17851 for ; Tue, 3 Dec 2002 08:09:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3DC8a06239 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 08:12:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DC8v06236 for ; Tue, 3 Dec 2002 08:12:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17835 for ; Tue, 3 Dec 2002 08:09:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DC2v06210; Tue, 3 Dec 2002 08:12:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DB6v06121 for ; Tue, 3 Dec 2002 08:11:06 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17758 for ; Tue, 3 Dec 2002 08:08:14 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3DB2l8001573 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 3 Dec 2002 08:11:03 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3DB1dG025865 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Dec 2002 08:11:02 -0500 (EST) Message-ID: <3DECACE5.80208@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Bradner CC: iptel@ietf.org Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion References: <200212031209.gB3C94E4002695@newdev.harvard.edu> In-Reply-To: <200212031209.gB3C94E4002695@newdev.harvard.edu> 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, 03 Dec 2002 08:08:53 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The context is meant to lead to a binary decision: Either you know you're in the context or you know you're not. Each node knows its context (a set of E.164-style numbers or a domain name) and simply checks if the tel URI context matches one of them, exactly. Again, based on the discussion, this is not useful or necessary for 800 numbers or service routing - this is effectively to prevent a PBX extension that 'escaped' its context to be used somewhere out of scope (a Harvard extension within Columbia, say, or the internal Belgian/Japanese NNI service number that a few people mentioned). Any geographic scope should be in something like caller preferences. Scott Bradner wrote: > >- Context: this number can only be interpreted by first routing the call > >to this context, and the interpreting it there > > > not sure that is enough if the context is geographic since the > "first routing node" may be half the world away > > Scott > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Dec 3 08:26:46 2002 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 IAA18515 for ; Tue, 3 Dec 2002 08:26:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3DT7j07063 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 08:29:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DT7v07060 for ; Tue, 3 Dec 2002 08:29:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18482 for ; Tue, 3 Dec 2002 08:26:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DT1v07046; Tue, 3 Dec 2002 08:29:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DSGv07003 for ; Tue, 3 Dec 2002 08:28:16 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18468 for ; Tue, 3 Dec 2002 08:25:24 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3DSDl8003428 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 3 Dec 2002 08:28:13 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3DSBdG026910 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Dec 2002 08:28:12 -0500 (EST) Message-ID: <3DECB0EB.501@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexeitsev, D" CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis 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: Tue, 03 Dec 2002 08:26:03 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexeitsev, D wrote: > Hello All, > > Just a few questions, comments for my clarification: > > The main scope of the tel URI is the publication on the web pages, how No, it's not - that's just one. Its main scope is the identification of termination points identified by E.164 numbers. It could just as well appear in the From or To of a SIP message, for example. > this URI is used by the SIP UAs (mail agents, ...) i.e. if it is > converted to the SIP URI by adding the default outgoing proxy address > as hostportion is out of scope for this document. > > Coming from the use scope the entities that tel URI will identify will > be only those that are available to the regular telephone subscribers > i.e. geographical nongeographical and service numbers, but not the > network internal numbers that are not allowed for subscribers to dial > anyway (hex digits, ...) Local numbers can indeed have these hex digits. > > > If it is true then there is no need to allow the use of hex digits, if > the scope is more then just the numbers that are allowed for > subscribers input, then the 4 bit space for address digits as defined > in Q.763 must be preserved. Given the identifier role, I'm a bit reluctant to rule out the full 4-bit space (hex digits). Since this is just an identifier, I see no harm in having tel:+1-201-ABC-1234 (where A, B, C are the hex digits, not digits on your dialpad). The only drawback I can see in practice is that this will indeed be confused with the 1-800-AAA-4357 style. > > > Greetings, > Denis Alexeitsev > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Dec 3 08:33:46 2002 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 IAA18896 for ; Tue, 3 Dec 2002 08:33:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3Da7L07542 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 08:36:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Da7v07539 for ; Tue, 3 Dec 2002 08:36:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18851 for ; Tue, 3 Dec 2002 08:33:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Da3v07525; Tue, 3 Dec 2002 08:36:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DZFv07485 for ; Tue, 3 Dec 2002 08:35:15 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18792 for ; Tue, 3 Dec 2002 08:32:23 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3DZ6l8003882 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 3 Dec 2002 08:35:06 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3DZ4dG027333 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Dec 2002 08:35:05 -0500 (EST) Message-ID: <3DECB288.40102@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Scott Bradner , rohan@cisco.com, iptel@ietf.org Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion References: <200211301954.gAUJsNn6022405@newdev.harvard.edu> <3DE91AF0.6050209@cs.columbia.edu> <3DEC648C.6010105@dynamicsoft.com> In-Reply-To: <200211301954.gAUJsNn6022405@newdev.harvard.edu> 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, 03 Dec 2002 08:32:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > - Context = 'resolve this identifier under this context' > > (;context=+1-212-939-7000 = Pizza Hut as if dialed from 212-939-7000) > > > I believe this is out of scope. We are not trying to direct routing. I hope not. > > > > > > - Context = 'this number is only valid if dialed from this context; > > it's an error otherwise' (the number may still reach something or > > other, but it's not the intended destination) > > > This is what I believe we are talking about. At least that's what I've been trying to get at :-) > > > I thought I heard someone suggest another usage during the meeting, to > support things like VPNs: > > - Context: this number can only be interpreted by first routing the call > to this context, and the interpreting it there > > For example, if a company has a PBX without DID, and its number is 973 > 555 1234, I would reach extension 33 this way: > > tel:33;context="+19735551234" > > THis is similar in concept to relative URI references. > > I don't think this is in scope either, and so perhaps I misinterpreted > what was said during the iptel meeting. If someone does think we are > supporting this, please speak up. At least in the past, we've explicitly ruled this out since the context is insufficient to get to that destination. (This is particularly true for domain names.) From what I can tell, anything but a simple binary decision answering "can I process this URI" is going to be too brittle for use or too constrained in its functionality. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 08:37:45 2002 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 IAA19049 for ; Tue, 3 Dec 2002 08:37:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3De6G08449 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 08:40:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3De6v08446 for ; Tue, 3 Dec 2002 08:40:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19027 for ; Tue, 3 Dec 2002 08:37:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3De2v08430; Tue, 3 Dec 2002 08:40:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DdFv08357 for ; Tue, 3 Dec 2002 08:39:15 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18983 for ; Tue, 3 Dec 2002 08:36:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: AW: [Iptel] comments on rfc2806bis MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-ID: <06CF906FE3998C4E944213062009F1620DEE2B@oefeg-s02.oefeg.loc> Thread-Topic: [Iptel] comments on rfc2806bis Thread-Index: AcKaw74bBgvGC8/vTZ+AUAnw1WCXBwADUQB2 From: "Stastny Richard" To: "Alexeitsev, D" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gB3DdFv08358 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, 3 Dec 2002 14:42:19 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, from my understanding the tel: URI scheme will be used mainly in at least 3 environments: -on a web-page, as you mention, -in SIP messages, ev. with the yu-extensions -in ENUM NAPTRs, also with the yu extensions and maybe others. all three environments may have different requirements. in the latter environments, you may need hex-digits, e.g. for routing numbers regards Richad -----Urspr체ngliche Nachricht----- Von: Alexeitsev, D [mailto:D.Alexeitsev@telekom.de] Gesendet: Di 03.12.2002 12:54 An: iptel@ietf.org Cc: Betreff: [Iptel] comments on rfc2806bis Hello All, Just a few questions, comments for my clarification: The main scope of the tel URI is the publication on the web pages, how this URI is used by the SIP UAs (mail agents, ...) i.e. if it is converted to the SIP URI by adding the default outgoing proxy address as hostportion is out of scope for this document. Coming from the use scope the entities that tel URI will identify will be only those that are available to the regular telephone subscribers i.e. geographical nongeographical and service numbers, but not the network internal numbers that are not allowed for subscribers to dial anyway (hex digits, ...) If it is true then there is no need to allow the use of hex digits, if the scope is more then just the numbers that are allowed for subscribers input, then the 4 bit space for address digits as defined in Q.763 must be preserved. Greetings, Denis Alexeitsev _______________________________________________ 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 mailnull@www1.ietf.org Tue Dec 3 08:59:46 2002 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 IAA20307 for ; Tue, 3 Dec 2002 08:59:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3E27i09858 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 09:02:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3E27v09855 for ; Tue, 3 Dec 2002 09:02:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20257 for ; Tue, 3 Dec 2002 08:59:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3E22v09845; Tue, 3 Dec 2002 09:02:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3E1Tv09781 for ; Tue, 3 Dec 2002 09:01:29 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20210 for ; Tue, 3 Dec 2002 08:58:37 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 3 Dec 2002 15:01:01 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 15:01:00 +0100 Message-Id: From: "Alexeitsev, D" To: hgs@cs.columbia.edu Cc: iptel@ietf.org Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 3 Dec 2002 15:00:51 +0100 Thanks for the answer, comments inline: >Given the identifier role, I'm a bit reluctant to rule out the full >4-bit space (hex digits). Since this is just an identifier, I see no >harm in having > >tel:+1-201-ABC-1234 > >(where A, B, C are the hex digits, not digits on your dialpad). The only >drawback I can see in practice is that this will indeed be confused with >the 1-800-AAA-4357 style. [DA] Yes I would definitely support having the possibility to transfer hex digits even if they are not considered to be a part of the E.164 numbering space. The only issue I see here is that this kind of digits are not allowed for the end subscribers to dial, thus the tel:+1-201-ABC-1234 will never result in a successful call when placed on the web page and will success if used inside of the network. But this brings us back to the issue of unique against dialable. B.t.w I agree that it is not a problem if 1-800-AAA-4357 is used, as the actual tel: URI will be valid. Greetings, Denis Alexeitsev _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 09:20:48 2002 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 JAA21480 for ; Tue, 3 Dec 2002 09:20:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3EN9B11511 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 09:23:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3EN9v11508 for ; Tue, 3 Dec 2002 09:23:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21439 for ; Tue, 3 Dec 2002 09:20:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3EN3v11499; Tue, 3 Dec 2002 09:23:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3EMuv11475 for ; Tue, 3 Dec 2002 09:22:56 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21432 for ; Tue, 3 Dec 2002 09:20:03 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 3 Dec 2002 15:21:02 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 15:21:01 +0100 Message-Id: From: "Alexeitsev, D" To: Richard.Stastny@oefeg.at Cc: iptel@ietf.org Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" 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, 3 Dec 2002 15:21:01 +0100 Thanks for answer, comments inline >from my understanding the tel: URI scheme will be used mainly in at least 3 environments: >-on a web-page, as you mention, > >-in SIP messages, ev. with the yu-extensions > >-in ENUM NAPTRs, also with the yu extensions and maybe others. > >all three environments may have different requirements. [DA] I think is it a very valid consideration that people are putting different requirements on tel: URI from the perspective of future environment. >in the latter environments, you may need hex-digits, e.g. for routing numbers [DA]Yes that is what I was trying to reference by "if the scope is more then just the numbers that are allowed for subscribers input, then the 4 bit space for address digits as defined in Q.763 must be preserved" If the later environments are considered to be in the scope (I hope so) then I believe that the uniqueness of the hex digits in routing numbers may require additional considerations as the different service providers working inside one national numbering plan may independently reuse the same routing number. But if in the case of routing numbers tel URI with hex digits stays inside service providers domain then the uniqueness requirement is fulfilled. Greetings, Denis Alexeitsev _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 10:28:24 2002 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 KAA26179 for ; Tue, 3 Dec 2002 10:28:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3FUkc17696 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 10:30:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3FUkv17693 for ; Tue, 3 Dec 2002 10:30:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26125 for ; Tue, 3 Dec 2002 10:27:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3FUav17665; Tue, 3 Dec 2002 10:30:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3FTtv17561 for ; Tue, 3 Dec 2002 10:29:55 -0500 Received: from imo-r03.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26101 for ; Tue, 3 Dec 2002 10:27:02 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r03.mx.aol.com (mail_out_v34.13.) id 7.6e.26e99a1d (657); Tue, 3 Dec 2002 10:29:28 -0500 (EST) Message-ID: <6e.26e99a1d.2b1e27d7@aol.com> Subject: Re: [Iptel] comments on rfc2806bis - grammar To: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com CC: iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_6e.26e99a1d.2b1e27d7_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 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, 3 Dec 2002 10:29:27 EST --part1_6e.26e99a1d.2b1e27d7_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/2/2002 10:33:44 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > Unfortunately, I don't see how I can specify 'at most one isub, but can > appear anywhere' while specifying a single context. You'd have to > enumerate all combinations, as in > > *par [isdn-subaddress] *par context *par > *par context *par [isdn-subaddress] > > Any other ideas? > [MAP] Guess I'm totally confused by this. Whatever ABN we end up with, it seems that it must include no more than one ISDN subadress. I don't understand this point of it appearing in different places and being related to the context. I would think that there are two separate things: "isub= " and "phone-context = " and they each may appear once and in either order. Mike Pierce Artel --part1_6e.26e99a1d.2b1e27d7_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/2/2002 10:33:44 PM Eastern Standard Time, hgs@cs.columbia.edu writes:


Unfortunately, I don't see how I can specify 'at most one isub, but can
appear anywhere' while specifying a single context. You'd have to
enumerate all combinations, as in

*par [isdn-subaddress] *par context *par
*par context *par [isdn-subaddress]

Any other ideas?



[MAP] Guess I'm totally confused by this. Whatever ABN we end up with, it seems that it must include no more than one ISDN subadress. I don't understand this point of it appearing in different places and being related to the context. I would think that there are two separate things: "isub= " and "phone-context = " and they each may appear once and in either order.

Mike Pierce
Artel --part1_6e.26e99a1d.2b1e27d7_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 10:40:45 2002 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 KAA27274 for ; Tue, 3 Dec 2002 10:40:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3Fh7G19466 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 10:43:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Fh7v19463 for ; Tue, 3 Dec 2002 10:43:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27229 for ; Tue, 3 Dec 2002 10:40:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Fh2v19450; Tue, 3 Dec 2002 10:43:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Fgmv19420 for ; Tue, 3 Dec 2002 10:42:48 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27217 for ; Tue, 3 Dec 2002 10:39:55 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3Fgil8022605 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 3 Dec 2002 10:42:45 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3FghdG007789 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Dec 2002 10:42:44 -0500 (EST) Message-ID: <3DECD072.4090405@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis - grammar References: <6e.26e99a1d.2b1e27d7@aol.com> In-Reply-To: <6e.26e99a1d.2b1e27d7@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Dec 2002 10:40:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We've had a similar discussion in the SIP WG. ABNF is not sufficient to completely describe all legal (or illegal) patterns. In particular, expressing 'at most once, in any order' is not easily expressible in ABNF (for more than one item). If you have a suggestion, please offer it. The only way I have found is to enumerate all combinations, which quickly gets ouf of hand, as in context isub ext | context ext isub | ext context isub | ... with *par sprinkled in between each element. This is probably barely manageable for our current set of known parameters (;phone-context ;isub ;ext), but this will fail if another draft adds another one (say, ;cic). Mpierce1@aol.com wrote: > In a message dated 12/2/2002 10:33:44 PM Eastern Standard Time, > hgs@cs.columbia.edu writes: > > > > Unfortunately, I don't see how I can specify 'at most one isub, but can > > appear anywhere' while specifying a single context. You'd have to > > enumerate all combinations, as in > > > > *par [isdn-subaddress] *par context *par > > *par context *par [isdn-subaddress] > > > > Any other ideas? > > > > > [MAP] Guess I'm totally confused by this. Whatever ABN we end up with, > it seems that it must include no more than one ISDN subadress. I don't > understand this point of it appearing in different places and being > related to the context. I would think that there are two separate > things: "isub= " and "phone-context = " and they each may appear once > and in either order. > > Mike Pierce > Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 11:10:51 2002 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 LAA29736 for ; Tue, 3 Dec 2002 11:10:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3GDC122178 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 11:13:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GDCv22175 for ; Tue, 3 Dec 2002 11:13:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29711 for ; Tue, 3 Dec 2002 11:10:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GD6v22160; Tue, 3 Dec 2002 11:13:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GCNv22124 for ; Tue, 3 Dec 2002 11:12:23 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29678 for ; Tue, 3 Dec 2002 11:09:31 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3GCIl8025198 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 3 Dec 2002 11:12:18 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3GCGdG010372 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Dec 2002 11:12:17 -0500 (EST) Message-ID: <3DECD75F.2050701@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis References: <3DD9D7A5.5040503@dynamicsoft.com> In-Reply-To: <3DD9D7A5.5040503@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Dec 2002 11:10:07 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > All phone numbers MUST use the global form unless they cannot be > > represented as such. > > > isnt this the same as saying "SHOULD use the global form"? Almost; it explicitly states the (only) condition under which local form is allowed. SHOULD would seem to imply a more relaxed version. > > > > Implementations MUST NOT assume that telephone numbers have a > > maximum, minimum or fixed length, or that they always begin with a > > certain number. > > > For global numbers, I certainly can assume a maximum length of 15, as > that is the constraint in the BNF. I think you should say "local > numbers" instead of telephone numbers. I've removed the constraint from the BNF. As was pointed out, it couldn't deal with the visual separators. Given visual separators, the length becomes unbounded. Something like tel:+1-----------201.........(((((555)))))))1234 is odd, but legal according to the current BNF. (I've now rewritten the BNF so that each digit can be followed by at most one visual separator. Is there any reason to have more than that? This would limit the length to 30.) > > > > Phone numbers MAY contain visual separators. Visual separators > > () merely aid readability and MUST be ignored by > > the client. > > > What does "ignored" mean? There needs to be some defined semantic > operations in which to ignore them. I ask the question above if > comparison qualifies... Now, comparison explicitly discards the separators. > > > > Even though ITU-T E.123 [8] recommends the use of space characters as > > visual separators in printed telephone numbers, tel URIs MUST NOT use > > spaces. > > > The BNF clearly disallows spaces as part of the phone number itself, so > having a MUST NOT here seems redundant. Does this mean I can't have > escaped spaces as part of a parameter value? That is allowed by the BNF. I suppose we can allow %20 spaces as visual separators. Is there value in that? _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 11:19:34 2002 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 LAA00261 for ; Tue, 3 Dec 2002 11:19:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3GLt422961 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 11:21:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GLtv22958 for ; Tue, 3 Dec 2002 11:21:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00235 for ; Tue, 3 Dec 2002 11:19:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GLfv22942; Tue, 3 Dec 2002 11:21:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GIOv22647 for ; Tue, 3 Dec 2002 11:18:24 -0500 Received: from imo-r06.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00073 for ; Tue, 3 Dec 2002 11:15:32 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r06.mx.aol.com (mail_out_v34.13.) id c.65.36c2f9a (16484); Tue, 3 Dec 2002 11:17:20 -0500 (EST) Message-ID: <65.36c2f9a.2b1e330f@aol.com> To: fluffy@cisco.com, hgs@cs.columbia.edu CC: iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_65.36c2f9a.2b1e330f_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Subject: [Iptel] Re: Tel URI and 411 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, 3 Dec 2002 11:17:19 EST --part1_65.36c2f9a.2b1e330f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/3/2002 1:44:35 AM Eastern Standard Time, fluffy@cisco.com writes: > > That still leaves unclear the use of "context" for local dialing > > "prefixs" and "codes" lilke 0, 911, 411, etc. That requires another > > discussion line. > > I think either > tel:911;context=+1 or > tel:+1-911 > would work, semantically. I suspect the former will elicit fewer groans. > [fluffy] We could consider something like 411 a user interface mnemonic that you dial to get a common service. On my cell phone 411 gets me a service that refuses to tell me the phone number of subscribers to the same cellular service and is perfectly happy to make restaurant reservation for me and give me driving instructions. Go figure. [MAP] If we continue to have to deal with every type of dialing scheme in a unique fashion, then there is no end to this. I would presume that 411 and 911 have to be handled exactly the same way in a tel:url. (As well as all the other N11 codes). There needs to be one way to deal with any locally dialed code that the end user expects to result in routing to somewhere, when that code can not be represented as a global (E.164) number and is not a "local-number" (within a private dialing plan). This set of codes are ones which are always routed based on the location of originator, and often based on the service provider (your cell phone example). What about #77 which routes to the Maryland Highway Patrol (on a cell phone only), and I think something like #ABC which routes to the local TV station but only on Verizon mobile phones, and I think people can identify hundreds of others. All of these non-E164/non local-number cases need to be handled in one way: without an E.164 county code "prefix" and without a "context". Both of these are meaningless in this case (unless "context" is taken to mean another way to provide a way to identify the originator - see previous e-mails). Mike Pierce Artel --part1_65.36c2f9a.2b1e330f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/3/2002 1:44:35 AM Eastern Standard Time, fluffy@cisco.com writes:


> > That still leaves unclear the use of "context" for local dialing
> > "prefixs" and "codes" lilke 0, 911, 411, etc. That requires another
> > discussion line.
>
> I think either
> tel:911;context=+1 or
> tel:+1-911
> would work, semantically. I suspect the former will elicit fewer groans.
>

[fluffy] We could consider something like 411 a user interface mnemonic that you dial
to get a common service. On my cell phone 411 gets me a service that refuses
to tell me the phone number of subscribers to the same cellular service and
is perfectly happy to make restaurant reservation for me and give me driving
instructions. Go figure.


[MAP] If we continue to have to deal with every type of dialing scheme in a unique fashion, then there is no end to this. I would presume that 411 and 911 have to be handled exactly the same way in a tel:url. (As well as all the other N11 codes). There needs to be one way to deal with any locally dialed code that the end user expects to result in routing to somewhere, when that code can not be represented as a global (E.164) number and is not a "local-number" (within a private dialing plan). This set of codes are ones which are always routed based on the location of originator, and often based on the service provider (your cell phone example). What about #77 which routes to the Maryland Highway Patrol (on a cell phone only), and I think something like #ABC which routes to the local TV station but only on Verizon mobile phones, and I think people can identify hundreds of others.

All of these non-E164/non local-number cases need to be handled in one way: without an E.164 county code "prefix" and without a "context". Both of these are meaningless in this case (unless "context" is taken to mean another way to provide a way to identify the originator - see previous e-mails).

Mike Pierce
Artel
--part1_65.36c2f9a.2b1e330f_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 12:15:45 2002 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 MAA03897 for ; Tue, 3 Dec 2002 12:15:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3HI7228607 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 12:18:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HI6v28604 for ; Tue, 3 Dec 2002 12:18:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03858 for ; Tue, 3 Dec 2002 12:15:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HI1v28563; Tue, 3 Dec 2002 12:18:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HGDv28417 for ; Tue, 3 Dec 2002 12:16:13 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03666 for ; Tue, 3 Dec 2002 12:13:20 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3HG8l8003137 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 3 Dec 2002 12:16:08 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3HG6dG016097 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 3 Dec 2002 12:16:07 -0500 (EST) Message-ID: <3DECE655.3080305@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Iptel] Preliminary version of 2806bis 07 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 Dec 2002 12:13:57 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-07.txt Last minute comments are appreciated; I plan to submit it to the I-D editor later today. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 12:19:48 2002 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 MAA04176 for ; Tue, 3 Dec 2002 12:19:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3HMAs29105 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 12:22:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HMAv29102 for ; Tue, 3 Dec 2002 12:22:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04135 for ; Tue, 3 Dec 2002 12:19:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HM2v29059; Tue, 3 Dec 2002 12:22:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HLCv28977 for ; Tue, 3 Dec 2002 12:21:12 -0500 Received: from imo-r04.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04091 for ; Tue, 3 Dec 2002 12:18:19 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r04.mx.aol.com (mail_out_v34.13.) id 7.141.40e1b6d (25508); Tue, 3 Dec 2002 12:20:47 -0500 (EST) Message-ID: <141.40e1b6d.2b1e41ef@aol.com> Subject: [Iptel] comments on rfc2806bis - separators To: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com CC: iptel@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 6.0 for Windows XP US sub 51 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, 3 Dec 2002 12:20:47 EST Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In a message dated 12/3/2002 11:13:48 AM Eastern Standard Time, hgs@cs.columbia.edu writes: I've removed the constraint from the BNF. As was pointed out, it couldn't deal with the visual separators. Given visual separators, the length becomes unbounded. Something like tel:+1-----------201.........(((((555)))))))1234 is odd, but legal according to the current BNF. (I've now rewritten the BNF so that each digit can be followed by at most one visual separator. Is there any reason to have more than that? This would limit the length to 30.) [MAP] This goes back to the question of what the tel:uri is used for. The inclusion of visual separators seems to assume that it is intended as something which the human user will enter or see, which may have been the original idea. With the addition of other things, I think we have gone beyond this and should assume that it is not primarly for (easy) human understanding. That would allow us to remove any visual separators from the tel:uri. It would be recognized that a user interface could allow a user to enter visual separators including spaces (e.g., on a keyboard) and display them, but just not include them in the tel:uri it sends. Likewise, a user could type in letters and have them converted to numbers to go in the tel:uri. When receiving a tel:uri (without visual separators) the user interface could add them in for display if it understands the local dial plan. (Off hand, I can't think of a use of the tel:uri in which it would need to display what it receives, but I suppose there could be some.) Elimination of the visual separators would certainly simplify this whole thing. Mike Pierce Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 12:19:51 2002 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 MAA04189 for ; Tue, 3 Dec 2002 12:19:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3HMDa29120 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 12:22:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HMDv29117 for ; Tue, 3 Dec 2002 12:22:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04151 for ; Tue, 3 Dec 2002 12:19:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HM3v29079; Tue, 3 Dec 2002 12:22:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HLNv28993 for ; Tue, 3 Dec 2002 12:21:23 -0500 Received: from imo-r03.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04095 for ; Tue, 3 Dec 2002 12:18:31 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r03.mx.aol.com (mail_out_v34.13.) id 7.18c.122da9a2 (25508); Tue, 3 Dec 2002 12:20:46 -0500 (EST) Message-ID: <18c.122da9a2.2b1e41ed@aol.com> Subject: Re: [Iptel] comments on rfc2806bis - grammar To: hgs@cs.columbia.edu CC: iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_18c.122da9a2.2b1e41ed_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 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, 3 Dec 2002 12:20:45 EST --part1_18c.122da9a2.2b1e41ed_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/3/2002 10:43:04 AM Eastern Standard Time, hgs@cs.columbia.edu writes: > We've had a similar discussion in the SIP WG. ABNF is not sufficient to > completely describe all legal (or illegal) patterns. In particular, > expressing > > 'at most once, in any order' > > is not easily expressible in ABNF (for more than one item). If you have > a suggestion, please offer it. The only way I have found is to enumerate > all combinations, which quickly gets ouf of hand, as in > > context isub ext | context ext isub | ext context isub | ... > > with *par sprinkled in between each element. This is probably barely > manageable for our current set of known parameters (;phone-context ;isub > ;ext), but this will fail if another draft adds another one (say, ;cic). > [MAP] Then why are we using ABNF and spending so much time on it if it is "not sufficient"? If it is a choice between explicitly showing the order or explicitly showing that a parameter can occur only once, I would opt for the latter. I certainly would not expect to see this complication in the ABNF if the only purpose is to say that different orders are okay. And, as you say, adding another paramter would be a worse mess. In fact, why not specify the order? I don't have a suggestion, since I think I've lost sight of what it is we're trying to do. Based on a number of comments, I think we need to step back and re-assess what the purpose of all this is. Richard Stastny had a list of uses of the tel:uri as: -on a web-page -in SIP messages, ev. with the yu-extensions -in ENUM NAPTRs, also with the yu extensions and maybe others. And he noted that all three may have different requirements. (Like I would not expect a "local-number" or 911 or visual separators to ever be in a NAPTR.) Are there other uses? MIke Pierce Artel --part1_18c.122da9a2.2b1e41ed_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/3/2002 10:43:04 AM Eastern Standard Time, hgs@cs.columbia.edu writes:


We've had a similar discussion in the SIP WG. ABNF is not sufficient to
completely describe all legal (or illegal) patterns. In particular,
expressing

'at most once, in any order'

is not easily expressible in ABNF (for more than one item). If you have
a suggestion, please offer it. The only way I have found is to enumerate
all combinations, which quickly gets ouf of hand, as in

context isub ext | context ext isub | ext context isub | ...

with *par sprinkled in between each element. This is probably barely
manageable for our current set of known parameters (;phone-context ;isub
;ext), but this will fail if another draft adds another one (say, ;cic).



[MAP] Then why are we using ABNF and spending so much time on it if it is "not sufficient"?

If it is a choice between explicitly showing the order or explicitly showing that a parameter can occur only once, I would opt for the latter.

I certainly would not expect to see this complication in the ABNF if the only purpose is to say that different orders are okay. And, as you say, adding another paramter would be a worse mess. In fact, why not specify the order?

I don't have a suggestion, since I think I've lost sight of what it is we're trying to do. Based on a number of comments, I think we need to step back and re-assess what the purpose of all this is. Richard Stastny had a list of uses of the tel:uri as:

-on a web-page
-in SIP messages, ev. with the yu-extensions
-in ENUM NAPTRs, also with the yu extensions and maybe others.

And he noted that all three may have different requirements. (Like I would not expect a "local-number" or 911 or visual separators to ever be in a NAPTR.)

Are there other uses?

MIke Pierce
Artel
--part1_18c.122da9a2.2b1e41ed_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 12:36:49 2002 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 MAA05257 for ; Tue, 3 Dec 2002 12:36:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3HdBj30606 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 12:39:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HdBv30603 for ; Tue, 3 Dec 2002 12:39:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05227 for ; Tue, 3 Dec 2002 12:36:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Hd4v30591; Tue, 3 Dec 2002 12:39:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HcDv30530 for ; Tue, 3 Dec 2002 12:38:13 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05106 for ; Tue, 3 Dec 2002 12:35:20 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3Hc7l8006171 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 3 Dec 2002 12:38:07 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3Hc6dG017857 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Dec 2002 12:38:06 -0500 (EST) Message-ID: <3DECEB7C.3020700@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis - grammar References: <18c.122da9a2.2b1e41ed@aol.com> In-Reply-To: <18c.122da9a2.2b1e41ed@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Dec 2002 12:35:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [MAP] Then why are we using ABNF and spending so much time on it if it > is "not sufficient"? Because URIs are specified with ABNF :-) Nothing is perfect - lots of constraints can't be captured at the BNF level, but that doesn't make BNF useless. > I certainly would not expect to see this complication in the ABNF if the > only purpose is to say that different orders are okay. And, as you say, > adding another paramter would be a worse mess. In fact, why not specify > the order? I have no objection to specifying a fixed order. It would differ from the SIP URI "tradition", but this flexibility seems to add little real value. The only real problem is that parameters that we add later need to reference all other extension parameters, to maintain that order. I guess the 'order number' could be part of the IANA registration. > Are there other uses? I'm sure sooner or later H.323 will pick it up, too. It will just take a few years :-) > > > MIke Pierce > Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 12:42:58 2002 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 MAA05674 for ; Tue, 3 Dec 2002 12:42:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3HjK831147 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 12:45:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HjKv31144 for ; Tue, 3 Dec 2002 12:45:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05601 for ; Tue, 3 Dec 2002 12:42:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Hj5v31128; Tue, 3 Dec 2002 12:45:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HiEv31067 for ; Tue, 3 Dec 2002 12:44:14 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05535 for ; Tue, 3 Dec 2002 12:41:16 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3Hhql8007640 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 3 Dec 2002 12:43:53 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3HhpdG018316 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Dec 2002 12:43:52 -0500 (EST) Message-ID: <3DECECD5.3050804@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis - separators References: <141.40e1b6d.2b1e41ef@aol.com> In-Reply-To: <141.40e1b6d.2b1e41ef@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Dec 2002 12:41:41 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm all for simplification. The only real reason is that the receiver may not really know how to render, say, a tel: URI contained in a SIP request. If a US-English UA gets a European number, it likely has no clue what part is the area code and what part is the subscriber number. (Indeed, in that case, even a smart UI would have real difficulty discerning the two parts, given that area codes are variable-length.) As long as people do From: +49 (2232) 12345 this may not be a big deal. The specification complexity is pretty modest - one additional line of BNF. The main drawback of visual separators is in URI comparison - a byte-by-byte comparison may yield inequality, while a URI-aware comparison (and a normal human user) would detect equality after stripping the visual separators. > > It would be recognized that a user interface could allow a user to enter > visual separators including spaces (e.g., on a keyboard) and display > them, > but just not include them in the tel:uri it sends. Likewise, a user could > type in letters and have them converted to numbers to go in the > tel:uri. When > receiving a tel:uri (without visual separators) the user interface > could add > them in for display if it understands the local dial plan. (Off hand, > I can't > think of a use of the tel:uri in which it would need to display what it > receives, but I suppose there could be some.) > > Elimination of the visual separators would certainly simplify this whole > thing. > > Mike Pierce > Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 13:11:00 2002 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 NAA07167 for ; Tue, 3 Dec 2002 13:11:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3IDN101196 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 13:13:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3IDNv01193 for ; Tue, 3 Dec 2002 13:13:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07111 for ; Tue, 3 Dec 2002 13:10:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3IDEv01173; Tue, 3 Dec 2002 13:13:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3ICZv01114 for ; Tue, 3 Dec 2002 13:12:35 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07054 for ; Tue, 3 Dec 2002 13:09:41 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB3ICQYH011367; Tue, 3 Dec 2002 13:12:26 -0500 (EST) Message-ID: <3DECF404.6030707@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Mpierce1@aol.com, iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis - grammar References: <18c.122da9a2.2b1e41ed@aol.com> <3DECEB7C.3020700@cs.columbia.edu> 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, 03 Dec 2002 13:12:20 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is not the opportunity to revisit the way in which we are encoding parameters in URIs. To date, the ordering was not fixed, and it was up to the semantic text to tell you that you should have only one instance of a parameter. Let us stick with that and move on. -Jonathan R. Henning Schulzrinne wrote: > >> [MAP] Then why are we using ABNF and spending so much time on it if it >> is "not sufficient"? > > > > Because URIs are specified with ABNF :-) Nothing is perfect - lots of > constraints can't be captured at the BNF level, but that doesn't make > BNF useless. > >> I certainly would not expect to see this complication in the ABNF if the >> only purpose is to say that different orders are okay. And, as you say, >> adding another paramter would be a worse mess. In fact, why not specify >> the order? > > > > I have no objection to specifying a fixed order. It would differ from > the SIP URI "tradition", but this flexibility seems to add little real > value. The only real problem is that parameters that we add later need > to reference all other extension parameters, to maintain that order. I > guess the 'order number' could be part of the IANA registration. > >> Are there other uses? > > > > I'm sure sooner or later H.323 will pick it up, too. It will just take a > few years :-) > >> >> >> MIke Pierce >> Artel > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www.ietf.org/mailman/listinfo/iptel > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Tue Dec 3 14:39:53 2002 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 OAA12577 for ; Tue, 3 Dec 2002 14:39:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3JgGG08765 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 14:42:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3JgGv08762 for ; Tue, 3 Dec 2002 14:42:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12566 for ; Tue, 3 Dec 2002 14:39:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Jg5v08746; Tue, 3 Dec 2002 14:42:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Jfhv08701 for ; Tue, 3 Dec 2002 14:41:43 -0500 Received: from imo-r10.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12556 for ; Tue, 3 Dec 2002 14:38:48 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r10.mx.aol.com (mail_out_v34.13.) id 7.46.31de24ca (4394); Tue, 3 Dec 2002 14:41:14 -0500 (EST) Message-ID: <46.31de24ca.2b1e62da@aol.com> Subject: Re: [Iptel] Preliminary version of 2806bis 07 To: hgs@cs.columbia.edu, iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_46.31de24ca.2b1e62da_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 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, 3 Dec 2002 14:41:14 EST --part1_46.31de24ca.2b1e62da_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Comments: Nits/minor: 5.3 States that "At most one of the and parameters can appear in a tel URI." SInce this apparently means one of each, as indicated after the ABNF, then suggest wording the above "At most one of the and one of the parameters ..." 5.1.4 final sentence: Reword as "If it is not within the same context, it MUST NOT initiate the call and MUST treat the URI like an invalid destination." Use of the word "prefix". Since this has a very specific meaning in E.164 (as noted in 7.4), several uses in 5.1.4 of this draft should be changed to avoid confusion as follows: 4th para starting with "There are two ways ..." in first sentence modify first way to read "via a full global number or any number of its leading digits (e.g., "=33") and ..." 6th para starting with "A global number context..." modify 2nd and 3rd sentences as follows: "All global numbers matching these initial digits must be assigned to the same organization that is describing the context and no such matching number can be used by any other organization. If such an initial string of digits does not exist, .." 7th para: change final word "prefix" to "initial set of digits". 8th para starting with "For a local number..." in final sentence about TU Damstadt, change "prefix" to "context". 10th para: Change begin of 1st sentence to "A context consisting of the initial digits of a global number does not imply ..." ------------------------------------------------------------------------------ ----------------------- Major comment: The draft sufficiently covers the cases of global (E.164) numbers and local (private dialing plan) numbers. However, I continue to be concerned with the representation of special numbers such as 911, 411, etc as "local numbers" with a context made up of "+" and a country code plus possibly additional digits. I am not satisfied with the resolution of this issue which I began to raise last May on the SIPPING list. There needs to be a distinct uri format defined to carry these and other special dialing plan numbers which are not a part of the E.164 plan. They need to be handled differently than "local numbers", which are generally described in this draft to be the equivalent of private dialing plan numbers (PBX extension without direct inward dialing which are also not part of the E.164 numbers). These special numbers do not require a "context", at least, not in the same way as "local (private) numbers". Consider the following: tel:411;phone-context=+1-410-817-2000 This could be a call to 411 (local information) from the telephone number 410-817-2000 or it could be a call to extension 411 located within the PBX which decided to use the context 1-410-817-2000. (Either of these is allowed by the draft.) The format of the tel:uri should not be such that the interpretation is ambiguous. I believe that SIP-ISUP interworking (recently approved as an RFC) would require the ability to be able to distinguish these two cases, since they must be mapped into ISUP differently. Calls to 911, 411, 0, etc should not ever need a context. Their routing is always based on the number dialed plus information concerning the location (or identity) of the originator. The destination does not require a "context" to "verify that it is within the same context" as the call to private numbers do. If the "context" is intended to specify the identity of the originator, there are already other parameters to do this. If the "context" is intended to specify the area covered by the desired destination (for routing or verification), then it would require more than a country code (as shown in the example in the draft). There is no known number sequence which could represent what is needed for this purpose. Definition of a 3rd format for such special numbers would include support for other locally dialable numbers such as #77, 0, 011 which have not been described. Mike Pierce Artel --part1_46.31de24ca.2b1e62da_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit Comments:

Nits/minor:

5.3 States that "At most one of the <isdn-subaddress> and <extension> parameters can appear in a tel URI." SInce this apparently means one of each, as indicated after the ABNF, then suggest wording the above "At most one of the <isdn-subaddress> and one of the <extension> parameters ..."

5.1.4 final sentence: Reword as "If it is not within the same context, it MUST NOT initiate the call and MUST treat the URI like an invalid destination."

Use of the word "prefix". Since this has a very specific meaning in E.164 (as noted in 7.4), several uses in 5.1.4 of this draft should be changed to avoid confusion as follows:

4th para starting with "There are two ways ..." in first sentence modify first way to read "via a full global number or any number of its leading digits (e.g., "=33") and ..."

6th para starting with "A global number context..." modify 2nd and 3rd sentences as follows: "All global numbers matching these initial digits must be assigned to the same organization that is describing the context and no such matching number can be used by any other organization. If such an initial string of digits does not exist, .."

7th para: change final word "prefix" to "initial set of digits".

8th para starting with "For a local number..." in final sentence about TU Damstadt, change "prefix" to "context".

10th para: Change begin of 1st sentence to "A context consisting of the initial digits of a global number does not imply ..."

-----------------------------------------------------------------------------------------------------

Major comment:

The draft sufficiently covers the cases of global (E.164) numbers and local (private dialing plan) numbers. However, I continue to be concerned with the representation of special numbers such as 911, 411, etc as "local numbers" with a context made up of "+" and a country code plus possibly additional digits. I am not satisfied with the resolution of this issue which I began to raise last May on the SIPPING list. There needs to be a distinct uri format defined to carry these and other special dialing plan numbers which are not a part of the E.164 plan. They need to be handled differently than "local numbers", which are generally described in this draft to be the equivalent of private dialing plan numbers (PBX extension without direct inward dialing which are also not part of the E.164 numbers). These special numbers do not require a "context", at least, not in the same way as "local (private) numbers".

Consider the following:
tel:411;phone-context=+1-410-817-2000

This could be a call to 411 (local information) from the telephone number 410-817-2000 or it could be a call to extension 411 located within the PBX which decided to use the context 1-410-817-2000. (Either of these is allowed by the draft.) The format of the tel:uri should not be such that the interpretation is ambiguous. I believe that SIP-ISUP interworking (recently approved as an RFC) would require the ability to be able to distinguish these two cases, since they must be mapped into ISUP differently.

Calls to 911, 411, 0, etc should not ever need a context. Their routing is always based on the number dialed plus information concerning the location (or identity) of the originator. The destination does not require a "context" to "verify that it is within the same context" as the call to private numbers do. If the "context" is intended to specify the identity of the originator, there are already other parameters to do this. If the "context" is intended to specify the area covered by the desired destination (for routing or verification), then it would require more than a country code (as shown in the example in the draft). There is no known number sequence which could represent what is needed for this purpose.

Definition of a 3rd format for such special numbers would include support for other locally dialable numbers such as #77, 0, 011 which have not been described.

Mike Pierce
Artel


--part1_46.31de24ca.2b1e62da_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 14:46:51 2002 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 OAA12938 for ; Tue, 3 Dec 2002 14:46:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3JnFM09101 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 14:49:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3JnEv09098 for ; Tue, 3 Dec 2002 14:49:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12910 for ; Tue, 3 Dec 2002 14:46:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Jn3v09087; Tue, 3 Dec 2002 14:49:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Jmqv09056 for ; Tue, 3 Dec 2002 14:48:52 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12875 for ; Tue, 3 Dec 2002 14:45:57 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3Jmjl8027702 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 3 Dec 2002 14:48:46 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3JmgdG029838 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Dec 2002 14:48:44 -0500 (EST) Message-ID: <3DED0A18.60705@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: iptel@ietf.org Subject: Re: [Iptel] Preliminary version of 2806bis 07 References: <46.31de24ca.2b1e62da@aol.com> In-Reply-To: <46.31de24ca.2b1e62da@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Dec 2002 14:46:32 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit tel:411 is not particularly helpful. At least with tel:411;phone-context=+1, somebody in Holland (or a gateway there) knows that this number has no local meaning. Again, the point is that tel is an identifier. The context just makes it unique. For the N11 numbers, +1 will do fine, as they are logically the same service within NANPA. Alternatively, if they are carrier-specific, something like tel:*77;phone-context=verizon.com will do. As usual, concrete alternative suggestions are most appreciated. > Major comment: > > The draft sufficiently covers the cases of global (E.164) numbers and > local (private dialing plan) numbers. However, I continue to be > concerned with the representation of special numbers such as 911, 411, > etc as "local numbers" with a context made up of "+" and a country code > plus possibly additional digits. I am not satisfied with the resolution > of this issue which I began to raise last May on the SIPPING list. There > needs to be a distinct uri format defined to carry these and other > special dialing plan numbers which are not a part of the E.164 plan. > They need to be handled differently than "local numbers", which are > generally described in this draft to be the equivalent of private > dialing plan numbers (PBX extension without direct inward dialing which > are also not part of the E.164 numbers). These special numbers do not > require a "context", at least, not in the same way as "local (private) > numbers". > > Consider the following: > tel:411;phone-context=+1-410-817-2000 > > This could be a call to 411 (local information) from the telephone > number 410-817-2000 or it could be a call to extension 411 located > within the PBX which decided to use the context 1-410-817-2000. (Either > of these is allowed by the draft.) The format of the tel:uri should not > be such that the interpretation is ambiguous. I believe that SIP-ISUP > interworking (recently approved as an RFC) would require the ability to > be able to distinguish these two cases, since they must be mapped into > ISUP differently. > > Calls to 911, 411, 0, etc should not ever need a context. Their routing > is always based on the number dialed plus information concerning the > location (or identity) of the originator. The destination does not > require a "context" to "verify that it is within the same context" as > the call to private numbers do. If the "context" is intended to specify > the identity of the originator, there are already other parameters to do > this. If the "context" is intended to specify the area covered by the > desired destination (for routing or verification), then it would require > more than a country code (as shown in the example in the draft). There > is no known number sequence which could represent what is needed for > this purpose. > > Definition of a 3rd format for such special numbers would include > support for other locally dialable numbers such as #77, 0, 011 which > have not been described. > > Mike Pierce > Artel > > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 17:36:01 2002 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 RAA22909 for ; Tue, 3 Dec 2002 17:36:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3McPF22564 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 17:38:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3McPv22561 for ; Tue, 3 Dec 2002 17:38:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22906 for ; Tue, 3 Dec 2002 17:35:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3McFv22551; Tue, 3 Dec 2002 17:38:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Mbuv22520 for ; Tue, 3 Dec 2002 17:37:56 -0500 Received: from imo-m10.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22900 for ; Tue, 3 Dec 2002 17:35:01 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m10.mx.aol.com (mail_out_v34.13.) id 7.9b.319a9a41 (3699); Tue, 3 Dec 2002 17:37:40 -0500 (EST) Message-ID: <9b.319a9a41.2b1e8c34@aol.com> Subject: Re: [Iptel] Preliminary version of 2806bis 07 To: hgs@cs.columbia.edu CC: iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_9b.319a9a41.2b1e8c34_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 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, 3 Dec 2002 17:37:40 EST --part1_9b.319a9a41.2b1e8c34_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/3/2002 2:49:09 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > tel:411 is not particularly helpful. At least with > tel:411;phone-context=+1, somebody in Holland (or a gateway there) knows > [MAP] I agree that 411 by itself is not enough. But a context of +1 doesn't allow a GW in an area of the US where they don't use 411 (or whatever other n11 code is being passed) to know that the number has no local meaning (since it is within the +1 "context".) What about n11 codes that have different meanings in different parts of the US (or Canada)? As the NANPA web site says: "In some states, N11 codes that are not assigned nationally may be assigned locally, provided that these local assignments can be withdrawn promptly if a national assignment is made." > > Again, the point is that tel is an identifier. The context just makes it > unique. For the N11 numbers, +1 will do fine, as they are logically the > same service within NANPA. Alternatively, if they are carrier-specific, > something like > > tel:*77;phone-context=verizon.com > [MAP] Presumably, Verizon would use verizon.com to indicate its own internal private network numbers, not to qualify its "publicly" dialable numbers. Other information present should identify the originator as a Verizon customer. Incidentally, the character before the 77 in this example is #, not *. Either way, how would these "numbers" be included in the tel:uri? > will do. As usual, concrete alternative suggestions are most appreciated. > [MAP] It's time to get -07 out so we can begin the next round of comments. I'll concentrate on the concrete proposals for special numbers based on the one I made last May. Mike Pierce Artel --part1_9b.319a9a41.2b1e8c34_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/3/2002 2:49:09 PM Eastern Standard Time, hgs@cs.columbia.edu writes:


tel:411 is not particularly helpful. At least with
tel:411;phone-context=+1, somebody in Holland (or a gateway there) knows
that this number has no local meaning.


[MAP] I agree that 411 by itself is not enough. But a context of +1 doesn't allow a GW in an area of the US where they don't use 411 (or whatever other n11 code is being passed) to know that the number has no local meaning (since it is within the +1 "context".) What about n11 codes that have different meanings in different parts of the US (or Canada)?

As the NANPA web site says:

"In some states, N11 codes that are not assigned nationally may be assigned locally, provided that these local assignments can be withdrawn promptly if a national assignment is made."


Again, the point is that tel is an identifier. The context just makes it
unique. For the N11 numbers, +1 will do fine, as they are logically the
same service within NANPA. Alternatively, if they are carrier-specific,
something like

tel:*77;phone-context=verizon.com

[MAP] Presumably, Verizon would use verizon.com to indicate its own internal private network numbers, not to qualify its "publicly" dialable numbers. Other information present should identify the originator as a Verizon customer.

Incidentally, the character before the 77 in this example is #, not *. Either way, how would these "numbers" be included in the tel:uri?


will do. As usual, concrete alternative suggestions are most appreciated.

[MAP] It's time to get -07 out so we can begin the next round of comments. I'll concentrate on the concrete proposals for special numbers based on the one I made last May.

Mike Pierce
Artel


--part1_9b.319a9a41.2b1e8c34_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 17:40:43 2002 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 RAA23037 for ; Tue, 3 Dec 2002 17:40:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3Mh8w22826 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 17:43:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Mh7v22823 for ; Tue, 3 Dec 2002 17:43:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23023 for ; Tue, 3 Dec 2002 17:40:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Mh2v22814; Tue, 3 Dec 2002 17:43:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Mgdv22775 for ; Tue, 3 Dec 2002 17:42:39 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23002 for ; Tue, 3 Dec 2002 17:39:43 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB3MgSYH011497; Tue, 3 Dec 2002 17:42:28 -0500 (EST) Message-ID: <3DED3351.4070008@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis References: <3DD9D7A5.5040503@dynamicsoft.com> <3DECD75F.2050701@cs.columbia.edu> 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, 03 Dec 2002 17:42:25 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >> > Implementations MUST NOT assume that telephone numbers have a >> > maximum, minimum or fixed length, or that they always begin with a >> > certain number. >> >> >> For global numbers, I certainly can assume a maximum length of 15, as >> that is the constraint in the BNF. I think you should say "local >> numbers" instead of telephone numbers. > > > > I've removed the constraint from the BNF. As was pointed out, it > couldn't deal with the visual separators. Given visual separators, the > length becomes unbounded. Something like > > tel:+1-----------201.........(((((555)))))))1234 > > is odd, but legal according to the current BNF. (I've now rewritten the > BNF so that each digit can be followed by at most one visual separator. > Is there any reason to have more than that? This would limit the length > to 30.) I've been pondering the role of visual separators in the URI, and did a bit of thinking and research on the topic. Here are my thoughts. On one hand, since URI are ultimately for computer consumtpion, the separators play no role. They also complicate the comparison process since they should probably be removed before comparison. Simplicity would argue for their elimination entirely. However, one can argue that they play a reasonable role in supporting the general transcribability requirement of a URI. From RFC 2396: > A URI often needs to be remembered by people, and it is easier > for people to remember a URI when it consists of meaningful > components. This would argue in favor of the separators, since people very frequently use them to help correct write the number. As an example, its much easier to get the correct number of ones when writing: tel:+1(111)111-1111 as opposed to tel:+11111111111. Interestingly, there is precedent for the usage of such separators in a URN. The ISBN URN (rfc3187), uses dashes in the same way we use them. The specifications for that URN scheme do require that the dashes are removed before comparing for equivalence. So, in the interests of transcribability and in keeping with the trend in the ISBN URN, I would argue that we retain the separators and remove them for comparison purposes. So, the issue remains of whether or not to allow multiple separators. I think what you have done is reasonable - allowing a single separator. I can think of no reason why we would need more. >> >> > Even though ITU-T E.123 [8] recommends the use of space characters as >> > visual separators in printed telephone numbers, tel URIs MUST NOT >> use >> > spaces. >> >> >> The BNF clearly disallows spaces as part of the phone number itself, so >> having a MUST NOT here seems redundant. Does this mean I can't have >> escaped spaces as part of a parameter value? That is allowed by the BNF. > > > I suppose we can allow %20 spaces as visual separators. Is there value > in that? > Probably not. This isn't like an HTTP URI, where we are trying to describe files whose names are frequently unconstrained in their natural form. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Tue Dec 3 17:40:45 2002 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 RAA23051 for ; Tue, 3 Dec 2002 17:40:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3Mh9d22841 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 17:43:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Mh9v22838 for ; Tue, 3 Dec 2002 17:43:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23027 for ; Tue, 3 Dec 2002 17:40:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Mh2v22798; Tue, 3 Dec 2002 17:43:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3MgOv22767 for ; Tue, 3 Dec 2002 17:42:24 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22975 for ; Tue, 3 Dec 2002 17:39:29 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3MfvK0022785; Tue, 3 Dec 2002 14:41:57 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3MftxZ024166; Tue, 3 Dec 2002 14:41:56 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-31.cisco.com [10.86.242.31]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA00806; Tue, 3 Dec 2002 14:41:53 -0800 (PST) Message-ID: <3DED3331.F67DEFE8@cisco.com> From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Henning Schulzrinne , Scott Bradner , rohan@cisco.com, iptel@ietf.org Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion References: <200211301954.gAUJsNn6022405@newdev.harvard.edu> <3DE91AF0.6050209@cs.columbia.edu> <3DEC648C.6010105@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Dec 2002 17:41:53 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Henning Schulzrinne wrote: > > Scott, > > > > trying to guess at the source of confusion here. I suspect that part of > > the problem might be two meanings of the word 'context': > > > > - Context = 'resolve this identifier under this context' > > (;context=+1-212-939-7000 = Pizza Hut as if dialed from 212-939-7000) > > I believe this is out of scope. We are not trying to direct routing. > > > > > - Context = 'this number is only valid if dialed from this context; it's > > an error otherwise' (the number may still reach something or other, but > > it's not the intended destination) > > This is what I believe we are talking about. > > I thought I heard someone suggest another usage during the meeting, to > support things like VPNs: > Right. I was considering things like private numbering plans/VPNs, where you within a single provider network (or cooperating providers) can pass private numbers around without requiring translation to public E.164 numbers. However, you also need to pass a "VPN Group ID" in order to ensure proper interpretation and further routing at the next hop. In essence, a context. > > - Context: this number can only be interpreted by first routing the call > to this context, and the interpreting it there > > For example, if a company has a PBX without DID, and its number is 973 > 555 1234, I would reach extension 33 this way: > > tel:33;context="+19735551234" > > THis is similar in concept to relative URI references. > I was only referring to private numbering plans. > > I don't think this is in scope either, and so perhaps I misinterpreted > what was said during the iptel meeting. If someone does think we are > supporting this, please speak up. I do believe we should support private numbering plans and something like context seems useful for that. -- Flemming _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 17:46:07 2002 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 RAA23221 for ; Tue, 3 Dec 2002 17:46:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3MmVW23048 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 17:48:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3MmVv23045 for ; Tue, 3 Dec 2002 17:48:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23217 for ; Tue, 3 Dec 2002 17:45:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Mm6v23020; Tue, 3 Dec 2002 17:48:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3MlKv22989 for ; Tue, 3 Dec 2002 17:47:20 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23190 for ; Tue, 3 Dec 2002 17:44:25 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB3MlSDO006517; Tue, 3 Dec 2002 17:47:29 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id ABJ83488; Tue, 3 Dec 2002 17:36:53 -0500 (EST) Message-Id: <4.3.2.7.2.20021203174409.00badef0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Mpierce1@aol.com From: Michael Hammer Subject: Re: [Iptel] Preliminary version of 2806bis 07 Cc: hgs@cs.columbia.edu, iptel@ietf.org In-Reply-To: <46.31de24ca.2b1e62da@aol.com> 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: Tue, 03 Dec 2002 17:46:57 -0500 At 02:41 PM 12/3/2002 -0500, Mpierce1@aol.com wrote: >Consider the following: >tel:411;phone-context=+1-410-817-2000 This could also be a reference to my speed-dial list. Where do we draw the line between route-able telephone numbers and keypresses to invoke services? Mike H. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 17:57:46 2002 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 RAA23725 for ; Tue, 3 Dec 2002 17:57:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3N0B323670 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 18:00:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3N0Av23667 for ; Tue, 3 Dec 2002 18:00:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23701 for ; Tue, 3 Dec 2002 17:57:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3N04v23640; Tue, 3 Dec 2002 18:00:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3MxYv23589 for ; Tue, 3 Dec 2002 17:59:34 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23670 for ; Tue, 3 Dec 2002 17:56:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB3MxOYH011508; Tue, 3 Dec 2002 17:59:24 -0500 (EST) Message-ID: <3DED3749.7070102@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis - semantics References: <3DD9D7A5.5040503@dynamicsoft.com> <3DEBC987.6010109@cs.columbia.edu> 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, 03 Dec 2002 17:59:21 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Thanks for the extensive comments. Comments on non-editorial items > in-line. Split to simplify follow-up. > > Jonathan Rosenberg wrote: > >> My big comment is that the draft doesnt actually define any semantics >> associated with the tel URI. There is nothing which says that I should >> make a call, or that I should do an enum query, or that I should make a >> sip call, etc. Even if there are multiple possibilities, we need a >> section that describes the options, and what it basically means when you >> encounter a tel URI in various contexts. > > > > I've tried to emphasize up front "URI scheme ``tel'' that describes > resources identified by telephone numbers." Thus, I tend to think of it > much more like a URN - it does not specify a protocol to get the > resource ("dialing"), but rather there are several ways to resolve it to > something real (a phone call, say). Agreed its closer to a URN. Indeed, one might question why it wasn't made a URN in the first place (urn:tel:111), but I suppose that is too radical a change for this point in time. I suppose that the tel URI really munges two things together. One is truly a URN - merely a unique name. There are many ways that can be used to access the resource identified by the name. You could send a SIP request to it, using the SIP protocol, or you could send an H323 request to it, using H.323, or you can call it using a circuit switched telephone, which can be considered a "protocol" in its own right, akin to SIP and H.323. Part of the confusion is that we are using the tel URI to represent both the name and one specific protocol for accessing the resource - the circuit switched telephone network. Had we separated these two to begin with, this whole enum URI thing would be a non-issue. The URN specifies the abstract resource name. Using DNS (i.e., ENUM), you look it up, and find the set of URI that can be used to reach that resource. This might include a SIP URI, H.323 URI, or a "telephony" URI, which indicates that the only way to reach this resource is through the PSTN. That URI would clearly not be looked up again in DNS. Indeed, one path forward is to narrow the scope of the tel URI as defined now to not be a generic name, but rather, to indicate that this specific telephone number should be contacted on the PSTN. We can then additionally specify a URN, and it is that URN which would be looked up in ENUM. > This document defines the URI scheme ``tel'' that describes resources > identified by telephone numbers. The telephone number can refer to > terminals in the telephone network or the Internet, mobile and landline > devices, voice, data and fax devices. One wrinkle. If we plan on adding trunk groups to the tel URI, we can no longer claim that we are addressing TERMINALs, since a circuit on a trunk group is not a terminal! Based on the above discussion, circuits in a trunk group may very well be another URN. That would help us handle some of the thorny naming issues surrounding trunk groups; we could use some of the URN infrastructure for this. Hmm.... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Tue Dec 3 18:48:09 2002 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 SAA25523 for ; Tue, 3 Dec 2002 18:48:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3NoYg26715 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 18:50:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3NoYv26712 for ; Tue, 3 Dec 2002 18:50:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25505 for ; Tue, 3 Dec 2002 18:47:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3NoQv26702; Tue, 3 Dec 2002 18:50:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Nnfv26643 for ; Tue, 3 Dec 2002 18:49:41 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25490 for ; Tue, 3 Dec 2002 18:46:45 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3NnUl8025104 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 3 Dec 2002 18:49:30 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB3NnTdG021404 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Dec 2002 18:49:29 -0500 (EST) Message-ID: <3DED4286.7040409@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis - semantics References: <3DD9D7A5.5040503@dynamicsoft.com> <3DEBC987.6010109@cs.columbia.edu> <3DED3749.7070102@dynamicsoft.com> In-Reply-To: <3DED3749.7070102@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Dec 2002 18:47:18 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Agreed its closer to a URN. Indeed, one might question why it wasn't > made a URN in the first place (urn:tel:111), but I suppose that is too > radical a change for this point in time. > > I suppose that the tel URI really munges two things together. One is > truly a URN - merely a unique name. There are many ways that can be used > to access the resource identified by the name. You could send a SIP > request to it, using the SIP protocol, or you could send an H323 request > to it, using H.323, or you can call it using a circuit switched > telephone, which can be considered a "protocol" in its own right, akin > to SIP and H.323. > > Part of the confusion is that we are using the tel URI to represent both > the name and one specific protocol for accessing the resource - the > circuit switched telephone network. > > Had we separated these two to begin with, this whole enum URI thing > would be a non-issue. The URN specifies the abstract resource name. > Using DNS (i.e., ENUM), you look it up, and find the set of URI that can > be used to reach that resource. This might include a SIP URI, H.323 URI, > or a "telephony" URI, which indicates that the only way to reach this > resource is through the PSTN. That URI would clearly not be looked up > again in DNS. I don't think that works very well, simply because this is subject to change at any moment. I don't think it's a good idea to want to change an identifier just because I've placed a number into ENUM (or removed it from there). In the end, this has to be a recursive lookup - attempt if the number is in ENUM. If not, it must be reachable (if at all) only using traditional circuit switching. If it is in ENUM, recurse if necessary (i.e., if there's another URI). > > Indeed, one path forward is to narrow the scope of the tel URI as > defined now to not be a generic name, but rather, to indicate that this > specific telephone number should be contacted on the PSTN. We can then > additionally specify a URN, and it is that URN which would be looked up > in ENUM. > > One wrinkle. If we plan on adding trunk groups to the tel URI, we can no > longer claim that we are addressing TERMINALs, since a circuit on a I think I've tried to remove all references to terminals, except by example. E.164 doesn't address terminals - it just says "public network termination point". > trunk group is not a terminal! Based on the above discussion, circuits > in a trunk group may very well be another URN. That would help us handle > some of the thorny naming issues surrounding trunk groups; we could use > some of the URN infrastructure for this. > > Hmm.... > > -Jonathan R. > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 3 20:00:49 2002 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 UAA28023 for ; Tue, 3 Dec 2002 20:00:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB413F431668 for iptel-archive@odin.ietf.org; Tue, 3 Dec 2002 20:03:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB413Ev31665 for ; Tue, 3 Dec 2002 20:03:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28001 for ; Tue, 3 Dec 2002 20:00:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4137v31659; Tue, 3 Dec 2002 20:03:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB412Fv31624 for ; Tue, 3 Dec 2002 20:02:15 -0500 Received: from acmepacket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27971 for ; Tue, 3 Dec 2002 19:59:18 -0500 (EST) Received: from BPenfield [127.0.0.1] by acmepacket.com (SMTPD32-7.07) id A40D8E3502B4; Tue, 03 Dec 2002 20:02:05 -0500 Message-ID: <001301c29b30$ba9297e0$2300000a@BPenfield> From: "Bob Penfield" To: "Henning Schulzrinne" , "Jonathan Rosenberg" Cc: References: <3DD9D7A5.5040503@dynamicsoft.com> <3DECD75F.2050701@cs.columbia.edu> Subject: Re: [Iptel] comments on rfc2806bis (maximum length) 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 3 Dec 2002 20:01:50 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Henning Schulzrinne" > > For global numbers, I certainly can assume a maximum length of 15, as > > that is the constraint in the BNF. I believe the maximum length for a global number should be at least 17. I may be mistaken, but I recall from a previous life that E.164 allows for up to 9-digit local numbers with up to 5-digit city/area code and 3-digit country code. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 05:43:54 2002 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 FAA05591 for ; Wed, 4 Dec 2002 05:43:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4AkFg08113 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 05:46:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4AkFv08110 for ; Wed, 4 Dec 2002 05:46:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05582 for ; Wed, 4 Dec 2002 05:43:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Ak8v08099; Wed, 4 Dec 2002 05:46:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4AjTv08068 for ; Wed, 4 Dec 2002 05:45:29 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05558 for ; Wed, 4 Dec 2002 05:42:37 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for iptel@ietf.org; Wed, 4 Dec 2002 11:31:05 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 11:31:04 +0100 Message-Id: From: "Alexeitsev, D" To: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis - separators MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 4 Dec 2002 11:31:04 +0100 Hello All >I'm all for simplification. The only real reason is that the receiver >may not really know how to render, say, a tel: URI contained in a SIP >request. If a US-English UA gets a European number, it likely has no >clue what part is the area code and what part is the subscriber number. >(Indeed, in that case, even a smart UI would have real difficulty >discerning the two parts, given that area codes are variable-length.) As >long as people do > >From: +49 (2232) 12345 > >this may not be a big deal. [DA] If this is the only real use of the visual separators, then I agree with Mikes proposal to remove them fom the URI definition and recomment the use of display name. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 06:24:53 2002 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 GAA06239 for ; Wed, 4 Dec 2002 06:24:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4BRCX10051 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 06:27:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4BRCv10048 for ; Wed, 4 Dec 2002 06:27:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06235 for ; Wed, 4 Dec 2002 06:24:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4BR4v10039; Wed, 4 Dec 2002 06:27:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4BQfv10016 for ; Wed, 4 Dec 2002 06:26:41 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06225 for ; Wed, 4 Dec 2002 06:23:51 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 4 Dec 2002 12:12:14 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 12:12:14 +0100 Message-Id: From: "Alexeitsev, D" To: jdrosen@dynamicsoft.com Cc: iptel@ietf.org Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 4 Dec 2002 12:12:11 +0100 Hello All >So, in the interests of transcribability and in keeping with the trend >in the ISBN URN, I would argue that we retain the separators and remove >them for comparison purposes. [DA] Is there a difference from the point of view of the URI definition between user input standardisation and protocol on the wire standardisation? In the case of user input I agree that It might be simpler to use telephone numbers with separation as lot of us do in the telephone books, but the information on the wire that is aimed for the machine consume does not really need it. Greetings, Denis Alexeitsev _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 07:43:14 2002 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 HAA08164 for ; Wed, 4 Dec 2002 07:43:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4CjY014583 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 07:45:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4CjXv14580 for ; Wed, 4 Dec 2002 07:45:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08157 for ; Wed, 4 Dec 2002 07:42:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Cj4v14558; Wed, 4 Dec 2002 07:45:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Ci2v14510 for ; Wed, 4 Dec 2002 07:44:02 -0500 Received: from mta1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08097 for ; Wed, 4 Dec 2002 07:41:09 -0500 (EST) Received: from m70113 (mta1 [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0H6L00HDSHXAEC@mta1.huawei.com> for iptel@ietf.org; Wed, 04 Dec 2002 20:41:35 +0800 (CST) From: Mahesh Subject: RE: [Iptel] comments on rfc2806bis (maximum length) In-reply-to: <001301c29b30$ba9297e0$2300000a@BPenfield> To: Bob Penfield , Henning Schulzrinne , Jonathan Rosenberg Cc: iptel@ietf.org Reply-to: maheshl@huawei.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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, 04 Dec 2002 20:45:51 +0800 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello Mr Henning, Yaa you are right. E164 number does support the specifications you have said. (9-digit local numbers with up to 5-digit city/area code and 3-digit country code.) -----Original Message----- From: iptel-admin@ietf.org [mailto:iptel-admin@ietf.org]On Behalf Of Bob Penfield Sent: Wednesday, December 04, 2002 9:02 AM To: Henning Schulzrinne; Jonathan Rosenberg Cc: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis (maximum length) ----- Original Message ----- From: "Henning Schulzrinne" > > For global numbers, I certainly can assume a maximum length of 15, as > > that is the constraint in the BNF. I believe the maximum length for a global number should be at least 17. I may be mistaken, but I recall from a previous life that E.164 allows for up to 9-digit local numbers with up to 5-digit city/area code and 3-digit country code. _______________________________________________ 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 mailnull@www1.ietf.org Wed Dec 4 08:38:10 2002 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 IAA10116 for ; Wed, 4 Dec 2002 08:38:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4DeVp18155 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 08:40:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4DeVv18152 for ; Wed, 4 Dec 2002 08:40:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10102 for ; Wed, 4 Dec 2002 08:37:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4De1v18115; Wed, 4 Dec 2002 08:40:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Ddev18070 for ; Wed, 4 Dec 2002 08:39:40 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10070 for ; Wed, 4 Dec 2002 08:36:48 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4Ddbl8021586 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 4 Dec 2002 08:39:37 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4DdZdG002029 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Dec 2002 08:39:36 -0500 (EST) Message-ID: <3DEE0511.5010408@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexeitsev, D" CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis 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: Wed, 04 Dec 2002 08:37:21 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit URI (and kin) are also meant for human consumption (see the RFC 2396 quote that Jonathan referred to); there is no separate "wire format". Since there is a loss in usability if you remove the separators, I would argue that the visual separators should stay. The additional complexity is rather modest. In addition, all other IETF phone number representations (for VPIM and such) also allow for visual separators. Alexeitsev, D wrote: > Hello All > > >>So, in the interests of transcribability and in keeping with the trend >>in the ISBN URN, I would argue that we retain the separators and remove >>them for comparison purposes. > > > [DA] Is there a difference from the point of view of the URI definition between user input standardisation and protocol on the wire standardisation? In the case of user input I agree that It might be simpler to use telephone numbers with separation as lot of us do in the telephone books, but the information on the wire that is aimed for the machine consume does not really need it. > > Greetings, > Denis Alexeitsev > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Dec 4 08:43:14 2002 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 IAA10293 for ; Wed, 4 Dec 2002 08:43:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4DjZt18374 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 08:45:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4DjZv18371 for ; Wed, 4 Dec 2002 08:45:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10279 for ; Wed, 4 Dec 2002 08:42:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Dj3v18351; Wed, 4 Dec 2002 08:45:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Diev18314 for ; Wed, 4 Dec 2002 08:44:40 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10249 for ; Wed, 4 Dec 2002 08:41:48 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA16785; Wed, 4 Dec 2002 08:44:37 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA29072; Wed, 4 Dec 2002 08:44:38 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Dec 2002 08:44:37 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5BC1@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , Henning Schulzrinne Cc: iptel@ietf.org Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 4 Dec 2002 08:44:34 -0500 Maybe I've missed something, but we usually write (724) 742-6826, and not (724)742-6826. My business card actually has +1 (724) 742-6826. That means two separators. I do think we should permit visual separators, stripping them for comparison purposes as you suggest. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, December 03, 2002 5:42 PM > To: Henning Schulzrinne > Cc: iptel@ietf.org > Subject: Re: [Iptel] comments on rfc2806bis > > > > > Henning Schulzrinne wrote: > > >> > Implementations MUST NOT assume that telephone numbers have a > >> > maximum, minimum or fixed length, or that they always > begin with a > >> > certain number. > >> > >> > >> For global numbers, I certainly can assume a maximum > length of 15, as > >> that is the constraint in the BNF. I think you should say "local > >> numbers" instead of telephone numbers. > > > > > > > > I've removed the constraint from the BNF. As was pointed out, it > > couldn't deal with the visual separators. Given visual > separators, the > > length becomes unbounded. Something like > > > > tel:+1-----------201.........(((((555)))))))1234 > > > > is odd, but legal according to the current BNF. (I've now > rewritten the > > BNF so that each digit can be followed by at most one > visual separator. > > Is there any reason to have more than that? This would > limit the length > > to 30.) > > I've been pondering the role of visual separators in the URI, > and did a > bit of thinking and research on the topic. Here are my thoughts. > > On one hand, since URI are ultimately for computer consumtpion, the > separators play no role. They also complicate the comparison process > since they should probably be removed before comparison. Simplicity > would argue for their elimination entirely. > > However, one can argue that they play a reasonable role in supporting > the general transcribability requirement of a URI. From RFC 2396: > > > A URI often needs to be remembered by people, and it is easier > > for people to remember a URI when it consists of meaningful > > components. > > This would argue in favor of the separators, since people very > frequently use them to help correct write the number. As an > example, its > much easier to get the correct number of ones when writing: > > tel:+1(111)111-1111 > > as opposed to tel:+11111111111. > > Interestingly, there is precedent for the usage of such > separators in a > URN. The ISBN URN (rfc3187), uses dashes in the same way we use them. > The specifications for that URN scheme do require that the dashes are > removed before comparing for equivalence. > > So, in the interests of transcribability and in keeping with > the trend > in the ISBN URN, I would argue that we retain the separators > and remove > them for comparison purposes. > > So, the issue remains of whether or not to allow multiple > separators. I > think what you have done is reasonable - allowing a single > separator. I > can think of no reason why we would need more. > > > >> > >> > Even though ITU-T E.123 [8] recommends the use of space > characters as > >> > visual separators in printed telephone numbers, tel > URIs MUST NOT > >> use > >> > spaces. > >> > >> > >> The BNF clearly disallows spaces as part of the phone > number itself, so > >> having a MUST NOT here seems redundant. Does this mean I can't have > >> escaped spaces as part of a parameter value? That is > allowed by the BNF. > > > > > > I suppose we can allow %20 spaces as visual separators. Is > there value > > in that? > > > > Probably not. This isn't like an HTTP URI, where we are trying to > describe files whose names are frequently unconstrained in > their natural > form. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > 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 From mailnull@www1.ietf.org Wed Dec 4 08:49:13 2002 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 IAA10528 for ; Wed, 4 Dec 2002 08:49:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4DpZV18578 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 08:51:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4DpYv18575 for ; Wed, 4 Dec 2002 08:51:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10487 for ; Wed, 4 Dec 2002 08:48:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Dp4v18564; Wed, 4 Dec 2002 08:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Doov18549 for ; Wed, 4 Dec 2002 08:50:50 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10425 for ; Wed, 4 Dec 2002 08:47:58 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4Dokl8023695 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 4 Dec 2002 08:50:47 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4DojdG002867 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Dec 2002 08:50:46 -0500 (EST) Message-ID: <3DEE07AF.6080201@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Jonathan Rosenberg'" , iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis References: <313680C9A886D511A06000204840E1CF030B5BC1@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5BC1@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 04 Dec 2002 08:48:31 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We meant "two separators in a row", as in +1--724..6826. Except for typos, two consecutive visual seps don't seem to serve a role. The advantage of limiting the number of separators per digit is that it limits the maximum legal length of the number. Yes, clearly, a tel URI can, in total, contain more than one separator. Rosen, Brian wrote: > Maybe I've missed something, but we usually write (724) 742-6826, and not > (724)742-6826. My business card actually has +1 (724) 742-6826. That means > two > separators. > > I do think we should permit visual separators, stripping them for comparison > purposes as you suggest. > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 09:28:13 2002 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 JAA12758 for ; Wed, 4 Dec 2002 09:28:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4EUZj20812 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 09:30:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4EUZv20809 for ; Wed, 4 Dec 2002 09:30:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12737 for ; Wed, 4 Dec 2002 09:27:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4EU4v20775; Wed, 4 Dec 2002 09:30:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4ETRv20737 for ; Wed, 4 Dec 2002 09:29:27 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12705 for ; Wed, 4 Dec 2002 09:26:35 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4ETXqT002728; Wed, 4 Dec 2002 09:29:33 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id ABJ87502; Wed, 4 Dec 2002 09:18:56 -0500 (EST) Message-Id: <4.3.2.7.2.20021204092647.00b127c8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: maheshl@huawei.com From: Michael Hammer Subject: RE: [Iptel] comments on rfc2806bis (maximum length) Cc: Bob Penfield , Henning Schulzrinne , Jonathan Rosenberg , iptel@ietf.org In-Reply-To: References: <001301c29b30$ba9297e0$2300000a@BPenfield> 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: Wed, 04 Dec 2002 09:29:02 -0500 I seem to remember 15 being the magic maximum number from E.164 I think. Mike At 08:45 PM 12/4/2002 +0800, Mahesh wrote: >Hello Mr Henning, > >Yaa you are right. E164 number does support the specifications you have >said. (9-digit local numbers with up to 5-digit city/area code and 3-digit >country code.) > >-----Original Message----- >From: iptel-admin@ietf.org [mailto:iptel-admin@ietf.org]On Behalf Of Bob >Penfield >Sent: Wednesday, December 04, 2002 9:02 AM >To: Henning Schulzrinne; Jonathan Rosenberg >Cc: iptel@ietf.org >Subject: Re: [Iptel] comments on rfc2806bis (maximum length) > > > >----- Original Message ----- >From: "Henning Schulzrinne" > > > > For global numbers, I certainly can assume a maximum length of 15, as > > > that is the constraint in the BNF. > >I believe the maximum length for a global number should be at least 17. I >may be mistaken, but I recall from a previous life that E.164 allows for up >to 9-digit local numbers with up to 5-digit city/area code and 3-digit >country code. > >_______________________________________________ >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 mailnull@www1.ietf.org Wed Dec 4 09:47:13 2002 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 JAA13978 for ; Wed, 4 Dec 2002 09:47:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4EnZR22299 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 09:49:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4EnZv22296 for ; Wed, 4 Dec 2002 09:49:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13944 for ; Wed, 4 Dec 2002 09:46:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4En3v22277; Wed, 4 Dec 2002 09:49:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4EmYv22242 for ; Wed, 4 Dec 2002 09:48:34 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13916 for ; Wed, 4 Dec 2002 09:45:41 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4EmEK0021087; Wed, 4 Dec 2002 06:48:14 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id DYV00057; Wed, 4 Dec 2002 06:48:34 -0800 (PST) From: "Cullen Jennings" To: "Henning Schulzrinne" , "Rosen, Brian" Cc: "'Jonathan Rosenberg'" , Subject: RE: [Iptel] comments on rfc2806bis Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3DEE07AF.6080201@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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, 4 Dec 2002 06:51:01 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Not sure what Brian meant but when I read his email, I interpreted it as (724) 742-6826 did have two visual separators in a row. The ) and the space after the ) and before the 732. Cullen > -----Original Message----- > From: iptel-admin@ietf.org [mailto:iptel-admin@ietf.org]On Behalf Of > Henning Schulzrinne > Sent: Wednesday, December 04, 2002 5:49 AM > To: Rosen, Brian > Cc: 'Jonathan Rosenberg'; iptel@ietf.org > Subject: Re: [Iptel] comments on rfc2806bis > > > We meant "two separators in a row", as in +1--724..6826. Except for > typos, two consecutive visual seps don't seem to serve a role. The > advantage of limiting the number of separators per digit is that it > limits the maximum legal length of the number. > > Yes, clearly, a tel URI can, in total, contain more than one separator. > > Rosen, Brian wrote: > > Maybe I've missed something, but we usually write (724) > 742-6826, and not > > (724)742-6826. My business card actually has +1 (724) > 742-6826. That means > > two > > separators. > > > > I do think we should permit visual separators, stripping them > for comparison > > purposes as you suggest. > > > > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Dec 4 09:53:12 2002 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 JAA14271 for ; Wed, 4 Dec 2002 09:53:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4EtYb22625 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 09:55:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4EtYv22622 for ; Wed, 4 Dec 2002 09:55:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14225 for ; Wed, 4 Dec 2002 09:52:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Et3v22574; Wed, 4 Dec 2002 09:55:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Epuv22399 for ; Wed, 4 Dec 2002 09:51:56 -0500 Received: from fw11.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14090 for ; Wed, 4 Dec 2002 09:49:03 -0500 (EST) Received: by fw11.telekom.de; (8.8.8/1.3/10May95) id PAA23463; Wed, 4 Dec 2002 15:47:48 +0100 (MET) Received: from g9jbr.mgb01.telekom.de by G8PXB.blf01.telekom.de with ESMTP; Wed, 4 Dec 2002 15:51:51 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 15:51:50 +0100 Message-Id: From: "Alexeitsev, D" To: hgs@cs.columbia.edu Cc: iptel@ietf.org Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 4 Dec 2002 15:51:48 +0100 Hello All, >The advantage of limiting the number of separators per digit is that it limits the maximum legal length of the number. [DA] Sorry if this was already discussed, but what is the rationale behind limiting the length of the number? Greetings, Denis Alexeitsev _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 10:06:17 2002 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 KAA15024 for ; Wed, 4 Dec 2002 10:06:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4F8dJ23821 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 10:08:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4F8dv23818 for ; Wed, 4 Dec 2002 10:08:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15013 for ; Wed, 4 Dec 2002 10:05:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4F8Av23782; Wed, 4 Dec 2002 10:08:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4F7Sv23702 for ; Wed, 4 Dec 2002 10:07:28 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14965 for ; Wed, 4 Dec 2002 10:04:35 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4F7Ol8000499 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 4 Dec 2002 10:07:25 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4F7NdG009236 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Dec 2002 10:07:24 -0500 (EST) Message-ID: <3DEE19A4.8080908@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexeitsev, D" CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis 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: Wed, 04 Dec 2002 10:05:08 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Not much of an advantage, but in general it's nice to be able to say "that 1 MB URI you just sent me must be bogus". One less avenue for a denial-of-service attack. (This obviously does not advocate fixed length buffers without length checking...) Alexeitsev, D wrote: > Hello All, > > >>The advantage of limiting the number of separators per digit is that it limits the maximum legal length of the number. > > > [DA] Sorry if this was already discussed, but what is the rationale behind limiting the length of the number? > > Greetings, > Denis Alexeitsev _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 10:08:13 2002 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 KAA15159 for ; Wed, 4 Dec 2002 10:08:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4FAZH23985 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 10:10:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FAZv23982 for ; Wed, 4 Dec 2002 10:10:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15127 for ; Wed, 4 Dec 2002 10:07:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FA5v23958; Wed, 4 Dec 2002 10:10:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4F9pv23926 for ; Wed, 4 Dec 2002 10:09:52 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15107 for ; Wed, 4 Dec 2002 10:06:58 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25784; Wed, 4 Dec 2002 10:09:44 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24888; Wed, 4 Dec 2002 10:09:45 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Dec 2002 10:09:44 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5BC4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , "Rosen, Brian" Cc: "'Jonathan Rosenberg'" , iptel@ietf.org Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 4 Dec 2002 10:09:43 -0500 We are not communicating, sorry. You need two separators in a row to do "(724) 742-6826" They aren't the SAME separator, but they are two consecutive separators in a row. There is a space between the ")" and the "7". Your response leads me to think the only thing you disallow is the same separator repeated without an intervening meaningful character. Thus you would allow + 1 ().-7 2 4 ().-7 4 2 ().-6 8 2 6 but not +1 7247426826 I'd like to see the ABNF that described that rule :) I'll agree that there is no need to repeat the same separator, but there is a need to have two different separators adjacent. Interestingly, I think it really is two max, although I'm not an expert on how every country displays local numbers. There are many examples of spaces around parens, but I don't think there are any others. You might even get away with a rule that permitted a space around a paren as the only multiple separator rule, something like lparen = [" "] "(" [" "] rparen = [" "] ")" [" "] sep = " " | "-" | "." | lparen | rparen ... Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, December 04, 2002 8:49 AM > To: Rosen, Brian > Cc: 'Jonathan Rosenberg'; iptel@ietf.org > Subject: Re: [Iptel] comments on rfc2806bis > > > We meant "two separators in a row", as in +1--724..6826. Except for > typos, two consecutive visual seps don't seem to serve a role. The > advantage of limiting the number of separators per digit is that it > limits the maximum legal length of the number. > > Yes, clearly, a tel URI can, in total, contain more than one > separator. > > Rosen, Brian wrote: > > Maybe I've missed something, but we usually write (724) > 742-6826, and not > > (724)742-6826. My business card actually has +1 (724) > 742-6826. That means > > two > > separators. > > > > I do think we should permit visual separators, stripping > them for comparison > > purposes as you suggest. > > > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 10:15:13 2002 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 KAA15599 for ; Wed, 4 Dec 2002 10:15:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4FHZB24316 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 10:17:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FHZv24313 for ; Wed, 4 Dec 2002 10:17:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15568 for ; Wed, 4 Dec 2002 10:14:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FH4v24269; Wed, 4 Dec 2002 10:17:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FGSv24238 for ; Wed, 4 Dec 2002 10:16:28 -0500 Received: from imo-r05.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15514 for ; Wed, 4 Dec 2002 10:13:34 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r05.mx.aol.com (mail_out_v34.13.) id 7.18c.123dca16 (3699); Wed, 4 Dec 2002 10:15:57 -0500 (EST) Message-ID: <18c.123dca16.2b1f762d@aol.com> Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion - context To: hgs@cs.columbia.edu, sob@harvard.edu CC: iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_18c.123dca16.2b1f762d_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 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, 4 Dec 2002 10:15:57 EST --part1_18c.123dca16.2b1f762d_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/3/2002 8:12:31 AM Eastern Standard Time, hgs@cs.columbia.edu writes: > The context is meant to lead to a binary decision: Either you know > you're in the context or you know you're not. Each node knows its > context (a set of E.164-style numbers or a domain name) and simply > checks if the tel URI context matches one of them, exactly. > > Again, based on the discussion, this is not useful or necessary for 800 > numbers or service routing - this is effectively to prevent a PBX > extension that 'escaped' its context to be used somewhere out of scope > (a Harvard extension within Columbia, say, or the internal > Belgian/Japanese NNI service number that a few people mentioned). > [MAP] Now I think we are getting to the point. The "context" only provides the result of a comparison - yes or no - as a form of security. It does not provide any routing information or anything else about the identity of the originator. As such, it can be anything that the receiver can use for a comparison to verify that a call got to the right place. Presuming that the routing works, a call should get to the correct place, so this comparision is just an extra check for the somewhat paranoid. (The real paranoid would use real security measures.) Therefore, it would be nice if the "context" could be guaranteed to be globally unique, but not absolutely essential. Using E.164 number to do this is one way. There are many others that would be more applicable, since we're talking about cases (private numbering plans, etc) which do not have a E.164 number. I would suggest the Private Enterprise Number, administered by IANA, which itself nicely fits under the ISO scheme for unique identifiers. This use of a part of an E.164 number for the "context" has lead this discussion down all kinds of wrong path, including a lot of my comments. Mike Pierce Artel --part1_18c.123dca16.2b1f762d_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/3/2002 8:12:31 AM Eastern Standard Time, hgs@cs.columbia.edu writes:


The context is meant to lead to a binary decision: Either you know
you're in the context or you know you're not. Each node knows its
context (a set of E.164-style numbers or a domain name) and simply
checks if the tel URI context matches one of them, exactly.

Again, based on the discussion, this is not useful or necessary for 800
numbers or service routing - this is effectively to prevent a PBX
extension that 'escaped' its context to be used somewhere out of scope
(a Harvard extension within Columbia, say, or the internal
Belgian/Japanese NNI service number that a few people mentioned).





[MAP] Now I think we are getting to the point. The "context" only provides the result of a comparison - yes or no - as a form of security. It does not provide any routing information or anything else about the identity of the originator. As such, it can be anything that the receiver can use for a comparison to verify that a call got to the right place. Presuming that the routing works, a call should get to the correct place, so this comparision is just an extra check for the somewhat paranoid. (The real paranoid would use real security measures.)

Therefore, it would be nice if the "context" could be guaranteed to be globally unique, but not absolutely essential. Using E.164 number to do this is one way. There are many others that would be more applicable, since we're talking about cases (private numbering plans, etc) which do not have a E.164 number. I would suggest the Private Enterprise Number, administered by IANA, which itself nicely fits under the ISO scheme for unique identifiers.

This use of a part of an E.164 number for the "context" has lead this discussion down all kinds of wrong path, including a lot of my comments.

Mike Pierce
Artel
--part1_18c.123dca16.2b1f762d_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 10:26:50 2002 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 KAA16199 for ; Wed, 4 Dec 2002 10:26:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4FTDn25159 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 10:29:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FTCv25156 for ; Wed, 4 Dec 2002 10:29:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16154 for ; Wed, 4 Dec 2002 10:26:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FT5v25127; Wed, 4 Dec 2002 10:29:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FSOv25074 for ; Wed, 4 Dec 2002 10:28:24 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16128 for ; Wed, 4 Dec 2002 10:25:30 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4FSJl8003148 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 4 Dec 2002 10:28:20 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4FSIdG010853 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Dec 2002 10:28:19 -0500 (EST) Message-ID: <3DEE1E8B.3060000@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sob@harvard.edu, iptel@ietf.org Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion - context References: <18c.123dca16.2b1f762d@aol.com> In-Reply-To: <18c.123dca16.2b1f762d@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 04 Dec 2002 10:26:03 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Therefore, it would be nice if the "context" could be guaranteed to be > globally unique, but not absolutely essential. Using E.164 number to do > this is one way. There are many others that would be more applicable, > since we're talking about cases (private numbering plans, etc) which do > not have a E.164 number. I would suggest the Private Enterprise Number, > administered by IANA, which itself nicely fits under the ISO scheme for > unique identifiers. I'm trying to find discriminators that (1) are globally unique (2) do not require additional assignment authorities (3) are readily known to members of the organization (4) make it easy to detect mis-spellings I agree that the Enterprise Number could be used, but it is not clear that it adds much value beyond the domain name and probably fails criteria (3) and (4). Unlike the EN, the domain name and global-number string more readily deal with enterprises that have multiple local dialing plans ("local numbers in Hong Kong office" = hongkong.acme.com, "local numbers in London office" = london.acme.com). The more identifiers, the more (random) choices and configuration. Since the context check is effectively a string comparison, we can add another namespace later, if the two existing ones prove to be insufficient. > > This use of a part of an E.164 number for the "context" has lead this > discussion down all kinds of wrong path, including a lot of my comments. > > Mike Pierce > Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 10:31:50 2002 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 KAA16615 for ; Wed, 4 Dec 2002 10:31:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4FYD225490 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 10:34:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FYDv25487 for ; Wed, 4 Dec 2002 10:34:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16573 for ; Wed, 4 Dec 2002 10:31:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FY7v25476; Wed, 4 Dec 2002 10:34:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FXCv25432 for ; Wed, 4 Dec 2002 10:33:12 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16475 for ; Wed, 4 Dec 2002 10:30:19 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4FX9l8003539 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 4 Dec 2002 10:33:09 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4FX7dG011284 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Dec 2002 10:33:08 -0500 (EST) Message-ID: <3DEE1FAD.4030002@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis References: <313680C9A886D511A06000204840E1CF030B5BC4@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5BC4@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 04 Dec 2002 10:30:53 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit So much fuss about the minor members of the alphabet :-) I don't see why (724)742-6826 wouldn't work for you. After all, this is how the numbers are commonly written. (We agreed, I believe, that spaces should not be legal visual separators, so the only real combination of interest are things like ")-" and "-(". I've never seen those in real life.) Rosen, Brian wrote: > We are not communicating, sorry. > > You need two separators in a row to do "(724) 742-6826" > They aren't the SAME separator, but they are two consecutive > separators in a row. There is a space between the ")" and the "7". > > Your response leads me to think the only thing you > disallow is the same separator repeated without an intervening > meaningful character. Thus you would allow > + 1 ().-7 2 4 ().-7 4 2 ().-6 8 2 6 > but not > +1 7247426826 > > I'd like to see the ABNF that described that rule :) > > I'll agree that there is no need to repeat the same separator, > but there is a need to have two different separators adjacent. > > Interestingly, I think it really is two max, although I'm not an > expert on how every country displays local numbers. There are > many examples of spaces around parens, but I don't think there > are any others. You might even get away with a rule that > permitted a space around a paren as the only multiple separator > rule, something like > > lparen = [" "] "(" [" "] > rparen = [" "] ")" [" "] > sep = " " | "-" | "." | lparen | rparen > ... _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 10:33:44 2002 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 KAA16764 for ; Wed, 4 Dec 2002 10:33:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4Fa7F25621 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 10:36:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Fa6v25618 for ; Wed, 4 Dec 2002 10:36:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16726 for ; Wed, 4 Dec 2002 10:33:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Fa1v25610; Wed, 4 Dec 2002 10:36:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FZtv25592 for ; Wed, 4 Dec 2002 10:35:55 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16715 for ; Wed, 4 Dec 2002 10:33:01 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 4 Dec 2002 16:34:05 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 16:34:04 +0100 Message-Id: From: "Alexeitsev, D" To: hgs@cs.columbia.edu Cc: iptel@ietf.org Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 4 Dec 2002 16:34:03 +0100 Hello All, >Not much of an advantage, but in general it's nice to be able to say >"that 1 MB URI you just sent me must be bogus". One less avenue for a >denial-of-service attack. (This obviously does not advocate fixed length >buffers without length checking...) [DA] Thanks for the clarification. I think it is already possible to say that, as one would not find any routing entry for this URI :-) From my experience with the problems that operators are facing with the number length limitations I would not like fixing it exactly to the size of currently defined E.164. It generally good design to have some future proved reserve in this buffer, but I'm not sure if it possible to recommend any specific value. Greeting, Denis Alexeitsev _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 10:35:48 2002 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 KAA16873 for ; Wed, 4 Dec 2002 10:35:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4FcBV26335 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 10:38:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FcAv26332 for ; Wed, 4 Dec 2002 10:38:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16855 for ; Wed, 4 Dec 2002 10:35:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Fc1v26324; Wed, 4 Dec 2002 10:38:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FbSv26191 for ; Wed, 4 Dec 2002 10:37:28 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16814 for ; Wed, 4 Dec 2002 10:34:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB4FbKYH011766; Wed, 4 Dec 2002 10:37:21 -0500 (EST) Message-ID: <3DEE212B.7020907@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: hgs@cs.columbia.edu, sob@harvard.edu, iptel@ietf.org Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion - context References: <18c.123dca16.2b1f762d@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 04 Dec 2002 10:37:15 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Mpierce1@aol.com wrote: > In a message dated 12/3/2002 8:12:31 AM Eastern Standard Time, > hgs@cs.columbia.edu writes: > > >> The context is meant to lead to a binary decision: Either you know >> you're in the context or you know you're not. Each node knows its >> context (a set of E.164-style numbers or a domain name) and simply >> checks if the tel URI context matches one of them, exactly. >> >> Again, based on the discussion, this is not useful or necessary for 800 >> numbers or service routing - this is effectively to prevent a PBX >> extension that 'escaped' its context to be used somewhere out of scope >> (a Harvard extension within Columbia, say, or the internal >> Belgian/Japanese NNI service number that a few people mentioned). > > > > > > > [MAP] Now I think we are getting to the point. The "context" only > provides the result of a comparison - yes or no - as a form of security. Security?? It has nothign to do with security. > It does not provide any routing information or anything else about the > identity of the originator. That has been the point Henning has been trying to make in the last dozen emails he has sent. > As such, it can be anything that the > receiver can use for a comparison to verify that a call got to the right > place. No. The context is used by the originator, not the receiver. If the originator gets a URI that it determines is outside of its context, it discards the URI as invalid. > Presuming that the routing works, a call should get to the > correct place, so this comparision is just an extra check for the > somewhat paranoid. (The real paranoid would use real security measures.) Security has nothing to do with it. I can securely call a wrong number, happily verifying that the person on the other end does indeed have extension 5150. Its just that the URI was pointed to a different someone with extensions 5150. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Wed Dec 4 10:39:47 2002 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 KAA17004 for ; Wed, 4 Dec 2002 10:39:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4FgAI26532 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 10:42:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FgAv26529 for ; Wed, 4 Dec 2002 10:42:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16994 for ; Wed, 4 Dec 2002 10:39:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Fg5v26515; Wed, 4 Dec 2002 10:42:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FfDv26473 for ; Wed, 4 Dec 2002 10:41:13 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16959 for ; Wed, 4 Dec 2002 10:38:19 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4Ff9l8004214 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 4 Dec 2002 10:41:10 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4Ff8dG012107 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Dec 2002 10:41:09 -0500 (EST) Message-ID: <3DEE218D.7070001@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexeitsev, D" CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis 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: Wed, 04 Dec 2002 10:38:53 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The about-to-be-released (07) draft does not impose a length restriction. Hopefully, that will settle this particular issue. Alexeitsev, D wrote: > Hello All, > > >>Not much of an advantage, but in general it's nice to be able to say >>"that 1 MB URI you just sent me must be bogus". One less avenue for a >>denial-of-service attack. (This obviously does not advocate fixed length >>buffers without length checking...) > > > [DA] Thanks for the clarification. I think it is already possible to say that, as one would not find any routing entry for this URI :-) >>From my experience with the problems that operators are facing with the number length limitations I would not like fixing it exactly to the size of currently defined E.164. It generally good design to have some future proved reserve in this buffer, but I'm not sure if it possible to recommend any specific value. > > Greeting, > Denis Alexeitsev _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 10:43:44 2002 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 KAA17300 for ; Wed, 4 Dec 2002 10:43:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4Fk7L26893 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 10:46:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Fk7v26890 for ; Wed, 4 Dec 2002 10:46:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17288 for ; Wed, 4 Dec 2002 10:43:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Fk2v26866; Wed, 4 Dec 2002 10:46:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FjGv26818 for ; Wed, 4 Dec 2002 10:45:16 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17188 for ; Wed, 4 Dec 2002 10:42:22 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB4Fj7YH011770; Wed, 4 Dec 2002 10:45:07 -0500 (EST) Message-ID: <3DEE22FE.40708@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Rosen, Brian" , iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis References: <313680C9A886D511A06000204840E1CF030B5BC4@whq-msgusr-02.pit.comms.marconi.com> <3DEE1FAD.4030002@cs.columbia.edu> 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: Wed, 04 Dec 2002 10:45:02 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > So much fuss about the minor members of the alphabet :-) As you have probably observed, nothing brings out opinions more than discussions on syntax ;) > > I don't see why > > (724)742-6826 > > wouldn't work for you. After all, this is how the numbers are commonly > written. (We agreed, I believe, that spaces should not be legal visual > separators, so the only real combination of interest are things like > ")-" and "-(". I've never seen those in real life.) Right - I was about to point out that spaces are not allowed in URI. If we did want them, we would be doing something like this: tel:+1%20(724)%20742-6826 which, I think, reduces the readability rather than increasing it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Wed Dec 4 11:08:11 2002 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 LAA18968 for ; Wed, 4 Dec 2002 11:08:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4GAYK29294 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 11:10:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GAYv29291 for ; Wed, 4 Dec 2002 11:10:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18919 for ; Wed, 4 Dec 2002 11:07:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GAPv29255; Wed, 4 Dec 2002 11:10:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4G2dv28217 for ; Wed, 4 Dec 2002 11:02:39 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18418 for ; Wed, 4 Dec 2002 10:59:45 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02311; Wed, 4 Dec 2002 11:02:34 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11423; Wed, 4 Dec 2002 11:02:35 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Dec 2002 11:02:34 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5BC5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , Henning Schulzrinne Cc: iptel@ietf.org Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 4 Dec 2002 11:02:33 -0500 Confusion reins. I don't care a whit what is "on the wire" in terms of readability. You don't look at the actual sip message. You look at the presentation of it. What you want to do is to send the spaces escaped. You can escape all of the seps if you want to. What matters is if I send +44 11 22 33 4567 then it displays that way on the other side. It's very hard (we've tried) to build a "pretty printer" that takes an arbitrary number and displays it pleasantly on callerId. It's pretty easy to preserve what was sent. I want to do that. Confusing things even more, the business card in front of me displays a number like: +49 (0) 90 32 / 69 12 64 Slash is on you sep list, right? Then, what do we do about that pesky (0)? It's one of those context thingies, right? This guy is in my contact database that way. If I dial the number, I know how to deal with the zero. However, we don't want to build into the UA the mechanism to translate depending on where you are. That means a proxy does it, or probably the terminating gateway. So, I probably send the zero, but do I need to send context info. I suspect not, but we should think about it. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, December 04, 2002 10:45 AM > To: Henning Schulzrinne > Cc: Rosen, Brian; iptel@ietf.org > Subject: Re: [Iptel] comments on rfc2806bis > > > > > Henning Schulzrinne wrote: > > So much fuss about the minor members of the alphabet :-) > > As you have probably observed, nothing brings out opinions more than > discussions on syntax ;) > > > > > I don't see why > > > > (724)742-6826 > > > > wouldn't work for you. After all, this is how the numbers > are commonly > > written. (We agreed, I believe, that spaces should not be > legal visual > > separators, so the only real combination of interest are > things like > > ")-" and "-(". I've never seen those in real life.) > > Right - I was about to point out that spaces are not allowed > in URI. If > we did want them, we would be doing something like this: > > tel:+1%20(724)%20742-6826 > > which, I think, reduces the readability rather than increasing it. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > 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 mailnull@www1.ietf.org Wed Dec 4 11:24:45 2002 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 LAA19731 for ; Wed, 4 Dec 2002 11:24:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4GR8A30318 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 11:27:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GR8v30315 for ; Wed, 4 Dec 2002 11:27:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19705 for ; Wed, 4 Dec 2002 11:24:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GR3v30306; Wed, 4 Dec 2002 11:27:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GQRv30274 for ; Wed, 4 Dec 2002 11:26:27 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19698 for ; Wed, 4 Dec 2002 11:23:32 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4GQLl8008195 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 4 Dec 2002 11:26:22 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB4GQKdG015958 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Dec 2002 11:26:20 -0500 (EST) Message-ID: <3DEE2C25.1000205@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Jonathan Rosenberg'" , iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis References: <313680C9A886D511A06000204840E1CF030B5BC5@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5BC5@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 04 Dec 2002 11:24:05 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Since there's no agreed-upon semantic distinction between space, ., () and -, I don't think we need to support spaces. +44-11-22-33-4567 will work just as well. I suspect you'll also see +44.11.22.33.4567 and humans will easily deal with either. The (0) issue, indicating optionality, does not arise in E.164 numbers. Rosen, Brian wrote: > It's very hard (we've tried) to build a "pretty printer" that takes > an arbitrary number and displays it pleasantly on callerId. > It's pretty easy to preserve what was sent. I want to do that. We're in agreement on that. The separators, any of them, are enough to render numbers in a way that people can more easily read and transcribe them, compared to a longish string of digits. > > Confusing things even more, the business card in front of me displays > a number like: > +49 (0) 90 32 / 69 12 64 > > Slash is on you sep list, right? > > Then, what do we do about that pesky (0)? You don't worry about it - it's not part of the E.164 number and we long ago agreed that we would not deal with whatever dial prefixes are needed to dial, say, long-distance numbers. It would simply be +49-9032-691264 or +49(9032)691264 > It's one of those context thingies, right? No. Please, please, let's not go there again. We've had a month of that discussion and I'd rather not rehash it. > This guy is in my contact database that way. > If I dial the number, I know how to deal with the zero. > However, we don't want to build into the UA the mechanism to translate > depending on where you are. That means a proxy does it, or > probably the terminating gateway. So, I probably send the zero, but do Whoever actually dials needs to know how E.164 numbers become dial strings. That's not terribly hard, since that entity only needs to detect how local the number is (same country? same area code?) and know its local dialing rules (11-digit dialing? 10-digit dialing? 7-digit dialing? Add 0 or 1 or 011?) The draft talks about this at some length. I gather some systems (ISDN?) even allow E.164 numbers directly or at least allow uniform national dialing without worrying about whether an area code is needed or not. > I need to send context info. I suspect not, but we should think > about it. > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 14:35:50 2002 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 OAA00317 for ; Wed, 4 Dec 2002 14:35:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4JcER14657 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 14:38:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4JcEv14654 for ; Wed, 4 Dec 2002 14:38:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00291 for ; Wed, 4 Dec 2002 14:35:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Jc4v14644; Wed, 4 Dec 2002 14:38:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Ja7v13911 for ; Wed, 4 Dec 2002 14:36:07 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00178 for ; Wed, 4 Dec 2002 14:33:11 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22852; Wed, 4 Dec 2002 14:35:59 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA12038; Wed, 4 Dec 2002 14:36:01 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Dec 2002 14:36:00 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5BC6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: "'Jonathan Rosenberg'" , iptel@ietf.org Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 4 Dec 2002 14:35:57 -0500 Sorry, I'm think we're off the deep end. What is the goal here? I thought it was how you ginned up a URI from a phone number. I was having enough trouble when we punted dial strings; that's what the simplest UA needs to do - send a dial string. Everything else is useless if all you have is a box with a handset and a 10 key pad. But okay, we ignore that one for now. I don't see the difference between a "local number" and the (0) example. It's not a dial string, it's a number that is interpreted within a context (the exchange where the call is made from in this case). In the most typical environment, the caller doesn't know that, only the GW knows that. You HAVE to send the (0) or a full E.164, or the gateway won't know what to do. What is a moderately complex UA to do? Either it has to have rules that always expand to a full E.164, or it has to send the (0). I think the distinction between the global number and anything else is useful, and I'd like to keep it. I think everything else (including dial strings btw) is a local number that is expressed within some context. If I dial 9-011-44-7810-23437 that's a LOCAL NUMBER, expressed in a local context, in this case, the PBX at Marconi in Warrendale. If I dial (0) 90 32 / 69 12 34 that's a local number in a context. There is no difference between those and 6826, which has the SAME context as the first example above. If we are willing to define contexts and parameters like extension, then we can deal with (0) and even dial strings exactly the same way. Again, I AM willing to punt on dial strings for now, I just wanted to make the point that they are just local numbers within some defined context. Then we get to pretty-printing. Seems to me you are in for a penny... on pretty printing - you either preserve the formatting from the source or you don't. Substituting "-" or "." for " " is not preserving formatting. If we want to preserve formatting, which I do, then we allow (escaped) spaces. If we don't, then we should eliminate visual separators entirely. What I really want to do is to look at the "real" problem. Seems to me that in web pages, AORs and the like, there is little benefit in anything but a global number without pretty printing. To me, those are easy. I think any gateway should be able to deal with a global number, as should any UA. The hard part is how real phones talk to real gateways through real proxy servers. I think we should make this version of the RFC work for most cases of that. If we must ignore dial strings, okay, but we can't ignore things like phone numbers in contact lists, callerId and phone books (directories). All of those have local numbers in contexts. That is what they send, that is what they expect to receive, and the tel: URI should handle that gracefully. To me, that includes preservation of formatting. This has been a great source of incompatibility between implementations; sipphones send one thing, gateways expect another is the classic. We need to specify how these things work. In my implementation, the proxy servers translate between what the UA sends and what the gateway expects. We use regular expressions to create dialing plans and translate those plans to whatever the gateways are connected to. Works fine as long as you can send any kind of phone number, and the context of where that number came from, to the proxy. The biggest source of trouble is when a contact in a contact list gets sent from a roaming user. If, for example, I have a contact in my contact list for the guy that sits next to me in Warrendale that is 4823, and I log into a sipphone in the U.K, and then push my speed dial button for that guy, I want his phone to ring. That is not hard, as long as the contact is interpreted in the domain I wrote it in, which is my "home" domain. All I have to do is to get the local (i.e. UK) proxy server to know what domain it is. We need a reasonable syntax for this, and a reasonable naming convention for domains. I WANT to send the (0), and I want to have all the formatting in the URIs. I need to have the context the number came from. Then, I can do whatever translation is needed, find the right gateway, etc. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, December 04, 2002 11:24 AM > To: Rosen, Brian > Cc: 'Jonathan Rosenberg'; iptel@ietf.org > Subject: Re: [Iptel] comments on rfc2806bis > > > Since there's no agreed-upon semantic distinction between > space, ., () > and -, I don't think we need to support spaces. > +44-11-22-33-4567 will > work just as well. I suspect you'll also see +44.11.22.33.4567 and > humans will easily deal with either. The (0) issue, indicating > optionality, does not arise in E.164 numbers. > > Rosen, Brian wrote: > > It's very hard (we've tried) to build a "pretty printer" that takes > > an arbitrary number and displays it pleasantly on callerId. > > It's pretty easy to preserve what was sent. I want to do that. > > We're in agreement on that. The separators, any of them, are > enough to > render numbers in a way that people can more easily read and > transcribe > them, compared to a longish string of digits. > > > > > Confusing things even more, the business card in front of > me displays > > a number like: > > +49 (0) 90 32 / 69 12 64 > > > > Slash is on you sep list, right? > > > > Then, what do we do about that pesky (0)? > > You don't worry about it - it's not part of the E.164 number > and we long > ago agreed that we would not deal with whatever dial prefixes > are needed > to dial, say, long-distance numbers. It would simply be > > +49-9032-691264 > > or > > +49(9032)691264 > > > > It's one of those context thingies, right? > > No. Please, please, let's not go there again. We've had a > month of that > discussion and I'd rather not rehash it. > > > This guy is in my contact database that way. > > If I dial the number, I know how to deal with the zero. > > However, we don't want to build into the UA the mechanism > to translate > > depending on where you are. That means a proxy does it, or > > probably the terminating gateway. So, I probably send the > zero, but do > > Whoever actually dials needs to know how E.164 numbers become dial > strings. That's not terribly hard, since that entity only needs to > detect how local the number is (same country? same area > code?) and know > its local dialing rules (11-digit dialing? 10-digit dialing? 7-digit > dialing? Add 0 or 1 or 011?) > > The draft talks about this at some length. > > I gather some systems (ISDN?) even allow E.164 numbers directly or at > least allow uniform national dialing without worrying about > whether an > area code is needed or not. > > > I need to send context info. I suspect not, but we should think > > about it. > > > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 4 15:15:47 2002 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 PAA01934 for ; Wed, 4 Dec 2002 15:15:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4KIB817270 for iptel-archive@odin.ietf.org; Wed, 4 Dec 2002 15:18:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4KIBv17267 for ; Wed, 4 Dec 2002 15:18:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01927 for ; Wed, 4 Dec 2002 15:15:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4KI3v17256; Wed, 4 Dec 2002 15:18:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4KHIv17216 for ; Wed, 4 Dec 2002 15:17:18 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01888 for ; Wed, 4 Dec 2002 15:14:22 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB4KH9l19306; Wed, 4 Dec 2002 12:17:10 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB4KHLt13599; Wed, 4 Dec 2002 14:17:21 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 12:17:07 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2054F542B@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Henning Schulzrinne'" , "'Alexeitsev, D'" Cc: "'iptel@ietf.org'" Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29BD2.19A2D758" 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, 4 Dec 2002 12:16:59 -0800 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_01C29BD2.19A2D758 Content-Type: text/plain Good. But just to clarify that an E.164 number can NOT have more than 15 digits: - The total length of an E.164 number can NOT be more than 15 digits. - The E.164 number can be either: - Geographic number, where the country code is 1 to 3 digits and the national number is 15-n (where n is 1 to 3). Individual countries can partion the national number into a subscriber number and a an area code subject to the 15-n total lenght maximum. - A global number with a 3 digit country code for global services, and a global subscriber number with up to 12 digits. - An international public telecommunication number with a country code of 3 digit, and id code of 1-4 digit, and a subscriber number of 12-x digits (x=1-4). > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, December 04, 2002 7:39 AM > To: Alexeitsev, D > Cc: iptel@ietf.org > Subject: Re: [Iptel] comments on rfc2806bis > > > The about-to-be-released (07) draft does not impose a length > restriction. Hopefully, that will settle this particular issue. > > Alexeitsev, D wrote: > > Hello All, > > > > > >>Not much of an advantage, but in general it's nice to be able to say > >>"that 1 MB URI you just sent me must be bogus". One less > avenue for a > >>denial-of-service attack. (This obviously does not advocate > fixed length > >>buffers without length checking...) > > > > > > [DA] Thanks for the clarification. I think it is already > possible to > > say that, as one would not find any routing entry for this URI :-) > >>From my experience with the problems that operators are facing with > >>the number length limitations I would not like fixing it exactly to > >>the size of currently defined E.164. It generally good > design to have > >>some future proved reserve in this buffer, but I'm not sure if it > >>possible to recommend any specific value. > > > > Greeting, > > Denis Alexeitsev > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www.ietf.org/mailman/listinfo/iptel > ------_=_NextPart_001_01C29BD2.19A2D758 Content-Type: text/html RE: [Iptel] comments on rfc2806bis

Good.

But just to clarify that an E.164 number can NOT have more than 15 digits:

- The total length of an E.164 number can NOT be more than 15 digits.
- The E.164 number can be either:
  - Geographic number, where the country code is 1 to 3 digits and the
    national number is 15-n (where n is 1 to 3). Individual countries
    can partion the national number into a subscriber number and a
    an area code subject to the 15-n total lenght maximum.
  - A global number with a 3 digit country code for global services, and
    a global subscriber number with up to 12 digits.
  - An international public telecommunication number with a country code
    of 3 digit, and id code of 1-4 digit, and a subscriber number of 12-x
    digits (x=1-4).



> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Wednesday, December 04, 2002 7:39 AM
> To: Alexeitsev, D
> Cc: iptel@ietf.org
> Subject: Re: [Iptel] comments on rfc2806bis
>
>
> The about-to-be-released (07) draft does not impose a length
> restriction. Hopefully, that will settle this particular issue.
>
> Alexeitsev, D wrote:
> > Hello All,
> >
> >
> >>Not much of an advantage, but in general it's nice to be able to say
> >>"that 1 MB URI you just sent me must be bogus". One less
> avenue for a
> >>denial-of-service attack. (This obviously does not advocate
> fixed length
> >>buffers without length checking...)
> >
> >
> > [DA] Thanks for the clarification. I think it is already
> possible to
> > say that, as one would not find any routing entry for this URI :-)
> >>From my experience with the problems that operators are facing with
> >>the number length limitations I would not like fixing it exactly to
> >>the size of currently defined E.164. It generally good
> design to have
> >>some future proved reserve in this buffer, but I'm not sure if it
> >>possible to recommend any specific value.
> >
> > Greeting,
> > Denis Alexeitsev
>
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www.ietf.org/mailman/listinfo/iptel
>

------_=_NextPart_001_01C29BD2.19A2D758-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Thu Dec 5 04:54:39 2002 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 EAA05905 for ; Thu, 5 Dec 2002 04:54:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB59vA609738 for iptel-archive@odin.ietf.org; Thu, 5 Dec 2002 04:57:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59vAv09735 for ; Thu, 5 Dec 2002 04:57:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05883 for ; Thu, 5 Dec 2002 04:54:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59v5v09696; Thu, 5 Dec 2002 04:57:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59uPv09656 for ; Thu, 5 Dec 2002 04:56:25 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05834 for ; Thu, 5 Dec 2002 04:53:22 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for iptel@ietf.org; Thu, 5 Dec 2002 10:47:05 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 10:47:04 +0100 Message-Id: From: "Alexeitsev, D" To: iptel@ietf.org Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 5 Dec 2002 10:47:02 +0100 Hello All I think it could be easier to say that no visual separators are allowed in the tel URI and then it is up to the SIP-phone, mail client whatever to transform the wired user input into the digits string. This would spear us a lot of this kind of discussions. I can not see why would someone start dialling by putting any spaces or brackets in to the telephone number as he dials. This may have unexpected impact on the regular subscriber behaviour where people would start dial brackets on the mobile phones and so on... Anyway people are tending not to remember anything, even not the friendly http URI but use the favourites or telephone books in mobile phones. Greetings, Denis Alexeitsev _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Thu Dec 5 08:32:51 2002 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 IAA10656 for ; Thu, 5 Dec 2002 08:32:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5DZCr22445 for iptel-archive@odin.ietf.org; Thu, 5 Dec 2002 08:35:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5DZCv22442 for ; Thu, 5 Dec 2002 08:35:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10629 for ; Thu, 5 Dec 2002 08:32:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5DZ3v22404; Thu, 5 Dec 2002 08:35:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5DYGv22339 for ; Thu, 5 Dec 2002 08:34:16 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10588 for ; Thu, 5 Dec 2002 08:31:24 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB5DYCbb012318 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 5 Dec 2002 08:34:13 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB5DYBdG022737 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Dec 2002 08:34:12 -0500 (EST) Message-ID: <3DEF5547.40608@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexeitsev, D" CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis 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: Thu, 05 Dec 2002 08:31:51 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit You missed the point of the discussion. The recipient UA (in the SIP case) does not have sufficient information to insert the visual separators. Thus, you're losing valuable (user presentation) information. As noted a few times, URIs *are* meant to be seen and transcribed by humans; see RFC 2396. Nobody can force you to insert visual seps, but that doesn't mean we should take the opportunity away from people. I much prefer tel:+49-2232-2.63.29 to tel:+49223226329 Can we close this discussion now - this is not a real problem. Alexeitsev, D wrote: > Hello All > > I think it could be easier to say that no visual separators are allowed in the tel URI and then it is up to the SIP-phone, mail client whatever to transform the wired user input into the digits string. This would spear us a lot of this kind of discussions. > > I can not see why would someone start dialling by putting any spaces or brackets in to the telephone number as he dials. This may have unexpected impact on the regular subscriber behaviour where people would start dial brackets on the mobile phones and so on... > Anyway people are tending not to remember anything, even not the friendly http URI but use the favourites or telephone books in mobile phones. > > Greetings, > Denis Alexeitsev > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Dec 5 10:29:48 2002 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 KAA16309 for ; Thu, 5 Dec 2002 10:29:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5FWBH31802 for iptel-archive@odin.ietf.org; Thu, 5 Dec 2002 10:32:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5FWBv31799 for ; Thu, 5 Dec 2002 10:32:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16281 for ; Thu, 5 Dec 2002 10:29:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5FW4v31750; Thu, 5 Dec 2002 10:32:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5FVov31677 for ; Thu, 5 Dec 2002 10:31:50 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16212 for ; Thu, 5 Dec 2002 10:28:56 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 5 Dec 2002 16:28:22 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 16:28:21 +0100 Message-Id: From: "Alexeitsev, D" To: hgs@cs.columbia.edu Cc: iptel@ietf.org Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 5 Dec 2002 16:28:15 +0100 Hello All I think I still missing the point, but I agree to close this discussion if I'm the only one who does. If it is only for the called party pleasure problem then, we can recommend to use the display name or any other means that are available to please him. My concerns are about the possible impact on the subscribers behaviour if people would start dialling points, spaces and brackets on the terminals that do not support separators omission just because some of them can. The preferences for visual separators are different around the world anyway, so tel:+49223226329 with more probability will be understood correctly on the other hemisphere as tel:+49-2232-2.63.29 Greetings, Denis Alexeitsev -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, December 05, 2002 2:32 PM To: Alexeitsev, D Cc: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis You missed the point of the discussion. The recipient UA (in the SIP case) does not have sufficient information to insert the visual separators. Thus, you're losing valuable (user presentation) information. As noted a few times, URIs *are* meant to be seen and transcribed by humans; see RFC 2396. Nobody can force you to insert visual seps, but that doesn't mean we should take the opportunity away from people. I much prefer Can we close this discussion now - this is not a real problem. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Thu Dec 5 11:49:00 2002 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 LAA19118 for ; Thu, 5 Dec 2002 11:49:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5GpOv05097 for iptel-archive@odin.ietf.org; Thu, 5 Dec 2002 11:51:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5GpOv05094 for ; Thu, 5 Dec 2002 11:51:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19104 for ; Thu, 5 Dec 2002 11:48:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5GpFv05077; Thu, 5 Dec 2002 11:51:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5GoAv05027 for ; Thu, 5 Dec 2002 11:50:10 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19070 for ; Thu, 5 Dec 2002 11:47:15 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB5GoPBB010112; Thu, 5 Dec 2002 11:50:26 -0500 (EST) Received: from mhammer-w2k02.cisco.com (rtp-vpn1-867.cisco.com [10.82.227.99]) by cia.cisco.com (Mirapoint) with ESMTP id ABJ99426; Thu, 5 Dec 2002 11:39:49 -0500 (EST) Message-Id: <4.3.2.7.2.20021205114419.03e2fcb8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Alexeitsev, D" From: Michael Hammer Subject: RE: [Iptel] comments on rfc2806bis Cc: hgs@cs.columbia.edu, iptel@ietf.org In-Reply-To: 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: Thu, 05 Dec 2002 11:49:54 -0500 Denis, While I think that the processing of what goes into the message on origination could just as easily strip out the separators, the bottom line is that any processes along the signaling path can do that as well if separators are found in the URI before processing the number. But, the key here is not key-presses from phones, but what happens when the URI is presented in a Web page and clicked-on to talk. So it is for the sake of visual displays that this is allowed, not for typical phones. The two forms of URI (with and without separators) should be iso-potent. My only question is whether it would be allowable for a node along the path to normalize the number to a non-separator form to help optimize downstream processing. Is that allowed? Mike At 04:28 PM 12/5/2002 +0100, Alexeitsev, D wrote: >Hello All > >I think I still missing the point, but I agree to close this discussion if >I'm the only one who does. If it is only for the called party pleasure >problem then, we can recommend to use the display name or any other means >that are available to please him. > >My concerns are about the possible impact on the subscribers behaviour if >people would start dialling points, spaces and brackets on the terminals >that do not support separators omission just because some of them can. > >The preferences for visual separators are different around the world >anyway, so >tel:+49223226329 with more probability will be understood correctly on the >other hemisphere as tel:+49-2232-2.63.29 > >Greetings, >Denis Alexeitsev > >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: Thursday, December 05, 2002 2:32 PM >To: Alexeitsev, D >Cc: iptel@ietf.org >Subject: Re: [Iptel] comments on rfc2806bis > > >You missed the point of the discussion. The recipient UA (in the SIP >case) does not have sufficient information to insert the visual >separators. Thus, you're losing valuable (user presentation) >information. As noted a few times, URIs *are* meant to be seen and >transcribed by humans; see RFC 2396. > >Nobody can force you to insert visual seps, but that doesn't mean we >should take the opportunity away from people. I much prefer > > > >Can we close this discussion now - this is not a real problem. >_______________________________________________ >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 mailnull@www1.ietf.org Thu Dec 5 13:16:10 2002 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 NAA22017 for ; Thu, 5 Dec 2002 13:16:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5IIXN11754 for iptel-archive@odin.ietf.org; Thu, 5 Dec 2002 13:18:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5IIXv11751 for ; Thu, 5 Dec 2002 13:18:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22009 for ; Thu, 5 Dec 2002 13:15:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5IIGv11738; Thu, 5 Dec 2002 13:18:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5IGvv11685 for ; Thu, 5 Dec 2002 13:16:57 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21987 for ; Thu, 5 Dec 2002 13:14:02 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB5IGfbb005881 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 5 Dec 2002 13:16:41 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB5IGddG024739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Dec 2002 13:16:40 -0500 (EST) Message-ID: <3DEF977A.5000608@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Jonathan Rosenberg'" , iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis References: <313680C9A886D511A06000204840E1CF030B5BC6@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5BC6@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 05 Dec 2002 13:14:18 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit While I don't claim to follow all of your remarks below, let me try to summarize what I see as consensus positions within the working group: - We emphasize globally unique identifiers assigned within the PSTN (roughly equivalent to the set of E.164-conformant numbers) that are unique everywhere, but may not be reachable from all places. The document calls these global numbers. - In many cases, these identifiers are never dialed, but are used for identification or lookup only. - If they are dialed, we assume that the device connected to a PSTN line or trunk is the only one that truly knows what digits need to be emitted to reach the intended destination successfully. One could argue that this functionality could be split into two parts, but since the dialing process is actually a multi-state process (with timers, waiting for certain network conditions and tones, etc.), it is not clear that this can successfully be done without writing a Turing-complete language (or at least a state-transition language) or re-inventing MGCP or Megaco. Modem AT dial strings come close, but they require a fair amount of external configuration, such as the type of dial-tone expected (e.g., stutter dial-tone) and timers, so this is only modestly helpful. It is well known that AT dial strings are brittle for anything but the most trivial cases since they cannot deal with error cases or anything more complicated than a simple second dial tone and fixed-length waits. (Try creating a dial-string when calling card numbers are involved...) Given the global identifier nature of URI/URNs, I doubt that it is useful to encode dial strings as such. To me, this seems like encoding the egress gateway or local proxy server in a HTTP URI or the outbound SMTP MTA in a mailto URI. - Local numbers are escape hatches in cases where a terminal does not have a global number. They are strongly discouraged; e.g., they would not be needed for normal cases where a business has DID or extensions. They would only be needed for private dialing plans. They are made globally unique by the addition of the phone-context parameter. The phone-context parameter has only two functions: ensuring global uniqueness across tel URIs and detecting whether the URI scope is identical to the local scope. In particular, in the terminology of the document, local numbers are *not* what is actually dialed. (I believe this is where I'm losing Brian's discussion thread.) - Since URIs are meant to be human-readable, it is appropriate to add visual separators that are semantically invisible. All such separators are equivalent and roughly the same as white space in programming languages ("syntactic sugar"), which also comes in several flavors (SP, HT, LF). - We haven't quite decided whether service numbers need special treatment. I hope this helps. Henning Rosen, Brian wrote: > Sorry, I'm think we're off the deep end. > > What is the goal here? > > I thought it was how you ginned up a URI from a phone number. > I was having enough trouble when we punted dial strings; > that's what the simplest UA needs to do - send a dial string. > Everything else is useless if all you have is a box with a > handset and a 10 key pad. But okay, we ignore that one for > now. > > I don't see the difference between a "local number" and the > (0) example. It's not a dial string, it's a number that is > interpreted within a context (the exchange where the call > is made from in this case). In the most typical environment, > the caller doesn't know that, only the GW knows that. > You HAVE to send the (0) or a full E.164, or the gateway > won't know what to do. What is a moderately complex UA to do? > Either it has to have rules that always expand to a full E.164, > or it has to send the (0). > > I think the distinction between the global number and anything > else is useful, and I'd like to keep it. I think everything > else (including dial strings btw) is a local number that is > expressed within some context. If I dial 9-011-44-7810-23437 > that's a LOCAL NUMBER, expressed in a local context, in this case, > the PBX at Marconi in Warrendale. If I dial (0) 90 32 / 69 12 34 > that's a local number in a context. There is no difference > between those and 6826, which has the SAME context as the first > example above. If we are willing to define contexts and > parameters like extension, then we can deal with (0) and even > dial strings exactly the same way. Again, I AM willing > to punt on dial strings for now, I just wanted to make the point > that they are just local numbers within some defined context. > > Then we get to pretty-printing. Seems to me you are in for a > penny... on pretty printing - you either preserve the formatting > from the source or you don't. Substituting "-" or "." for " " is > not preserving formatting. If we want to preserve formatting, > which I do, then we allow (escaped) spaces. If we don't, then > we should eliminate visual separators entirely. > > What I really want to do is to look at the "real" problem. > Seems to me that in web pages, AORs and the like, there is little > benefit in anything but a global number without pretty printing. > To me, those are easy. I think any gateway should be able to > deal with a global number, as should any UA. > > The hard part is how real phones talk to real gateways through real > proxy servers. I think we should make this version of the RFC > work for most cases of that. If we must ignore dial strings, okay, > but we can't ignore things like phone numbers in contact lists, > callerId and phone books (directories). All of those have local > numbers in contexts. That is what they send, that is what they > expect to receive, and the tel: URI should handle that gracefully. > To me, that includes preservation of formatting. > > This has been a great source of incompatibility between > implementations; sipphones send one thing, gateways expect another > is the classic. We need to specify how these things work. > > In my implementation, the proxy servers translate between what > the UA sends and what the gateway expects. We use regular expressions > to create dialing plans and translate those plans to whatever the > gateways are connected to. Works fine as long as you can send any > kind of phone number, and the context of where that number came from, > to the proxy. The biggest source of trouble is when a contact in a > contact list gets sent from a roaming user. If, for example, > I have a contact in my contact list for the guy that sits next to me > in Warrendale that is 4823, and I log into a sipphone in the U.K, > and then push my speed dial button for that guy, I want his phone to > ring. That is not hard, as long as the contact is interpreted in > the domain I wrote it in, which is my "home" domain. All I have to > do is to get the local (i.e. UK) proxy server to know what domain it is. > > We need a reasonable syntax for this, and a reasonable naming > convention for domains. I WANT to send the (0), and I want to have > all the formatting in the URIs. I need to have the context the number > came from. Then, I can do whatever translation is needed, > find the right gateway, etc. > > Brian > > > > > > > > >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Wednesday, December 04, 2002 11:24 AM >>To: Rosen, Brian >>Cc: 'Jonathan Rosenberg'; iptel@ietf.org >>Subject: Re: [Iptel] comments on rfc2806bis >> >> >>Since there's no agreed-upon semantic distinction between >>space, ., () >>and -, I don't think we need to support spaces. >>+44-11-22-33-4567 will >>work just as well. I suspect you'll also see +44.11.22.33.4567 and >>humans will easily deal with either. The (0) issue, indicating >>optionality, does not arise in E.164 numbers. >> >>Rosen, Brian wrote: >> >>>It's very hard (we've tried) to build a "pretty printer" that takes >>>an arbitrary number and displays it pleasantly on callerId. >>>It's pretty easy to preserve what was sent. I want to do that. >> >>We're in agreement on that. The separators, any of them, are >>enough to >>render numbers in a way that people can more easily read and >>transcribe >>them, compared to a longish string of digits. >> >> >>>Confusing things even more, the business card in front of >> >>me displays >> >>>a number like: >>>+49 (0) 90 32 / 69 12 64 >>> >>>Slash is on you sep list, right? >>> >>>Then, what do we do about that pesky (0)? >> >>You don't worry about it - it's not part of the E.164 number >>and we long >>ago agreed that we would not deal with whatever dial prefixes >>are needed >>to dial, say, long-distance numbers. It would simply be >> >>+49-9032-691264 >> >>or >> >>+49(9032)691264 >> >> >> >>>It's one of those context thingies, right? >> >>No. Please, please, let's not go there again. We've had a >>month of that >>discussion and I'd rather not rehash it. >> >> >>>This guy is in my contact database that way. >>>If I dial the number, I know how to deal with the zero. >>>However, we don't want to build into the UA the mechanism >> >>to translate >> >>>depending on where you are. That means a proxy does it, or >>>probably the terminating gateway. So, I probably send the >> >>zero, but do >> >>Whoever actually dials needs to know how E.164 numbers become dial >>strings. That's not terribly hard, since that entity only needs to >>detect how local the number is (same country? same area >>code?) and know >>its local dialing rules (11-digit dialing? 10-digit dialing? 7-digit >>dialing? Add 0 or 1 or 011?) >> >>The draft talks about this at some length. >> >>I gather some systems (ISDN?) even allow E.164 numbers directly or at >>least allow uniform national dialing without worrying about >>whether an >>area code is needed or not. >> >> >>>I need to send context info. I suspect not, but we should think >>>about it. >>> >> _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Thu Dec 5 15:32:47 2002 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 PAA27198 for ; Thu, 5 Dec 2002 15:32:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5KZCQ20584 for iptel-archive@odin.ietf.org; Thu, 5 Dec 2002 15:35:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5KZBv20581 for ; Thu, 5 Dec 2002 15:35:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27139 for ; Thu, 5 Dec 2002 15:32:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5KZ2v20496; Thu, 5 Dec 2002 15:35:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5KWAv20380 for ; Thu, 5 Dec 2002 15:32:10 -0500 Received: from acmepacket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26983 for ; Thu, 5 Dec 2002 15:29:13 -0500 (EST) Received: from RPORTER [63.67.143.2] by acmepacket.com (SMTPD32-7.07) id A7C2762703E2; Thu, 05 Dec 2002 15:32:02 -0500 Message-ID: <066301c29c9d$c21638f0$2a00000a@RPORTER> From: "Rick W. Porter" To: "IPTEL" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0660_01C29C73.D92DE170" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Iptel] Route Capability question(s) 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, 5 Dec 2002 15:34:49 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_0660_01C29C73.D92DE170 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I came across some interesting situations while testing TRIP that seem = to beg some clarification of the negotiated Route Capability. I assume = that TRIP peers internal to an ITAD can have different route = capabilities. My basic questions is what the negotiated route capabilities applies to? = If it means that nothing that passes thru that connection contains a = route type outside the negotiated route capabilities, your LS topology = can create situations where the ITAD is segmented. This violates the = premise that all internal peers have the same info. Additionally, an LS = will likely burn many CPU cycles when during flooding it must tailor a = received message to each internal peer. If it applies to the peer LS (not just the connection), I have questions = arising from a couple scenarios... First, what do you do for a peer who = is not directly connected to you (you never establish a peering session = and negotiate route capabilities with them)? Second, let's assume that = an LS can be (mis)configured to negotiate different route capabilities = with different peers. What is the correct behavior when there are = multiple "paths" to get between two peers with different negotiated = route capabilities? Do you assume the lowest common denominator of = negotiated route capability? One thought that I had is revising the spec to eliminate route = capability negotiation within an ITAD. I'm open to other suggestions, = but at a glance it seems to me the best thing to do. I understand this = does create potential memory allocation problems if you must store all = route types (even those you have no use for). Below are a few RFC 3219 points of interest. =20 later, Rick =20 =20 Section 4.2.1.1.1: "An LS MUST NOT use route types that are not = supported by the peer LS in any particular peering session." If someone = is not directly connected to you, then you have no peering session. Section 5.2.5: "The ReachableRoutes attribute is recomputed at each LS = except where flooding is being used (e.g., within a domain)." Implies = the same message forwarded to everyone. Section 6.3: "The error checks in this section MUST be performed by each = LS upon receipt of every UPDATE message. These error checks MUST occur = before flooding procedures are invoked with internal peers." No mention = is made of checking for unsupported route types. =20 ------=_NextPart_000_0660_01C29C73.D92DE170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I came across some = interesting=20 situations while testing TRIP that seem to beg some clarification of the = negotiated Route Capability. I assume that TRIP peers internal to an = ITAD can=20 have different route capabilities.
 
My basic questions is what = the=20 negotiated route capabilities applies to?
 
If it means that nothing = that passes=20 thru that connection contains a route type outside the negotiated route=20 capabilities, your LS topology can create situations where the ITAD is=20 segmented. This violates the premise that all internal peers have = the same=20 info. Additionally, an LS will likely burn = many CPU cycles=20 when during flooding it must tailor a received message to=20 each internal peer.
 
If it applies to the peer = LS (not=20 just the connection), I have questions arising from a couple = scenarios... First,=20 what do you do for a peer who is not directly connected to you (you = never=20 establish a peering session and negotiate route capabilities with them)? = Second,=20 let's assume that an LS can be (mis)configured to negotiate different = route=20 capabilities with different peers. What is the correct behavior = when there=20 are multiple "paths" to get between two peers with different negotiated = route=20 capabilities? Do you assume the lowest common denominator of negotiated = route=20 capability?
 
One thought that I had is = revising=20 the spec to eliminate route capability negotiation within an ITAD. I'm = open to=20 other suggestions, but at a glance it seems to me the best thing to do. = I=20 understand this does create potential memory allocation problems if you = must=20 store all route types (even those you have no use = for).
 
Below are a few RFC 3219 = points of=20 interest.
 
later,
Rick
 
 
 
Section 4.2.1.1.1: "An LS = MUST NOT=20 use route types that are not supported by the peer LS in any particular = peering=20 session."  If someone is = not=20 directly connected to you, then you have no peering = session.
 
Section 5.2.5: "The = ReachableRoutes=20 attribute is recomputed at each LS except where flooding is being used = (e.g.,=20 within a domain)."  = Implies the same=20 message forwarded to everyone.
 
Section 6.3: "The error = checks in=20 this section MUST be performed by each LS upon receipt of every UPDATE=20 message.  These error = checks MUST=20 occur before flooding procedures are invoked with internal peers." No = mention is=20 made of checking for unsupported route types.
 
------=_NextPart_000_0660_01C29C73.D92DE170-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Dec 6 12:35:15 2002 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 MAA15440 for ; Fri, 6 Dec 2002 12:35:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6HbfJ08788 for iptel-archive@odin.ietf.org; Fri, 6 Dec 2002 12:37:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Hbev08785 for ; Fri, 6 Dec 2002 12:37:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15421 for ; Fri, 6 Dec 2002 12:34:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6HbXv08776; Fri, 6 Dec 2002 12:37:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Harv08129 for ; Fri, 6 Dec 2002 12:36:53 -0500 Received: from imo-m08.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15403 for ; Fri, 6 Dec 2002 12:33:56 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m08.mx.aol.com (mail_out_v34.13.) id r.f5.262b1743 (4560); Fri, 6 Dec 2002 12:36:39 -0500 (EST) Message-ID: Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion - context To: jdrosen@dynamicsoft.com CC: iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_f5.262b1743.2b223a27_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 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 Dec 2002 12:36:39 EST --part1_f5.262b1743.2b223a27_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/4/2002 10:35:45 AM Eastern Standard Time, jdrosen@dynamicsoft.com writes: > [MAP] I agree it has nothing to do with "real" Security, but the description in the draft about verifying that the context matches before using the tel:uri to place a call and rejecting it if it doesn't could be called "security" by some. What else would it be for? I agree, it's not good enough to really qualify as "Security". > > > It does not provide any routing information or anything else about the > > identity of the originator. > > [JR] That has been the point Henning has been trying to make in the last > dozen emails he has sent. > > > As such, it can be anything that the > > receiver can use for a comparison to verify that a call got to the right > > place. > > [JR] No. > > The context is used by the originator, not the receiver. If the > originator gets a URI that it determines is outside of its context, it > [MAP] Different meaning of "originator" and "receiver". By "receiver", I meant the entity that receives the tel:uri, which might be a gateway that "originates" a call into the PSTN, or "originates" ringing of a phone. The comparision that Henning described means that the "originator" (of the tel:uri) just puts it in and the "receiver" (of the tel:uri) uses it (for comparision). Mike Pierce Artel --part1_f5.262b1743.2b223a27_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/4/2002 10:35:45 AM Eastern Standard Time, jdrosen@dynamicsoft.com writes:


Security?? It has nothign to do with security.



[MAP] I agree it has nothing to do with "real" Security, but the description in the draft about verifying that the context matches before using the tel:uri to place a call and rejecting it if it doesn't could be called "security" by some. What else would it be for? I agree, it's not good enough to really qualify as "Security".


> It does not provide any routing information or anything else about the
> identity of the originator.

[JR] That has been the point Henning has been trying to make in the last
dozen emails he has sent.

> As such, it can be anything that the
> receiver can use for a comparison to verify that a call got to the right
> place.

[JR] No.

The context is used by the originator, not the receiver. If the
originator gets a URI that it determines is outside of its context, it
discards the URI as invalid.



[MAP] Different meaning of "originator" and "receiver". By "receiver", I meant the entity that receives the tel:uri, which might be a gateway that "originates" a call into the PSTN, or "originates" ringing of a phone. The comparision that Henning described means that the "originator" (of the tel:uri) just puts it in and the "receiver" (of the tel:uri) uses it (for comparision).

Mike Pierce
Artel

--part1_f5.262b1743.2b223a27_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Dec 6 12:35:18 2002 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 MAA15454 for ; Fri, 6 Dec 2002 12:35:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6Hbi808803 for iptel-archive@odin.ietf.org; Fri, 6 Dec 2002 12:37:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Hbiv08800 for ; Fri, 6 Dec 2002 12:37:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15425 for ; Fri, 6 Dec 2002 12:34:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6HbVv08760; Fri, 6 Dec 2002 12:37:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Harv08127 for ; Fri, 6 Dec 2002 12:36:53 -0500 Received: from imo-m09.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15402 for ; Fri, 6 Dec 2002 12:33:56 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m09.mx.aol.com (mail_out_v34.13.) id e.16c.181fdf15 (4560); Fri, 6 Dec 2002 12:36:40 -0500 (EST) Message-ID: <16c.181fdf15.2b223a28@aol.com> Subject: Re: [Iptel] comments on rfc2806bis To: Brian.Rosen@marconi.com CC: iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_16c.181fdf15.2b223a28_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 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 Dec 2002 12:36:40 EST --part1_16c.181fdf15.2b223a28_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/4/2002 11:11:00 AM Eastern Standard Time, Brian.Rosen@marconi.com writes: > Confusion reins. > [MAP] I'll second that. Here's another. (I'll stick my neck out first - go ahead, chop it off - but E.123 (Feb 2001) is the international standard for the representation of telephone numbers in (printed) human readable format. It defines the format Brian finds on his business card, including the / and spaces. Yes, I think ITU-T went a little out of their scope when they added web addresses and e-mail address formats to E.123, but that's another issue.) Now the next step of confusion: A footnote in E.123 indicates that the hypen is used in some countries as a separator, but that in the Netherlands it is used to indicate the point at which the dialer should wait for another dial tone. Another confusion for the tel:uri: E.123 says that "the ( ) should not be used in an international number". In fact, in E.123, the "spacing" symbols are: spaces, dots, and hypens. It says "only spaces should be used in an international number" and a footnote implies that dots and hypens are allowed but should be phased out. E.123 defines "procedural" symbols as: +, parentheses, slash. I believe some time ago I made the point that there are two separate things: 1. human representation of a number (entry on or display by a terminal) 2. representation in the protocol ( or "on-the wire") Attempts to make these the same are leading to extreme difficulty, bad compromises, endless discussions, etc. I understand the reason for wanting to make the actual protocol human readable, but other things are being added that would cause a lot more trouble for a human than the lack of separators. E.123 covers the human interface representation (item 1). This should not be the issue in the tel:uri. IPTEL needs to concentrate on item 2. If one wanted to design a human interface according to the principles in E.123, there might be, for example, a case in which one could enter multiple telephone numbers separated by a slash (as on Brian's busines card). The functionality might translate this into multiple tel:uri's. (I don't see a single tel:url having multiple telephone numbers.) Mike Pierce Artel --part1_16c.181fdf15.2b223a28_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/4/2002 11:11:00 AM Eastern Standard Time, Brian.Rosen@marconi.com writes:


Confusion reins.

[MAP] I'll second that.

Here's another. (I'll stick my neck out first - go ahead, chop it off - but E.123 (Feb 2001) is the international standard for the representation of telephone numbers in (printed) human readable format. It defines the format Brian finds on his business card, including the / and spaces. Yes, I think ITU-T went a little out of their scope when they added web addresses and e-mail address formats to E.123, but that's another issue.)

Now the next step of confusion: A footnote in E.123 indicates that the hypen is used in some countries as a separator, but that in the Netherlands it is used to indicate the point at which the dialer should wait for another dial tone.

Another confusion for the tel:uri: E.123 says that "the ( ) should not be used in an international number".

In fact, in E.123, the "spacing" symbols are: spaces, dots, and hypens. It says "only spaces should be used in an international number" and a footnote implies that dots and hypens are allowed but should be phased out. E.123 defines "procedural" symbols as: +, parentheses, slash.

I believe some time ago I made the point that there are two separate things:

1. human representation of a number (entry on or display by a terminal)
2. representation in the protocol ( or "on-the wire")

Attempts to make these the same are leading to extreme difficulty, bad compromises, endless discussions, etc. I understand the reason for wanting to make the actual protocol human readable, but other things are being added that would cause a lot more trouble for a human than the lack of separators.

E.123 covers the human interface representation (item 1). This should not be the issue in the tel:uri. IPTEL needs to concentrate on item 2. If one wanted to design a human interface according to the principles in E.123, there might be, for example, a case in which one could enter multiple telephone numbers separated by a slash (as on Brian's busines card). The functionality might translate this into multiple tel:uri's. (I don't see a single tel:url having multiple telephone numbers.)


Mike Pierce
Artel

--part1_16c.181fdf15.2b223a28_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Dec 6 12:45:47 2002 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 MAA15998 for ; Fri, 6 Dec 2002 12:45:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6HmDo09246 for iptel-archive@odin.ietf.org; Fri, 6 Dec 2002 12:48:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6HmCv09243 for ; Fri, 6 Dec 2002 12:48:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15964 for ; Fri, 6 Dec 2002 12:45:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Hm2v09231; Fri, 6 Dec 2002 12:48:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6HjQv09151 for ; Fri, 6 Dec 2002 12:45:26 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15882 for ; Fri, 6 Dec 2002 12:42:29 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB6HjDR3003716 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 6 Dec 2002 12:45:13 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB6HjBdG017273 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Dec 2002 12:45:12 -0500 (EST) Message-ID: <3DF0E195.5080208@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: jdrosen@dynamicsoft.com, iptel@ietf.org Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion - context 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: Fri, 06 Dec 2002 12:42:45 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [MAP] I agree it has nothing to do with "real" Security, but the > description in the draft about verifying that the context matches before > using the tel:uri to place a call and rejecting it if it doesn't could > be called "security" by some. What else would it be for? I agree, it's > not good enough to really qualify as "Security". Frankly, I don't care what misinformed people call things. It has about as much to do with security as rejecting a misdirected email that somehow founds its way to cs.columbia.edu. The whole point is that you want to prevent accidents and make error diagnosis easier. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Dec 6 12:49:44 2002 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 MAA16098 for ; Fri, 6 Dec 2002 12:49:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6HqBU09440 for iptel-archive@odin.ietf.org; Fri, 6 Dec 2002 12:52:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6HqAv09437 for ; Fri, 6 Dec 2002 12:52:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16084 for ; Fri, 6 Dec 2002 12:49:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Hq2v09413; Fri, 6 Dec 2002 12:52:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Hp1v09340 for ; Fri, 6 Dec 2002 12:51:01 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16066 for ; Fri, 6 Dec 2002 12:48:04 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB6HooR3004171 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 6 Dec 2002 12:50:50 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB6HomdG018070 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Dec 2002 12:50:49 -0500 (EST) Message-ID: <3DF0E2E6.8030109@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: Brian.Rosen@marconi.com, iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis References: <16c.181fdf15.2b223a28@aol.com> In-Reply-To: <16c.181fdf15.2b223a28@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 06 Dec 2002 12:48:22 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There has been no real, technical problem identified with keeping the visual separators, beyond "taste" problem. Can we please close this issue? People can indeed populate tel URIs according to the guidelines of E.123 (minus the spaces, which are generally a pain in URIs). Just like nobody can force people to use the correct ISBN hyphenation, we just have to make sure that nothing breaks if a poor user hasn't read E.123 lately. Obviously, functionality is unaffected by such user punctuation mistakes. The argument about human readability are not with the tel URI, but with RFC 2396. I suggest you take your complaints to the relevant URI working group. Mpierce1@aol.com wrote: > In a message dated 12/4/2002 11:11:00 AM Eastern Standard Time, > Brian.Rosen@marconi.com writes: > > >> Confusion reins. > > > [MAP] I'll second that. > > Here's another. (I'll stick my neck out first - go ahead, chop it off - > but E.123 (Feb 2001) is the international standard for the > representation of telephone numbers in (printed) human readable format. > It defines the format Brian finds on his business card, including the / > and spaces. Yes, I think ITU-T went a little out of their scope when > they added web addresses and e-mail address formats to E.123, but that's > another issue.) > > Now the next step of confusion: A footnote in E.123 indicates that the > hypen is used in some countries as a separator, but that in the > Netherlands it is used to indicate the point at which the dialer should > wait for another dial tone. > > Another confusion for the tel:uri: E.123 says that "the ( ) should not > be used in an international number". > > In fact, in E.123, the "spacing" symbols are: spaces, dots, and hypens. > It says "only spaces should be used in an international number" and a > footnote implies that dots and hypens are allowed but should be phased > out. E.123 defines "procedural" symbols as: +, parentheses, slash. > > I believe some time ago I made the point that there are two separate > things: > > 1. human representation of a number (entry on or display by a terminal) > 2. representation in the protocol ( or "on-the wire") > > Attempts to make these the same are leading to extreme difficulty, bad > compromises, endless discussions, etc. I understand the reason for > wanting to make the actual protocol human readable, but other things are > being added that would cause a lot more trouble for a human than the > lack of separators. > > E.123 covers the human interface representation (item 1). This should > not be the issue in the tel:uri. IPTEL needs to concentrate on item 2. > If one wanted to design a human interface according to the principles in > E.123, there might be, for example, a case in which one could enter > multiple telephone numbers separated by a slash (as on Brian's busines > card). The functionality might translate this into multiple tel:uri's. > (I don't see a single tel:url having multiple telephone numbers.) > > > Mike Pierce > Artel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Dec 6 14:40:55 2002 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 OAA21494 for ; Fri, 6 Dec 2002 14:40:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6JhLE16210 for iptel-archive@odin.ietf.org; Fri, 6 Dec 2002 14:43:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6JhLv16207 for ; Fri, 6 Dec 2002 14:43:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21466 for ; Fri, 6 Dec 2002 14:40:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Jh4v16198; Fri, 6 Dec 2002 14:43:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6JgUv16184 for ; Fri, 6 Dec 2002 14:42:30 -0500 Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21451 for ; Fri, 6 Dec 2002 14:39:34 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.11.6) id gB6JgPQ74051; Fri, 6 Dec 2002 14:42:25 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Iptel] comments on rfc2806bis (maximum length) Message-ID: <001001c29d5f$b94adba0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <4.3.2.7.2.20021204092647.00b127c8@cia.cisco.com> 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, 6 Dec 2002 14:43:16 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I seem to remember 15 being the magic > maximum number from E.164 I think. Yes. Excluding the international prefix, the maximum number is 15 digits. However I think that rfc2806 currently allows an infinite number of visual separators among those 15 digits. :) _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Dec 6 14:45:48 2002 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 OAA21685 for ; Fri, 6 Dec 2002 14:45:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6JmEu16400 for iptel-archive@odin.ietf.org; Fri, 6 Dec 2002 14:48:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6JmEv16397 for ; Fri, 6 Dec 2002 14:48:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21671 for ; Fri, 6 Dec 2002 14:45:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Jm7v16375; Fri, 6 Dec 2002 14:48:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6JlWv16318 for ; Fri, 6 Dec 2002 14:47:32 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21628 for ; Fri, 6 Dec 2002 14:44:36 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB6JlPR3018140 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 6 Dec 2002 14:47:26 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB6JlOdG003143 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Dec 2002 14:47:25 -0500 (EST) Message-ID: <3DF0FE39.8030103@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: brett@broadsoft.com CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis (maximum length) References: <001001c29d5f$b94adba0$2b01a8c0@broadsoft.com> In-Reply-To: <001001c29d5f$b94adba0$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 06 Dec 2002 14:44:57 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Version -07, in the I-D editor's hands, dispenses with infinity, based on the discussion here. In general, it might be useful if folks took a moment to read the new draft before commenting. A number of editorial changes were made that reflect the discussion. I'd hate to go over the same old territory again and again. For those who can't wait: http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-07.txt http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-07.pdf Henning Brett Tate wrote: >>I seem to remember 15 being the magic >>maximum number from E.164 I think. > > > Yes. Excluding the international prefix, > the maximum number is 15 digits. > > However I think that rfc2806 currently > allows an infinite number of visual > separators among those 15 digits. :) > > _______________________________________________ > 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 mailnull@www1.ietf.org Fri Dec 6 17:00:46 2002 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 RAA26755 for ; Fri, 6 Dec 2002 17:00:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6M3Dh24360 for iptel-archive@odin.ietf.org; Fri, 6 Dec 2002 17:03:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6M3Dv24357 for ; Fri, 6 Dec 2002 17:03:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26738 for ; Fri, 6 Dec 2002 17:00:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6M34v24348; Fri, 6 Dec 2002 17:03:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6M2Vv24323 for ; Fri, 6 Dec 2002 17:02:31 -0500 Received: from 68.114.197.229 ([68.114.197.229]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26714 for ; Fri, 6 Dec 2002 16:59:29 -0500 (EST) Received: from mail1.icebreakerworld.com (mail1.icebreakerworld.com [170.224.13.91]) by x73.infopact.nl (8.12.0/8.12.0) with ESMTP id gAFD32sN029686 for ; Fri, 6 Dec 2002 22:02:03 +0000 Received: from MX2.estpak.ee (ld3.estpak.ee [194.126.101.102]) by post.lanck.net (8.12.6/8.12.6) with SMTP id gAPDQ3qp006011 for ; Fri, 6 Dec 2002 22:02:03 +0000 Received: from Sender ([213.21.211.91]) by n2.peterstar.net (8.11.6/8.11.4) with SMTP id gAT9iHt04280 for ; Fri, 6 Dec 2002 22:02:03 +0000 From: "andreas_j" To: "" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Mozilla 4.51 [ru] (Win98; I) Message-ID: <000501c29867$1be7e170$0c64a8c0@WSBALTIC2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Iptel] Bulk Email Sending & Bullet Proof Web Hosting 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 Dec 2002 22:02:03 +0000 We offer you e-mail addresses databases for advertisement mailing; we sell databases also carry out mailing and hosting for the advertising projects. We can work on a turnkey project create a site with original design, program and subject contents. Our databases updates constantly with the e-mail addresses from all over the world. Their validity and originality are verified. Today they contains over than 50 million addresses. We use our own mailing soft which can be ideally adjusted for every customer. We have a high-speed channel and a high power server. The constant of our service demand allows us to keep low prices. http://www.e-mailpromo.net Please don't hesitate to contact us anytime! We'll be happy to answer every your question! http://www.e-mailpromo.net We received your address from a public area. We apologize if this letter has reached you by mistake. We'll not disturb you any more. NB. This message is sent in compliance with the new e-mail bill section 301. Under Bill S. 1618 TITLE III passed by the 105th US Congress. This message can not be considered as Spam as long as we include the way to be Removed, Paragraph (a)(c) of S. 1618. TO REMOVE YOUR ADDRESS FROM YOUR MAILING LIST: you can send message to info@e-mailpromo.net with Subject "Remove". _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Sun Dec 8 15:23:03 2002 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 PAA08674 for ; Sun, 8 Dec 2002 15:23:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB8KPVO07244 for iptel-archive@odin.ietf.org; Sun, 8 Dec 2002 15:25:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB8KPVv07241 for ; Sun, 8 Dec 2002 15:25:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08663 for ; Sun, 8 Dec 2002 15:22:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB8KPGv07232; Sun, 8 Dec 2002 15:25:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB8KOMv07201 for ; Sun, 8 Dec 2002 15:24:22 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08651 for ; Sun, 8 Dec 2002 15:21:22 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB8KOGFp012131 for ; Sun, 8 Dec 2002 12:24:16 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id EKN00131; Sun, 8 Dec 2002 12:24:38 -0800 (PST) From: "Cullen Jennings" To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Iptel] Jabber logs from last meeting 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, 8 Dec 2002 12:27:17 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Nothing of any use was put in the IM session but, in case you want to see, .... http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 9 11:21:41 2002 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 LAA16141 for ; Mon, 9 Dec 2002 11:21:41 -0500 (EST) 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 gB9GNg208113; Mon, 9 Dec 2002 11:23:42 -0500 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 gB9GEW208008 for ; Mon, 9 Dec 2002 11:14:32 -0500 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.5/8.12.5) with ESMTP id gB9GEThN092777 for ; Mon, 9 Dec 2002 11:14:29 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 69304443A7; Mon, 9 Dec 2002 11:14:20 -0500 (EST) 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 4867A443A6 for ; Mon, 9 Dec 2002 11:14:20 -0500 (EST) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id gB9GEIa45439 for ; Mon, 9 Dec 2002 11:14:18 -0500 (EST) Received: from relay2.clb.oleane.net (relay2.clb.oleane.net [213.56.31.22]) by dusty.research.bell-labs.com (8.12.6/8.12.6) with ESMTP id gB9GE1Gm003358 for ; Mon, 9 Dec 2002 11:14:02 -0500 (EST) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by relay2.clb.oleane.net with SMTP id gB9GE9Pw028514 for ; Mon, 9 Dec 2002 17:14:09 +0100 Message-ID: <026701c29f9f$073f4a80$0601a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0264_01C29FA7.68C9B6C0" 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 Conference 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: Mon, 9 Dec 2002 17:21:28 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_0264_01C29FA7.68C9B6C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A Free SIP Server in the International SIP Conference Registration = Package=20 Each participant to the International SIP'03 conference will be given = iptel.org's SIP server in his registration package. It is a free SIP = server recently released to the community. It will be in a form of a = credit-card-size CD with an enclosed description.=20 iptel.org is a non-profit knowledge-advancement company under umbrella = of FhG (Germany's reasearch network, non-profit too). All other outcomes = (currently, on-line knowledge base and the SIP server) are freely = available to the community at no cost. Please get more details at: = http://www.iptel.org=20 Get all informations on the International SIP event at: = http://www.upperside.fr/intersip03/sip03intro.htm=20 ------=_NextPart_000_0264_01C29FA7.68C9B6C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A=20 Free SIP Server in the International SIP Conference Registration Package =

Each participant to the International SIP'03 = conference will=20 be given iptel.org's SIP server in his registration package. It is a = free SIP=20 server recently released to the community. It will be in a form of a=20 credit-card-size CD with an enclosed description. =

iptel.org is a=20 non-profit knowledge-advancement company under umbrella of FhG = (Germany's=20 reasearch network, non-profit too). All other outcomes (currently, = on-line=20 knowledge base and the SIP server) are freely available to the community = at no=20 cost. Please get more details at: http://www.iptel.org

Get all=20 informations on the International SIP event at: http://www.upp= erside.fr/intersip03/sip03intro.htm=20
 
------=_NextPart_000_0264_01C29FA7.68C9B6C0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 9 13:02:53 2002 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 NAA22072 for ; Mon, 9 Dec 2002 13:02:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9I5K419651 for iptel-archive@odin.ietf.org; Mon, 9 Dec 2002 13:05:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9I5Kv19648 for ; Mon, 9 Dec 2002 13:05:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22038 for ; Mon, 9 Dec 2002 13:02:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9I58v19632; Mon, 9 Dec 2002 13:05:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9I4Nv19602 for ; Mon, 9 Dec 2002 13:04:23 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22025 for ; Mon, 9 Dec 2002 13:01:24 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07519; Mon, 9 Dec 2002 13:04:14 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA17095; Mon, 9 Dec 2002 13:04:16 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Dec 2002 13:04:15 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5BDA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Mpierce1@aol.com Cc: iptel@ietf.org Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 9 Dec 2002 13:04:10 -0500 Sorry to be obstinate, but I don't get it. The "technical problem" is that the set of visual separators proposed does match what real people use. Either you fix that, or I think we should get rid of all the separators. Why is a subset interesting? If you can't reproduce what the users actually use, what are you providing? If I typed "(724) 742-6826" and it got mangled to 724.742-6826 in the URI is that helpful? I think not. At this point, I think we should eliminate separators. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, December 06, 2002 12:48 PM > To: Mpierce1@aol.com > Cc: Brian.Rosen@marconi.com; iptel@ietf.org > Subject: Re: [Iptel] comments on rfc2806bis > > > There has been no real, technical problem identified with keeping the > visual separators, beyond "taste" problem. Can we please > close this issue? > > People can indeed populate tel URIs according to the > guidelines of E.123 > (minus the spaces, which are generally a pain in URIs). Just > like nobody > can force people to use the correct ISBN hyphenation, we just have to > make sure that nothing breaks if a poor user hasn't read > E.123 lately. > Obviously, functionality is unaffected by such user > punctuation mistakes. > > The argument about human readability are not with the tel > URI, but with > RFC 2396. I suggest you take your complaints to the relevant > URI working > group. > > Mpierce1@aol.com wrote: > > In a message dated 12/4/2002 11:11:00 AM Eastern Standard Time, > > Brian.Rosen@marconi.com writes: > > > > > >> Confusion reins. > > > > > > [MAP] I'll second that. > > > > Here's another. (I'll stick my neck out first - go ahead, > chop it off - > > but E.123 (Feb 2001) is the international standard for the > > representation of telephone numbers in (printed) human > readable format. > > It defines the format Brian finds on his business card, > including the / > > and spaces. Yes, I think ITU-T went a little out of their > scope when > > they added web addresses and e-mail address formats to > E.123, but that's > > another issue.) > > > > Now the next step of confusion: A footnote in E.123 > indicates that the > > hypen is used in some countries as a separator, but that in the > > Netherlands it is used to indicate the point at which the > dialer should > > wait for another dial tone. > > > > Another confusion for the tel:uri: E.123 says that "the ( ) > should not > > be used in an international number". > > > > In fact, in E.123, the "spacing" symbols are: spaces, dots, > and hypens. > > It says "only spaces should be used in an international > number" and a > > footnote implies that dots and hypens are allowed but > should be phased > > out. E.123 defines "procedural" symbols as: +, parentheses, slash. > > > > I believe some time ago I made the point that there are two > separate > > things: > > > > 1. human representation of a number (entry on or display by > a terminal) > > 2. representation in the protocol ( or "on-the wire") > > > > Attempts to make these the same are leading to extreme > difficulty, bad > > compromises, endless discussions, etc. I understand the reason for > > wanting to make the actual protocol human readable, but > other things are > > being added that would cause a lot more trouble for a human > than the > > lack of separators. > > > > E.123 covers the human interface representation (item 1). > This should > > not be the issue in the tel:uri. IPTEL needs to concentrate > on item 2. > > If one wanted to design a human interface according to the > principles in > > E.123, there might be, for example, a case in which one could enter > > multiple telephone numbers separated by a slash (as on > Brian's busines > > card). The functionality might translate this into multiple > tel:uri's. > > (I don't see a single tel:url having multiple telephone numbers.) > > > > > > Mike Pierce > > Artel > > > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 9 13:05:40 2002 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 NAA22224 for ; Mon, 9 Dec 2002 13:05:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9I88520415 for iptel-archive@odin.ietf.org; Mon, 9 Dec 2002 13:08:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9I87v20412 for ; Mon, 9 Dec 2002 13:08:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22215 for ; Mon, 9 Dec 2002 13:05:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9I82v20383; Mon, 9 Dec 2002 13:08:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9I7mv20356 for ; Mon, 9 Dec 2002 13:07:48 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22203 for ; Mon, 9 Dec 2002 13:04:50 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB9I7aR3029285 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 9 Dec 2002 13:07:40 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gB9I7YdG013568 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Dec 2002 13:07:35 -0500 (EST) Message-ID: <3DF4DC10.1070402@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: Mpierce1@aol.com, iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis References: <313680C9A886D511A06000204840E1CF030B5BDA@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5BDA@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 09 Dec 2002 13:08:16 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Correction: you can certainly type see tel:+1(724)742-6826. () are legal separators. Rosen, Brian wrote: > Sorry to be obstinate, but I don't get it. The "technical problem" > is that the set of visual separators proposed does match what real people > use. > Either you fix that, or I think we should get rid of all the separators. > Why is a subset interesting? If you can't reproduce what the users > actually use, what are you providing? If I typed "(724) 742-6826" and > it got mangled to 724.742-6826 in the URI is that helpful? I think not. > > At this point, I think we should eliminate separators. > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 9 16:15:56 2002 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 QAA02437 for ; Mon, 9 Dec 2002 16:15:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9LIQZ00304 for iptel-archive@odin.ietf.org; Mon, 9 Dec 2002 16:18:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9LIQv00301 for ; Mon, 9 Dec 2002 16:18:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02393 for ; Mon, 9 Dec 2002 16:15:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9LI9v32733; Mon, 9 Dec 2002 16:18:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9LENv32624 for ; Mon, 9 Dec 2002 16:14:23 -0500 Received: from web14801.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02255 for ; Mon, 9 Dec 2002 16:11:22 -0500 (EST) Message-ID: <20021209211416.95282.qmail@web14801.mail.yahoo.com> Received: from [63.186.1.154] by web14801.mail.yahoo.com via HTTP; Mon, 09 Dec 2002 13:14:16 PST From: helen wang To: iptel@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Iptel] Unsubscribe! 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 Dec 2002 13:14:16 -0800 (PST) Hello: I want to unsubscribe from your email list! Thanks! Helen Wang __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 10 04:03:42 2002 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 EAA02098 for ; Tue, 10 Dec 2002 04:03:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBA96HV15139 for iptel-archive@odin.ietf.org; Tue, 10 Dec 2002 04:06:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBA96Hv15136 for ; Tue, 10 Dec 2002 04:06:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02087 for ; Tue, 10 Dec 2002 04:03:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBA966v15127; Tue, 10 Dec 2002 04:06:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBA95jv15098 for ; Tue, 10 Dec 2002 04:05:45 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02081 for ; Tue, 10 Dec 2002 04:02:37 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Iptel] comments on rfc2806bis MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <06CF906FE3998C4E944213062009F1620DEE4D@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Iptel] comments on rfc2806bis Thread-Index: AcKci1bguAJINKuxTlauwk/4xOvq6QDlUDog From: "Stastny Richard" To: "Henning Schulzrinne" , "Rosen, Brian" Cc: "Jonathan Rosenberg" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBA95jv15099 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, 10 Dec 2002 10:08:42 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi folks > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, December 05, 2002 7:14 PM > To: Rosen, Brian > Cc: 'Jonathan Rosenberg'; iptel@ietf.org > Subject: Re: [Iptel] comments on rfc2806bis > > > While I don't claim to follow all of your remarks below, let > me try to > summarize what I see as consensus positions within the working group: > > - We emphasize globally unique identifiers assigned within the PSTN > (roughly equivalent to the set of E.164-conformant numbers) that are > unique everywhere, but may not be reachable from all places. The > document calls these global numbers. I do not really know why you try to define something new here. In the PSTN the globally unique identifiers ARE the E.164 numbers as defined in ITU-T Rec.E.164, which is also called the global NUMBERING plan In ITU-T Rec. E.164 it is also defined, that the maximum lenght of E.164 numbers is 15 (period). > > - In many cases, these identifiers are never dialed, but are used for > identification or lookup only. Incorrect, these identifiers are NEVER dialled, because there is no globally unique DIALING plan. On every PSTN line you are ALWAYS in a (national and/or local) context, so to DIAL an E.164 number, you ALWAYS have to DIAL the international access code (e.g. 00 or 011 or whatever). Per convention (and I think there is even an recommendation out there describing this) one may write E.164 numbers in the format e.g. +1-123-123-1234. In mobile phone systems (e.g. GSM) it is allowed to enter (dial?) the "+" character at the terminal, which is translated by the system into the access code used in the current (roamed into) network. > > - If they are dialed, we assume that the device connected to > a PSTN line > or trunk is the only one that truly knows what digits need to > be emitted > to reach the intended destination successfully. One could argue that > this functionality could be split into two parts, but since > the dialing > process is actually a multi-state process (with timers, waiting for > certain network conditions and tones, etc.), it is not clear > that this > can successfully be done without writing a Turing-complete > language (or > at least a state-transition language) or re-inventing MGCP or Megaco. > Modem AT dial strings come close, but they require a fair amount of > external configuration, such as the type of dial-tone expected (e.g., > stutter dial-tone) and timers, so this is only modestly > helpful. It is > well known that AT dial strings are brittle for anything but the most > trivial cases since they cannot deal with error cases or > anything more > complicated than a simple second dial tone and fixed-length > waits. (Try > creating a dial-string when calling card numbers are involved...) > > Given the global identifier nature of URI/URNs, I doubt that it is > useful to encode dial strings as such. To me, this seems like > encoding > the egress gateway or local proxy server in a HTTP URI or the > outbound > SMTP MTA in a mailto URI. > > - Local numbers are escape hatches in cases where a terminal does not > have a global number. They are strongly discouraged; e.g., they would > not be needed for normal cases where a business has DID or > extensions. > They would only be needed for private dialing plans. They are made > globally unique by the addition of the phone-context parameter. The > phone-context parameter has only two functions: ensuring global > uniqueness across tel URIs and detecting whether the URI scope is > identical to the local scope. > > In particular, in the terminology of the document, local numbers are > *not* what is actually dialed. (I believe this is where I'm losing > Brian's discussion thread.) IMHO opinion you should not invent your own terminology, there is enough confusion out there anyway. As I described above, there is a global NUMBERING PLAN but no global DIALING Plan. But there are NATIONAL, LOCAL and PRIVATE NUMBERING and DIALING plans. I take the European example, because it is more familiar to me, but the same (with other access codes) is valid in the NANP. A PSTN line is ALWAYs (as already stated above) either in a local (or in countries with a CLOSED numbering plan -see below- in a national) dialing plan. So if a number is dialled, it is assumed by default that it is a local number (e.g. my office number can be dialled in Vienna by 789780 (you may, but not need to, dial in addition the extension 32). If you dial this number from another city in Austria, you have to escape with "0" to the national numbering plan, add the area code "1" for Vienna and dial 0-1-79780. If you dial the number from Germany (they have the same escape code as in Austria) you have to dial the international access code "00" and dial also the country code for Austria "43" 00-43-1-79780. In the US you would DIAL 011-43-1-79780. In writing (or on a GSM phone) you may also use +43179780. Comment: A closed numbering plan is one where no local numbers exists, so you always have to dial the national numbers (with area code, e.g. France, or within the networks of mobile operators) BTW, as you may have recognised, in Austria (and other countries) we have not only an open numbering plan, but also a numbering plan with variable lenght. Both the lenght of the area code (1-4 digits) and the local numbers vary (3-7 digits). Furthermore, the lenght of the DDI (dial in) in not fixed, although there is a strong recommendation, that the number of the E.164 number plus the DDI digit shall not exceed 15 digits. This and also the access codes (and the not mentioned Carrier access code and Carrier identification codes (CAC+CIC) require, that PSTN switched can handle at least 18 (better 24) dialled digits. (also some routing numbers may add to the digit lenght) What you mean above with "local" numbers is really PRIVATE numbers or better numbers out of a PRIVATE numbering plan. If somebody is dialing my extension from within the office, he/she is dialing 32. If I want to dial home from my office (+43-1-9793321), I have to dial "0" to get a "line" and then the local Vienna number (0-9793321). Somebody in Germany in an office may need to dial 0-00-43-1-9793321. In the Mariott in Atlanta I may need to dial 9-011-43-1-9793321. On the other hand, in my mobile phone I have this number stored as +4319793321, which works in all mobile networks (even in the US) and in the home network. Remark: in mobile networks (at least in Austria) you always need to dial national numbers, never local numbers - closed numbering plan - see above). My recommendation is that always E.164 numbers shall be used if the number can be given as E.164 number, so NO context is needed. A context SHALL only be used if the number CANNOT be expressed as E.164 number (e.g. a network specific number (e.g. used by some mobile operators), or a DDI number which cannot be dialled from outside a private network). An 800 number (+800, or +1-800, or +43-800) does not require a context. The 800 number MAY be routed differently (to different PSTN numbers), if dialed within a specific context (but this information should be contained in the originating info and in the translation database translating the 800 number to PSTN numbers, but not in the context attached to the tel: URI of the 800 number. Warning: Keeping in mind the current discussion of the possibility to use with VoIP any number anywhere in the world, the assumption that the originating number (CLI) can be used to derive the originating location as no longer valid. A complete new system needs to be defined. If you may use New York City area codes in Montana or Idaho over DSL lines, the idea to route your 800 number dialed to a NYC Pizza service has a serious flaw (you may get a very cold pizza). (see also the VoIP Numbering Issue from Verizon, Qwest and Bell South) to NANC. best regards Richard Stastny _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 10 09:16:54 2002 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 JAA06822 for ; Tue, 10 Dec 2002 09:16:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAEJLZ31097 for iptel-archive@odin.ietf.org; Tue, 10 Dec 2002 09:19:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAEJLv31094 for ; Tue, 10 Dec 2002 09:19:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06804 for ; Tue, 10 Dec 2002 09:16:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAEJ5v31081; Tue, 10 Dec 2002 09:19:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAEIov31055 for ; Tue, 10 Dec 2002 09:18:50 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06778 for ; Tue, 10 Dec 2002 09:15:52 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gBAEIkR3006432 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 10 Dec 2002 09:18:46 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gBAEIjdG018838 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Dec 2002 09:18:46 -0500 (EST) Message-ID: <3DF5F839.8020009@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard CC: iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis References: <06CF906FE3998C4E944213062009F1620DEE4D@oefeg-s02.oefeg.loc> In-Reply-To: <06CF906FE3998C4E944213062009F1620DEE4D@oefeg-s02.oefeg.loc> 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, 10 Dec 2002 09:20:41 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I've removed much of the original message since it deals with dialing numbers/strings, which, as the draft clearly states up front, are out of scope. May I suggest that we do not further burden the discussion with this non-topic? > I do not really know why you try to define something new here. In the > PSTN the > globally unique identifiers ARE the E.164 numbers as defined in ITU-T > Rec.E.164, > which is also called the global NUMBERING plan > > In ITU-T Rec. E.164 it is also defined, that the maximum lenght of E.164 > numbers > is 15 (period). I'm not defining anything new here. I don't see the benefit of restricting the syntax of tel URIs to limit the length, since the underlying name space (E.164) already does this. (If E.164 changes its mind, it would be nice if the spec and implementations are unaffected.) If you read the spec, you'll find that it references the 15-digit limit. > Incorrect, these identifiers are NEVER dialled, because there is no > globally > unique DIALING plan. On every PSTN line you are ALWAYS in a (national > and/or local) > context, so to DIAL an E.164 number, you ALWAYS have to DIAL the > international > access code (e.g. 00 or 011 or whatever). Per convention (and I think > there is > even an recommendation out there describing this) one may write E.164 > numbers > in the format e.g. +1-123-123-1234. In mobile phone systems (e.g. GSM) > it is > allowed to enter (dial?) the "+" character at the terminal, which is > translated > by the system into the access code used in the current (roamed into) > network. You provide an example where the user "dials" the E.164 number, so I don't see why my statement is wrong. > IMHO opinion you should not invent your own terminology, there is enough > confusion out there anyway. As always, constructive suggestions are most welcome. > > As I described above, there is a global NUMBERING PLAN but no global > DIALING Plan. The draft does not mention global dialing plans. > What you mean above with "local" numbers is really PRIVATE numbers or > better numbers out of a PRIVATE numbering plan. If somebody is dialing > my extension from within the office, he/she is dialing 32. The 'local number' terminology is a holdover from RFC 2806. I'm happy to change it to 'private number' if that is less confusing. > My recommendation is that always E.164 numbers shall be used if the > number > can be given as E.164 number, so NO context is needed. A context SHALL > only be > used if the number CANNOT be expressed as E.164 number (e.g. a network > specific > number (e.g. used by some mobile operators), or a DDI number which > cannot be > dialled from outside a private network). I'm confused by this statement. Nobody who has actually followed the debate has suggested that E.164 numbers need a context. We determined several weeks ago that 800# qualify as bona fide E.164 numbers, after resolving the issue of possible non-unique assignment. > > An 800 number (+800, or +1-800, or +43-800) does not require a context. Again, I've said this many times, in many different ways. I'm not sure why this is being raised again. My summary did not say anything different, either. In general, I would find it helpful if people took time to disagree with (and suggest improvements to) the actual text in the document, rather than with the terse summaries or rephrasings on the mailing list. Henning _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 10 09:34:47 2002 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 JAA07324 for ; Tue, 10 Dec 2002 09:34:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAEbEt32267 for iptel-archive@odin.ietf.org; Tue, 10 Dec 2002 09:37:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAEbEv32264 for ; Tue, 10 Dec 2002 09:37:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07299 for ; Tue, 10 Dec 2002 09:34:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAEb2v31813; Tue, 10 Dec 2002 09:37:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAEaHv31651 for ; Tue, 10 Dec 2002 09:36:17 -0500 Received: from smtp.latinmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07156 for ; Tue, 10 Dec 2002 09:33:19 -0500 (EST) Received: from latinmail.com.com (unknown [216.167.63.40]) by smtp.latinmail.com (Postfix) with SMTP id E145818B9B for ; Tue, 10 Dec 2002 09:36:11 -0500 (EST) To: iptel@ietf.org From: Victor Peters X-Mailer: LatinMail v3.0 -- http://www.latinmail.com.com Content-Type: text/plain; charset=us-ascii X-Priority: 3 Message-Id: <20021210143611.E145818B9B@smtp.latinmail.com> Subject: [Iptel] Hello (From Dr. Victor Peters) 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, 10 Dec 2002 09:36:14 -0500 From: Dr. Victor Peters Chief Financial Director Independent National Electoral Commission (INEC) Lagos - Nigeria Date: 10th December, 2002 Dear Sir, RE: INVESTMENT & CONFIDENTIAL BUSINESS PROPOSAL It is my warmest pleasure writing you this confidential business offer irrespective of the fact that we have not met or done anything that will re-impose absolute confidence but nevertheless. I am very determined to communicate you with much conviction that you will give my proposal a consideration. As earlier stated I am Dr. Victor Peters, a Financial Director working with INEC. My Agency is in charge of conducting all elections in my country Nigeria and by the virtue of my unique position in office as the Chief Financial Director. I was elevated by the commission to become the chairman of foreign contract tender board committee whose responsibility is to award and supervise foreign contract to ensure it is executed promptly. Consequently, I the chairman of the tender board committee in collaboration with two other top committee members over-invoiced certain contract for the supply of electoral equipments needed for the forth-coming elections in April 2003. The initial cost of the contract was pegged at US$50 million, but after the feasibility study was done, while submitting my report to the office of the presidency for final approval, we deliberately inflated the cost to an excess amount of US$ 30 million making the cost to be US$ 80 million. Right now, the gist of contacting you is we are constrained to claim the fund due to certain laws enacted by the government guiding civil service code of conduct Bureau which prohibits top civil servants working under Government establishment from operating offshore or foreign Account and this situation has kept us in a fix to openly come forward to claim the outstanding balance of US$ 30 million, hence after series of private meetings we decided to make contact in order to get a reliable foreign partner whom we will forward his or her credentials to claim the fund based on mutual trust and agreement. In a nutshell, we need your assistance and support to claim this fund so that at the later time convenient for us, we will come over to your country after the funds have been transferred, we will meet you and collect our own percentage while you will keep the rest as yours. For your support and total dedication to realize the objectives of this operation, you shall be entitled to 30% of the sum total while 70% of the fund belongs to the three officials involved in the deal. Note, you are vividly assured that you will not be subjected to any kind of risk for your support and involvement in this venture hence we have piloted a good strategy to ensure the operations goes smoothly of which we have targeted two weeks duration to accomplished our Aim. Kindly treat this matter Absolutely confidential because the officials involved are still in service and some of us intend to resign our appointment immediately after the transaction is finalized. I look forward to hearing positively from you while further details will be given as soon as I get your response. Best Regards Dr. Victor Peters _________________________________________________________ http://www.latinmail.com. Gratuito, latino y en espa�ol. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 10 09:57:45 2002 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 JAA08969 for ; Tue, 10 Dec 2002 09:57:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAF0Dv03072 for iptel-archive@odin.ietf.org; Tue, 10 Dec 2002 10:00:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAF0Dv03069 for ; Tue, 10 Dec 2002 10:00:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08936 for ; Tue, 10 Dec 2002 09:57:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAF03v03041; Tue, 10 Dec 2002 10:00:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAExgv02937 for ; Tue, 10 Dec 2002 09:59:42 -0500 Received: from smtp.latinmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08888 for ; Tue, 10 Dec 2002 09:56:43 -0500 (EST) Received: from latinmail.com.com (unknown [216.167.63.38]) by smtp.latinmail.com (Postfix) with SMTP id BE05B180A2 for ; Tue, 10 Dec 2002 09:59:35 -0500 (EST) To: iptel@ietf.org From: Victor Peters X-Mailer: LatinMail v3.0 -- http://www.latinmail.com.com Content-Type: text/plain; charset=us-ascii X-Priority: 3 Message-Id: <20021210145935.BE05B180A2@smtp.latinmail.com> Subject: [Iptel] Hello (From Dr. Victor Peters) 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, 10 Dec 2002 09:59:38 -0500 From: Dr. Victor Peters Chief Financial Director Independent National Electoral Commission (INEC) Lagos - Nigeria Date: 10th December, 2002 Dear Sir, RE: INVESTMENT & CONFIDENTIAL BUSINESS PROPOSAL It is my warmest pleasure writing you this confidential business offer irrespective of the fact that we have not met or done anything that will re-impose absolute confidence but nevertheless. I am very determined to communicate you with much conviction that you will give my proposal a consideration. As earlier stated I am Dr. Victor Peters, a Financial Director working with INEC. My Agency is in charge of conducting all elections in my country Nigeria and by the virtue of my unique position in office as the Chief Financial Director. I was elevated by the commission to become the chairman of foreign contract tender board committee whose responsibility is to award and supervise foreign contract to ensure it is executed promptly. Consequently, I the chairman of the tender board committee in collaboration with two other top committee members over-invoiced certain contract for the supply of electoral equipments needed for the forth-coming elections in April 2003. The initial cost of the contract was pegged at US$50 million, but after the feasibility study was done, while submitting my report to the office of the presidency for final approval, we deliberately inflated the cost to an excess amount of US$ 30 million making the cost to be US$ 80 million. Right now, the gist of contacting you is we are constrained to claim the fund due to certain laws enacted by the government guiding civil service code of conduct Bureau which prohibits top civil servants working under Government establishment from operating offshore or foreign Account and this situation has kept us in a fix to openly come forward to claim the outstanding balance of US$ 30 million, hence after series of private meetings we decided to make contact in order to get a reliable foreign partner whom we will forward his or her credentials to claim the fund based on mutual trust and agreement. In a nutshell, we need your assistance and support to claim this fund so that at the later time convenient for us, we will come over to your country after the funds have been transferred, we will meet you and collect our own percentage while you will keep the rest as yours. For your support and total dedication to realize the objectives of this operation, you shall be entitled to 30% of the sum total while 70% of the fund belongs to the three officials involved in the deal. Note, you are vividly assured that you will not be subjected to any kind of risk for your support and involvement in this venture hence we have piloted a good strategy to ensure the operations goes smoothly of which we have targeted two weeks duration to accomplished our Aim. Kindly treat this matter Absolutely confidential because the officials involved are still in service and some of us intend to resign our appointment immediately after the transaction is finalized. I look forward to hearing positively from you while further details will be given as soon as I get your response. Best Regards Dr. Victor Peters _________________________________________________________ http://www.latinmail.com. Gratuito, latino y en espa�ol. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 10 10:13:44 2002 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 KAA09873 for ; Tue, 10 Dec 2002 10:13:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAFGCA05082 for iptel-archive@odin.ietf.org; Tue, 10 Dec 2002 10:16:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAFGCv05079 for ; Tue, 10 Dec 2002 10:16:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09849 for ; Tue, 10 Dec 2002 10:13:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAFG4v05036; Tue, 10 Dec 2002 10:16:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAFF1v04946 for ; Tue, 10 Dec 2002 10:15:01 -0500 Received: from smtp.latinmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09764 for ; Tue, 10 Dec 2002 10:12:02 -0500 (EST) Received: from latinmail.com.com (unknown [209.207.185.29]) by smtp.latinmail.com (LatinMail) with SMTP id E09503BE50 for ; Tue, 10 Dec 2002 10:14:54 -0500 (EST) To: iptel@ietf.org From: Victor Peters X-Mailer: LatinMail v3.0 -- http://www.latinmail.com.com Content-Type: text/plain; charset=us-ascii X-Priority: 3 Message-Id: <20021210151454.E09503BE50@smtp.latinmail.com> Subject: [Iptel] Hello (From Dr. Victor Peters) 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, 10 Dec 2002 10:14:46 -0500 From: Dr. Victor Peters Chief Financial Director Independent National Electoral Commission (INEC) Lagos - Nigeria Date: 10th December, 2002 Dear Sir, RE: INVESTMENT & CONFIDENTIAL BUSINESS PROPOSAL It is my warmest pleasure writing you this confidential business offer irrespective of the fact that we have not met or done anything that will re-impose absolute confidence but nevertheless. I am very determined to communicate you with much conviction that you will give my proposal a consideration. As earlier stated I am Dr. Victor Peters, a Financial Director working with INEC. My Agency is in charge of conducting all elections in my country Nigeria and by the virtue of my unique position in office as the Chief Financial Director. I was elevated by the commission to become the chairman of foreign contract tender board committee whose responsibility is to award and supervise foreign contract to ensure it is executed promptly. Consequently, I the chairman of the tender board committee in collaboration with two other top committee members over-invoiced certain contract for the supply of electoral equipments needed for the forth-coming elections in April 2003. The initial cost of the contract was pegged at US$50 million, but after the feasibility study was done, while submitting my report to the office of the presidency for final approval, we deliberately inflated the cost to an excess amount of US$ 30 million making the cost to be US$ 80 million. Right now, the gist of contacting you is we are constrained to claim the fund due to certain laws enacted by the government guiding civil service code of conduct Bureau which prohibits top civil servants working under Government establishment from operating offshore or foreign Account and this situation has kept us in a fix to openly come forward to claim the outstanding balance of US$ 30 million, hence after series of private meetings we decided to make contact in order to get a reliable foreign partner whom we will forward his or her credentials to claim the fund based on mutual trust and agreement. In a nutshell, we need your assistance and support to claim this fund so that at the later time convenient for us, we will come over to your country after the funds have been transferred, we will meet you and collect our own percentage while you will keep the rest as yours. For your support and total dedication to realize the objectives of this operation, you shall be entitled to 30% of the sum total while 70% of the fund belongs to the three officials involved in the deal. Note, you are vividly assured that you will not be subjected to any kind of risk for your support and involvement in this venture hence we have piloted a good strategy to ensure the operations goes smoothly of which we have targeted two weeks duration to accomplished our Aim. Kindly treat this matter Absolutely confidential because the officials involved are still in service and some of us intend to resign our appointment immediately after the transaction is finalized. I look forward to hearing positively from you while further details will be given as soon as I get your response. Best Regards Dr. Victor Peters _________________________________________________________ http://www.latinmail.com. Gratuito, latino y en espa�ol. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 10 23:43:50 2002 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 XAA01356 for ; Tue, 10 Dec 2002 23:43:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBB4kNY21161 for iptel-archive@odin.ietf.org; Tue, 10 Dec 2002 23:46:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB4kNv21158 for ; Tue, 10 Dec 2002 23:46:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01353 for ; Tue, 10 Dec 2002 23:43:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB4kEv21140; Tue, 10 Dec 2002 23:46:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB4juv21105 for ; Tue, 10 Dec 2002 23:45:56 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01344 for ; Tue, 10 Dec 2002 23:42:49 -0500 (EST) From: stoshniwal@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id gBB4NCi02804; Wed, 11 Dec 2002 09:53:13 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C8C.0019CC92 ; Wed, 11 Dec 2002 10:11:47 +0530 X-Lotus-FromDomain: HSSBLR To: iptel@ietf.org cc: lennox@cs.columbia.edu, schulzrinne@cs.columbia.edu Message-ID: <65256C8C.0019CC38.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Iptel] CPL draft status & namespacing 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, 11 Dec 2002 10:11:46 +0530 Hi all, The draft-ietf-iptel-cpl-06.txt has expired in July, 2002. Has the same been published as a RFC already? If not, is there a revision planned for the same? The DTD identifier and namespace defined in the draft are of the form (respectively): "-//IETF//DTD RFCxxxx CPL 1.0//EN" "http://www.rfc-editor.org/rfc/rfcxxxx.txt" Do current implementations use these identifiers? If so, what is the value used for xxxx? Thanks in advance, Siddharth. -------------------------------------------------------- Siddharth Toshniwal Hughes Software Systems Prestige Opal http://www.hssworld.com 146, Infantry Road Ph (O): +91-80-2286390 (7094) Bangalore-560001, India Mobile: +91-9845154068 --------------------------------------------------------- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 11 00:30:39 2002 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 AAA02406 for ; Wed, 11 Dec 2002 00:30:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBB5XCW23147 for iptel-archive@odin.ietf.org; Wed, 11 Dec 2002 00:33:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB5XCv23144 for ; Wed, 11 Dec 2002 00:33:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02381 for ; Wed, 11 Dec 2002 00:30:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB5X2v23136; Wed, 11 Dec 2002 00:33:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB5W9v23106 for ; Wed, 11 Dec 2002 00:32:09 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02339 for ; Wed, 11 Dec 2002 00:29:05 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.78]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBB5VYYH015220; Wed, 11 Dec 2002 00:31:34 -0500 (EST) Message-ID: <3DF6CDB3.7080306@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stoshniwal@hss.hns.com CC: iptel@ietf.org, lennox@cs.columbia.edu, schulzrinne@cs.columbia.edu Subject: Re: [Iptel] CPL draft status & namespacing References: <65256C8C.0019CC38.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Dec 2002 00:31:31 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit stoshniwal@hss.hns.com wrote: > > > Hi all, > > The draft-ietf-iptel-cpl-06.txt has expired in July, 2002. > Has the same been published as a RFC already? If not, is > there a revision planned for the same? It is waiting in the rfc-editors queue. From http://www.rfc-editor.org/queue.html you can see the status as: 2002/02/05 draft-ietf-iptel-cpl-06.txt REF draft-ietf-sip-caller-prefs-##.txt J. Lennox, H. Schulzrinne CPL: A Language for User Control of Internet Telephony Services Bytes: 130696 which means its waiting the completion of draft-ietf-sip-caller-prefs, which is a normative reference from CPL. That spec (which I edit) has had some upheavels lately that have delayed it, but is getting close. > > The DTD identifier and namespace defined in the draft > are of the form (respectively): > > "-//IETF//DTD RFCxxxx CPL 1.0//EN" > "http://www.rfc-editor.org/rfc/rfcxxxx.txt" > > Do current implementations use these identifiers? > If so, what is the value used for xxxx? These will be filled in within the specification once the RFC issues. I suspect most implementations ignore these lines. -Jonathan R> -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Wed Dec 11 08:08:50 2002 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 IAA03359 for ; Wed, 11 Dec 2002 08:08:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBDBGb25918 for iptel-archive@odin.ietf.org; Wed, 11 Dec 2002 08:11:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBDBGv25915 for ; Wed, 11 Dec 2002 08:11:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03344 for ; Wed, 11 Dec 2002 08:08:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBDB5v25905; Wed, 11 Dec 2002 08:11:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBDArv25871 for ; Wed, 11 Dec 2002 08:10:53 -0500 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03333 for ; Wed, 11 Dec 2002 08:07:56 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gBBD9N1x013051; Wed, 11 Dec 2002 08:09:23 -0500 (EST) From: Scott Bradner Message-Id: <200212111309.gBBD9N1x013051@newdev.harvard.edu> To: iptel@ietf.org, stoshniwal@hss.hns.com Subject: Re: [Iptel] CPL draft status & namespacing Cc: lennox@cs.columbia.edu, schulzrinne@cs.columbia.edu In-Reply-To: <65256C8C.0019CC38.00@sampark.hss.hns.com> 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, 11 Dec 2002 08:09:23 -0500 (EST) its in the rfc editor queue waiting for a normative reference to be published http://www.rfc-editor.org/queue.html Scott ---------- From iptel-admin@ietf.org Tue Dec 10 23:44:51 2002 From: stoshniwal@hss.hns.com X-Lotus-FromDomain: HSSBLR To: iptel@ietf.org cc: lennox@cs.columbia.edu, schulzrinne@cs.columbia.edu Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Iptel] CPL draft status & namespacing 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, 11 Dec 2002 10:11:46 +0530 Hi all, The draft-ietf-iptel-cpl-06.txt has expired in July, 2002. Has the same been published as a RFC already? If not, is there a revision planned for the same? The DTD identifier and namespace defined in the draft are of the form (respectively): "-//IETF//DTD RFCxxxx CPL 1.0//EN" "http://www.rfc-editor.org/rfc/rfcxxxx.txt" Do current implementations use these identifiers? If so, what is the value used for xxxx? Thanks in advance, Siddharth. -------------------------------------------------------- Siddharth Toshniwal Hughes Software Systems Prestige Opal http://www.hssworld.com 146, Infantry Road Ph (O): +91-80-2286390 (7094) Bangalore-560001, India Mobile: +91-9845154068 --------------------------------------------------------- _______________________________________________ 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 mailnull@www1.ietf.org Wed Dec 11 09:38:47 2002 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 JAA06984 for ; Wed, 11 Dec 2002 09:38:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBEfEr31570 for iptel-archive@odin.ietf.org; Wed, 11 Dec 2002 09:41:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBEfEv31567 for ; Wed, 11 Dec 2002 09:41:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06975 for ; Wed, 11 Dec 2002 09:38:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBEf5v31553; Wed, 11 Dec 2002 09:41:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBEeWv31528 for ; Wed, 11 Dec 2002 09:40:32 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06932 for ; Wed, 11 Dec 2002 09:37:30 -0500 (EST) From: snmadhusudan@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id gBBEHsi06653 for ; Wed, 11 Dec 2002 19:47:54 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C8C.005040A2 ; Wed, 11 Dec 2002 20:06:34 +0530 X-Lotus-FromDomain: HSSBLR To: iptel@ietf.org Message-ID: <65256C8C.00504054.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Iptel] CPL language switch 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, 11 Dec 2002 20:06:24 +0530 Hi, Section 5.3 on Language Switches in draft-ietf-iptel-cpl-06 states "If the caller specified the special language-range "*", it is ignored for the purposes of matching." I would assume that the caller has no specific choices about the language and he accepts any language. Hence a CPL switch on language trying to match a particular language is redundant. Can I take that the 'language' output matched successfully for this case and proceed further ? But the next line states "Languages with a "q" value of 0 are also ignored." Here the ignored word confuses me. Is it that the language with a q=0 is ignored and other languages are used for matching? Can someone plz clarify the same with an example ? Thanx in advance. Madhusudan SN. Hughes Software Systems. Bangalore. India. Phone: +91-80-2286390 This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Thu Dec 12 22:10:25 2002 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 WAA22030 for ; Thu, 12 Dec 2002 22:10:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBD3CxA05997 for iptel-archive@odin.ietf.org; Thu, 12 Dec 2002 22:12:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD3Cxv05994 for ; Thu, 12 Dec 2002 22:12:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22009 for ; Thu, 12 Dec 2002 22:09:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD3Chv05948; Thu, 12 Dec 2002 22:12:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD383v05667 for ; Thu, 12 Dec 2002 22:08:03 -0500 Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21901 for ; Thu, 12 Dec 2002 22:04:57 -0500 (EST) Received: from cs.columbia.edu ([12.84.238.218]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021213030752.XJRK9286.mtiwmhc11.worldnet.att.net@cs.columbia.edu> for ; Fri, 13 Dec 2002 03:07:52 +0000 Message-ID: <3DF94E81.6080104@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Iptel] 2806bis: service numbers 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 Dec 2002 22:05:37 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One of the open issues in 2806bis is the treatment of service numbers. There seem to be two basic classes, with some subcases: 1) Nationally uniform numbers, with the same treatment For example, in most countries, emergency numbers like 999, 112 or 911 fall in this category. They might ring in different locations, but that's not fundamentally different than a PizzaHut number. nanpa.com says: "In the U.S., the FCC administers N11 codes, and recognizes only 211, 311, 511, and 711 as nationally assigned. Other codes have traditional uses as shown in the table below." My perception is that other countries don't use service numbers as much, beyond emergency calling and that if they do, they designate the same service within a country code, but I'm sure other have a better perspective on this. 2) Regionally diverse numbers Apparently, some x11 numbers are used differently in different regions. (Examples?) 3) Carrier-specific services This seems to be common for #NN numbers on cell phones (e.g., to call for assistance or to get traffic help) What are the options for tel URIs: (A) punt - explicitly exclude them; I don't think that's a good idea as people will put these on web pages (B) use the same scheme as for other 'private'/'local' numbers (Here, private doesn't really apply; local is probably closer to the mark.) For carrier-specific numbers, use a domain name context, for national numbers the country code (as in tel:911;phone-context=+1; this assumes that 911 is not used for something else in the Carribean). State-specific numbers are painful, but one could imagine a convention such as tel:211;phone-context=nj.us (C) Make them look like E.164 numbers, as in tel:+1-911 Ugly and not likely to be intuitive. There may well be other options, such as logical names that get mapped to the local service representation ("telsvc:traffic", "telsvc:repair"), but the list of registrations seems long. We'd probably want to get NANPA to vet such assignments. I think the least bad option is (B), with regional designations (;phone-context=us). Comments? Henning _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Dec 13 00:39:42 2002 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 AAA04737 for ; Fri, 13 Dec 2002 00:39:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBD5gIl14612 for iptel-archive@odin.ietf.org; Fri, 13 Dec 2002 00:42:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD5gIv14609 for ; Fri, 13 Dec 2002 00:42:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04643 for ; Fri, 13 Dec 2002 00:39:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD5g4v14589; Fri, 13 Dec 2002 00:42:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD5fev14572 for ; Fri, 13 Dec 2002 00:41:40 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04569 for ; Fri, 13 Dec 2002 00:38:33 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBD5fNYH016602; Fri, 13 Dec 2002 00:41:23 -0500 (EST) Message-ID: <3DF97300.4010208@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: snmadhusudan@hss.hns.com CC: iptel@ietf.org Subject: Re: [Iptel] CPL language switch References: <65256C8C.00504054.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Dec 2002 00:41:20 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit snmadhusudan@hss.hns.com wrote: > > > Hi, > Section 5.3 on Language Switches in draft-ietf-iptel-cpl-06 > states > "If the caller specified the special language-range "*", > it is ignored for the purposes of matching." > > I would assume that the caller has no specific choices about > the language and he accepts any language. The caller specifies their preferred languages using the Accept-Language header. > Hence a CPL switch > on language trying to match a particular language is redundant. Of course not. If the caller indicated that they want spanish, the CPL language-switch can do something specific in that case. > Can I take that the 'language' output matched successfully for > this case and proceed further ? > > But the next line states > "Languages with a "q" value of 0 are also ignored." > > Here the ignored word confuses me. Is it that the language > with a q=0 is ignored and other languages are used for matching? Right. If the accept-language looks like: Accept-Language: en;q=1.0, es;q=0.0, de;q=0.5 the es language would be ignored for purposes of the CPL switch. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Fri Dec 13 00:50:45 2002 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 AAA05547 for ; Fri, 13 Dec 2002 00:50:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBD5rLE14898 for iptel-archive@odin.ietf.org; Fri, 13 Dec 2002 00:53:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD5rLv14895 for ; Fri, 13 Dec 2002 00:53:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05541 for ; Fri, 13 Dec 2002 00:50:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD5r6v14886; Fri, 13 Dec 2002 00:53:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD5qEv14866 for ; Fri, 13 Dec 2002 00:52:14 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05530 for ; Fri, 13 Dec 2002 00:49:03 -0500 (EST) From: snmadhusudan@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id gBD5Sxi13433; Fri, 13 Dec 2002 10:59:04 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C8E.001FD8D2 ; Fri, 13 Dec 2002 11:17:51 +0530 X-Lotus-FromDomain: HSSBLR To: Jonathan Rosenberg cc: iptel@ietf.org Message-ID: <65256C8E.001FD75B.00@sampark.hss.hns.com> Subject: Re: [Iptel] CPL language switch Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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, 13 Dec 2002 11:17:47 +0530 Hi, Thanx for the response. Had another query about the case when the Accept Language looks like Accept-Language: * In this case, any language tag after the switch can be considered a match. Correct? > "If the caller specified the special language-range "*", > it is ignored for the purposes of matching." > > I would assume that the caller has no specific choices about > the language and he accepts any language. The caller specifies their preferred languages using the Accept-Language header. Right. If the accept-language looks like: Accept-Language: en;q=1.0, es;q=0.0, de;q=0.5 the es language would be ignored for purposes of the CPL switch. Madhusudan SN. Hughes Software Systems, Bangalore. INDIA. Phone: +91-80-2286390 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Dec 13 11:00:27 2002 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 LAA26790 for ; Fri, 13 Dec 2002 11:00:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDG2vK25809 for iptel-archive@odin.ietf.org; Fri, 13 Dec 2002 11:02:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDG2uv25806 for ; Fri, 13 Dec 2002 11:02:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26761 for ; Fri, 13 Dec 2002 10:59:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDG06v25700; Fri, 13 Dec 2002 11:00:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDFxAv25642 for ; Fri, 13 Dec 2002 10:59:10 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26713 for ; Fri, 13 Dec 2002 10:56:10 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDFwlkE024236; Fri, 13 Dec 2002 10:58:47 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id ABK62331; Fri, 13 Dec 2002 10:48:09 -0500 (EST) Message-Id: <4.3.2.7.2.20021213105254.00b2d708@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Henning Schulzrinne From: Michael Hammer Subject: Re: [Iptel] 2806bis: service numbers Cc: iptel@ietf.org In-Reply-To: <3DF94E81.6080104@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: Fri, 13 Dec 2002 10:58:13 -0500 Henning, Your telsvc:411 or telsvc:directory probably hits closest to what these numbers really are, service codes. For option B, if the user is mobile and dials 911, would his terminal know the phone-context, or would this be added by the outbound proxy that receives the call? Mike At 10:05 PM 12/12/2002 -0500, Henning Schulzrinne wrote: >One of the open issues in 2806bis is the treatment of service numbers. >There seem to be two basic classes, with some subcases: > >1) Nationally uniform numbers, with the same treatment > >For example, in most countries, emergency numbers like 999, 112 or 911 >fall in this category. They might ring in different locations, but that's >not fundamentally different than a PizzaHut number. > >nanpa.com says: > >"In the U.S., the FCC administers N11 codes, and recognizes only 211, 311, >511, and 711 as nationally assigned. Other codes have traditional uses as >shown in the table below." > >My perception is that other countries don't use service numbers as much, >beyond emergency calling and that if they do, they designate the same >service within a country code, but I'm sure other have a better >perspective on this. > >2) Regionally diverse numbers > >Apparently, some x11 numbers are used differently in different >regions. (Examples?) > >3) Carrier-specific services > >This seems to be common for #NN numbers on cell phones (e.g., to call for >assistance or to get traffic help) > >What are the options for tel URIs: > >(A) punt - explicitly exclude them; I don't think that's a good idea as >people will put these on web pages > >(B) use the same scheme as for other 'private'/'local' numbers > >(Here, private doesn't really apply; local is probably closer to the mark.) > >For carrier-specific numbers, use a domain name context, for national >numbers the country code (as in tel:911;phone-context=+1; this assumes >that 911 is not used for something else in the Carribean). State-specific >numbers are painful, but one could imagine a convention such as > >tel:211;phone-context=nj.us > >(C) Make them look like E.164 numbers, as in tel:+1-911 > >Ugly and not likely to be intuitive. > >There may well be other options, such as logical names that get mapped to >the local service representation ("telsvc:traffic", "telsvc:repair"), but >the list of registrations seems long. We'd probably want to get NANPA to >vet such assignments. > >I think the least bad option is (B), with regional designations >(;phone-context=us). > >Comments? > >Henning > >_______________________________________________ >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 mailnull@www1.ietf.org Fri Dec 13 11:25:42 2002 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 LAA27279 for ; Fri, 13 Dec 2002 11:25:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDGSC027071 for iptel-archive@odin.ietf.org; Fri, 13 Dec 2002 11:28:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDGSBv27068 for ; Fri, 13 Dec 2002 11:28:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27272 for ; Fri, 13 Dec 2002 11:25:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDGQ4v27027; Fri, 13 Dec 2002 11:26:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDGPvv27012 for ; Fri, 13 Dec 2002 11:25:57 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27241 for ; Fri, 13 Dec 2002 11:22:56 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gBDGPlSE003330 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 13 Dec 2002 11:25:48 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gBDGPddG001013 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Dec 2002 11:25:43 -0500 (EST) Message-ID: <3DFA0A66.8020806@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: iptel@ietf.org Subject: Re: [Iptel] 2806bis: service numbers References: <4.3.2.7.2.20021213105254.00b2d708@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20021213105254.00b2d708@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Dec 2002 11:27:18 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael Hammer wrote: > Henning, > > Your telsvc:411 or telsvc:directory probably hits closest to what these > numbers really are, service codes. The problem with telsvc:411 is that this could mean different things in different places, which is not exactly "universal". (Yes, that's true for file URLs, too, but those are, to me, an example of something to be avoided, not replicated.) Thus, I would much prefer a symbolic registration in the URN spirit which is then mapped to the locally appropriate mechanism. The only drawback is that adding new services is a bit harder. Gateways have to know lots of service names, which change, rather than very few context names, which do not change (or very infrequently). We have something like service names in the SLP URI, by the way. But they imply a certain protocol mechanism to resolve them. > > For option B, if the user is mobile and dials 911, would his terminal > know the phone-context, or would this be added by the outbound proxy > that receives the call? I'm hoping that they wouldn't dial 911, but rather something like sos@their-aor, but leaving that aside, the caller would have to add the context, since the URI could be misinterpreted otherwise. Let's say 611 means repair in one place and directory assistance in another. The proxy can't know what you meant and blindly dialing the digits is going to lead to rather nasty surprises. Or, for the 911 example, I'd much rather have the Japanese proxy say "sorry, 911 is only valid in context +1; you're in some other context" than get a voice message in Japanese saying the equivalent of "the number you have dialed is not in service". > > Mike > > >> (B) use the same scheme as for other 'private'/'local' numbers >> >> (Here, private doesn't really apply; local is probably closer to the >> mark.) >> >> For carrier-specific numbers, use a domain name context, for national >> numbers the country code (as in tel:911;phone-context=+1; this assumes >> that 911 is not used for something else in the Carribean). >> State-specific numbers are painful, but one could imagine a convention >> such as >> >> tel:211;phone-context=nj.us >> There may well be other options, such as logical names that get mapped >> to the local service representation ("telsvc:traffic", >> "telsvc:repair"), but the list of registrations seems long. We'd >> probably want to get NANPA to vet such assignments. >> >> I think the least bad option is (B), with regional designations >> (;phone-context=us). >> >> Comments? >> >> Henning >> >> _______________________________________________ >> 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 mailnull@www1.ietf.org Fri Dec 13 11:46:46 2002 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 LAA27951 for ; Fri, 13 Dec 2002 11:46:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDGnG528697 for iptel-archive@odin.ietf.org; Fri, 13 Dec 2002 11:49:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDGnGv28694 for ; Fri, 13 Dec 2002 11:49:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27944 for ; Fri, 13 Dec 2002 11:46:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDGn2v28679; Fri, 13 Dec 2002 11:49:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDGmCv28591 for ; Fri, 13 Dec 2002 11:48:12 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27908 for ; Fri, 13 Dec 2002 11:45:11 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDGmXYO003834; Fri, 13 Dec 2002 11:48:33 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id ABK63002; Fri, 13 Dec 2002 11:37:55 -0500 (EST) Message-Id: <4.3.2.7.2.20021213113943.00b7ba08@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Henning Schulzrinne From: Michael Hammer Subject: Re: [Iptel] 2806bis: service numbers Cc: iptel@ietf.org In-Reply-To: <3DFA0A66.8020806@cs.columbia.edu> References: <4.3.2.7.2.20021213105254.00b2d708@cia.cisco.com> <4.3.2.7.2.20021213105254.00b2d708@cia.cisco.com> 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: Fri, 13 Dec 2002 11:47:56 -0500 Henning, Understood. That form merely replicates the existing problem. You would probably need something like: telsvc:411;service-context:nj.us Is the intent to provide a globally unique hierarchy of services that any server could look up and treat accordingly? For example, if the mobile user dials 911 and it is rendered as (tel: or telsvc: whichever): telsvc:911;service-context:us could it then translate that to: telsvc:211;service-context:country-x which is local to that country where the call originates. Or more directly, translate to the actual tel: or sip: URI that is the number of the local emergency service. Mike At 11:27 AM 12/13/2002 -0500, Henning Schulzrinne wrote: >Michael Hammer wrote: >>Henning, >>Your telsvc:411 or telsvc:directory probably hits closest to what these >>numbers really are, service codes. > >The problem with telsvc:411 is that this could mean different things in >different places, which is not exactly "universal". (Yes, that's true for >file URLs, too, but those are, to me, an example of something to be >avoided, not replicated.) > >Thus, I would much prefer a symbolic registration in the URN spirit which >is then mapped to the locally appropriate mechanism. The only drawback is >that adding new services is a bit harder. Gateways have to know lots of >service names, which change, rather than very few context names, which do >not change (or very infrequently). > >We have something like service names in the SLP URI, by the way. But they >imply a certain protocol mechanism to resolve them. > >>For option B, if the user is mobile and dials 911, would his terminal >>know the phone-context, or would this be added by the outbound proxy that >>receives the call? > >I'm hoping that they wouldn't dial 911, but rather something like >sos@their-aor, but leaving that aside, the caller would have to add the >context, since the URI could be misinterpreted otherwise. Let's say 611 >means repair in one place and directory assistance in another. The proxy >can't know what you meant and blindly dialing the digits is going to lead >to rather nasty surprises. Or, for the 911 example, I'd much rather have >the Japanese proxy say "sorry, 911 is only valid in context +1; you're in >some other context" than get a voice message in Japanese saying the >equivalent of "the number you have dialed is not in service". > >>Mike > >>>(B) use the same scheme as for other 'private'/'local' numbers >>> >>>(Here, private doesn't really apply; local is probably closer to the mark.) >>> >>>For carrier-specific numbers, use a domain name context, for national >>>numbers the country code (as in tel:911;phone-context=+1; this assumes >>>that 911 is not used for something else in the Carribean). >>>State-specific numbers are painful, but one could imagine a convention such as >>> >>>tel:211;phone-context=nj.us > > >>>There may well be other options, such as logical names that get mapped >>>to the local service representation ("telsvc:traffic", "telsvc:repair"), >>>but the list of registrations seems long. We'd probably want to get >>>NANPA to vet such assignments. >>> >>>I think the least bad option is (B), with regional designations >>>(;phone-context=us). >>> >>>Comments? >>> >>>Henning >>> >>>_______________________________________________ >>>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 mailnull@www1.ietf.org Fri Dec 13 14:12:49 2002 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 OAA02230 for ; Fri, 13 Dec 2002 14:12:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDJFJt05117 for iptel-archive@odin.ietf.org; Fri, 13 Dec 2002 14:15:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDJFIv05114 for ; Fri, 13 Dec 2002 14:15:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02223 for ; Fri, 13 Dec 2002 14:12:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDJF6v05103; Fri, 13 Dec 2002 14:15:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDJETv05068 for ; Fri, 13 Dec 2002 14:14:29 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02176 for ; Fri, 13 Dec 2002 14:11:28 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gBDJECSE021464 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 13 Dec 2002 14:14:12 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gBDJE9dG019957 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Dec 2002 14:14:11 -0500 (EST) Message-ID: <3DFA31E4.3070500@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: iptel@ietf.org Subject: Re: [Iptel] 2806bis: service numbers References: <4.3.2.7.2.20021213105254.00b2d708@cia.cisco.com> <4.3.2.7.2.20021213105254.00b2d708@cia.cisco.com> <4.3.2.7.2.20021213113943.00b7ba08@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20021213113943.00b7ba08@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Dec 2002 14:15:48 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Understood. That form merely replicates the existing problem. You > would probably need something like: > > telsvc:411;service-context:nj.us Yes, although at that point, it's unclear what the benefit is compared to tel:411;phone-context=nj.us > > Is the intent to provide a globally unique hierarchy of services that > any server could look up and treat accordingly? For example, if the > mobile user dials 911 and it is rendered as (tel: or telsvc: whichever): > > telsvc:911;service-context:us > > could it then translate that to: > > telsvc:211;service-context:country-x > > which is local to that country where the call originates. Or more > directly, translate to the actual tel: or sip: URI that is the number of > the local emergency service. I think the idea would be to translate this into either an E.164 number (e.g., for out-of-area 911 numbers), possibly expressed as a tel URI, or a SIP URI. The E.164 tel URI would presumably be useful only if this translation is delegated to some third party. I don't know if an ENUM-like directory would work here, since you would not query for a number, but a range of numbers. You would query "I'm at 212 555 1234, what's the repair service number for me?", but the answer would be the same for all 212 numbers, in most cases. > > Mike > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Dec 13 16:18:46 2002 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 QAA05577 for ; Fri, 13 Dec 2002 16:18:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDLLHS12518 for iptel-archive@odin.ietf.org; Fri, 13 Dec 2002 16:21:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDLLHv12515 for ; Fri, 13 Dec 2002 16:21:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05563 for ; Fri, 13 Dec 2002 16:18:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDLL5v12499; Fri, 13 Dec 2002 16:21:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDLKSv12468 for ; Fri, 13 Dec 2002 16:20:28 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05526 for ; Fri, 13 Dec 2002 16:17:26 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDLKlCS013840; Fri, 13 Dec 2002 16:20:47 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id ABK66492; Fri, 13 Dec 2002 16:10:09 -0500 (EST) Message-Id: <4.3.2.7.2.20021213160858.04e62fe8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Henning Schulzrinne From: Michael Hammer Subject: Re: [Iptel] 2806bis: service numbers Cc: iptel@ietf.org In-Reply-To: <3DFA31E4.3070500@cs.columbia.edu> References: <4.3.2.7.2.20021213113943.00b7ba08@cia.cisco.com> <4.3.2.7.2.20021213105254.00b2d708@cia.cisco.com> <4.3.2.7.2.20021213105254.00b2d708@cia.cisco.com> <4.3.2.7.2.20021213113943.00b7ba08@cia.cisco.com> 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: Fri, 13 Dec 2002 16:20:10 -0500 That would only provide a distinction between a name and an address. Not sure if it is worth the trouble though. Mike At 02:15 PM 12/13/2002 -0500, Henning Schulzrinne wrote: >>Understood. That form merely replicates the existing problem. You would >>probably need something like: >>telsvc:411;service-context:nj.us > >Yes, although at that point, it's unclear what the benefit is compared to > >tel:411;phone-context=nj.us > >>Is the intent to provide a globally unique hierarchy of services that any >>server could look up and treat accordingly? For example, if the mobile >>user dials 911 and it is rendered as (tel: or telsvc: whichever): >>telsvc:911;service-context:us >>could it then translate that to: >>telsvc:211;service-context:country-x >>which is local to that country where the call originates. Or more >>directly, translate to the actual tel: or sip: URI that is the number of >>the local emergency service. > >I think the idea would be to translate this into either an E.164 number >(e.g., for out-of-area 911 numbers), possibly expressed as a tel URI, or a >SIP URI. The E.164 tel URI would presumably be useful only if this >translation is delegated to some third party. I don't know if an ENUM-like >directory would work here, since you would not query for a number, but a >range of numbers. You would query "I'm at 212 555 1234, what's the repair >service number for me?", but the answer would be the same for all 212 >numbers, in most cases. > > >>Mike _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Dec 13 23:10:50 2002 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 XAA15589 for ; Fri, 13 Dec 2002 23:10:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBE4DPw01590 for iptel-archive@odin.ietf.org; Fri, 13 Dec 2002 23:13:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBE4DPv01586 for ; Fri, 13 Dec 2002 23:13:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15585 for ; Fri, 13 Dec 2002 23:10:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBE4D5v01578; Fri, 13 Dec 2002 23:13:05 -0500 Received: from jeilcp.com ([218.144.22.89]) by www1.ietf.org (8.11.6/8.11.6) with SMTP id gBE4C4v01555 for ; Fri, 13 Dec 2002 23:12:07 -0500 Message-Id: <200212140412.gBE4C4v01555@www1.ietf.org> From: jeil To: iptel@www1.ietf.org Reply-To: ksw@jeilcp.com Mime-Version: 1.0 Content-Type: text/html; charset=ks_c_5601-1987 Subject: [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: Fri, 13 Dec 2002 23:12:07 -0500
정보통신부 권고사항에 의거 작성한 [광고] 메일입니다.
앞으로 메일수신을 원치 않으시면 수신거부를 눌러주십시오.
이곳에 넣으시고자 하는 내용을 넣으세요..^^

 

처음엔 부업이라 불리울지도 모릅니다.
하지만..부업이라 불리기엔 그 의미가 너무나 큽니다.
앞으로의 보험시장은 선진국이 갔던 길따라 우리도 변해가기 마련입니다.
5%의 전문 설계사와 나머지 일반설계사로 구성된 보험시장..
갈수록 확장되어지는 저렴한 인터넷보험시장..
기존의 설계사분의 경쟁력은 어디에서 생기는 것일려나요?
이미 설계사없이 보험을 받는곳도 생겨나고 있고 있는 마당에, 그 95%의 사람들은 어디로 가게될까요?
 

퇴직걱정없는 나만의 인터넷 보험대리점...


저희 사이버팀에 가입한분에 한하여 자신만의 홈페이지와 그안에서 자동차보험 또는 그외 장기 보험등을 자신의 이메일로 받아볼 수 있게 지원해드립니다.또한, 인터넷상에서의 홍보를 도와드립니다.
재택근무라곤하지만,더 많은 정보를 갖을 수 있도록 그리고 실제 활용되어질 수 있도록 해드립니다.그렇게 키워진 나만의 인터넷 보험대리점,, 아무도 그일을 막지 못하고, 그것은 하나의 재산이 될수있읍니다.
자신의 홈페이지는 또다른 비즈니스의 매개체가 되니까요..
 

먼저 활동지역을 잡으세요..사이버팀에서 도와드립니다..

 
저희 사이버팀을 통해가입하신분들은,물론 활동지역에 제한은 없지만,먼저 활동지역을 잡으세여.. 사시는 동네를 기준으로 홈페이지에서 들어온 주문들을 그 지역담당자분께  다시 고스란히 돌려드립니다.물론,이미 지정되어진 것만 아니라면 그 지역을 먼저 선점하신분께 그 권한을 드립니다. 선점하시기위하여는 디비엠 시스템의 이해와 시스템의 이해를
공부하셔야만 합니다.아무런 노력하지 않는분들까지 저희가 안고 가지는 못합니다.
무엇보다 노력하시는 분께 더많은 기회를 드리고 더많은 수입을 드리기위해 노력하는 제일인슈가 될 것을 약속드립니다.
 

보험영업에 자신있는 분은 보험영업을
증원에 자신있는 분은 증원을..

 
사이버플래너의 수당지급율은 일반 설계사들보다 더 많습니다.
이유는 하나죠,회사의 제반경비를 사이버플래너 님들께 쓰지 않게되니 그 경비가 다시 그분들에게 좀더큰 지급율로 돌아오는것입니다.
능력을 인정받고자하시는 분들은 당연히 사이버플래너로의 선택이 수당이 크다고 볼수있읍니다.또한, 더 큰 매력은 증원에 있습니다. 자신에게 증원된 분들의 자동차보험 보험료의 3%를 올려받으니,증원이 단지 10분만 된다고 하더라도 그 수입은 자신의 실제수입보다 더 커질 수가 있는 것이죠.
 


귀하의 허락없이 홍보성 전자 우편을 보내게 된 점 정중히 사과 드립니다. 정보통신망 이용촉진법 규정을 준수하여 광고메일임을 표시하였으며, 수신거부 장치를 마련하고 있습니다. 귀하의 전자 우편 주소는 인터넷 상의 공개된 장소에서 습득하였으며, 저희는 귀하의 전자우편 주소외 어떠한 개인정보도 가지고 있지 않으므로 안심하시기 바랍니다.


We sincerely apologize for sending advertising e-mail to you without your permission.We have indicated that this is advertising mail in accordance to the Law of Information and Network Usage, and we have installed a Spam Guard function. We obtained your e-mail address in an open place of public access on the Internet. Please be assured that we do not have any of your personal information other than your e-mail address.

 

_______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 16 16:35:03 2002 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 QAA19104 for ; Mon, 16 Dec 2002 16:35:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGLba816457 for iptel-archive@odin.ietf.org; Mon, 16 Dec 2002 16:37:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGLbav16454 for ; Mon, 16 Dec 2002 16:37:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19079 for ; Mon, 16 Dec 2002 16:34:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGLbIv16314; Mon, 16 Dec 2002 16:37:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGLabv15781 for ; Mon, 16 Dec 2002 16:36:37 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19040 for ; Mon, 16 Dec 2002 16:33:28 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBGLaFYH018294; Mon, 16 Dec 2002 16:36:15 -0500 (EST) Message-ID: <3DFE474B.8040403@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: snmadhusudan@hss.hns.com CC: iptel@ietf.org Subject: Re: [Iptel] CPL language switch References: <65256C8E.001FD75B.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Dec 2002 16:36:11 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit snmadhusudan@hss.hns.com wrote: > > > Hi, > Thanx for the response. > Had another query about the case when the Accept Language looks > like > Accept-Language: * > > In this case, any language tag after the switch can be considered > a match. Correct? I don't think so. "Ignoring" it, to me, means its the same as if the entire header was not present. That would match the "not-present" output or "otherwise" output as described in the top of section 5. Jonathan L - does that match your understanding? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Mon Dec 16 16:46:43 2002 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 QAA19317 for ; Mon, 16 Dec 2002 16:46:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGLnHg16937 for iptel-archive@odin.ietf.org; Mon, 16 Dec 2002 16:49:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGLnGv16934 for ; Mon, 16 Dec 2002 16:49:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19309 for ; Mon, 16 Dec 2002 16:46:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGLn4v16922; Mon, 16 Dec 2002 16:49:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGLmFv16872 for ; Mon, 16 Dec 2002 16:48:15 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19292 for ; Mon, 16 Dec 2002 16:45:10 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBGLm9YH018340; Mon, 16 Dec 2002 16:48:10 -0500 (EST) Message-ID: <3DFE4A16.8060808@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rick W. Porter" CC: IPTEL Subject: Re: [Iptel] Route Capability question(s) References: <066301c29c9d$c21638f0$2a00000a@RPORTER> 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, 16 Dec 2002 16:48:06 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rick W. Porter wrote: > I came across some interesting situations while testing TRIP that seem > to beg some clarification of the negotiated Route Capability. I assume > that TRIP peers internal to an ITAD can have different route capabilities. What is the motivation for such an assumption? That seems pretty counter-intuitive to me. > > My basic questions is what the negotiated route capabilities applies to? > > If it means that nothing that passes thru that connection contains a > route type outside the negotiated route capabilities, THis is what I thought. > your LS topology > can create situations where the ITAD is segmented. This violates the > premise that all internal peers have the same info. Only because you are assuming LS's in the ame ITAD can have different route capabilities. > Additionally, an LS > will likely burn many CPU cycles when during flooding it must tailor a > received message to each internal peer. Again, only if you make this assumption. > > If it applies to the peer LS (not just the connection), I have questions > arising from a couple scenarios... First, what do you do for a peer who > is not directly connected to you (you never establish a peering session > and negotiate route capabilities with them)? Then they are not a peer: > Peers: Two LSs that share a logical association (a transport > connection). If the LSs are in the same ITAD, they are internal > peers. Otherwise, they are external peers. The logical association > between two peer LSs is called a peering session. > Second, let's assume that > an LS can be (mis)configured to negotiate different route capabilities > with different peers. What is the correct behavior when there are > multiple "paths" to get between two peers with different negotiated > route capabilities? Do you assume the lowest common denominator of > negotiated route capability? Sounds like the answer is "dont do that". > > One thought that I had is revising the spec to eliminate route > capability negotiation within an ITAD. I'm open to other suggestions, > but at a glance it seems to me the best thing to do. I understand this > does create potential memory allocation problems if you must store all > route types (even those you have no use for). I just assumed all LS in an ITAD had to support the same route capabilities. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Tue Dec 17 09:56:29 2002 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 JAA14920 for ; Tue, 17 Dec 2002 09:56:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHEx1214988 for iptel-archive@odin.ietf.org; Tue, 17 Dec 2002 09:59:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHEx1v14985 for ; Tue, 17 Dec 2002 09:59:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14913 for ; Tue, 17 Dec 2002 09:55:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHEw5v14936; Tue, 17 Dec 2002 09:58:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHEsGv14834 for ; Tue, 17 Dec 2002 09:54:16 -0500 Received: from acmepacket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14859 for ; Tue, 17 Dec 2002 09:51:13 -0500 (EST) Received: from RPORTER [63.67.143.2] by acmepacket.com (SMTPD32-7.07) id AA94C5DE028E; Tue, 17 Dec 2002 09:54:12 -0500 Message-ID: <015001c2a5dc$96b026b0$2a00000a@RPORTER> From: "Rick W. Porter" To: "Jonathan Rosenberg" Cc: "IPTEL" References: <066301c29c9d$c21638f0$2a00000a@RPORTER> <3DFE4A16.8060808@dynamicsoft.com> Subject: Re: [Iptel] Route Capability question(s) 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 17 Dec 2002 09:57:15 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jonathan, Thank you for taking the time to respond. I was picturing a network where network elements within an ITAD support different protocols or address families. For example, some network elements support H323-Q931 and SIP, while other network elements support just SIP. I thought this may be desirable due to geographic concerns and installed protocol bases. As you add protocols to a network, it may also be desirable to have a non-homogeneous Route Capability within an ITAD (at least as a transient effect). IMHO, if TRIP only supports homogeneous Route Capability within an ITAD, it should probably be noted somewhere. I guess I raise the point b/c it was not clear to me--if no one else finds it confusing, great. If you want to mandate that ITADs have homogeneous Route Capability, then all my issues go away you can stop reading my response... Otherwise, I responded to a couple other points below. Thanks, Rick ----- Original Message ----- > > If it applies to the peer LS (not just the connection), I have questions > > arising from a couple scenarios... First, what do you do for a peer who > > is not directly connected to you (you never establish a peering session > > and negotiate route capabilities with them)? > > Then they are not a peer: > > > Peers: Two LSs that share a logical association (a transport > > connection). If the LSs are in the same ITAD, they are internal > > peers. Otherwise, they are external peers. The logical association > > between two peer LSs is called a peering session. My understanding was that TRIP does not require a full mesh (as does BGP), so two LSs in the same ITAD could learn each others routes without being directly connected. Below, I depict the simplest such situation within an ITAD. LS A <---> LS B <---> LS C I believe you would still want LS A to learn LS C's routes (and vice versa). And, according to Section 10.1, "When an LS receives an UPDATE message from an internal peer, the LS floods the new information from that message to all of its other internal peers." I understand this to mean that LS B would send all new LS A routes to LS C (and vice versa). I agree that LS A and LS C do not have a peering session, but what would be the relationship between LS A and LS C (given they're in the same ITAD)? My understanding is that they would be still be internal peers, but have no peering session. You would determine "connectivity" with them using the ITAD Topology attributes. If they are internal peers, what route capabilities would LS A allow for LS C? If they are not internal peers, would LS A treat LS C routes (learned via the peering session with LS B) as routes from an external peer? > > > > Second, let's assume that > > an LS can be (mis)configured to negotiate different route capabilities > > with different peers. What is the correct behavior when there are > > multiple "paths" to get between two peers with different negotiated > > route capabilities? Do you assume the lowest common denominator of > > negotiated route capability? > > Sounds like the answer is "dont do that". > I agree that this gets very messy, very quickly. That is why I proposed eliminating the Route Capability negotiation within an ITAD. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Dec 17 15:26:46 2002 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 PAA22680 for ; Tue, 17 Dec 2002 15:26:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHKTKG01789 for iptel-archive@odin.ietf.org; Tue, 17 Dec 2002 15:29:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHKTKv01786 for ; Tue, 17 Dec 2002 15:29:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22675 for ; Tue, 17 Dec 2002 15:26:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHKTAv01771; Tue, 17 Dec 2002 15:29:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHKSkv01753 for ; Tue, 17 Dec 2002 15:28:46 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22664 for ; Tue, 17 Dec 2002 15:25:40 -0500 (EST) Received: from HSALAMAW2K (ams-clip-equant-dhcp-132.cisco.com [10.61.124.133]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBHKS0jS019787; Tue, 17 Dec 2002 12:28:02 -0800 (PST) From: "Hussein Salama" To: "'Rick W. Porter'" , "'Jonathan Rosenberg'" Cc: "'IPTEL'" Subject: RE: [Iptel] Route Capability question(s) Message-ID: <004401c2a60a$dc84f520$857c3d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <015001c2a5dc$96b026b0$2a00000a@RPORTER> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal 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, 17 Dec 2002 22:28:22 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > -----Original Message----- > From: iptel-admin@ietf.org [mailto:iptel-admin@ietf.org] On > Behalf Of Rick W. Porter > Sent: Tuesday, December 17, 2002 4:57 PM > To: Jonathan Rosenberg > Cc: IPTEL > Subject: Re: [Iptel] Route Capability question(s) > > > Hi Jonathan, > > Thank you for taking the time to respond. > > I was picturing a network where network elements within an > ITAD support different protocols or address families. For > example, some network elements support H323-Q931 and SIP, > while other network elements support just SIP. I thought > this may be desirable due to geographic concerns and > installed protocol bases. As you add protocols to a network, > it may also be desirable to have a non-homogeneous Route > Capability within an ITAD (at least as a transient effect). > > IMHO, if TRIP only supports homogeneous Route Capability > within an ITAD, it should probably be noted somewhere. I > guess I raise the point b/c it was not clear to me--if no one > else finds it confusing, great. What if some LSs support H323-Q931 only while other LSs in the same ITAD support both H323-Q931 and SIP? This could happen for example when migrating from one call control technology to another. For correctness, it is sufficient that all internal LSs that support a common route capability to synchronize the TRIBs corresponding to that capability. For example, if two LSs, LS1 supports H323-Q931 only and LS2 supports both SIP and H323-Q931, then the two LSs must only synchronize their H323-Q931 TRIBs. LS1 shouldn't be required to create a SIP TRIB.Hence, I think that the restriction should be that all internal LSs that support a common route capability should form a coonected network. Thanks Hussein > If you want to mandate that > ITADs have homogeneous Route Capability, then all my issues > go away you can stop reading my response... Otherwise, I > responded to a couple other points below. > > Thanks, > Rick > > ----- Original Message ----- > > > If it applies to the peer LS (not just the connection), I have > > > questions arising from a couple scenarios... First, what > do you do > > > for a peer who is not directly connected to you (you > never establish > > > a peering session and negotiate route capabilities with them)? > > > > Then they are not a peer: > > > > > Peers: Two LSs that share a logical association (a transport > > > connection). If the LSs are in the same ITAD, they > are internal > > > peers. Otherwise, they are external peers. The > logical association > > > between two peer LSs is called a peering session. > > My understanding was that TRIP does not require a full mesh > (as does BGP), so two LSs in the same ITAD could learn each > others routes without being directly connected. Below, I > depict the simplest such situation within an ITAD. > > LS A <---> LS B <---> LS C > > I believe you would still want LS A to learn LS C's routes > (and vice versa). And, according to Section 10.1, "When an LS > receives an UPDATE message from an internal peer, the LS > floods the new information from that message to all of its > other internal peers." I understand this to mean that LS B > would send all new LS A routes to LS C (and vice versa). > > I agree that LS A and LS C do not have a peering session, but > what would be the relationship between LS A and LS C (given > they're in the same ITAD)? My understanding is that they > would be still be internal peers, but have no peering > session. You would determine "connectivity" with them using > the ITAD Topology attributes. > > If they are internal peers, what route capabilities would LS > A allow for LS C? If they are not internal peers, would LS A > treat LS C routes (learned via the peering session with LS B) > as routes from an external peer? > > > > > > > > Second, let's assume that > > > an LS can be (mis)configured to negotiate different route > > > capabilities with different peers. What is the correct > behavior when > > > there are multiple "paths" to get between two peers with > different > > > negotiated route capabilities? Do you assume the lowest common > > > denominator of negotiated route capability? > > > > Sounds like the answer is "dont do that". > > > > I agree that this gets very messy, very quickly. That is why > I proposed eliminating the Route Capability negotiation > within an ITAD. > > > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Dec 18 01:12:44 2002 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 BAA03726 for ; Wed, 18 Dec 2002 01:12:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBI6FMY01296 for iptel-archive@odin.ietf.org; Wed, 18 Dec 2002 01:15:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI6FMv01293 for ; Wed, 18 Dec 2002 01:15:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03715 for ; Wed, 18 Dec 2002 01:12:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI6F9v01277; Wed, 18 Dec 2002 01:15:09 -0500 Received: from www1.ietf.org ([211.209.50.6]) by www1.ietf.org (8.11.6/8.11.6) with SMTP id gBI6EFv01242 for iptel@www1.ietf.org; Wed, 18 Dec 2002 01:14:17 -0500 Message-Id: <200212180614.gBI6EFv01242@www1.ietf.org> To: From: bagstage Content-Type: text/html;charset=ks_c_5601-1987 Subject: [Iptel] bagstage.co.kr 특별한 여성 패션 핸드백/가방 전문 쇼핑몰. (광고) 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, 18 Dec 2002 01:14:17 -0500
위 배너는 발송자 및 메일내용과 무관합니다.
http://user6.baitop.co.kr/~nooneguy/spam/bagstage
 

    안녕하세요.
   특별한 당신을 위한 여성전문 가방 핸드백 쇼핑몰 백스테이지입니다.

   오픈한지 한달이 지나가고 있는데 벌써 방문자수도 많이 늘고 있고
   제품에 대한 주문 및 문의도 부쩍 늘어가고 있습니다.
   한번 방문하시어 유행의 흐름을 접해보시기 바랍니다.

   12월 한달간 다음과 같이 진행합니다.
   전 상품 10% ~ 20% 세일
   구매금액의 2%를 마일리지 적립
   또한, 추천인에게 2% 마일리지 적립
   신규회원 가입시 마일리지 1000점 부여
   적립 마일리지 3000점 이상시 사용가능
   12월 우수구객 5명을 선정, 소정의 사은품을 드립니다.

   메일을 받으신 모든 분들의 행복한 연말연시를 기원합니다.
   
_______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Dec 18 08:09:50 2002 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 IAA05018 for ; Wed, 18 Dec 2002 08:09:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBIDCMb02951 for iptel-archive@odin.ietf.org; Wed, 18 Dec 2002 08:12:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIDCLv02948 for ; Wed, 18 Dec 2002 08:12:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05012 for ; Wed, 18 Dec 2002 08:09:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIDCAv02905; Wed, 18 Dec 2002 08:12:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIDAdv02758 for ; Wed, 18 Dec 2002 08:10:39 -0500 Received: from acmepacket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04881 for ; Wed, 18 Dec 2002 08:07:36 -0500 (EST) Received: from RPORTER [63.67.143.2] by acmepacket.com (SMTPD32-7.07) id A3C6A82000C2; Wed, 18 Dec 2002 08:10:30 -0500 Message-ID: <008a01c2a697$434e9090$2a00000a@RPORTER> From: "Rick W. Porter" To: "IPTEL" Cc: "Hussein Salama" References: <004401c2a60a$dc84f520$857c3d0a@amer.cisco.com> Subject: Re: [Iptel] Route Capability question(s) 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 18 Dec 2002 08:13:31 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Hussein for your input. It sounds to me like you agree that an ITAD may need to have network elements with different Route Capabilities. Your proposed restriction that all internal LSs that support a common route capability should form a connected network sounds perfectly reasonable to me, and it stops the ITAD from becoming segmented. However, there are implications for message processing--mainly the flooding, which I explore below. We'll assume that negotiated route capability applies to the peer session (connection), which seems a logical assumption to me. Let's take a simple scenario illustrated below where LS1 and LS2 support SIP and H323-Q931, while LS3 only supports H323-Q931. LS1 <---> LS2 <---> LS3 When LS2 receives a SIP route from LS1, what happens to it? I believe that according to current flooding rules, it would get flooded in it's entirety to LS3. Do you propose that LS2 tailors the message to forward only negotiated route types to LS3? If LS2 filters out the unnegotiated route types for each peer, it would not be a big issue in this scenario. Messages from LS1 that contain only SIP routes would be completely dropped, and messages from LS1 that contain both SIP and H323-Q931 routes would have the SIP routes filtered out so only H323-Q931 routes would be forwarded. Although not a big deal here, the center of a star configuration with many peers may burn lots of CPU cycles tailoring messages during flooding. Does that defeat the purpose of flooding?Maybe a release note for an LS product would be sufficient, but it seems to me to be more a protocol issue than an implementation issue. I understand that an intelligent implementation may minimize the impact by "grouping" connections by negotiated route types so the message could be tailored to a group instead of tailoring it to individual peers. If LS2 does not filter out unnegotiated routes (as currently seems to be suggested), it would forward the message in its entirety to LS3. Does LS3 ignore out the unsupported (SIP) route type? Possibly send a notification message (potential error code=0x306)? If there were an LS4 connected only to LS3, would LS3 then filter the SIP routes before flooding? Ignoring and flooding the unnegotiated route type would seem to be the simplest from an implementation standpoint. Then, why did we negotiate a route capability for the connection? Thanks, Rick _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Dec 20 19:48:34 2002 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 TAA17149 for ; Fri, 20 Dec 2002 19:48:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBL0pYc21426 for iptel-archive@odin.ietf.org; Fri, 20 Dec 2002 19:51:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBL0pXv21423 for ; Fri, 20 Dec 2002 19:51:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17045 for ; Fri, 20 Dec 2002 19:48:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBL0pCv21394; Fri, 20 Dec 2002 19:51:12 -0500 Received: from speople.co.kr ([211.110.75.137]) by www1.ietf.org (8.11.6/8.11.6) with SMTP id gBL0onv21348 for ; Fri, 20 Dec 2002 19:50:50 -0500 Message-Id: <200212210050.gBL0onv21348@www1.ietf.org> From: 보보스21 To: iptel@www1.ietf.org Reply-To: mail3@speople.co.kr Mime-Version: 1.0 Content-Type: text/html; charset=ks_c_5601-1987 Subject: [Iptel] [명품광고]선물 미리준비하세요!! 모든 명품브랜드 특가전할인판매-100%정품보증 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, 20 Dec 2002 19:50:50 -0500 Untitled Document
_______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 23 02:20:08 2002 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 CAA23146 for ; Mon, 23 Dec 2002 02:20:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBN7NYA25017 for iptel-archive@odin.ietf.org; Mon, 23 Dec 2002 02:23:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBN7NXv25014 for ; Mon, 23 Dec 2002 02:23:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23143 for ; Mon, 23 Dec 2002 02:19:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBN7NJv24998; Mon, 23 Dec 2002 02:23:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBN7M7v24758 for ; Mon, 23 Dec 2002 02:22:07 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23137 for ; Mon, 23 Dec 2002 02:18:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBN7LDYH021422; Mon, 23 Dec 2002 02:21:14 -0500 (EST) Message-ID: <3E06B966.6090205@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rick W. Porter" CC: IPTEL , Hussein Salama Subject: Re: [Iptel] Route Capability question(s) References: <004401c2a60a$dc84f520$857c3d0a@amer.cisco.com> <008a01c2a697$434e9090$2a00000a@RPORTER> 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, 23 Dec 2002 02:21:10 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have no problem with enterprises that have LSs that speak different protocols. However, I would model that as multiple logical ITADs, rather than a single ITAD. Each logical ITAD would have homogeneous capabilities amongs the elements. LS's at the border of one logical ITADF to another would be responsible for propagating only the appropriate routes from one to the other. I see no need to make this more complicated. -Jonathan R. Rick W. Porter wrote: > Thanks Hussein for your input. It sounds to me like you agree that an ITAD > may need to have network elements with different Route Capabilities. Your > proposed restriction that all internal LSs that support a common route > capability should form a connected network sounds perfectly reasonable to > me, and it stops the ITAD from becoming segmented. However, there are > implications for message processing--mainly the flooding, which I explore > below. > > We'll assume that negotiated route capability applies to the peer session > (connection), which seems a logical assumption to me. Let's take a simple > scenario illustrated below where LS1 and LS2 support SIP and H323-Q931, > while LS3 only supports H323-Q931. > > LS1 <---> LS2 <---> LS3 > > When LS2 receives a SIP route from LS1, what happens to it? I believe that > according to current flooding rules, it would get flooded in it's entirety > to LS3. Do you propose that LS2 tailors the message to forward only > negotiated route types to LS3? > > If LS2 filters out the unnegotiated route types for each peer, it would not > be a big issue in this scenario. Messages from LS1 that contain only SIP > routes would be completely dropped, and messages from LS1 that contain both > SIP and H323-Q931 routes would have the SIP routes filtered out so only > H323-Q931 routes would be forwarded. Although not a big deal here, the > center of a star configuration with many peers may burn lots of CPU cycles > tailoring messages during flooding. Does that defeat the purpose of > flooding?Maybe a release note for an LS product would be sufficient, but it > seems to me to be more a protocol issue than an implementation issue. I > understand that an intelligent implementation may minimize the impact by > "grouping" connections by negotiated route types so the message could be > tailored to a group instead of tailoring it to individual peers. > > If LS2 does not filter out unnegotiated routes (as currently seems to be > suggested), it would forward the message in its entirety to LS3. Does LS3 > ignore out the unsupported (SIP) route type? Possibly send a notification > message (potential error code=0x306)? If there were an LS4 connected only to > LS3, would LS3 then filter the SIP routes before flooding? Ignoring and > flooding the unnegotiated route type would seem to be the simplest from an > implementation standpoint. Then, why did we negotiate a route capability for > the connection? > > > Thanks, > Rick > > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www.ietf.org/mailman/listinfo/iptel > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 mailnull@www1.ietf.org Thu Dec 26 07:07:10 2002 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 HAA09499 for ; Thu, 26 Dec 2002 07:07:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBQCC0223008 for iptel-archive@odin.ietf.org; Thu, 26 Dec 2002 07:12:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBQCC0J23004 for ; Thu, 26 Dec 2002 07:12:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09496 for ; Thu, 26 Dec 2002 07:06:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBQCBLJ22996; Thu, 26 Dec 2002 07:11:21 -0500 Received: from hanmir.com ([220.77.173.101]) by www1.ietf.org (8.11.6/8.11.6) with SMTP id gBQC9xJ22947 for ; Thu, 26 Dec 2002 07:10:00 -0500 Message-Id: <200212261210.gBQC9xJ22947@www1.ietf.org> From: 하무언 To: iptel@www1.ietf.org Reply-To: cantos1001@hanmir.com Mime-Version: 1.0 Content-Type: text/html; charset=ks_c_5601-1987 Subject: [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: Thu, 26 Dec 2002 07:10:00 -0500
정보통신부 권고사항에 의거 작성한 [광고] 메일입니다.
앞으로 메일수신을 원치 않으시면 수신거부를 눌러주십시오.

"발 건강관리 참고자료"

발은 사람에게 매우 중요한 부위이며 인체의 축소판이다.!!

발은 26개의 뼈, 41개의 인대와 20개의 근육이 하나의 복합체로 작용해 긴밀한 관계를 맺어 직립의 기본이 되고 몸의 중량을 받쳐주는 주춧돌 구실을 한다.

특히 인체의 내장기관과 상응관계가 있어 발을 자극하면 무기력해진 내장기관을 정상화하거나 활성화할 수 있다.

발은 다리, 골반, 척추에 영향을 준다. 또 모세혈관이나 말초신경이 많이 분포돼 있어 제2의 심장이라고도 부른다. 발은 심장에서 가장 먼 곳에 있으므로 혈액순환이 원활하지 않으면 갖가지 질병이 생긴다.
발에 이상이 있거나 피로하면 걷거나 서 있기가 힘들 뿐 아니라 척추나 혈액순환에도 장애를 줘 질병에 걸리기 쉽다.

●발바닥을 자극하면 어떤 효과?

한의학에서 발바닥은 경혈(經穴:침자리)이 집중돼 있는 중요한 곳이다. 경혈을 자극하면 이에 상응하는 내장이나 기관의 움직임이 활발해지고 혈액순환과 자율신경의 움직임이 좋아져 질병을 치료·예방할 수 있다. 신진대사가 원활해지고 혈압이 정상으로 돌아온다는 것이다.

자갈과 모래밭의 원리로 만든제품 

         

자갈지압 CT-2002A                  한방지압 CT-2002B

자갈과 모래밭 원리와 발의리플렉스요법을 응용한

지압과족침용 헬스샌들!! 건강신발!! 선물로도 좋습니다.!!

   

 (헬스샌들 CT-704) 

저희 온누리산업은 50 여건의 특허와 국제대회 수상 및 국내 우수발명품 선정에 힘입어 일상 생활용품에 건강효과를 도입한 지압매트 건강매트 건강신발 지압샌들 건강샌들 운전샌달  지압욕실화 지압실내화 효도신발  지압슬립퍼를 비롯한 발건강매트,신발 발관리제품등 20 여종의 발건강관리 관련제품을 생산 판매하고 있습니다.
칸토스 CANTOS 헬스매트 건강신발 및 슬리퍼는 지압과 족침원리를 이용하여 일상생활을 위한 착용 그 자체 만으로도 발에 분포되어 있는 전신기혈의 상응점 들을 자극하여 건강의 유지 및 증진 효과를 도모한 제품입니다.

   발의 리플렉스 요법을 응용한 각종 건강상품 주문문의..

귀하의 메일주소는 웹서핑,계시판,방명록에서 알게 된것입니다.E-Mail 주소 외에, 다른 정보는 갖고 있지 않습니다.정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다.

메일발송에 불편을 드렸다면 정중하게 사과드립니다. 메일받기를 원치 않으시면 수신거부를 눌러주세요.

온누리산업 Tel: 051-516-6556   http://helshoes.com

 

 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Thu Dec 26 17:19:24 2002 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 RAA16480 for ; Thu, 26 Dec 2002 17:19:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBQMOQ617215 for iptel-archive@odin.ietf.org; Thu, 26 Dec 2002 17:24:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBQMOPJ17211 for ; Thu, 26 Dec 2002 17:24:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16477 for ; Thu, 26 Dec 2002 17:18:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBQMOBJ17203; Thu, 26 Dec 2002 17:24:11 -0500 Received: from hanmir.com ([220.77.173.101]) by www1.ietf.org (8.11.6/8.11.6) with SMTP id gBQMNaJ17189 for ; Thu, 26 Dec 2002 17:23:37 -0500 Message-Id: <200212262223.gBQMNaJ17189@www1.ietf.org> From: 하무언 To: iptel@www1.ietf.org Reply-To: cantos1001@hanmir.com Mime-Version: 1.0 Content-Type: text/html; charset=ks_c_5601-1987 Subject: [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: Thu, 26 Dec 2002 17:23:37 -0500
정보통신부 권고사항에 의거 작성한 [광고] 메일입니다.
앞으로 메일수신을 원치 않으시면 수신거부를 눌러주십시오.

"발 건강관리 참고자료"

발은 사람에게 매우 중요한 부위이며 인체의 축소판이다.!!

발은 26개의 뼈, 41개의 인대와 20개의 근육이 하나의 복합체로 작용해 긴밀한 관계를 맺어 직립의 기본이 되고 몸의 중량을 받쳐주는 주춧돌 구실을 한다.

특히 인체의 내장기관과 상응관계가 있어 발을 자극하면 무기력해진 내장기관을 정상화하거나 활성화할 수 있다.

발은 다리, 골반, 척추에 영향을 준다. 또 모세혈관이나 말초신경이 많이 분포돼 있어 제2의 심장이라고도 부른다. 발은 심장에서 가장 먼 곳에 있으므로 혈액순환이 원활하지 않으면 갖가지 질병이 생긴다.
발에 이상이 있거나 피로하면 걷거나 서 있기가 힘들 뿐 아니라 척추나 혈액순환에도 장애를 줘 질병에 걸리기 쉽다.

●발바닥을 자극하면 어떤 효과?

한의학에서 발바닥은 경혈(經穴:침자리)이 집중돼 있는 중요한 곳이다. 경혈을 자극하면 이에 상응하는 내장이나 기관의 움직임이 활발해지고 혈액순환과 자율신경의 움직임이 좋아져 질병을 치료·예방할 수 있다. 신진대사가 원활해지고 혈압이 정상으로 돌아온다는 것이다.

자갈과 모래밭의 원리로 만든제품 

         

자갈지압 CT-2002A                  한방지압 CT-2002B

자갈과 모래밭 원리와 발의리플렉스요법을 응용한

지압과족침용 헬스샌들!! 건강신발!! 선물로도 좋습니다.!!

   

 (헬스샌들 CT-704) 

저희 온누리산업은 50 여건의 특허와 국제대회 수상 및 국내 우수발명품 선정에 힘입어 일상 생활용품에 건강효과를 도입한 지압매트 건강매트 건강신발 지압샌들 건강샌들 운전샌달  지압욕실화 지압실내화 효도신발  지압슬립퍼를 비롯한 발건강매트,신발 발관리제품등 20 여종의 발건강관리 관련제품을 생산 판매하고 있습니다.
칸토스 CANTOS 헬스매트 건강신발 및 슬리퍼는 지압과 족침원리를 이용하여 일상생활을 위한 착용 그 자체 만으로도 발에 분포되어 있는 전신기혈의 상응점 들을 자극하여 건강의 유지 및 증진 효과를 도모한 제품입니다.

   발의 리플렉스 요법을 응용한 각종 건강상품 주문문의..

귀하의 메일주소는 웹서핑,계시판,방명록에서 알게 된것입니다.E-Mail 주소 외에, 다른 정보는 갖고 있지 않습니다.정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다.

메일발송에 불편을 드렸다면 정중하게 사과드립니다. 메일받기를 원치 않으시면 수신거부를 눌러주세요.

온누리산업 Tel: 051-516-6556   http://helshoes.com

 

 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Thu Dec 26 20:40:10 2002 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 UAA18927 for ; Thu, 26 Dec 2002 20:40:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBR1jHm26410 for iptel-archive@odin.ietf.org; Thu, 26 Dec 2002 20:45:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBR1jHJ26407 for ; Thu, 26 Dec 2002 20:45:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18924 for ; Thu, 26 Dec 2002 20:39:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBR1j8J26319; Thu, 26 Dec 2002 20:45:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBR1i1J26163 for ; Thu, 26 Dec 2002 20:44:01 -0500 Received: from yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18858 for ; Thu, 26 Dec 2002 20:38:12 -0500 (EST) Message-Id: <200212270138.UAA18858@ietf.org> From: =?GB2312?B?yc+6o7fj4/6+rbzDv6q3osf4?= To: iptel@ietf.org Content-Type: text/plain;charset="GB2312" X-Priority: 3 X-Mailer: Foxmail 4.1 [cn] Subject: [Iptel] =?GB2312?B?yc+6o7+qt6LH+NeisuG5q8u+s6TG2s/tyty087bussbV/r2xwPg=?= 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 Dec 2002 09:37:33 +0800 역랙혐角�瞿＝條실圃�리苟橄돨쒔셌茄竟，혐漣리뚤 鬧꿍、쭝빵瞳역랙혐돨폐撚唐寧溝죗膽쁨漣꿉。圈헙 숨http://www.fngjng.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Dec 30 06:17:56 2002 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 GAA22332 for ; Mon, 30 Dec 2002 06:17:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUBOhD27718 for iptel-archive@odin.ietf.org; Mon, 30 Dec 2002 06:24:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUBOhJ27715 for ; Mon, 30 Dec 2002 06:24:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22313 for ; Mon, 30 Dec 2002 06:17:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUBOLJ27481; Mon, 30 Dec 2002 06:24:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUBN6J27260 for ; Mon, 30 Dec 2002 06:23:06 -0500 Received: from emztd765.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22153 for ; Mon, 30 Dec 2002 06:15:45 -0500 (EST) Message-Id: <200212301115.GAA22153@ietf.org> From: "MRS. MARYAM ABACHA" Reply-To: maryam42003@37.com To: iptel@ietf.org X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBUBN7J27261 Subject: [Iptel] PLEASE ASSIST ME !! 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 Dec 2002 12:16:00 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 30TH DECEMBER, 2002 FROM: MRS. MARYAM ABACHA EMAIL: maryam2003@fastermail.com DEAR SIR, FIRSTLY, I MUST WISH YOU A HAPPY AND PROSPEROUS NEW YEAR IN ADVANCE. I AM MRS. MARYAM ABACHA, WIFE OF LATE GEN. SANNI ABACHA, EX-MILITARY HEAD OF STATE OF THE FEDERAL REPUBLIC OF NIGERIA WHO DIED ON THE 8TH OF JUNE 1998 OF HEART PROBLEMS. I CONTACTED YOU BECAUSE OF MY NEED TO DEAL WITH PERSONS WHOM MY FAMILY AND I HAVE HAD NO PREVIOUS PERSONAL RELATIONSHIPS. SINCE THE DEATH OF MY HUSBAND, MY FAMILY HAD BEEN SUBJECTED TO ALL SORTS OF HARASSMENT AND INTIMIDATION WITH LOTS OF NEGATIVE REPORTS EMANATING FROM THE GOVERNMENT AND THE PRESS ABOUT MY HUSBAND. THE PRESENT GOVERNMENT HAS ALSO ENSURED THAT OUR BANK ACCOUNTS ARE FROZEN AND ALL ASSETS SEIZED BOTH LOCAL AND INTERNATIONAL, BUT MY ONLY SOURCE OF HOPE NOW IS AN AVAILABLE US$30,000,000.00 CASH, (THIRTY MILLION DOLLARS) WHICH WAS SECRETLY DEPOSITED BY MY LATE HUSBAND AS PERSONAL EFFECTS IN A SECURITY COMPANY IN ASIA, UNKNOWN TO THE NIGERIAN GOVERNMENT. I HAVE BEEN UNDER HOUSE ARREST TOGETHER WITH MY SON SINCE FEBRUARY, 1999 AND THEREFORE CANNOT TRAVEL. PLEASE I AM SOLICITING YOUR ASSISTANCE FOR THE TRANSFER OF THIS MONEY FROM THE SECURITY COMPANY INTO YOUR PERSONAL ACCOUNT. I PROMISE TO COMPENSATE YOU WITH 20% 0F THE TOTAL SUM. FOR THE SAKE OF GOD, PLEASE DO NOT BETRAY AFTER RECEIVING THE MONEY. I WILL JOIN YOU IN YOUR COUNTRY AFTER OUR FINAL RELEASE BY THE FEDERAL GOVERNMENT. FOR THE EASE OF COMMUNICATION, PLEASE SEND ME YOUR PHONE AND FAX NUMBERS SO THAT MY LAWYER CAN SEND YOU ALL THE NECESSARY LEGAL DOCUMENTS THAT WILL BACK YOU UP FOR THE CLAIM. THANK YOU. YOURS SINCERELY, MRS. MARYAM ABACHA _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel