From mailnull@www1.ietf.org Fri Nov 1 02:21: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 CAA10374 for ; Fri, 1 Nov 2002 02:21:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA17O2T04750 for iptel-archive@odin.ietf.org; Fri, 1 Nov 2002 02:24: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 gA17O1v04747 for ; Fri, 1 Nov 2002 02:24: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 CAA10360 for ; Fri, 1 Nov 2002 02:21:26 -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 gA17O0v04743 for ; Fri, 1 Nov 2002 02:24:00 -0500 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA17NWv04730 for ; Fri, 1 Nov 2002 02:23:32 -0500 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 gA17N7xF013722; Thu, 31 Oct 2002 23:23:07 -0800 (PST) Received: from fluffyw2k (sjc-vpn3-405.cisco.com [10.21.65.149]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id ASX00201; Thu, 31 Oct 2002 23:23:40 -0800 (PST) From: "Cullen Jennings" To: Cc: 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 V5.50.4807.1700 Subject: [Iptel] test 2 Sender: iptel-admin@www1.ietf.org Errors-To: iptel-admin@www1.ietf.org X-BeenThere: iptel@www1.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, 31 Oct 2002 23:23:11 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit test 2 _______________________________________________ Iptel mailing list Iptel@www1.ietf.org http://optimus/mailman/listinfo/iptel From extest-admin@lists.bell-labs.com Fri Nov 1 06:40:13 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 GAA03926 for ; Fri, 1 Nov 2002 06:40:13 -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 gA1Bgd227223 for ; Fri, 1 Nov 2002 06:42:39 -0500 Date: Fri, 1 Nov 2002 06:42:39 -0500 Message-Id: <200211011142.gA1Bgd227223@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 Fri Nov 1 13:17: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 NAA27146 for ; Fri, 1 Nov 2002 13:17:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1IJ2k25351 for iptel-archive@odin.ietf.org; Fri, 1 Nov 2002 13:19: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 gA1IJ2v25348 for ; Fri, 1 Nov 2002 13:19:02 -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 NAA27117 for ; Fri, 1 Nov 2002 13:16: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 gA1IJ1v25332 for ; Fri, 1 Nov 2002 13:19: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 gA1IIAv25290 for ; Fri, 1 Nov 2002 13:18:10 -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 NAA27068 for ; Fri, 1 Nov 2002 13:15:40 -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 gA1II5PP029246 for ; Fri, 1 Nov 2002 10:18:05 -0800 (PST) Received: from fluffyw2k (sjc-vpn3-405.cisco.com [10.21.65.149]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id AUE00488; Fri, 1 Nov 2002 10:18:32 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Iptel] test 3 Sender: iptel-admin@www1.ietf.org Errors-To: iptel-admin@www1.ietf.org X-BeenThere: iptel@www1.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, 1 Nov 2002 10:18:05 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit test 3 _______________________________________________ Iptel mailing list Iptel@www1.ietf.org http://optimus/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Nov 1 18:42:19 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 SAA08837 for ; Fri, 1 Nov 2002 18:42:19 -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 gA1NbC230543; Fri, 1 Nov 2002 18:37:12 -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 gA1NXh230510 for ; Fri, 1 Nov 2002 18:33:43 -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 gA1NXfhN092867 for ; Fri, 1 Nov 2002 18:33:41 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id A9804443A5; Fri, 1 Nov 2002 18:33:36 -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 8420A443A4 for ; Fri, 1 Nov 2002 18:33:36 -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 SMTP id gA1NXZa04242 for ; Fri, 1 Nov 2002 18:33:35 -0500 (EST) Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by dusty; Fri Nov 1 18:33:34 EST 2002 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 gA1NXQPP003642; Fri, 1 Nov 2002 15:33:27 -0800 (PST) Received: from fluffyw2k (sjc-vpn3-405.cisco.com [10.21.65.149]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id AUU00282; Fri, 1 Nov 2002 15:33:49 -0800 (PST) From: "Cullen Jennings" To: "IPTEL List" Cc: "Jonathan Rosenberg" , "Fluffy" 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 V5.50.4807.1700 Subject: [IPTEL] Moving the IPTEL mailing list Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 1 Nov 2002 15:33:21 -0800 Content-Transfer-Encoding: 7bit Hello All, We are going to move the mailing list to be hosted at ietf.org. All of you need to resubscribe. We are NOT moving anyone over from the existing list. Web-based (un)subscribe: https://www1.ietf.org/mailman/listinfo/iptel List-Subscribe: mailto:iptel-request@ietf.org?subject=subscribe List-Unsubscribe: mailto:iptel-request@ietf.org?subject=unsubscribe List-Help: mailto:iptel-request@ietf.org?subject=help List-Post: mailto:iptel@ietf.org Thanks, Cullen _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Nov 4 09:57: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 JAA15391 for ; Mon, 4 Nov 2002 09:57:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4Ex7u30025 for iptel-archive@odin.ietf.org; Mon, 4 Nov 2002 09:59: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 gA4Ex7v30022 for ; Mon, 4 Nov 2002 09:59: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 JAA15383 for ; Mon, 4 Nov 2002 09:56:37 -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 gA4Ex0v29969; Mon, 4 Nov 2002 09:59: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 gA4Es1v29753 for ; Mon, 4 Nov 2002 09:54:01 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14940; Mon, 4 Nov 2002 09:51:31 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gA4Ervb03744; Mon, 4 Nov 2002 09:53:57 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA06670; Mon, 4 Nov 2002 08:53:56 -0600 (CST) Message-ID: <3DC689FB.6080606@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories 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: SIPPING LIST , iptel@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Iptel] Trunk groups in URI Sender: iptel-admin@www1.ietf.org Errors-To: iptel-admin@www1.ietf.org X-BeenThere: iptel@www1.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, 04 Nov 2002 08:53:47 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks: Some of you may recall that we had a healthy discussion on representing trunk groups in URIs 6 weeks ago or so. We have distilled the issues discussed in the course of those emails into the following I-D: Until it appears in the IETF archive, you can get it from the above URL. We can discuss it further in Atlanta. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Iptel mailing list Iptel@www1.ietf.org https://www1.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Nov 6 18:56: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 SAA17422 for ; Wed, 6 Nov 2002 18:56:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6NwJD22241 for iptel-archive@odin.ietf.org; Wed, 6 Nov 2002 18:58: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 gA6NwJv22238 for ; Wed, 6 Nov 2002 18:58: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 SAA17383 for ; Wed, 6 Nov 2002 18:55: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 gA6Nw5v22201; Wed, 6 Nov 2002 18: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 gA6Nv5v22150 for ; Wed, 6 Nov 2002 18:57:05 -0500 Received: from imo-m07.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17341 for ; Wed, 6 Nov 2002 18:54:28 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m07.mx.aol.com (mail_out_v34.13.) id l.124.1998f345 (4262) for ; Wed, 6 Nov 2002 18:56:44 -0500 (EST) Message-ID: <124.1998f345.2afb063c@aol.com> To: iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_124.1998f345.2afb063c_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Subject: [Iptel] Comments on draft-iptel-trunk-group Sender: iptel-admin@www1.ietf.org Errors-To: iptel-admin@www1.ietf.org X-BeenThere: iptel@www1.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, 6 Nov 2002 18:56:44 EST --part1_124.1998f345.2afb063c_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Comments as follows: 1 In order to read correctly, the words "trunk-groups" in the first sentence should read "trunk group identifiers". 2.1 Definitions - Suggest to delete the final sentence about a trunk group having "both its terminations in the same switching system". This just leads to confusion and has no significance to the rest of the discussion. The reference to it being "common to refer to bundles of DS0s as a trunk" should be deleted, since this just confuses the issue. I don't believe it is "common". 3.1 It is incorrect to list carrying the trunk group information in the tel:uri as a "requirement". I believe that the functional requirements for carrying a telephone number (in the tel:uri) and for carrying a trunk group identifier are very much different, so it would be best not to put it there. However, if the realities of current/future SIP limit the choices to putting it in the tel:uri or the sip:uri, then it is probably correct that the tel:uri is the better of the options, but it is not a "requirement". 4. ABNF There seems to be some confusion in the permissable trunk group names. Using the "=" to separate the namespace and label seems a little strange. The draft-polk-sipping-resource, which also has a "namespace/labe;" contruct uses a "." as a separator. Although the trunk-group-label follows an "=", it is shown that the label itself can contain (and begin with) the "=" character. If the intention is to allow any characters in the label in order to support any exsiting naming scheme (a worthy goal), then isn't this a case in which it is enclosed in quotes and any characters can be inside the quotes? Mike Pierce Artel --part1_124.1998f345.2afb063c_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit Comments as follows:

1 In order to read correctly, the words "trunk-groups" in the first sentence should read "trunk group identifiers".

2.1 Definitions - Suggest to delete the final sentence about a trunk group having "both its terminations in the same switching system". This just leads to confusion and has no significance to the rest of the discussion.

The reference to it being "common to refer to bundles of DS0s as a trunk" should be deleted, since this just confuses the issue. I don't believe it is "common".

3.1 It is incorrect to list carrying the trunk group information in the tel:uri as a "requirement".

I believe that the functional requirements for carrying a telephone number (in the tel:uri) and for carrying a trunk group identifier are very much different, so it would be best not to put it there. However, if the realities of current/future SIP limit the choices to putting it in the tel:uri or the sip:uri, then it is probably correct that the tel:uri is the better of the options, but it is not a "requirement".


4. ABNF

There seems to be some confusion in the permissable trunk group names.

Using the "=" to separate the namespace and label seems a little strange. The draft-polk-sipping-resource, which also has a "namespace/labe;" contruct uses a "." as a separator.

Although the trunk-group-label follows an "=", it is shown that the label itself can contain (and begin with) the "=" character. If the intention is to allow any characters in the label in order to support any exsiting naming scheme (a worthy goal), then isn't this a case in which it is enclosed in quotes and any characters can be inside the quotes?

Mike Pierce
Artel

--part1_124.1998f345.2afb063c_boundary-- _______________________________________________ Iptel mailing list Iptel@www1.ietf.org https://www1.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Nov 6 23:39: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 XAA23220 for ; Wed, 6 Nov 2002 23:39:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA74fHK05448 for iptel-archive@odin.ietf.org; Wed, 6 Nov 2002 23:41: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 gA74fHv05445 for ; Wed, 6 Nov 2002 23:41: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 XAA23217 for ; Wed, 6 Nov 2002 23:38: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 gA74f2v05435; Wed, 6 Nov 2002 23:41: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 gA74eev05416 for ; Wed, 6 Nov 2002 23:40:40 -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 XAA23201 for ; Wed, 6 Nov 2002 23:38:01 -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 gA74e8xF029883; Wed, 6 Nov 2002 20:40:13 -0800 (PST) Received: from fluffyw2k (rtp-vpn1-75.cisco.com [10.82.224.75]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id BJF00279; Wed, 6 Nov 2002 20:40:43 -0800 (PST) From: "Cullen Jennings" To: Cc: "Cullen Jennings" , "Jonathan Rosenberg" 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 V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Iptel] Proposed Agenda for 55th IETF Sender: iptel-admin@www1.ietf.org Errors-To: iptel-admin@www1.ietf.org X-BeenThere: iptel@www1.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, 6 Nov 2002 20:40:15 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Here is the currently proposed agenda for the next meeting. Any things we need to add, change, or drop? Other comments and requests? Keep in mind we only have one hour. Thanks, Cullen IP Telephony (iptel) TUESDAY, November 19, 1700-1800 ================================= CHAIRS: Jonathan Rosenberg Cullen Jennings AGENDA: 5 mins Agenda Bashing 15 mins TGREP Open Issues Dhaval Shah draft-ietf-iptel-tgrep 10 mins 2806bis Open Issues Henning Schulzrinne draft-antti-rfc2806bis 15 mins Open Issues with Trunk Groups Vijay Gurbani draft-ietf-iptel-trunk-group 15 mins Open Issues CPC/OLI in Tel URL Jon Peterson draft-peterson-tel-cpc Timer permitting any comments on: draft-brandner-enum-uri draft-levin-iptel-h323-url-scheme LINKS: Mailing list: iptel@ietf.org Archive: www.ietf.org/mail-archive/working-groups/iptel WG web page: http://www.ietf.org/html.charters/iptel-charter.html Additional page: http://www.softarmor.com/iptel/ _______________________________________________ Iptel mailing list Iptel@www1.ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Nov 7 00:23:04 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 AAA23976 for ; Thu, 7 Nov 2002 00:23:04 -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 gA75HB203862; Thu, 7 Nov 2002 00:17:11 -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 gA75GL203849 for ; Thu, 7 Nov 2002 00:16:21 -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 gA75GKhN047693 for ; Thu, 7 Nov 2002 00:16:20 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id F0D80443A5; Thu, 7 Nov 2002 00:16:15 -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 C33EF443A4 for ; Thu, 7 Nov 2002 00:16:14 -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 SMTP id gA75GDa76637 for ; Thu, 7 Nov 2002 00:16:13 -0500 (EST) Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by dusty; Thu Nov 7 00:16:13 EST 2002 Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gA75G0ot025303; Wed, 6 Nov 2002 21:16:00 -0800 (PST) Received: from fluffyw2k (rtp-vpn1-75.cisco.com [10.82.224.75]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id BJH00182; Wed, 6 Nov 2002 21:16:27 -0800 (PST) From: "Cullen Jennings" To: "Cullen Jennings" , "IPTEL List" Cc: "Jonathan Rosenberg" 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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [IPTEL] reminder to subscribe to the new IPTEL mailing list 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: Wed, 6 Nov 2002 21:15:58 -0800 Content-Transfer-Encoding: 7bit I just posted a draft agenda on the new iptel mailing list. If you have not subscribed to ten new list yet - please consider doing so some time soon. My apologies if you have already subscribed and are getting this message. Thanks, Cullen > Web-based (un)subscribe: https://www.ietf.org/mailman/listinfo/iptel > > List-Subscribe: mailto:iptel-request@ietf.org?subject=subscribe > List-Unsubscribe: mailto:iptel-request@ietf.org?subject=unsubscribe > List-Help: mailto:iptel-request@ietf.org?subject=help > > List-Post: mailto:iptel@ietf.org _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Nov 7 11:11:11 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 LAA00194 for ; Thu, 7 Nov 2002 11:11:11 -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 gA7GD6207159; Thu, 7 Nov 2002 11:13:06 -0500 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id gA7GCE207146 for ; Thu, 7 Nov 2002 11:12:14 -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 gA7GCChN052445 for ; Thu, 7 Nov 2002 11:12:12 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 54860443A5; Thu, 7 Nov 2002 11:12:07 -0500 (EST) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 0D1A1443A4 for ; Thu, 7 Nov 2002 11:12:06 -0500 (EST) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id gA7GC5I42162 for ; Thu, 7 Nov 2002 11:12:05 -0500 (EST) Received: from radvpost.RADVISION.com ([12.44.63.6]) by dusty; Thu Nov 7 11:12:03 EST 2002 Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 11:12:16 -0500 Message-ID: From: Orit Levin To: "'iptel@lists. bell-labs. com' ('iptel@lists.bell-labs.com')" , "'iptel@www1.ietf.org'" , "'discuss@apps.ietf.org'" , "'uri@w3c.org'" Cc: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , Cullen Jennings , "Jonathan Rosenberg (JonathanRosenberg)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] FW: I-D ACTION:draft-levin-iptel-h323-url-scheme-05.txt Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 7 Nov 2002 11:12:05 -0500 Hello all! The referenced draft requests to register a new H.323 URL scheme with IANA. Please, review the draft and post all your comments to the IPTEL list so that we would be able to address them before and during the Atlanta IETF meeting. Thank you, Orit Levin Chief Architect RADVISION Tel: +1.201.6896330 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, November 07, 2002 9:28 AM To: enum@ietf.org Subject: [Enum] I-D ACTION:draft-levin-iptel-h323-url-scheme-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : H.323 URL Scheme Registration with IANA Author(s) : O. Levin Filename : draft-levin-iptel-h323-url-scheme-05.txt Pages : 6 Date : 2002-11-6 This IETF document reproduces the H323-URL definition found in ITU-T Recommendation H.323 [3] and is published as an RFC for ease of access and IANA registration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levin-iptel-h323-url-scheme-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-levin-iptel-h323-url-scheme-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-levin-iptel-h323-url-scheme-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2002-11-6174137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-levin-iptel-h323-url-scheme-05.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From mailnull@www1.ietf.org Thu Nov 7 11:11: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 LAA00206 for ; Thu, 7 Nov 2002 11:11:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7GDDA28512 for iptel-archive@odin.ietf.org; Thu, 7 Nov 2002 11:13: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 gA7GDDv28509 for ; Thu, 7 Nov 2002 11:13: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 LAA00161 for ; Thu, 7 Nov 2002 11:10: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 gA7GD3v28486; Thu, 7 Nov 2002 11:13:03 -0500 Received: from radvpost.RADVISION.com ([12.44.63.6]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7GC5v28423 for ; Thu, 7 Nov 2002 11:12:05 -0500 Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 11:12:16 -0500 Message-ID: From: Orit Levin To: "'iptel@lists. bell-labs. com' ('iptel@lists.bell-labs.com')" , "'iptel@www1.ietf.org'" , "'discuss@apps.ietf.org'" , "'uri@w3c.org'" Cc: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , Cullen Jennings , "Jonathan Rosenberg (JonathanRosenberg)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Iptel] FW: I-D ACTION:draft-levin-iptel-h323-url-scheme-05.txt Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Nov 2002 11:12:05 -0500 Hello all! The referenced draft requests to register a new H.323 URL scheme with IANA. Please, review the draft and post all your comments to the IPTEL list so that we would be able to address them before and during the Atlanta IETF meeting. Thank you, Orit Levin Chief Architect RADVISION Tel: +1.201.6896330 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, November 07, 2002 9:28 AM To: enum@ietf.org Subject: [Enum] I-D ACTION:draft-levin-iptel-h323-url-scheme-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : H.323 URL Scheme Registration with IANA Author(s) : O. Levin Filename : draft-levin-iptel-h323-url-scheme-05.txt Pages : 6 Date : 2002-11-6 This IETF document reproduces the H323-URL definition found in ITU-T Recommendation H.323 [3] and is published as an RFC for ease of access and IANA registration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levin-iptel-h323-url-scheme-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-levin-iptel-h323-url-scheme-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-levin-iptel-h323-url-scheme-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2002-11-6174137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-levin-iptel-h323-url-scheme-05.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Thu Nov 7 11:19:06 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 LAA00545 for ; Thu, 7 Nov 2002 11:19:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7GL8F28910 for iptel-archive@odin.ietf.org; Thu, 7 Nov 2002 11:21: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 gA7GL8v28907 for ; Thu, 7 Nov 2002 11:21: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 LAA00531 for ; Thu, 7 Nov 2002 11:18: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 gA7GL3v28897; Thu, 7 Nov 2002 11:21: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 gA7GKRv28856 for ; Thu, 7 Nov 2002 11:20:27 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00493; Thu, 7 Nov 2002 11:17:55 -0500 (EST) Received: from dick.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA27433; Thu, 7 Nov 2002 08:20:07 -0800 Message-Id: <5.1.0.14.2.20021107110621.046b6768@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: enum@ietf.org From: Richard Shockey Cc: iptel@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Iptel] A note from your ENUM WG chairs .... 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, 07 Nov 2002 11:20:38 -0500 Patrik and I have reviewed the issue of this document and have consulted extensively with the Area Directors. The Area Directors have asked the IPTEL WG to assume all responsibility for telephony related URI schemes which will include the TEL URL and the H.323 URL scheme etc. In this context we believe this document properly belongs in IPTEL and therefore is "out of scope" for the ENUM WG. The ENUM WG will continue to be responsible for enumservice registration documents not directly under consideration by a specific WG ( aka fax,vpim). After consulting with the IPTEL chairs they have a full schedule of their own and will not be able to discuss this document there there. So... we _will_ allocate time in Atlanta to review this document one more time after which is will need to go to IPTEL. ############################# The 'enum' URI http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Thu Nov 7 15:48: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 PAA11628 for ; Thu, 7 Nov 2002 15:48:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7KoGe18309 for iptel-archive@odin.ietf.org; Thu, 7 Nov 2002 15:50: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 gA7KoGv18306 for ; Thu, 7 Nov 2002 15:50: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 PAA11602 for ; Thu, 7 Nov 2002 15:47: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 gA7Ko7v18283; Thu, 7 Nov 2002 15:50: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 gA7KZ2v15449 for ; Thu, 7 Nov 2002 15:35:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; x-msg: NoteWell Subject: [Iptel] Note Well Statement 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, 07 Nov 2002 15:11:40 -0500 >From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Sat Nov 9 01:25: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 BAA03255 for ; Sat, 9 Nov 2002 01:25:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA96ROV30316 for iptel-archive@odin.ietf.org; Sat, 9 Nov 2002 01:27: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 gA96ROv30313 for ; Sat, 9 Nov 2002 01:27: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 BAA03248 for ; Sat, 9 Nov 2002 01:24: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 gA96RIv30304; Sat, 9 Nov 2002 01:27: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 gA96Qtv30282 for ; Sat, 9 Nov 2002 01:26:55 -0500 Received: from 12-213-83-139.client.attbi.com (12-213-83-139.client.attbi.com [12.213.83.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03236 for ; Sat, 9 Nov 2002 01:24:02 -0500 (EST) Received: from mailcity.com (juno.com [173.65.15.92]) by mailexcite.com (8.11.6/8.11.6) with ESMTP id 9963 for ; Sat, 9 Nov 2002 06:26:30 +0000 From: "chabal" To: "" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 Message-ID: <283921649lswhoClhwi1ruj@concentric.net> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Subject: [Iptel] Up to $200 free money 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: Sat, 9 Nov 2002 06:26:30 +0000 GaminglandCasino.com

WWW.GAMINGLANDCASINO.COM
See why Gamingland Casino is the most incredible online casino.
Whatever you level, whatever your game, we've got all the casino excitement you're looking for in the comfort of your home!
Tha'ts right, we'll match your 1st purchase 100% up to $200!
And no waiting...your Free Bonus is credited to your account instantly!

GET $200 FREE
Buy $50 Get $50 FREE!

Buy $100 Get $100 FREE!

Buy $200 Get $200 FREE!


Play our Free NO DOWNLOAD quality games with superb graphics & sounds.

OPEN ACCOUNT

 Security & Support

 Gamingland Casino is fully licensed by the Directorate of  Offshore Gaming. We provide friendly Customer Support via  phone, email & fax.

WWW.GAMINGLANDCASINO.COM
GaminglandCasino.com

You have received this Newsletter because you, or someone else, is registered to this Email Address with gambling related sites. If you no longer wish to be included in our Email Updates, please click here




23275-29056-985
_______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Nov 11 09: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 JAA18601 for ; Mon, 11 Nov 2002 09:09:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABEBqd12647 for iptel-archive@odin.ietf.org; Mon, 11 Nov 2002 09:11:52 -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 gABEBqv12644 for ; Mon, 11 Nov 2002 09:11:52 -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 JAA18597 for ; Mon, 11 Nov 2002 09: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 gABEBBv12599; Mon, 11 Nov 2002 09:11: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 gABEAcv12573 for ; Mon, 11 Nov 2002 09:10:38 -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 JAA18567 for ; Mon, 11 Nov 2002 09:08:03 -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 gABEAZm6027332 for ; Mon, 11 Nov 2002 09:10:35 -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 gABEAYH9010698 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 11 Nov 2002 09:10:35 -0500 (EST) Message-ID: <3DCFBA57.2010703@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] 2806bis open issues 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, 11 Nov 2002 09:10:31 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The main open issue is the identification of the local dialing plan. The draft currently offers two approaches. I don't think the approaches are contentious, but the amount of specificity required needs to be nailed down. Should the identifier algorithm be more or less guaranteed to yield a unique identifier if two people choose one independently? If so, is there an algorithm for doing so? Another open issue is the use of freephone (800) numbers. According to the rules, they are local, but I suspect that usage such as tel:+1-800-555-1212 will be quite common. A final open issue is the interoperability matrix. According to my recollection, the desired status of 2806bis was Draft. Indications as to whether there are implementations of the phone-context, in particular, would be very valuable. Without that, it's another round in purgatory (I mean, Proposed). Please let me know if I forgot any additional issues that would benefit from discussion. I'm hoping that we can reach WGLC shortly after IETF 55. Henning _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Nov 13 11:21: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 LAA06962 for ; Wed, 13 Nov 2002 11:21:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADGNMY09758 for iptel-archive@odin.ietf.org; Wed, 13 Nov 2002 11:23: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 gADGNMv09755 for ; Wed, 13 Nov 2002 11:23: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 LAA06885 for ; Wed, 13 Nov 2002 11:20: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 gADGNCv09665; Wed, 13 Nov 2002 11:23: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 gADGM4v09371 for ; Wed, 13 Nov 2002 11:22:05 -0500 Received: from chinapolyglot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06753 for ; Wed, 13 Nov 2002 11:19:17 -0500 (EST) Received: from DellXP [210.21.107.131] by chinapolyglot.com with ESMTP (SMTPD32-7.06) id AB76BA2015C; Thu, 14 Nov 2002 00:19:02 +0800 Message-ID: <4112-2200211313162142361@DellXP> Organization: Polyglot Ltd From: "Polyglot" To: iptel@ietf.org MIME-Version: 1.0 Content-type: text/plain; charset=utf-7 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gADGM5v09372 Subject: [Iptel] Polyglot Translation 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, 14 Nov 2002 00:21:42 +0800 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Polyglot Translation Polyglot is a professional multilingual solutions provider. Our rich experience and professional team established us as a leader in the field of multilingual solutions. Polyglot can provide fast and accurate translations of financial, legal and technical documents on over 30 languages, such as English, German, Spanish, French, Italian, Chinese, Japanese, Korean, etc. We also provide software localization, website localization, simultaneous and consecutive interpretation for international meetings. For further information, please visit our website: http://www.polyglot.com.cn Contact us at: E-mail: info+AEA-polyglot.com.cn Tel: +-86 20 8657-3608 Fax: +-86 20 8657-3965 Add: 968 Office Tower, Central Hotel 33 Airport Road Guangzhou, China The message below is written in Chinese characters: +T916y0/hf/uL0VFsU/g- +T916y0/hf/uL0VFsU/hmL04AW7Zj0E+bWRp5zYvtigCJ41GzZbloSHaEThNOGmc6Z4QwAk4wW8x2hH7PmoxTyg- +ThNOGnaElh9PDXhuestOhmIRTuxXKFkaec2L7YoAieNRs2W5aEiYhlffdoSYhlFIVzBPTTAC- +YhFO7ID9Y9BPmw-30+WRp5zYvtigB2hFHGeG4wAV/rY3d2hH/7i9FnDVKh/wx/+4vRmIZX322JU8qR0YeNZYdO9jAB- +bNVfi2WHTvZTymKAZy9lh072/wx/+4vRi+15zVMFYuz/GoLxMAFftzABiX8wAWzVMAFhDzABTi0wAWXlMAGX6XtJe0kwAg- +a2RZFv8MYhFO7I/YY9BPm49vTvZnLFcwUxYwAX9RetlnLFcwUxYwAVb9lkVPGouudoRUDFjwTyCL0VSMTqRm/08gi9EwAg- +UXNOjovmYMX/DIv3i7+V7mIRTux2hH9RV0D/Gg- http://www.polyglot.com.cn +gFR8+2W5Xw//Gg- +dTWQrg-: info+AEA-polyglot.com.cn +dTWL3Q-: (86-20) 8657 3608 +TyB3Hw-: (86-20) 8657 3965 +VzBXQP8aTi1W/V5/Xd5nOlc6je8-33+U/c- +Ti1ZLpFSXpdRmVtXaXw-968 +kK5/Fv8a-510403 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Nov 15 15:16:04 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 PAA17756 for ; Fri, 15 Nov 2002 15:16:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFKIF213266 for iptel-archive@odin.ietf.org; Fri, 15 Nov 2002 15:18: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 gAFKIFv13263 for ; Fri, 15 Nov 2002 15:18: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 PAA17715 for ; Fri, 15 Nov 2002 15:15:33 -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 gAFKI7v13220; Fri, 15 Nov 2002 15: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 gAFKGOv12978 for ; Fri, 15 Nov 2002 15:16:24 -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 PAA17634 for ; Fri, 15 Nov 2002 15:13:42 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAFKGdEZ026060 for ; Fri, 15 Nov 2002 15:16:39 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AAR23071; Fri, 15 Nov 2002 15:16:16 -0500 (EST) Message-ID: <3DD55610.E4603E1B@cisco.com> From: Kevin Lingle X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: iptel@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Iptel] compile error in draft-ietf-iptel-trip-mib-04.txt TRIP-MIB module 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, 15 Nov 2002 15:16:16 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi, when compiling (using SMICng) the TRIP-MIB module extracted from the draft, i encountered the following error: E: f(TRIP-MIB.my), (1529,35) Item "applGroup" is not defined in module "NETWORK-SERVICES-MIB" RFC 2788 (NETWORK-SERVICES-MIB) doesn't define 'applGroup'. i think you might want to reference applRFC2788Group instead. *** 1526,1532 **** the tripNotificationGroup must also be implemented." MODULE NETWORK-SERVICES-MIB ! MANDATORY-GROUPS { applGroup } ::= { tripMIBCompliance 1 } --- 1526,1532 ---- the tripNotificationGroup must also be implemented." MODULE NETWORK-SERVICES-MIB ! MANDATORY-GROUPS { applRFC2788Group } ::= { tripMIBCompliance 1 } btw, TRIP-TC compiled fine. kevin -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ Sometimes I think I understand everything, then I regain consciousness. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Nov 18 10:49:15 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 KAA24401 for ; Mon, 18 Nov 2002 10:49:15 -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 gAIFO3208911; Mon, 18 Nov 2002 10:24:03 -0500 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id gAIFN2208898 for ; Mon, 18 Nov 2002 10:23:02 -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 gAIFN0hN068299 for ; Mon, 18 Nov 2002 10:23:00 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 28E5C443A6; Mon, 18 Nov 2002 10:22:55 -0500 (EST) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id EEB3B443A4 for ; Mon, 18 Nov 2002 10:22:54 -0500 (EST) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id gAIFMrI51980 for ; Mon, 18 Nov 2002 10:22:53 -0500 (EST) Received: from radvpost.RADVISION.com ([12.44.63.6]) by dusty; Mon Nov 18 10:22:50 EST 2002 Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Nov 2002 10:23:00 -0500 Message-ID: From: Orit Levin To: "'Yu, James'" Cc: mankin@psg.com, "'Scott Bradner'" , iptel@lists.bell-labs.com, sip@ietf.org, sipping@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [IPTEL] RE: request for iptell to review "url" IDs 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, 18 Nov 2002 10:22:56 -0500 James, Actually the exact "user" parameter appears in the H.323 Annex O which defines this and other parameters to H.323 URL. This Annex O is pending approval by the ITU-T because the telephone-URI (which it is dependant upon) hasn't been finalized yet within the IETF. I will present at my ENUM presentation today this "standardization dependencies" graph... BR, Orit Levin Chief Architect RADVISION Phone: +1.201.6896330 Video: +1.201.6896430 > -----Original Message----- > From: Yu, James [mailto:james.yu@neustar.biz] > Sent: Sunday, November 17, 2002 9:01 PM > To: orit@radvision.com > Cc: mankin@psg.com; 'Scott Bradner'; iptel@lists.bell-labs.com; > sip@ietf.org; sipping@ietf.org > Subject: RE: request for iptell to review "url" IDs > > Orit, > > The h323 url I-D currently does not define a parameter similar to > "user=phone" in the sip url to indicate that a telephone number is in the > user part of the h323 url. Suggest to add that in your I-D and clarify in > the I-D that tel url information including its extensions can appear in > the > user part when a telephone number is present in the user part. > > James > > > -----Original Message----- > > From: Scott Bradner [mailto:sob@harvard.edu] > > Sent: Monday, October 28, 2002 9:25 AM > > To: iptel@lists.bell-labs.com; sip@ietf.org; sipping@ietf.org > > Cc: antti.vaha-sipila@nokia.com; james.yu@neustar.biz; mankin@psg.com; > > orit@radvision.com; schulzrinne@cs.columbia.edu > > Subject: request for iptell to review "url" IDs > > > > > > > > > > msg from the TSV ADs > > > > we would like the iptel WG to take on the following 3 IDs > > > > draft-antti-rfc2806bis-05.txt > > draft-yu-tel-url-06.txt > > draft-levin-iptel-h323-url-scheme-04.txt > > > > we would like the WG to review the 3 IDs to be sure that they do not > > conflict in the use of terminology or technology and to work > > with the ID > > authors to resolve any conflicts > > > > anyone with opinions about these IDs should join the iptel > > list and discuss > > the issues there > > > > we expect that this task will be a short term one and we can move to > > getting these IDs published > > > > Scott & Allison > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Nov 18 16:06: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 QAA03467 for ; Mon, 18 Nov 2002 16:06:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIL8DH19558 for iptel-archive@odin.ietf.org; Mon, 18 Nov 2002 16:08: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 gAIL8Dv19555 for ; Mon, 18 Nov 2002 16:08: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 QAA03461 for ; Mon, 18 Nov 2002 16:05: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 gAIL85v19531; Mon, 18 Nov 2002 16:08: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 gAIL75v19056 for ; Mon, 18 Nov 2002 16:07:05 -0500 Received: from exchange.netarx.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03409 for ; Mon, 18 Nov 2002 16:04:22 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: Thread-Topic: Netarx (Cisco IPT RNO-Advanced Technology Partner Day 2 Service & Support).. Thread-Index: AcKPRm80xtsXmU/DQ9mc8fr10c6uOA== X-Priority: 1 Priority: Urgent Importance: high From: "Craig Perry" To: Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAIL76v19057 Subject: [Iptel] Netarx (Cisco IPT RNO-Advanced Technology Partner Day 2 Service & Support).. 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, 18 Nov 2002 16:06:59 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Did you know? BINGHAM FARMS, MI (August 12, 2002) - Netarx, Inc., announces a partnership with Cisco Systems to provide remote IP telephony (IPT) management services to help Cisco's customers operate their IP telephony installations more successfully and achieve their business goals. Netarx has completed specialized requirements and met Cisco's rigorous levels of certified personnel to achieve Cisco's designation as an Advanced Technology Provider for IP Telephony Remote Networking Operations (ATP-IPT/RNO) in the United States. Netarx demonstrates world-class process and technology development ensuring quality ongoing IP telephony support. The cornerstone of this offering is the Netarx-patented proactive network monitoring system (NMS) technology, the foundation upon which Netarx delivers consistent best practices and quality IPT operation support. Phil Go, CIO of Barton Malow, a $1.2 Billion design and construction firm, said "Choosing a converged IP telephony infrastructure was viewed as a strategic decision for Barton Malow. With Netarx's RNO-IPT capabilities, we are reducing our ongoing cost of ownership and are realizing the competitive advantages and benefits associated with IP telephony." "Netarx co-branded RNO-NMS technology service offering coupled with Cisco's IP telephony specialized partners is a powerful combination that is sure to raise the communication market's expectation for proactive "Day 2" management and support services. Cisco's ATP-IPT/RNO designation lends tremendous credibility to Netarx mission of converged technology adoption in the enterprise," said Duane Tursi, co-founder and president of Netarx. Remote Networking Operations is a critical element in any IP telephony support plan. It provides a combination of remote Cisco CallManager and infrastructure monitoring, proactive response, complex troubleshooting and resolution, soft-MAC (remote moves, adds, and changes) to support the operations of an IP telephony network. The intent is to remotely deliver service, thus lowering the total cost of ownership while raising customer satisfaction. Onsite support is available as required. The RNO support services provided by Netarx complement the Planning, Design and Implementation services provided by Cisco's Technology and Service Specialization partners, providing IPT customers a full life cycle solution. Netarx manages various LAN, WAN and IP Telephony enterprise communications networks comprised of more than 135 locations with greater than 4500 IP telephone endpoints. Netarx administers its RNO-NMS through Cisco IPT specialized partners who are able to purchase this service through Ingram Micro. About Netarx, Inc. As a technology partner committed to its clients, Netarx combines solid business understanding with leading-edge technology to enable measurable business growth and efficient operations through innovation. Netarx aligns all operations toward proactive customer service while mandating the highest degrees of customer satisfaction. Understanding business and its integrated relationship with technology, Netarx creates real "New-World" solutions that address market needs and foster companies' success. For more information about Netarx visit www.netarx.com/day2 Craig J. Perry Technical Sales Consultant Netarx Inc. 11 Grace Avenue, Suite 306 Great Neck, NY 11021 IP (516) 829-8700 X2530 (516) 829-8777 (Fax) (631) 697-3465 (Cell) cperry@netarx.com www.netarx.com Michigan (NOC/HQ) 30910 Telegraph Road & 13 Mile Road Bingham Farms, MI 48025 IP 248-647-9800 X2530 248-647-9840 (Fax) CISCO SYSTEMS (Remote Network Operations - Advanced Technology Partner) www.netarx.com/day2 "Reduce Mission-Critical Corporate Infrastructure Downtime and the Associated Costs with Netarx Day 2 Support Services" _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Nov 19 01:17: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 BAA16805 for ; Tue, 19 Nov 2002 01:16:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ6JFU17581 for iptel-archive@odin.ietf.org; Tue, 19 Nov 2002 01:19: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 gAJ6JFv17578 for ; Tue, 19 Nov 2002 01:19: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 BAA16797 for ; Tue, 19 Nov 2002 01:16:28 -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 gAJ6J3v17564; Tue, 19 Nov 2002 01:19: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 gAJ6IOv17529 for ; Tue, 19 Nov 2002 01:18:24 -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 BAA16764 for ; Tue, 19 Nov 2002 01:15:37 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJ6IGYH002994 for ; Tue, 19 Nov 2002 01:18:16 -0500 (EST) Message-ID: <3DD9D7A5.5040503@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] 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, 19 Nov 2002 01:18:13 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I haven't really been involved in the discussions on 2806bis up until now, so I apologize if any of these are repeating past comments. I have one big comment and a bunch of smaller ones. 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. 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? Besides that major comment, I have the following additional comments: * The short title that appears across the top of each page is "rfc2806bis". This should change to "The tel URI", since it won't be correct once we have a new rfc number. > 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. > 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. > This document defines the URI scheme "tel" that contains telephone > numbers. reword: "This document defines the "tel" URI scheme, which contains telephone numbers". > signaling network. Generally, this means E.164 numbers, or > numbers that can be trivially converted into them. this is the first reference to e.164; please provide the reference here. > Since URI use the forward slash to describe path hierarchy, the URI > scheme described here uses the semicolon, in keeping with SIP URI > conventions [4]. Expand SIP. > 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? > The URI is used as a request URI in SIP [4] requests. can be used.... This makes it sounds like the only application is SIP. > 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. > local-number = phone-number *global-par context *global-par 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? > reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" | > / "$" / "," this production is never used. What is it for? > 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? > 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? > 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"? > 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. > 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... > 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. > Since called and calling terminal numbers (TNs) are encoded in BCD in > ISUP, this allows for six additional values per digit, sometimes > represented as the hexadecimal characters A through F. However, in > accordance with E.164, they may not be included in global numbers. If that is the case, shouldn't the BNF for global-number differ from local-number to reflect this? > A global number prefix consists of the initial digits of a valid | > global number. When a global number prefix is used as the context, it | > MUST be chosen to be unique. unique across what? > As noted > earlier, numbers that can be represented as valid global numbers MUST > NOT be represented as local numbers plus phone-context. noted earlier where? I foudn this text: > International numbers have the property of being unambiguous > everywhere in the world and are RECOMMENDED. which is SHOULD strength, not MUST. > National freephone numbers SHOULD be represented with a local prefix. what is a local prefix? The text above defines global prefix and domain name. > The number SHOULD be visible to the end user if it is conceivable > that the user might not have a client which is able to use these > URIs. what does visible mean? > "Tel" URI parameters () MUST be registered with IANA. this is not sufficient to set up an IANA registry. You need to provide guidance to iana on what information has to appear in those registrations. I would expect this to include the parameter name, whether its mandatory or not, a paragraph on its usage, possible values, the BNF for it, the specification that defines it. You also need to provide IANA with the initial entries in the registry, which include those parameters defined in the spec (phone-context). > Mandatory parameters must be > described in an informational or standards-track RFC. Do we really want mandatory parameters defined in informational RFCs? References section needs to be split into normative and non-normative. WHy is there still a reference [4] to rfc2543? should be 3261. TOC needs to go up front. -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 Nov 19 02:10: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 CAA27597 for ; Tue, 19 Nov 2002 02:10:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ7D9O28582 for iptel-archive@odin.ietf.org; Tue, 19 Nov 2002 02:13: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 gAJ7D9v28579 for ; Tue, 19 Nov 2002 02:13: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 CAA27586 for ; Tue, 19 Nov 2002 02:10: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 gAJ7D4v28571; Tue, 19 Nov 2002 02:13: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 gAJ7Csv28540 for ; Tue, 19 Nov 2002 02:12:54 -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 CAA27576 for ; Tue, 19 Nov 2002 02:10:06 -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 gAJ7ChNf021628 for ; Mon, 18 Nov 2002 23:12:43 -0800 (PST) Received: from CJ650 (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 CQT00130; Mon, 18 Nov 2002 23:13:13 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Iptel] Few comments on draft-iptel-tgrep-00 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, 18 Nov 2002 23:13:47 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Few comments on the draft. Section 3.2 - might want to include discussion that available circuits plus circuits in use might not equal total circuits. At one point there was some discussion that Total Circuits represents a maximum that will never be exceeded and that the available circuits is the best estimate of remaining resources given the current resource usage statistics. I think it would be nice to have a bit more explanation what theses numbers represent. 3.2.2 - Open issue - do we need more specifications about minimal threshholding implementation? Do we need less? Actually I see this as one of the significant issues - how much should this draft define the threshholding schemes? At one level they are a local implementation issue - on the other end, if done really wrong, they protocol breaks. 3.3.1 - How does TGREP deal with the values wrapping? A call agent doing 1000 cps could wrap. 3.3.2 If we want to define some minimal threshholding scheme, should likely add min and max update times for this. 3.5.1 - Max length of trunk groups is 128 bytes. Is this enough? Some trunk group naming schemes are pretty verbose. 3.6.1 - The carrier ID inside of a given E.164 country code is 2 bytes. This is ok for +1 but is it large enough everywhere? _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Nov 19 11:36: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 LAA09196 for ; Tue, 19 Nov 2002 11:36:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJGcNo29368 for iptel-archive@odin.ietf.org; Tue, 19 Nov 2002 11:38: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 gAJGcNv29365 for ; Tue, 19 Nov 2002 11:38: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 LAA09186 for ; Tue, 19 Nov 2002 11:35: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 gAJGc4v29350; Tue, 19 Nov 2002 11: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 gAJGbXv29324 for ; Tue, 19 Nov 2002 11:37:33 -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 LAA09146 for ; Tue, 19 Nov 2002 11:34:49 -0500 (EST) Received: from BPenfield [127.0.0.1] by acmepacket.com (SMTPD32-7.07) id A8C66640012A; Tue, 19 Nov 2002 11:37:26 -0500 Message-ID: <000701c28fe9$e99d0950$6418a8c0@BPenfield> From: "Bob Penfield" To: "Cullen Jennings" , References: Subject: Re: [Iptel] Few comments on draft-iptel-tgrep-00 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, 19 Nov 2002 11:37:12 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Cullen Jennings" > > > 3.6.1 - The carrier ID inside of a given E.164 country code is 2 bytes. This > is ok for +1 but is it large enough everywhere? > It occurs to me that having the carrier be binary instead of ASCII might lead to problems particularly when we are comparing it with a tel-URI cic (or whatever it gets called) parameter that contains leading 0s. I don't know if there are any countries that have carrier codes with leading 0s or variable length carrier codes today, but would 0123 and 123 be the same carrier? _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Nov 19 14:21:38 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 OAA13821 for ; Tue, 19 Nov 2002 14:21:35 -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 gAJJ8G221531; Tue, 19 Nov 2002 14:08:16 -0500 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id gAJJ7K221499 for ; Tue, 19 Nov 2002 14:07:20 -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 gAJJ7IhN081866 for ; Tue, 19 Nov 2002 14:07:18 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 4C861443A6; Tue, 19 Nov 2002 14:07:13 -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 26931443A4 for ; Tue, 19 Nov 2002 14:07:13 -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 SMTP id gAJJ7Ba71489 for ; Tue, 19 Nov 2002 14:07:11 -0500 (EST) Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by dusty; Tue Nov 19 14:07:08 EST 2002 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 gAJJ6tsA027156; Tue, 19 Nov 2002 11:06:55 -0800 (PST) Received: from CJ650 (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 CSD00064; Tue, 19 Nov 2002 11:07:33 -0800 (PST) From: "Cullen Jennings" To: Cc: , 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) In-Reply-To: <5E42C1C85C5D064A947CF92FADE6D82E38B311@stntexch1.va.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [IPTEL] RE: [Sip] RE: request for iptell to review "url" IDs Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 11:08:07 -0800 Content-Transfer-Encoding: 7bit Can we try to keep the H.323 URL discussion on the iptel@ietf.org list please. Thanks, Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Yu, > James > Sent: Monday, November 18, 2002 8:30 AM > To: 'Orit Levin' > Cc: mankin@psg.com; 'Scott Bradner'; iptel@lists.bell-labs.com; > sip@ietf.org; sipping@ietf.org > Subject: [Sip] RE: request for iptell to review "url" IDs > > > Orit, > > I'm not familiar with the ITU-T H.323 Annex O. I assume that > h323 url is an > IETF standard (e.g., an IETF registered url). So it is better to include > the "user" parameter and others in this h323 url I-D. For the tel url and > its existing and future extensions, a general statement about how > the info. > (no need to describe the exact info.) can appear in the user part when > "user" parameter is present would be sufficient. Otherwise, > when this h323 > url I-D becomes a RFC, another I-D needs to be submitted to include the > "user" parameter and others that not included in this I-D. > > James > > > -----Original Message----- > > From: Orit Levin [mailto:orit@radvision.com] > > Sent: Monday, November 18, 2002 10:23 AM > > To: 'Yu, James' > > Cc: mankin@psg.com; 'Scott Bradner'; iptel@lists.bell-labs.com; > > sip@ietf.org; sipping@ietf.org > > Subject: RE: request for iptell to review "url" IDs > > > > > > James, > > Actually the exact "user" parameter appears in the H.323 Annex O which > > defines this and other parameters to H.323 URL. > > > > This Annex O is pending approval by the ITU-T because the > > telephone-URI > > (which it is dependant upon) hasn't been finalized yet within > > the IETF. > > > > I will present at my ENUM presentation today this "standardization > > dependencies" graph... > > > > BR, > > Orit Levin > > Chief Architect > > RADVISION > > Phone: +1.201.6896330 > > Video: +1.201.6896430 > > > > > > > -----Original Message----- > > > From: Yu, James [mailto:james.yu@neustar.biz] > > > Sent: Sunday, November 17, 2002 9:01 PM > > > To: orit@radvision.com > > > Cc: mankin@psg.com; 'Scott Bradner'; iptel@lists.bell-labs.com; > > > sip@ietf.org; sipping@ietf.org > > > Subject: RE: request for iptell to review "url" IDs > > > > > > Orit, > > > > > > The h323 url I-D currently does not define a parameter similar to > > > "user=phone" in the sip url to indicate that a telephone > > number is in the > > > user part of the h323 url. Suggest to add that in your I-D > > and clarify in > > > the I-D that tel url information including its extensions > > can appear in > > > the > > > user part when a telephone number is present in the user part. > > > > > > James > > > > > > > -----Original Message----- > > > > From: Scott Bradner [mailto:sob@harvard.edu] > > > > Sent: Monday, October 28, 2002 9:25 AM > > > > To: iptel@lists.bell-labs.com; sip@ietf.org; sipping@ietf.org > > > > Cc: antti.vaha-sipila@nokia.com; james.yu@neustar.biz; > > mankin@psg.com; > > > > orit@radvision.com; schulzrinne@cs.columbia.edu > > > > Subject: request for iptell to review "url" IDs > > > > > > > > > > > > > > > > > > > > msg from the TSV ADs > > > > > > > > we would like the iptel WG to take on the following 3 IDs > > > > > > > > draft-antti-rfc2806bis-05.txt > > > > draft-yu-tel-url-06.txt > > > > draft-levin-iptel-h323-url-scheme-04.txt > > > > > > > > we would like the WG to review the 3 IDs to be sure that > > they do not > > > > conflict in the use of terminology or technology and to work > > > > with the ID > > > > authors to resolve any conflicts > > > > > > > > anyone with opinions about these IDs should join the iptel > > > > list and discuss > > > > the issues there > > > > > > > > we expect that this task will be a short term one and we > > can move to > > > > getting these IDs published > > > > > > > > Scott & Allison > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Nov 19 15:37:04 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 PAA15873 for ; Tue, 19 Nov 2002 15:37:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJKdGK13046 for iptel-archive@odin.ietf.org; Tue, 19 Nov 2002 15:39: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 gAJKdGv13043 for ; Tue, 19 Nov 2002 15:39: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 PAA15863 for ; Tue, 19 Nov 2002 15:36: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 gAJKd6v13032; Tue, 19 Nov 2002 15:39: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 gAJKciv13010 for ; Tue, 19 Nov 2002 15:38:44 -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 PAA15845 for ; Tue, 19 Nov 2002 15:36:00 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJKd08H001645; Tue, 19 Nov 2002 15:39:00 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AAR93692; Tue, 19 Nov 2002 15:38:35 -0500 (EST) Message-ID: <3DDAA14B.723C296E@cisco.com> From: Kevin Lingle X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com, iptel@ietf.org Content-Type: multipart/mixed; boundary="------------E4061001EDEDFF944706775F" Subject: [Iptel] comments on draft-ietf-iptel-trip-mib-04.txt - Part 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, 19 Nov 2002 15:38:35 -0500 This is a multi-part message in MIME format. --------------E4061001EDEDFF944706775F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, i have some comments on the latest version of this I-D. Section 6.1 - TRIP-TC module ---------------------------- 1) TC TripApplProtocol DESCRIPTION... change "document" to "MIB module" 2) TC TripSendReceiveMode... can you explain each enumerated value w/in the DESCRIPTION? eg, "The operational mode of the TRIP applications. sendReceive(1) : sendOnly(2) : receiveOnly(3) : " Section 6.2 - TRIP-MIB module ----------------------------- 1) tripCfgTable... Thee table DESCRIPTION says.. "The objects in this table should be nonVolatile and survive reboot." - why don't you have a object of type StorageType in this table as you do for others? seems it should for consistency since you mention it in the descr here. such an object would only need r/o access. - what if a platform cannot provide NV storage of the info in this table across reboots? is this a requirment formalized by TRIP or more "desired" behavior? ie, is it really SHOULD or MUST? 2) tripCfgProtocolVersion... consider moving "RFC3219" to a REFERENCE clause. (i made a similar comment before wrt referencing I-D for this object) 3) tripOperStatus... we discussed this a bit in a previous version of the mib. i asked you to consider another operstatus value to reflect when there was a fault in the system. you asked whether we really needed that because faults will be covered by notifications. i responded with reasons why that answer wasn't sufficient. of course i left it as your call, so i guess i should just shut up. reading the mib again, though, the same thing struck me. it wasn't until i reviewed my email archive did i discover we'd already been over this issue. exactly how is this handled by notifications? which notification reflects a general fault with the trip LS? 4) tripCfgAddrInetAddrType... "tripAddr" -> "tripCfgAddr" 5) tripCfgAddr... i'd generalize "IP address" to just "address" and add words referring back to the InetAddrType object as the indicator of what type of address this object is. 6) tripCfgPort... why is port configurable (r/w) while address object isn't? 7) tripCfgMinItadOriginationInterval... "report" -> "reports" 8) tripCfgSendReceiveMode... "trip" -> "TRIP" 9) tripRouteTypeProtocolId... this object contains the following in the DESCRIPTION: "The size value of 116 has been assigned due to the sub identifier of object types length limitation as defined in SMIv2." what does that statement mean wrt this object? the SYNTAX TripApplProtocol doesn't shed any light. i'm confused. maybe the next comment will make this all a moot point... read on. 10) tripRouteTypeTable vs. tripPeerRouteTypeTable can't these tables be combined? add one additional object to differentiate "remote" from "local" and then you'd no longer need the address family objects form both tables to be both read-only AND part of the INDEX clause... it could truely be the more "correct" not-accessible ;) see the attached file for a stab at what a combined table might look like. 11) tripSupportedCommunityTable... is "The TRIP Communities attribute" the same as the tripSupportedCommunityId object used to index this table? is so, make is clearer that the indexing object of this table is that attribute. 12) tripSupportedCommunityEntry... need a period at the end of the DESCRIPTION. 13) tripSupportedCommunityStorage... is it a TRIP requirement (in a protocol sense) for such information to be NV? will a platform that can't meet such requirements be considered non-compliant? 14) tripPeerTable... presumably entries in this table are remote peers only, right? 15) tripPeerState... a) be more clear on local vs. remote references. when you say "to the peer" or "from the peer" are you referring to the "remote peer"? if so please be explicit in the description. b) how do you have a entry in 'idle' state? what types of "resources" are you referring to as not being allocated to the peer? obviously, it wouldn't include resources used to represent the mib table entry ;) c) how long does 'idle' state usually persist? is is generally so transient as to not be a useful state to represent in the mib?? d) add a space in description of 'established' value. "NOTIFICATION,and" -> "NOTIFICATION, and" 16) tripPeerAdminStatus... a) is there a valid DEFVAL for this object or must it be given for row creation to succeed? if the latter is the case, mention that in RowStatus object. b) what is the relationship between values of tripPeerAdminStatus and the values of tripPeerState? down -> idle?? ( i believe i asked about this before and david was going to look into it. ) 17) tripPeerConnectRetryInterval... DESCRIPTION says... "Attempt to set this value higher than the max retry should not be allowed." state more strongly... "will not be allowed". 18) tripPeerDisableTimer... should "of the peer" be "of the remote peer"? 19) tripPeerStorage... again, the issue of what about platforms that may not be able to do nonVolatile? seems this needs to be generally addressed throughout the mib. 20) tripPeerRowStatus... the presense of this object would indicate that this table can be provisioned. must it be or can some of these entries be learned via the workings of the protocol? 21) tripPeerStatsTable... a) "stats" -> "statistics" b) qualify when "this peer" or "the peer" is referring to "remote" peer. total messages counter objects are explicit while the other objects in the table aren't. 22) tripPeerFsmEstablishedTime... say "entered 'established' tripPeerState." 23) tripRouteAddress... can you explain to me exactly how the 105 size limit was reached? i presume it has something to do with the size of each index component and the overall object identifier length for objects in this table. i didn't attempt to do the math, so could you summerize? you say "prefix"... it this then some limited form of the address - limited due to SMI issues? 24) tripRouteTRIBMask... please expand TRIB acronym on first use. any rfc 3219 reference for these type bits? what does each type mean - more than just "adj-TRIBs-ins". 25) tripRouteLocalPref.... any REFERENCE for this? 26) tripRouteAdvertisementPath & tripRouteRoutedPath... a) any REFERENCE for this? b) say "sequence of TripItads" rather than integers. that will establish what per itad boundaries are w/in the octet string (ie, ever 4 octets). c) i presume you mean each itad is in network byte order, right? but what is the ordering of the entire sequence of itads? which end of the overall octet string do you start reading the path from? 27) tripRouteAtomicAggregation... not specific to this route table object, but in general does the capability represented by this object need to be made configurable somewhere? 28) tripRouteWithdrawn... how is this removal of a route accomplished? 29) how many route table entries can there be in a system? 30) how many communities can be associated with a route? i probably have other comments on remaining portions of the mib and draft doc, but i have to stop now. i'll email more tomorrow. kevin -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ Sometimes I think I understand everything, then I regain consciousness. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= --------------E4061001EDEDFF944706775F Content-Type: text/plain; charset=us-ascii; name="TRIP-MIB.combined.tripRouteTypeTable" Content-Disposition: inline; filename="TRIP-MIB.combined.tripRouteTypeTable" Content-Transfer-Encoding: 7bit -- -- tripRouteTypeTable -- tripRouteTypeTable OBJECT-TYPE SYNTAX SEQUENCE OF TripPeerRouteTypeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The TRIP peer Route Type table contains one entry per supported protocol - address family pair. The objects in this table are volatile and are refreshed after a reboot." ::= { tripMIBObjects X } tripPeerRouteTypeEntry OBJECT-TYPE SYNTAX TripPeerRouteTypeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information about the route type that a particular TRIP peer (local or remote) supports. Each entry represents information about either the local or a remote LS peer. The object tripRouteTypePeer is used to distinguish this. In the case of a local LS, the address/port information will reflect the values configured in tripCfgTable. In the case of a remote peer, the address/port information will reflect the values of an entry in the tripPeerTable." INDEX { applIndex, tripRouteTypeAddrInetType, tripRouteTypeAddr, tripRouteTypePort, tripRouteTypeProtocolId, tripRouteTypeAddrFamilyId } ::= { tripRouteTypeTable 1 } TripRouteTypeEntry ::= SEQUENCE { tripRouteTypeAddrInetType InetAddressType, tripRouteTypeAddr InetAddress, tripRouteTypePort InetPortNumber, tripRouteTypeProtocolId TripAppProtocol, tripRouteTypeAddrFamilyId TripAddressFamily, tripRouteTypePeer INTEGER } tripRouteTypeAddrInetType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of Inet Address of the tripRouteTypeAddr." REFERENCE "RFC 3291, section 3." ::= { tripRouteTypeEntry 1 } tripRouteTypeAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address of this entry's TRIP peer LS." REFERENCE "RFC 3291, section 3." ::= { tripRouteTypeEntry 2 } tripRouteTypePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The port for the TCP connection between this and an associated TRIP peer." ::= { tripRouteTypeEntry 3 } tripRouteTypeProtocolId OBJECT-TYPE SYNTAX TripAppProtocol MAX-ACCESS not-accessible STATUS current DESCRIPTION "The object identifier of a protocol that the associated peer is using." ::= { tripRouteTypeEntry 4 } tripRouteTypeAddrFamilyId OBJECT-TYPE SYNTAX TripAddressFamily MAX-ACCESS not-accessible STATUS current DESCRIPTION "The object identifier of an address family that the associated peer belongs to." ::= { tripRouteTypeEntry 5 } tripRouteTypePeer OBJECT-TYPE SYNTAX INTEGER { local(1), remote(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies whether this entry is associated with a 'local' or 'remote' LS peer." ::= { tripRouteTypeEntry 6 } --------------E4061001EDEDFF944706775F-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Nov 19 15:58:59 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 PAA16417 for ; Tue, 19 Nov 2002 15:58:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJL1C313986 for iptel-archive@odin.ietf.org; Tue, 19 Nov 2002 16:01: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 gAJL1Cv13983 for ; Tue, 19 Nov 2002 16:01: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 PAA16393 for ; Tue, 19 Nov 2002 15:58:28 -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 gAJL14v13971; Tue, 19 Nov 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 gAJL0nv13906 for ; Tue, 19 Nov 2002 16:00:49 -0500 Received: from imo-d06.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16389 for ; Tue, 19 Nov 2002 15:58:05 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d06.mx.aol.com (mail_out_v34.13.) id r.17c.1226d838 (4410); Tue, 19 Nov 2002 16:00:30 -0500 (EST) Message-ID: <17c.1226d838.2b0c006d@aol.com> Subject: Re: [Iptel] comments on rfc2806bis To: jdrosen@dynamicsoft.com, iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_17c.1226d838.2b0c006d_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 10500 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, 19 Nov 2002 16:00:29 EST --part1_17c.1226d838.2b0c006d_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/19/2002 1:17:27 AM Eastern Standard Time, jdrosen@dynamicsoft.com writes: > > local-number = phone-number *global-par context *global-par > > > 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? > 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. Mike Pierce Artel --part1_17c.1226d838.2b0c006d_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/19/2002 1:17:27 AM Eastern Standard Time, jdrosen@dynamicsoft.com writes:


>    local-number          =  phone-number *global-par context *global-par


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?



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.

Mike Pierce
Artel
--part1_17c.1226d838.2b0c006d_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Nov 19 15:59: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 PAA16430 for ; Tue, 19 Nov 2002 15:59:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJL1Eo14002 for iptel-archive@odin.ietf.org; Tue, 19 Nov 2002 16:01: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 gAJL1Ev13999 for ; Tue, 19 Nov 2002 16:01: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 PAA16397 for ; Tue, 19 Nov 2002 15:58: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 gAJL14v13951; Tue, 19 Nov 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 gAJL0Hv13890 for ; Tue, 19 Nov 2002 16:00:17 -0500 Received: from imo-m07.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16377 for ; Tue, 19 Nov 2002 15:57:33 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m07.mx.aol.com (mail_out_v34.13.) id r.10e.1a680a8e (4410); Tue, 19 Nov 2002 15:59:56 -0500 (EST) Message-ID: <10e.1a680a8e.2b0c004c@aol.com> Subject: Re: [Iptel] comments on rfc2806bis To: jdrosen@dynamicsoft.com, iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_10e.1a680a8e.2b0c004c_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 10500 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, 19 Nov 2002 15:59:56 EST --part1_10e.1a680a8e.2b0c004c_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/19/2002 1:17:27 AM Eastern Standard Time, jdrosen@dynamicsoft.com writes: > > 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? > I think of a PBX extension as being sort of the same functionality in some cases as the ISDN subaddress. Since the way to carry ISDN subaddress is included, it seems reasonable to be able to include PBX extensions (which are not part of the E.164 address). There are maybe two cases: 1. carrying just a PBX extension (say within the PBX itself) - I believe this can be carried as "local". 2. carrying a PBX extension in addition to the full E.164 number of the PBX. This is what was referred to above as "cannot be specified". Of course, trying to do case 2 seems to lead to a practical problem, since the protocol issues at an interworking point (to traditional PSTN signaling schemes in the US) really don't support the use of this PBX extension in the forwarded signaling, so one could ask, "Why bother including it in the tel:uri?". In some other countries, the situation is a little different (relates to use of overlap). Because of the old equipment, it was possible to tack the "PBX extension" onto the number used to get to the PBX, and directly dial it, meaning that the total number of digits could exceed the previous 12-digit max. With the current 15-digit max, I don't know if any case in the world could exceed this. I hope not. If not, the PBX extension is included as part of the E.164 number. Mike Pierce Artel --part1_10e.1a680a8e.2b0c004c_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/19/2002 1:17:27 AM Eastern Standard Time, jdrosen@dynamicsoft.com writes:


> 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?



I think of a PBX extension as being sort of the same functionality in some cases as the ISDN subaddress. Since the way to carry ISDN subaddress is included, it seems reasonable to be able to include PBX extensions (which are not part of the E.164 address).

There are maybe two cases:

1. carrying just a PBX extension (say within the PBX itself) - I believe this can be carried as "local".

2. carrying a PBX extension in addition to the full E.164 number of the PBX. This is what was referred to above as "cannot be specified".

Of course, trying to do case 2 seems to lead to a practical problem, since the protocol issues at an interworking point (to traditional PSTN signaling schemes in the US) really don't support the use of this PBX extension in the forwarded signaling, so one could ask, "Why bother including it in the tel:uri?".

In some other countries, the situation is a little different (relates to use of overlap). Because of the old equipment, it was possible to tack the "PBX extension" onto the number used to get to the PBX, and directly dial it, meaning that the total number of digits could exceed the previous 12-digit max. With the current 15-digit max, I don't know if any case in the world could exceed this. I hope not. If not, the PBX extension is included as part of the E.164 number.

Mike Pierce
Artel
--part1_10e.1a680a8e.2b0c004c_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Nov 19 17:50:57 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 RAA19611 for ; Tue, 19 Nov 2002 17:50:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJMrBh21845 for iptel-archive@odin.ietf.org; Tue, 19 Nov 2002 17: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 gAJMrBv21842 for ; Tue, 19 Nov 2002 17:53: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 RAA19604 for ; Tue, 19 Nov 2002 17:50:26 -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 gAJMr5v21834; Tue, 19 Nov 2002 17:53: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 gAJMqmv21812 for ; Tue, 19 Nov 2002 17:52:48 -0500 Received: from imo-d09.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19599 for ; Tue, 19 Nov 2002 17:50:02 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d09.mx.aol.com (mail_out_v34.13.) id r.108.1b333cff (30960); Tue, 19 Nov 2002 17:52:26 -0500 (EST) Message-ID: <108.1b333cff.2b0c1aaa@aol.com> Subject: Re: [Iptel] comments on rfc2806bis - 800 numbers To: jdrosen@dynamicsoft.com, iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_108.1b333cff.2b0c1aaa_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 10500 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, 19 Nov 2002 17:52:26 EST --part1_108.1b333cff.2b0c1aaa_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/19/2002 1:17:27 AM Eastern Standard Time, jdrosen@dynamicsoft.com writes: > > National freephone numbers SHOULD be represented with a local prefix. > > what is a local prefix? The text above defines global prefix and domain > name Freephone numbers (e.g., 800 in the US) present a problem for this tel:uri which, IMHO, has not been resolved. While they can easily be represented in the format of a full E.164 number, they can normally only be dialed within some local context (usually a country). Some implications in the draft are that either the global of the local representation would be correct. (See statement that "All phone numbers MUST use the global form unless they cannot be represented as such." which would seem to contradict the above statement.) It seems that it should be sufficient to say that any number which can be represented as a E.164 number MUST be represented this way. This would include all "800" numbers. And it needs to be made clear that the representation is unrelated to where it can be reached from (matter for local/national policy). Therefore, a Freephone number would never have a "local prefix" or a "local-anything". It never requires a "context" to be understood. Mike Pierce Artel --part1_108.1b333cff.2b0c1aaa_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/19/2002 1:17:27 AM Eastern Standard Time, jdrosen@dynamicsoft.com writes:


> National freephone numbers SHOULD be represented with a local prefix.

what is a local prefix? The text above defines global prefix and domain
name


Freephone numbers (e.g., 800 in the US) present a problem for this tel:uri which, IMHO, has not been resolved. While they can easily be represented in the format of a full E.164 number, they can normally only be dialed within some local context (usually a country). Some implications in the draft are that either the global of the local representation would be correct. (See statement that "All phone numbers MUST use the global form unless they cannot be represented as such." which would seem to contradict the above statement.)

It seems that it should be sufficient to say that any number which can be represented as a E.164 number MUST be represented this way. This would include all "800" numbers. And it needs to be made clear that the representation is unrelated to where it can be reached from (matter for local/national policy). Therefore, a Freephone number would never have a "local prefix" or a "local-anything". It never requires a "context" to be understood.

Mike Pierce
Artel
--part1_108.1b333cff.2b0c1aaa_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Nov 19 17:54: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 RAA19728 for ; Tue, 19 Nov 2002 17:54:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJMv6W22062 for iptel-archive@odin.ietf.org; Tue, 19 Nov 2002 17:57: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 gAJMv6v22059 for ; Tue, 19 Nov 2002 17:57: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 RAA19705 for ; Tue, 19 Nov 2002 17:54: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 gAJMv1v22050; Tue, 19 Nov 2002 17:57: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 gAJMuFv22011 for ; Tue, 19 Nov 2002 17:56:15 -0500 Received: from imo-d10.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19694 for ; Tue, 19 Nov 2002 17:53:29 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d10.mx.aol.com (mail_out_v34.13.) id r.1a9.c3d107a (30960); Tue, 19 Nov 2002 17:55:53 -0500 (EST) Message-ID: <1a9.c3d107a.2b0c1b78@aol.com> Subject: Re: [Iptel] comments on rfc2806bis - unique prefix To: jdrosen@dynamicsoft.com, iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1a9.c3d107a.2b0c1b78_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 10500 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, 19 Nov 2002 17:55:52 EST --part1_1a9.c3d107a.2b0c1b78_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/19/2002 1:17:27 AM Eastern Standard Time, jdrosen@dynamicsoft.com writes: > > A global number prefix consists of the initial digits of a valid | > > global number. When a global number prefix is used as the context, it > | > > MUST be chosen to be unique. > > unique across what? > This has been an issue in some previous discussions - how to "guarantee uniqueness" if each potential end user decides on their own value of "global number prefix"? If this uniqueness is critical to the operations that use the tel:uri, then there should be some rigid scheme for the user to pick the value, or else an IANA registration process. I really can't imagine an IANA registration process here. Note that the ABNF does not define a "global number prefix" but rather a context which may consist of a "global-number-digits" which is a "+" plus some number of digits. (The + is a little out of place here, since what follows may not be a full E.164 address. The ABNF doesn't even restrict it to being the first so many digits of a E.164 number.) Originally I thought that this "global prefix" was something that could be concatenated with the "local number" to form a full E.164 number. Since that is not true, it does not have to be a "prefix" of anything. It simply must be unique, and could be any digit string desired. There simply must be a way to define the rules for assignment. I thought we had arrived at some text to say that the user must select a "prefix" of the E.164 number, such that they are assigned every possible E.164 number beginning with that "prefix". The alternative would be to say that the context (if not using the domain-name scheme) must contain a full E.164 number (any one assigned to and choosen by the user) to represent its "domain". Mike Pierce Artel --part1_1a9.c3d107a.2b0c1b78_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/19/2002 1:17:27 AM Eastern Standard Time, jdrosen@dynamicsoft.com writes:


> A global number prefix consists of the initial digits of a valid       |
>    global number. When a global number prefix is used as the context, it  |
>    MUST be chosen to be unique.

unique across what?

This has been an issue in some previous discussions - how to "guarantee uniqueness" if each potential end user decides on their own value of "global number prefix"? If this uniqueness is critical to the operations that use the tel:uri, then there should be some rigid scheme for the user to pick the value, or else an IANA registration process. I really can't imagine an IANA registration process here.

Note that the ABNF does not define a "global number prefix" but rather a context which may consist of a "global-number-digits" which is a "+" plus some number of digits. (The + is a little out of place here, since what follows may not be a full E.164 address. The ABNF doesn't even restrict it to being the first so many digits of a E.164 number.)

Originally I thought that this "global prefix" was something that could be concatenated with the "local number" to form a full E.164 number. Since that is not true, it does not have to be a "prefix" of anything. It simply must be unique, and could be any digit string desired. There simply must be a way to define the rules for assignment. I thought we had arrived at some text to say that the user must select a "prefix" of the E.164 number, such that they are assigned every possible E.164 number beginning with that "prefix". The alternative would be to say that the context (if not using the domain-name scheme) must contain a full E.164 number (any one assigned to and choosen by the user) to represent its "domain".

Mike Pierce
Artel
--part1_1a9.c3d107a.2b0c1b78_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Nov 19 20:35:57 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 UAA23320 for ; Tue, 19 Nov 2002 20:35:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK1cCe31474 for iptel-archive@odin.ietf.org; Tue, 19 Nov 2002 20:38: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 gAK1cCv31471 for ; Tue, 19 Nov 2002 20:38: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 UAA23315 for ; Tue, 19 Nov 2002 20:35:26 -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 gAK1c5v31463; Tue, 19 Nov 2002 20:38: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 gAK1bdv31416 for ; Tue, 19 Nov 2002 20:37:39 -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 UAA23266 for ; Tue, 19 Nov 2002 20:34:53 -0500 (EST) content-class: urn:content-classes:message Subject: AW: [Iptel] comments on rfc2806bis - 800 numbers MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-ID: <06CF906FE3998C4E944213062009F1620248B6@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Iptel] comments on rfc2806bis - 800 numbers Thread-Index: AcKQHuP/0tC/bIRCQOOppLwFN0al9QAFWJFA From: "Stastny Richard" To: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gAK1bdv31417 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, 20 Nov 2002 02:40:33 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Maybe for this problem the following may work: As stated below, an national 800 number is always part of the E.164 numbering plan. Depending on the accounting agreements between national operators, you may reach the 800 numbers in another country or not. If not, on the PSTN you are routed to an announcement. So if yes, you may use e.g. tel:+1800xxx for an NANP 800 number, if not, you may indicate this with tel:800xxx,phonecontext=+1 Richard Stastny -----Ursprüngliche Nachricht----- Von: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Gesendet: Di 19.11.2002 23:52 An: jdrosen@dynamicsoft.com; iptel@ietf.org Cc: Betreff: Re: [Iptel] comments on rfc2806bis - 800 numbers In a message dated 11/19/2002 1:17:27 AM Eastern Standard Time, jdrosen@dynamicsoft.com writes: > National freephone numbers SHOULD be represented with a local prefix. what is a local prefix? The text above defines global prefix and domain name Freephone numbers (e.g., 800 in the US) present a problem for this tel:uri which, IMHO, has not been resolved. While they can easily be represented in the format of a full E.164 number, they can normally only be dialed within some local context (usually a country). Some implications in the draft are that either the global of the local representation would be correct. (See statement that "All phone numbers MUST use the global form unless they cannot be represented as such." which would seem to contradict the above statement.) It seems that it should be sufficient to say that any number which can be represented as a E.164 number MUST be represented this way. This would include all "800" numbers. And it needs to be made clear that the representation is unrelated to where it can be reached from (matter for local/national policy). Therefore, a Freephone number would never have a "local prefix" or a "local-anything". It never requires a "context" to be understood. Mike Pierce Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Nov 19 20:58: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 UAA25171 for ; Tue, 19 Nov 2002 20:58:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK216B32360 for iptel-archive@odin.ietf.org; Tue, 19 Nov 2002 21:01: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 gAK216v32357 for ; Tue, 19 Nov 2002 21:01: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 UAA25140 for ; Tue, 19 Nov 2002 20:58: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 gAK212v32345; Tue, 19 Nov 2002 21:01: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 gAK20Bv32272 for ; Tue, 19 Nov 2002 21:00:11 -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 UAA24477 for ; Tue, 19 Nov 2002 20:57:24 -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 gAK1xVu4023083; Tue, 19 Nov 2002 17:59:31 -0800 (PST) Received: from ORANLT.ietf55.ops.ietf.org (sjc-vpn1-392.cisco.com [10.21.97.136]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id CSX00385; Tue, 19 Nov 2002 18:00:06 -0800 (PST) From: "David R. Oran" To: Mpierce1@aol.com, jdrosen@dynamicsoft.com, iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis - 800 numbers Message-ID: <42430642.1037739573@ORANLT.ietf55.ops.ietf.org> In-Reply-To: <108.1b333cff.2b0c1aaa@aol.com> References: <108.1b333cff.2b0c1aaa@aol.com> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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, 19 Nov 2002 20:59:33 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit At the risk of wading in from left field... the unfortunate fact that E.164 numbers in the +1-800 domain cannot be successfully reached from anywhere does not in any way affect their validity as global tel: URL numbers. All we can guarantee for such numbers is that they are GLOBALLY UNAMBIGUOUS, which means that they either reach the indended global destination or they fail. There is no way we can (or should) legislate which cases are allowed fail or disallow numbers which fail when tried from the "wrong" source domain. dave. --On Tuesday, November 19, 2002 5:52 PM -0500 Mpierce1@aol.com wrote: > In a message dated 11/19/2002 1:17:27 AM Eastern Standard Time, > jdrosen@dynamicsoft.com writes: > > > >> National freephone numbers SHOULD be represented with a local prefix. > > what is a local prefix? The text above defines global prefix and domain > name > > > > > > Freephone numbers (e.g., 800 in the US) present a problem for this > tel:uri which, IMHO, has not been resolved. While they can easily be > represented in the format of a full E.164 number, they can normally only > be dialed within some local context (usually a country). Some > implications in the draft are that either the global of the local > representation would be correct. (See statement that "All phone numbers > MUST use the global form unless they cannot be represented as such." > which would seem to contradict the above statement.) > > It seems that it should be sufficient to say that any number which can be > represented as a E.164 number MUST be represented this way. This would > include all "800" numbers. And it needs to be made clear that the > representation is unrelated to where it can be reached from (matter for > local/national policy). Therefore, a Freephone number would never have a > "local prefix" or a "local-anything". It never requires a "context" to be > understood. > > Mike Pierce > Artel ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Nov 19 21:06: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 VAA26580 for ; Tue, 19 Nov 2002 21:06:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK298200860 for iptel-archive@odin.ietf.org; Tue, 19 Nov 2002 21:09: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 gAK298v00857 for ; Tue, 19 Nov 2002 21:09: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 VAA26342 for ; Tue, 19 Nov 2002 21:06: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 gAK241v32531; Tue, 19 Nov 2002 21:04: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 gAK23Kv32484 for ; Tue, 19 Nov 2002 21:03:20 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25386 for ; Tue, 19 Nov 2002 21:00:33 -0500 (EST) 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 gAK23E410977; Tue, 19 Nov 2002 20:03:15 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 18:03:01 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D205073E4E@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Stastny Richard'" , "'Mpierce1@aol.com'" , "'jdrosen@dynamicsoft.com'" , "'iptel@ietf.org'" Subject: RE: [Iptel] comments on rfc2806bis - 800 numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29038.EDFB37AC" 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, 19 Nov 2002 18:02:51 -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_01C29038.EDFB37AC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It may work sometimes, but not always. For example, a number may be = valid in the US but not in Canada (this is very common, perhaps even the most = common case).=20 These countries however both share the same +1 country code.=20 I guess one could argue that the area code of the originator could be = listed as phone-context (phone-context=3D+1-408). The proxy would have to figure out that 408 = is part of the US not Canada, and if it is valid or not for this 1-800 number (it would be impractical to list ALL the area codes where the 1-800 is valid).=20 Another alternative would be a phone-context describing differently the applicability=20 domain (something.ca or something.us). > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Tuesday, November 19, 2002 5:41 PM > To: Mpierce1@aol.com; jdrosen@dynamicsoft.com; iptel@ietf.org > Subject: AW: [Iptel] comments on rfc2806bis - 800 numbers >=20 >=20 > Maybe for this problem the following may work: > =20 > As stated below, an national 800 number is always part of the=20 > E.164 numbering plan. Depending on the accounting agreements=20 > between national operators, you may reach the 800 numbers in=20 > another country or not. If not, on the PSTN you are routed to=20 > an announcement. > =20 > So if yes, you may use e.g. tel:+1800xxx for an NANP 800=20 > number, if not, you may indicate this with = tel:800xxx,phonecontext=3D+1 > =20 > Richard Stastny >=20 > -----Urspr=FCngliche Nachricht-----=20 > Von: Mpierce1@aol.com [mailto:Mpierce1@aol.com]=20 > Gesendet: Di 19.11.2002 23:52=20 > An: jdrosen@dynamicsoft.com; iptel@ietf.org=20 > Cc:=20 > Betreff: Re: [Iptel] comments on rfc2806bis - 800 numbers > =09 > =09 > In a message dated 11/19/2002 1:17:27 AM Eastern=20 > Standard Time, jdrosen@dynamicsoft.com writes:=20 > =09 > =09 > =09 >=20 > > National freephone numbers SHOULD be=20 > represented with a local prefix.=20 > =09 > what is a local prefix? The text above defines=20 > global prefix and domain=20 > name >=20 >=20 > =09 > =09 > =09 > Freephone numbers (e.g., 800 in the US) present a=20 > problem for this tel:uri which, IMHO, has not been resolved.=20 > While they can easily be represented in the format of a full=20 > E.164 number, they can normally only be dialed within some=20 > local context (usually a country). Some implications in the=20 > draft are that either the global of the local representation=20 > would be correct. (See statement that "All phone numbers MUST=20 > use the global form unless they cannot be represented as=20 > such." which would seem to contradict the above statement.)=20 > =09 > It seems that it should be sufficient to say that any=20 > number which can be represented as a E.164 number MUST be=20 > represented this way. This would include all "800" numbers.=20 > And it needs to be made clear that the representation is=20 > unrelated to where it can be reached from (matter for=20 > local/national policy). Therefore, a Freephone number would=20 > never have a "local prefix" or a "local-anything". It never=20 > requires a "context" to be understood.=20 > =09 > Mike Pierce=20 > Artel=20 > =09 >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www.ietf.org/mailman/listinfo/iptel >=20 ------_=_NextPart_001_01C29038.EDFB37AC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Iptel] comments on rfc2806bis - 800 numbers

It may work sometimes, but not always. For example, a = number may be valid in
the US but not in Canada (this is very common, = perhaps even the most common case).
These countries however both share the same +1 = country code.

I guess one could argue that the area code of the = originator could be listed as phone-context
(phone-context=3D+1-408). The proxy would have to = figure out that 408 is part of the US not
Canada, and if it is valid or not for this 1-800 = number (it would be impractical to list
ALL the area codes where the 1-800 is valid). =

Another alternative would be a phone-context = describing differently the applicability
domain (something.ca or something.us).

> -----Original Message-----
> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at= ]
> Sent: Tuesday, November 19, 2002 5:41 PM
> To: Mpierce1@aol.com; jdrosen@dynamicsoft.com; = iptel@ietf.org
> Subject: AW: [Iptel] comments on rfc2806bis - = 800 numbers
>
>
> Maybe for this problem the following may = work:
> 
> As stated below, an national 800 number is = always part of the
> E.164 numbering plan. Depending on the = accounting agreements
> between national operators, you may reach the = 800 numbers in
> another country or not. If not, on the PSTN you = are routed to
> an announcement.
> 
> So if yes, you may use e.g. tel:+1800xxx for an = NANP 800
> number, if not, you may indicate this with = tel:800xxx,phonecontext=3D+1
> 
> Richard Stastny
>
>       = -----Urspr=FCngliche Nachricht-----
>       Von: = Mpierce1@aol.com [mailto:Mpierce1@aol.com]
>       Gesendet: Di = 19.11.2002 23:52
>       An: = jdrosen@dynamicsoft.com; iptel@ietf.org
>       Cc:
>       Betreff: Re: = [Iptel] comments on rfc2806bis - 800 numbers
>      
>      
>       In a message = dated 11/19/2002 1:17:27 AM Eastern
> Standard Time, jdrosen@dynamicsoft.com writes: =
>      
>      
>      
>
>       =         > National freephone = numbers SHOULD be
> represented with a local prefix.
>       =        
>       =         what is a local prefix? The = text above defines
> global prefix and domain
>       =         name
>
>
>      
>      
>      
>       Freephone = numbers (e.g., 800 in the US) present a
> problem for this tel:uri which, IMHO, has not = been resolved.
> While they can easily be represented in the = format of a full
> E.164 number, they can normally only be dialed = within some
> local context (usually a country). Some = implications in the
> draft are that either the global of the local = representation
> would be correct. (See statement that "All = phone numbers MUST
> use the global form unless they cannot be = represented as
> such." which would seem to contradict the = above statement.)
>      
>       It seems that it = should be sufficient to say that any
> number which can be represented as a E.164 = number MUST be
> represented this way. This would include all = "800" numbers.
> And it needs to be made clear that the = representation is
> unrelated to where it can be reached from = (matter for
> local/national policy). Therefore, a Freephone = number would
> never have a "local prefix" or a = "local-anything". It never
> requires a "context" to be = understood.
>      
>       Mike Pierce =
>       Artel
>      
>
> = _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www.ietf.org/mailman/listinfo/iptel=
>

------_=_NextPart_001_01C29038.EDFB37AC-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue Nov 19 21:22: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 VAA27311 for ; Tue, 19 Nov 2002 21:22:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK2Ohv01624 for iptel-archive@odin.ietf.org; Tue, 19 Nov 2002 21: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 gAK2Ogv01621 for ; Tue, 19 Nov 2002 21:24:42 -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 VAA27226 for ; Tue, 19 Nov 2002 21:21: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 gAK2OCv01511; Tue, 19 Nov 2002 21:24: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 gAK2J8v01262 for ; Tue, 19 Nov 2002 21:19:08 -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 VAA27035 for ; Tue, 19 Nov 2002 21:16:21 -0500 (EST) content-class: urn:content-classes:message Subject: AW: [Iptel] comments on rfc2806bis - 800 numbers MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-ID: <06CF906FE3998C4E944213062009F1620248B7@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Iptel] comments on rfc2806bis - 800 numbers Thread-Index: AcKQOWRRhKlw7CZPTYmG+NAqZNUTzAAAJ2rY From: "Stastny Richard" To: "Francois Audet" , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gAK2J9v01263 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, 20 Nov 2002 03:22:02 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Comments inline: -----Ursprüngliche Nachricht----- Von: Francois Audet [mailto:audet@nortelnetworks.com] Gesendet: Mi 20.11.2002 03:02 An: Stastny Richard; 'Mpierce1@aol.com'; 'jdrosen@dynamicsoft.com'; 'iptel@ietf.org' Cc: Betreff: RE: [Iptel] comments on rfc2806bis - 800 numbers It may work sometimes, but not always. For example, a number may be valid in the US but not in Canada (this is very common, perhaps even the most common case). These countries however both share the same +1 country code. Richard: this is correct I guess one could argue that the area code of the originator could be listed as phone-context (phone-context=+1-408). The proxy would have to figure out that 408 is part of the US not Canada, and if it is valid or not for this 1-800 number (it would be impractical to list ALL the area codes where the 1-800 is valid). Another alternative would be a phone-context describing differently the applicability domain (something.ca or something.us). Richard: Good point. This may be a good example for the usability of the DNS context. Discussing this in the Sportsbar, Lawrence and I found another good reason for the DNS context. With mobile number portability and in the case of network-specific numbers -that are numbers only valid within the given (mobile) network (non E.164 numbers), the "prefix-context" does not work. If you are a mobile operator with say context=+43664 and you have a number ported in with context=+43676, you may get a problem if a network-specific number is requested. But if you use a DNS context like t-mobile.net, you know whats going on: Question: is there a way to use both the "prefix" and DNS conetxt at the same time? Richard > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, November 19, 2002 5:41 PM > To: Mpierce1@aol.com; jdrosen@dynamicsoft.com; iptel@ietf.org > Subject: AW: [Iptel] comments on rfc2806bis - 800 numbers > > > Maybe for this problem the following may work: > > As stated below, an national 800 number is always part of the > E.164 numbering plan. Depending on the accounting agreements > between national operators, you may reach the 800 numbers in > another country or not. If not, on the PSTN you are routed to > an announcement. > > So if yes, you may use e.g. tel:+1800xxx for an NANP 800 > number, if not, you may indicate this with tel:800xxx,phonecontext=+1 > > Richard Stastny > > -----Ursprüngliche Nachricht----- > Von: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > Gesendet: Di 19.11.2002 23:52 > An: jdrosen@dynamicsoft.com; iptel@ietf.org > Cc: > Betreff: Re: [Iptel] comments on rfc2806bis - 800 numbers > > > In a message dated 11/19/2002 1:17:27 AM Eastern > Standard Time, jdrosen@dynamicsoft.com writes: > > > > > > National freephone numbers SHOULD be > represented with a local prefix. > > what is a local prefix? The text above defines > global prefix and domain > name > > > > > > Freephone numbers (e.g., 800 in the US) present a > problem for this tel:uri which, IMHO, has not been resolved. > While they can easily be represented in the format of a full > E.164 number, they can normally only be dialed within some > local context (usually a country). Some implications in the > draft are that either the global of the local representation > would be correct. (See statement that "All phone numbers MUST > use the global form unless they cannot be represented as > such." which would seem to contradict the above statement.) > > It seems that it should be sufficient to say that any > number which can be represented as a E.164 number MUST be > represented this way. This would include all "800" numbers. > And it needs to be made clear that the representation is > unrelated to where it can be reached from (matter for > local/national policy). Therefore, a Freephone number would > never have a "local prefix" or a "local-anything". It never > requires a "context" to be understood. > > 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 Tue Nov 19 21:48: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 VAA29406 for ; Tue, 19 Nov 2002 21:48:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK2oXg03332 for iptel-archive@odin.ietf.org; Tue, 19 Nov 2002 21:50: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 gAK2oXv03329 for ; Tue, 19 Nov 2002 21:50: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 VAA29349 for ; Tue, 19 Nov 2002 21:47: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 gAK2o3v03301; Tue, 19 Nov 2002 21:50: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 gAK2n6v03251 for ; Tue, 19 Nov 2002 21:49:06 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29117 for ; Tue, 19 Nov 2002 21:46:19 -0500 (EST) 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 gAK2mw412575; Tue, 19 Nov 2002 20:48:59 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 18:48:46 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D205073EC2@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Stastny Richard'" , "'Mpierce1@aol.com'" , "'jdrosen@dynamicsoft.com'" , "'iptel@ietf.org'" Subject: RE: [Iptel] comments on rfc2806bis - 800 numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2903F.5508D7DC" 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, 19 Nov 2002 18:48:41 -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_01C2903F.5508D7DC Content-Type: text/plain > Question: is there a way to use both the "prefix" and > DNS conetxt at the same time? I guess so. I imagine you could technically have multiple descriptors in the phone-context (phone-context=+43664, t-mobile.net). Or you could use whatever domain was used in the From URI (instead of the context), or the authenticated user, or whatever other criteria is applicable. I don't think we need to standardize any of this. ------_=_NextPart_001_01C2903F.5508D7DC Content-Type: text/html RE: [Iptel] comments on rfc2806bis - 800 numbers

>       Question: is there a way to use both the "prefix" and
> DNS conetxt at the same time?

I guess so. I imagine you could technically have multiple descriptors
in the phone-context (phone-context=+43664, t-mobile.net). Or you could
use whatever domain was used in the From URI (instead of the context),
or the authenticated user, or whatever other criteria is applicable.

I don't think we need to standardize any of this.

------_=_NextPart_001_01C2903F.5508D7DC-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Nov 20 01:37:16 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 BAA19002 for ; Wed, 20 Nov 2002 01:37:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK6dXY15093 for iptel-archive@odin.ietf.org; Wed, 20 Nov 2002 01:39: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 gAK6dXv15090 for ; Wed, 20 Nov 2002 01:39: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 BAA18980 for ; Wed, 20 Nov 2002 01:36:45 -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 gAK6d3v15074; Wed, 20 Nov 2002 01:39: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 gAK6a7v14353 for ; Wed, 20 Nov 2002 01:36:07 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18929 for ; Wed, 20 Nov 2002 01:33:17 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAK6Zt5V019909; Tue, 19 Nov 2002 22:35:55 -0800 (PST) Received: from CJ650 (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 CTL00167; Tue, 19 Nov 2002 22:36:25 -0800 (PST) From: "Cullen Jennings" To: "Bob Penfield" , "Cullen Jennings" , Subject: RE: [Iptel] Few comments on draft-iptel-tgrep-00 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <000701c28fe9$e99d0950$6418a8c0@BPenfield> 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, 19 Nov 2002 22:36:59 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In the meeting today it sounded like people thought ASCII would be the best choice. Any Objections? Cullen > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Tuesday, November 19, 2002 8:37 AM > To: Cullen Jennings; iptel@ietf.org > Subject: Re: [Iptel] Few comments on draft-iptel-tgrep-00 > > > > ----- Original Message ----- > From: "Cullen Jennings" > > > > > > > 3.6.1 - The carrier ID inside of a given E.164 country code is 2 bytes. > This > > is ok for +1 but is it large enough everywhere? > > > It occurs to me that having the carrier be binary instead of ASCII might > lead to problems particularly when we are comparing it with a tel-URI cic > (or whatever it gets called) parameter that contains leading 0s. I don't > know if there are any countries that have carrier codes with leading 0s or > variable length carrier codes today, but would 0123 and 123 be the same > carrier? > > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Nov 20 10:56: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 KAA22911 for ; Wed, 20 Nov 2002 10:56:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKFwx224183 for iptel-archive@odin.ietf.org; Wed, 20 Nov 2002 10:58: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 gAKFwxv24180 for ; Wed, 20 Nov 2002 10:58: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 KAA22890 for ; Wed, 20 Nov 2002 10:56: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 gAKFwbv24122; Wed, 20 Nov 2002 10:58:37 -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 gAKFuIv23983 for ; Wed, 20 Nov 2002 10:56: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 KAA22812 for ; Wed, 20 Nov 2002 10:53:35 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAKFu1K13441; Wed, 20 Nov 2002 07:56:01 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Nov 2002 07:56:01 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2050741CE@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Cullen Jennings'" , "'Bob Penfield'" , "'iptel@ietf.org'" Subject: RE: [Iptel] Few comments on draft-iptel-tgrep-00 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C290AD.4EBF18E6" 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, 20 Nov 2002 07:55:55 -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_01C290AD.4EBF18E6 Content-Type: text/plain No objections, I don't think you have a choice. I would like to point out that the carrier Id is NOT inside the E.164 contry code. Might want to be careful with the wording. They are outside the E.164 number. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, November 19, 2002 10:37 PM > To: Bob Penfield; Cullen Jennings; iptel@ietf.org > Subject: RE: [Iptel] Few comments on draft-iptel-tgrep-00 > > > > In the meeting today it sounded like people thought ASCII > would be the best choice. Any Objections? > > Cullen > > > > -----Original Message----- > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > Sent: Tuesday, November 19, 2002 8:37 AM > > To: Cullen Jennings; iptel@ietf.org > > Subject: Re: [Iptel] Few comments on draft-iptel-tgrep-00 > > > > > > > > ----- Original Message ----- > > From: "Cullen Jennings" > > > > > > > > > > > 3.6.1 - The carrier ID inside of a given E.164 country code is 2 > > > bytes. > > This > > > is ok for +1 but is it large enough everywhere? > > > > > It occurs to me that having the carrier be binary instead of ASCII > > might lead to problems particularly when we are comparing it with a > > tel-URI cic (or whatever it gets called) parameter that contains > > leading 0s. I don't know if there are any countries that > have carrier > > codes with leading 0s or variable length carrier codes today, but > > would 0123 and 123 be the same carrier? > > > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www.ietf.org/mailman/listinfo/iptel > ------_=_NextPart_001_01C290AD.4EBF18E6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Iptel] Few comments on draft-iptel-tgrep-00

No objections, I don't think you have a = choice.

I would like to point out that the carrier Id is NOT = inside the E.164 contry code. Might want
to be careful with the wording. They are outside the = E.164 number.

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Tuesday, November 19, 2002 10:37 = PM
> To: Bob Penfield; Cullen Jennings; = iptel@ietf.org
> Subject: RE: [Iptel] Few comments on = draft-iptel-tgrep-00
>
>
>
> In the meeting today it sounded like people = thought ASCII
> would be the best choice. Any = Objections?
>
> Cullen
>
>
> > -----Original Message-----
> > From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
> > Sent: Tuesday, November 19, 2002 8:37 = AM
> > To: Cullen Jennings; iptel@ietf.org
> > Subject: Re: [Iptel] Few comments on = draft-iptel-tgrep-00
> >
> >
> >
> > ----- Original Message -----
> > From: "Cullen Jennings" = <fluffy@cisco.com>
> > <snip>
> > >
> > >
> > > 3.6.1 - The carrier ID inside of a = given E.164 country code is 2
> > > bytes.
> > This
> > > is ok for +1 but is it large enough = everywhere?
> > >
> > It occurs to me that having the carrier be = binary instead of ASCII
> > might lead to problems particularly when = we are comparing it with a
> > tel-URI cic (or whatever it gets called) = parameter that contains
> > leading 0s. I don't know if there are any = countries that
> have carrier
> > codes with leading 0s or variable length = carrier codes today, but
> > would 0123 and 123 be the same = carrier?
> >
> >
>
> = _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www.ietf.org/mailman/listinfo/iptel=
>

------_=_NextPart_001_01C290AD.4EBF18E6-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Nov 20 13:34: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 NAA26849 for ; Wed, 20 Nov 2002 13:34:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKIadU03187 for iptel-archive@odin.ietf.org; Wed, 20 Nov 2002 13:36: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 gAKIadv03184 for ; Wed, 20 Nov 2002 13:36: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 NAA26836 for ; Wed, 20 Nov 2002 13:33: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 gAKIa8v03145; Wed, 20 Nov 2002 13:36: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 gAKIZbv03111 for ; Wed, 20 Nov 2002 13:35:37 -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 NAA26804 for ; Wed, 20 Nov 2002 13:32:52 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAKIZfw0013487; Wed, 20 Nov 2002 13:35:42 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AAS18451; Wed, 20 Nov 2002 13:35:16 -0500 (EST) Message-ID: <3DDBD5E4.5465EFB9@cisco.com> From: Kevin Lingle X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com, iptel@ietf.org CC: jdrosen@dynamicsoft.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Iptel] comments on draft-ietf-iptel-trip-mib-04.txt - Part 2 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, 20 Nov 2002 13:35:16 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi, picking up where i left off yesterday.... 31) tripItadTopologyTable & tripItadTopologyIdTable... how will these tables be used in managing the LS? can they somehow be combined so that there is one "valid" columar object that is not also part of the indexing scheme of the table and thus not (imho) bending the rules of the smi? surely, there is some valid piece of information to be retrieved that is also not part of info you consider required to uniquely identify a row in a table. when i see repetition of index objects being made read-only due to lack of other non-index columar objects, it makes me wonder if the table is really defining useful mgmt information. 32) it is generally a good practice to defined a configuration object to enable/disable notifications. make the default value disabled. that way there is a choice to turn notifs on or off for a device in the event that events generating notifs may flood a network or for managers to otherwise not be receiving notifs from devices. i don't see such a object in this mib. such an object could have control over all notifs defined in a mib or be defined w/ BITS syntax for individual control of each notification. 33) i don't quite understand why you have notifications for open and update messages and also a mechanism w/in the notification to identify the message type related to the notif and further sub-errorcodes. the errcode info then is not completely relevant to the hold timer expired notif is it? instead why not have a generalized "message error" notif where the errcode and suberrcode objects identify the messages involved. a general notif could then serve additional messages in the future w/out having to update the mib with a new message-specific notif. not sure if any of that errcode info is then relevant to the hold timer expired notif... maybe it's varbind objects could be reduced. 34) see my previous email wrt compile error for MODULE NETWORK-SERVICES-MIB MANDATORY-GROUPS { applGroup } 35) references section 9... [RFC3291] is "Textual Conventions for Internet Addresses" not "Network Services Monitoring MIB". thanks! kevin -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ Sometimes I think I understand everything, then I regain consciousness. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Nov 20 13:34:26 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 NAA26862 for ; Wed, 20 Nov 2002 13:34:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKIaeU03203 for iptel-archive@odin.ietf.org; Wed, 20 Nov 2002 13:36:40 -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 gAKIaev03200 for ; Wed, 20 Nov 2002 13:36: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 NAA26839 for ; Wed, 20 Nov 2002 13:33:55 -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 gAKIa9v03161; Wed, 20 Nov 2002 13:36: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 gAKIZmv03116 for ; Wed, 20 Nov 2002 13:35:48 -0500 Received: from imo-r08.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26811 for ; Wed, 20 Nov 2002 13:33:03 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r08.mx.aol.com (mail_out_v34.13.) id k.86.2387d311 (30960); Wed, 20 Nov 2002 13:31:06 -0500 (EST) Message-ID: <86.2387d311.2b0d2eea@aol.com> Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers To: Richard.Stastny@oefeg.at, audet@nortelnetworks.com, oran@cisco.com, jdrosen@dynamicsoft.com, iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_86.2387d311.2b0d2eea_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 10500 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, 20 Nov 2002 13:31:06 EST --part1_86.2387d311.2b0d2eea_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit There have been several comments related to the format/use of freephone (e.g., 800) numbers in the tel:uri. In a message dated 11/19/2002 8:39:53 PM Eastern Standard Time, Richard.Stastny@oefeg.at writes: > As stated below, an national 800 number is always part of the E.164 > numbering plan. Depending > on the accounting agreements between national operators, you may reach the > 800 numbers in another country or not. If not, on the PSTN you are routed > to an announcement. > > So if yes, you may use e.g. tel:+1800xxx for an NANP 800 number, if not, > you may indicate > this with tel:800xxx,phonecontext=+1 > In a message dated 11/19/2002 9:03:39 PM Eastern Standard Time, audet@nortelnetworks.com writes: > It may work sometimes, but not always. For example, a number may be valid in > the US but not in Canada (this is very common, perhaps even the most common > case). > These countries however both share the same +1 country code. > > I guess one could argue that the area code of the originator could be listed > as phone-context > (phone-context=+1-408). The proxy would have to figure out that 408 is part > of the US not > Canada, and if it is valid or not for this 1-800 number (it would be > impractical to list > ALL the area codes where the 1-800 is valid). > > Another alternative would be a phone-context describing differently the > applicability > domain (something.ca or something.us). > In a message dated 11/19/2002 8:59:19 PM Eastern Standard Time, oran@cisco.com writes: > the unfortunate fact that E.164 numbers in the +1-800 domain cannot be > successfully reached from anywhere does not in any way affect their > validity as global tel: URL numbers. > [MAP] I think one needs to look at the intended use of this tel:uri. I think of the best example (certainly one of the valid ones) is that the tel:uri is the real information to dial a call that is "behind" a link on a web page. In this case, anyone anywhere in the world may try to place a call by clicking on this link. Therefore, the contents/format of the tel:uri should not depend on whether or not your local national agreements allows the call to be made. The format needs to be one single global format (E.164-type format works well) and the local user agent/device needs to be able to figure out from the information in the tel:uri as well as knowledge of where it is to decide whether or not the call can be made (or even how to make it). The fact that an 800 number can be represented as an E.164 number is not unfortunate - I think it is a big help here. I suggest that the rule is that any number that can be represented in the E.164 format MUST be done this way. (A slight strengthening/clarification of the current text.) This means that an "800" number would never have a context included, just as no other E.164 number needs one. This removes some of the difficulties with the current definition. What I would really expect on a simple web page is something like the following: If in Germany, click here (the tel:uri behind it contains Germany country code and the 800 number) If in Austria, click here (the tel:uri behind it contains Austria country code and the 800 number) If in Italy click here (the tel:uri behind it contains Italy country code and the 800 number) If in Maryland, click here etc. If the 800 numbers in multiple places happen to be the same string of numbers, that is not important.) Clicking on the wrong link for the location would simply result in a call failing, just as if you read off the wrong number from a list and dialed it on your PSTN phone. On the other hand, a more complex web page/user agent may include logic (Java Script?) to provide a single point to click, and the user agent/device would know where it is (within the numbering plans) or the user would have told it and the UA would figure out which one of many internal numbers to use to place the call. Each of these internal numbers would be in the form of a tel:uri. Mike Pierce Artel --part1_86.2387d311.2b0d2eea_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit There have been several comments related to the format/use of freephone (e.g., 800) numbers in the tel:uri.

In a message dated 11/19/2002 8:39:53 PM Eastern Standard Time, Richard.Stastny@oefeg.at writes:


As stated below, an national 800 number is always part of the E.164 numbering plan. Depending
on the accounting agreements between national operators, you may reach the 800 numbers in another country or not. If not, on the PSTN you are routed to an announcement.

So if yes, you may use e.g. tel:+1800xxx for an NANP 800 number, if not, you may indicate
this with tel:800xxx,phonecontext=+1

In a message dated 11/19/2002 9:03:39 PM Eastern Standard Time, audet@nortelnetworks.com writes:


It may work sometimes, but not always. For example, a number may be valid in
the US but not in Canada (this is very common, perhaps even the most common
case).
These countries however both share the same +1 country code.

I guess one could argue that the area code of the originator could be listed
as phone-context
(phone-context=+1-408). The proxy would have to figure out that 408 is part
of the US not
Canada, and if it is valid or not for this 1-800 number (it would be
impractical to list
ALL the area codes where the 1-800 is valid).

Another alternative would be a phone-context describing differently the
applicability
domain (something.ca or something.us).

In a message dated 11/19/2002 8:59:19 PM Eastern Standard Time, oran@cisco.com writes:


the unfortunate fact that E.164 numbers in the +1-800 domain cannot be
successfully reached from anywhere does not in any way affect their
validity as global tel: URL numbers.


[MAP] I think one needs to look at the intended use of this tel:uri. I think of the best example (certainly one of the valid ones) is that the tel:uri is the real information to dial a call that is "behind" a link on a web page. In this case, anyone anywhere in the world may try to place a call by clicking on this link. Therefore, the contents/format of the tel:uri should not depend on whether or not your local national agreements allows the call to be made. The format needs to be one single global format (E.164-type format works well) and the local user agent/device needs to be able to figure out from the information in the tel:uri as well as knowledge of where it is to decide whether or not the call can be made (or even how to make it).

The fact that an 800 number can be represented as an E.164 number is not unfortunate - I think it is a big help here.

I suggest that the rule is that any number that can be represented in the E.164 format MUST be done this way. (A slight strengthening/clarification of the current text.) This means that an "800" number would never have a context included, just as no other E.164 number needs one. This removes some of the difficulties with the current definition.

What I would really expect on a simple web page is something like the following:

If in Germany, click here (the tel:uri behind it contains Germany country code and the 800 number)
If in Austria, click here (the tel:uri behind it contains Austria country code and the 800 number)
If in Italy click here (the tel:uri behind it contains Italy country code and the 800 number)
If in Maryland, click here
etc.

If the 800 numbers in multiple places happen to be the same string of numbers, that is not important.)

Clicking on the wrong link for the location would simply result in a call failing, just as if you read off the wrong number from a list and dialed it on your PSTN phone.

On the other hand, a more complex web page/user agent may include logic (Java Script?) to provide a single point to click, and the user agent/device would know where it is (within the numbering plans) or the user would have told it and the UA would figure out which one of many internal numbers to use to place the call. Each of these internal numbers would be in the form of a tel:uri.

Mike Pierce
Artel
--part1_86.2387d311.2b0d2eea_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Nov 20 15:59:02 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 PAA00588 for ; Wed, 20 Nov 2002 15:59:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKL1Fr13306 for iptel-archive@odin.ietf.org; Wed, 20 Nov 2002 16:01: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 gAKL1Fv13303 for ; Wed, 20 Nov 2002 16:01: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 PAA00573 for ; Wed, 20 Nov 2002 15:58:31 -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 gAKL17v13290; Wed, 20 Nov 2002 16:01: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 gAKL0av13240 for ; Wed, 20 Nov 2002 16:00:36 -0500 Received: from helimore2205.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00521 for ; Wed, 20 Nov 2002 15:57:24 -0500 (EST) Message-Id: <200211202057.PAA00521@ietf.org> From: "MR.Brainreth Mills" Reply-To: brain_mills@london.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 gAKL0av13243 Subject: [Iptel] FROM MILLS IN UK 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, 20 Nov 2002 22:04:13 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Dear Sir, I am Mr Brainreth Mills,the bill exchange director at the NATIONAL WESTMINSTER BANK PLC, 135 BISHOPSGATE LONDON EC2M 3UR. I am writing this letter to solicit for support and assistance from you to carry out this business opportunity in my department. Lying in an inactive account is the sum of Thirty Million United States Dollars($30,000,000.00)belonging to a foreign customer(Stanley Heard),the former President(Bill Clinton's personal physician) and Chairman of the National Chiropractic Health Care Advisory Committee who happens to be deceased. He died with his wife and two children in a plane crash on Board a small airplane that plunged into a river. Ever since he died the Bank has been expecting his next of kin to come and claim these funds. To this effect, we cannot release the money unless some one applies for it as the next of kin, as indicated in our Banking Guideline. Unfortunately he has no family member here in the UK or America who are aware of the existence of the money as he was he was a contract physician to the Chairman of Royal Bank of Scotland. At this juncture I have decided to do business with you in colloboration with officials that matter in the Bank, to this effect we solicit your assistance, in applying as the next of kin, then the money will be proccesed and released to you, as we do not want this money to go into the Bank Treasury as an unclaimed bill. The Banking law and guideline stipulate that if such money remains unclaimed for a period of Five years the money will be transfered into the Banks' Treasury as unclaimed bill. Our request for a Foreigner as a next of kin is occassioned by the fact that the customer was a Foreigner and a British cannot stand as next of kin. Sir, 15% of the money will be your share as a Foreign partner, while 5% will be for any expenses incured during the transaction, thereafter we would visit your country once the money hits your account for disbursement and investment. Please reach me at the above email if willing to do business with us. Best regards, Brainreth Mills _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Nov 20 16:41: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 QAA01905 for ; Wed, 20 Nov 2002 16:41:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKLhV316979 for iptel-archive@odin.ietf.org; Wed, 20 Nov 2002 16:43: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 gAKLhVv16976 for ; Wed, 20 Nov 2002 16:43: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 QAA01888 for ; Wed, 20 Nov 2002 16:40:45 -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 gAKLh6v16940; Wed, 20 Nov 2002 16:43: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 gAKLgLv16895 for ; Wed, 20 Nov 2002 16:42:21 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01849 for ; Wed, 20 Nov 2002 16:39:34 -0500 (EST) 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 gAKLg7527502; Wed, 20 Nov 2002 15:42:08 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Nov 2002 13:41:54 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2050D6F7E@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Mpierce1@aol.com'" , "'Richard.Stastny@oefeg.at'" , "'oran@cisco.com'" , "'jdrosen@dynamicsoft.com'" , "'iptel@ietf.org'" Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C290DD.A26ABBD2" 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, 20 Nov 2002 13:41:52 -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_01C290DD.A26ABBD2 Content-Type: text/plain Sounds reasonable to me. -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Wednesday, November 20, 2002 10:31 AM To: Richard.Stastny@oefeg.at; Audet, Francois [SC100:4K02:EXCH]; oran@cisco.com; jdrosen@dynamicsoft.com; iptel@ietf.org Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers There have been several comments related to the format/use of freephone (e.g., 800) numbers in the tel:uri. In a message dated 11/19/2002 8:39:53 PM Eastern Standard Time, Richard.Stastny@oefeg.at writes: As stated below, an national 800 number is always part of the E.164 numbering plan. Depending on the accounting agreements between national operators, you may reach the 800 numbers in another country or not. If not, on the PSTN you are routed to an announcement. So if yes, you may use e.g. tel:+1800xxx for an NANP 800 number, if not, you may indicate this with tel:800xxx,phonecontext=+1 In a message dated 11/19/2002 9:03:39 PM Eastern Standard Time, audet@nortelnetworks.com writes: It may work sometimes, but not always. For example, a number may be valid in the US but not in Canada (this is very common, perhaps even the most common case). These countries however both share the same +1 country code. I guess one could argue that the area code of the originator could be listed as phone-context (phone-context=+1-408). The proxy would have to figure out that 408 is part of the US not Canada, and if it is valid or not for this 1-800 number (it would be impractical to list ALL the area codes where the 1-800 is valid). Another alternative would be a phone-context describing differently the applicability domain (something.ca or something.us). In a message dated 11/19/2002 8:59:19 PM Eastern Standard Time, oran@cisco.com writes: the unfortunate fact that E.164 numbers in the +1-800 domain cannot be successfully reached from anywhere does not in any way affect their validity as global tel: URL numbers. [MAP] I think one needs to look at the intended use of this tel:uri. I think of the best example (certainly one of the valid ones) is that the tel:uri is the real information to dial a call that is "behind" a link on a web page. In this case, anyone anywhere in the world may try to place a call by clicking on this link. Therefore, the contents/format of the tel:uri should not depend on whether or not your local national agreements allows the call to be made. The format needs to be one single global format (E.164-type format works well) and the local user agent/device needs to be able to figure out from the information in the tel:uri as well as knowledge of where it is to decide whether or not the call can be made (or even how to make it). The fact that an 800 number can be represented as an E.164 number is not unfortunate - I think it is a big help here. I suggest that the rule is that any number that can be represented in the E.164 format MUST be done this way. (A slight strengthening/clarification of the current text.) This means that an "800" number would never have a context included, just as no other E.164 number needs one. This removes some of the difficulties with the current definition. What I would really expect on a simple web page is something like the following: If in Germany, click here (the tel:uri behind it contains Germany country code and the 800 number) If in Austria, click here (the tel:uri behind it contains Austria country code and the 800 number) If in Italy click here (the tel:uri behind it contains Italy country code and the 800 number) If in Maryland, click here etc. If the 800 numbers in multiple places happen to be the same string of numbers, that is not important.) Clicking on the wrong link for the location would simply result in a call failing, just as if you read off the wrong number from a list and dialed it on your PSTN phone. On the other hand, a more complex web page/user agent may include logic (Java Script?) to provide a single point to click, and the user agent/device would know where it is (within the numbering plans) or the user would have told it and the UA would figure out which one of many internal numbers to use to place the call. Each of these internal numbers would be in the form of a tel:uri. Mike Pierce Artel ------_=_NextPart_001_01C290DD.A26ABBD2 Content-Type: text/html Message
Sounds reasonable to me.
-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Wednesday, November 20, 2002 10:31 AM
To: Richard.Stastny@oefeg.at; Audet, Francois [SC100:4K02:EXCH]; oran@cisco.com; jdrosen@dynamicsoft.com; iptel@ietf.org
Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers

There have been several comments related to the format/use of freephone (e.g., 800) numbers in the tel:uri.

In a message dated 11/19/2002 8:39:53 PM Eastern Standard Time, Richard.Stastny@oefeg.at writes:


As stated below, an national 800 number is always part of the E.164 numbering plan. Depending
on the accounting agreements between national operators, you may reach the 800 numbers in another country or not. If not, on the PSTN you are routed to an announcement.

So if yes, you may use e.g. tel:+1800xxx for an NANP 800 number, if not, you may indicate
this with tel:800xxx,phonecontext=+1

In a message dated 11/19/2002 9:03:39 PM Eastern Standard Time, audet@nortelnetworks.com writes:


It may work sometimes, but not always. For example, a number may be valid in
the US but not in Canada (this is very common, perhaps even the most common
case).
These countries however both share the same +1 country code.

I guess one could argue that the area code of the originator could be listed
as phone-context
(phone-context=+1-408). The proxy would have to figure out that 408 is part
of the US not
Canada, and if it is valid or not for this 1-800 number (it would be
impractical to list
ALL the area codes where the 1-800 is valid).

Another alternative would be a phone-context describing differently the
applicability
domain (something.ca or something.us).

In a message dated 11/19/2002 8:59:19 PM Eastern Standard Time, oran@cisco.com writes:


the unfortunate fact that E.164 numbers in the +1-800 domain cannot be
successfully reached from anywhere does not in any way affect their
validity as global tel: URL numbers.


[MAP] I think one needs to look at the intended use of this tel:uri. I think of the best example (certainly one of the valid ones) is that the tel:uri is the real information to dial a call that is "behind" a link on a web page. In this case, anyone anywhere in the world may try to place a call by clicking on this link. Therefore, the contents/format of the tel:uri should not depend on whether or not your local national agreements allows the call to be made. The format needs to be one single global format (E.164-type format works well) and the local user agent/device needs to be able to figure out from the information in the tel:uri as well as knowledge of where it is to decide whether or not the call can be made (or even how to make it).

The fact that an 800 number can be represented as an E.164 number is not unfortunate - I think it is a big help here.

I suggest that the rule is that any number that can be represented in the E.164 format MUST be done this way. (A slight strengthening/clarification of the current text.) This means that an "800" number would never have a context included, just as no other E.164 number needs one. This removes some of the difficulties with the current definition.

What I would really expect on a simple web page is something like the following:

If in Germany, click here (the tel:uri behind it contains Germany country code and the 800 number)
If in Austria, click here (the tel:uri behind it contains Austria country code and the 800 number)
If in Italy click here (the tel:uri behind it contains Italy country code and the 800 number)
If in Maryland, click here
etc.

If the 800 numbers in multiple places happen to be the same string of numbers, that is not important.)

Clicking on the wrong link for the location would simply result in a call failing, just as if you read off the wrong number from a list and dialed it on your PSTN phone.

On the other hand, a more complex web page/user agent may include logic (Java Script?) to provide a single point to click, and the user agent/device would know where it is (within the numbering plans) or the user would have told it and the UA would figure out which one of many internal numbers to use to place the call. Each of these internal numbers would be in the form of a tel:uri.

Mike Pierce
Artel
------_=_NextPart_001_01C290DD.A26ABBD2-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Nov 20 17:57: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 RAA04181 for ; Wed, 20 Nov 2002 17:57:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKMx3v22412 for iptel-archive@odin.ietf.org; Wed, 20 Nov 2002 17:59: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 gAKMwXv22380 for ; Wed, 20 Nov 2002 17:58: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 RAA04152 for ; Wed, 20 Nov 2002 17:55: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 gAKMwIv22319; Wed, 20 Nov 2002 17:58: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 gAKMdVv21240 for ; Wed, 20 Nov 2002 17:39:31 -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 RAA03594 for ; Wed, 20 Nov 2002 17:35:38 -0500 (EST) content-class: urn:content-classes:message Subject: AW: AW: [Iptel] comments on rfc2806bis - 800 numbers MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-ID: <06CF906FE3998C4E944213062009F1620248C2@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Iptel] comments on rfc2806bis - 800 numbers Thread-Index: AcKQw3ePSVkQlAEsSWm80Wr1+ii3NQAIXNw5 From: "Stastny Richard" To: , , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gAKMdVv21241 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, 20 Nov 2002 23:41:20 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sounds resonable to me too. BTW, I have only full E.164 numbers in my mobile phone. One should consider also, that most switches and also many PBX recognise a local number even if given in E.164 format (given the number is reachable from outside with E.164) Since you normally on mobile phones and other inelligent terminal do not dial the number, but click on a link or on a name, the lenght does not matter. Richard -----Ursprüngliche Nachricht----- Von: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Gesendet: Mi 20.11.2002 19:31 An: Stastny Richard; audet@nortelnetworks.com; oran@cisco.com; jdrosen@dynamicsoft.com; iptel@ietf.org Cc: Betreff: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers There have been several comments related to the format/use of freephone (e.g., 800) numbers in the tel:uri. In a message dated 11/19/2002 8:39:53 PM Eastern Standard Time, Richard.Stastny@oefeg.at writes: As stated below, an national 800 number is always part of the E.164 numbering plan. Depending on the accounting agreements between national operators, you may reach the 800 numbers in another country or not. If not, on the PSTN you are routed to an announcement. So if yes, you may use e.g. tel:+1800xxx for an NANP 800 number, if not, you may indicate this with tel:800xxx,phonecontext=+1 In a message dated 11/19/2002 9:03:39 PM Eastern Standard Time, audet@nortelnetworks.com writes: It may work sometimes, but not always. For example, a number may be valid in the US but not in Canada (this is very common, perhaps even the most common case). These countries however both share the same +1 country code. I guess one could argue that the area code of the originator could be listed as phone-context (phone-context=+1-408). The proxy would have to figure out that 408 is part of the US not Canada, and if it is valid or not for this 1-800 number (it would be impractical to list ALL the area codes where the 1-800 is valid). Another alternative would be a phone-context describing differently the applicability domain (something.ca or something.us). In a message dated 11/19/2002 8:59:19 PM Eastern Standard Time, oran@cisco.com writes: the unfortunate fact that E.164 numbers in the +1-800 domain cannot be successfully reached from anywhere does not in any way affect their validity as global tel: URL numbers. [MAP] I think one needs to look at the intended use of this tel:uri. I think of the best example (certainly one of the valid ones) is that the tel:uri is the real information to dial a call that is "behind" a link on a web page. In this case, anyone anywhere in the world may try to place a call by clicking on this link. Therefore, the contents/format of the tel:uri should not depend on whether or not your local national agreements allows the call to be made. The format needs to be one single global format (E.164-type format works well) and the local user agent/device needs to be able to figure out from the information in the tel:uri as well as knowledge of where it is to decide whether or not the call can be made (or even how to make it). The fact that an 800 number can be represented as an E.164 number is not unfortunate - I think it is a big help here. I suggest that the rule is that any number that can be represented in the E.164 format MUST be done this way. (A slight strengthening/clarification of the current text.) This means that an "800" number would never have a context included, just as no other E.164 number needs one. This removes some of the difficulties with the current definition. What I would really expect on a simple web page is something like the following: If in Germany, click here (the tel:uri behind it contains Germany country code and the 800 number) If in Austria, click here (the tel:uri behind it contains Austria country code and the 800 number) If in Italy click here (the tel:uri behind it contains Italy country code and the 800 number) If in Maryland, click here etc. If the 800 numbers in multiple places happen to be the same string of numbers, that is not important.) Clicking on the wrong link for the location would simply result in a call failing, just as if you read off the wrong number from a list and dialed it on your PSTN phone. On the other hand, a more complex web page/user agent may include logic (Java Script?) to provide a single point to click, and the user agent/device would know where it is (within the numbering plans) or the user would have told it and the UA would figure out which one of many internal numbers to use to place the call. Each of these internal numbers would be in the form of a tel:uri. Mike Pierce Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Thu Nov 21 11:00: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 LAA07595 for ; Thu, 21 Nov 2002 11:00:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALG2qY24412 for iptel-archive@odin.ietf.org; Thu, 21 Nov 2002 11:02:52 -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 gALG2pv24409 for ; Thu, 21 Nov 2002 11:02:51 -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 LAA07546 for ; Thu, 21 Nov 2002 11:00: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 gALG2ev24317; Thu, 21 Nov 2002 11:02:40 -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 gALFi7v23080 for ; Thu, 21 Nov 2002 10:44:07 -0500 Received: from tomts10-srv.bellnexxia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06873 for ; Thu, 21 Nov 2002 10:41:23 -0500 (EST) Received: from DIZZY2 ([64.230.2.62]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021121154401.WBMC9064.tomts10-srv.bellnexxia.net@DIZZY2>; Thu, 21 Nov 2002 10:44:01 -0500 Message-ID: <003201c29174$f96b7c40$3e02e640@DIZZY2> From: "David Zinman" To: "Kevin Lingle" , , References: <3DDAA14B.723C296E@cisco.com> Subject: Re: [Iptel] comments on draft-ietf-iptel-trip-mib-04.txt - Part 1 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: Thu, 21 Nov 2002 10:45:10 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Kevin, Great idea to combine tripRouteTypeTable and tripPeerRouteTypeTable. I wish I had seen that. DZ ----- Original Message ----- From: "Kevin Lingle" To: ; Sent: Tuesday, November 19, 2002 3:38 PM Subject: [Iptel] comments on draft-ietf-iptel-trip-mib-04.txt - Part 1 > hi, > > i have some comments on the latest version of this I-D. > > Section 6.1 - TRIP-TC module > ---------------------------- > 1) TC TripApplProtocol DESCRIPTION... > change "document" to "MIB module" Done > > 2) TC TripSendReceiveMode... > can you explain each enumerated value w/in the DESCRIPTION? > eg, > "The operational mode of the TRIP applications. > > sendReceive(1) : > sendOnly(2) : > receiveOnly(3) : " > I've added the text to the DESCRIPTION clause, but I'm not sure there is anything left to add as far as descriptions, they are pretty self- explanatory. > > Section 6.2 - TRIP-MIB module > ----------------------------- > 1) tripCfgTable... > Thee table DESCRIPTION says.. > "The objects in this table should be nonVolatile and > survive reboot." > > - why don't you have a object of type StorageType in > this table as you do for others? seems it should > for consistency since you mention it in the descr > here. such an object would only need r/o access. done, made this object with r/w access. > - what if a platform cannot provide NV storage of > the info in this table across reboots? is this > a requirment formalized by TRIP or more "desired" > behavior? ie, is it really SHOULD or MUST? The "desired" behavior of this object is stated by the defval nonVolatile. I think this should be enough. > 2) tripCfgProtocolVersion... > consider moving "RFC3219" to a REFERENCE clause. > (i made a similar comment before wrt referencing > I-D for this object) done > 3) tripOperStatus... > we discussed this a bit in a previous version of > the mib. i asked you to consider another operstatus > value to reflect when there was a fault in the system. > you asked whether we really needed that because faults > will be covered by notifications. i responded with > reasons why that answer wasn't sufficient. of course > i left it as your call, so i guess i should just shut up. > reading the mib again, though, the same thing struck me. > it wasn't until i reviewed my email archive did i discover > we'd already been over this issue. > > exactly how is this handled by notifications? which > notification reflects a general fault with the trip LS? I think you mean tripCfgOperStatus. I'm not sure what happened here, this issue may have fallen through the cracks. Sorry. I will add a 'faulty' state. > > > 4) tripCfgAddrInetAddrType... > "tripAddr" -> "tripCfgAddr" > > 5) tripCfgAddr... > i'd generalize "IP address" to just "address" and > add words referring back to the InetAddrType object > as the indicator of what type of address this object is. done > 6) tripCfgPort... > why is port configurable (r/w) while address object > isn't? I've lost much of my email since these were written, but I seem to remember talking about this with Dave W. I believe that the consesus was to allow the user the flexibility to use whatever port was needed, but allowing a change of inet addr would impact too much on the TRIP network. Any TRIP experts to set me straight on this? > 7) tripCfgMinItadOriginationInterval... > "report" -> "reports" > > 8) tripCfgSendReceiveMode... > "trip" -> "TRIP" > > 9) tripRouteTypeProtocolId... > this object contains the following in the DESCRIPTION: > "The size value of 116 has been assigned due to the > sub identifier of object types length limitation as > defined in SMIv2." > > what does that statement mean wrt this object? > the SYNTAX TripApplProtocol doesn't shed any light. > > i'm confused. maybe the next comment will make > this all a moot point... read on. I changed the type of TripApplProtocol to integer. I missed fixing that comment. > 10) tripRouteTypeTable vs. tripPeerRouteTypeTable > can't these tables be combined? add one additional > object to differentiate "remote" from "local" and > then you'd no longer need the address family objects > form both tables to be both read-only AND part of > the INDEX clause... it could truely be the more > "correct" not-accessible ;) > > see the attached file for a stab at what a combined > table might look like. That's a great idea. My only concern is that much of the info for the local entry is redundant, but.... it's better than a redundant table. Thanks, I'll make the change. > 11) tripSupportedCommunityTable... > is "The TRIP Communities attribute" the same as > the tripSupportedCommunityId object used to index > this table? is so, make is clearer that the > indexing object of this table is that attribute. Made the description clearer. > 12) tripSupportedCommunityEntry... > need a period at the end of the DESCRIPTION. done > 13) tripSupportedCommunityStorage... > is it a TRIP requirement (in a protocol sense) for > such information to be NV? will a platform that can't > meet such requirements be considered non-compliant? it is not a requirement. Fixed in description. > 14) tripPeerTable... > presumably entries in this table are remote peers only, right? yes > 15) tripPeerState... > a) be more clear on local vs. remote references. > when you say "to the peer" or "from the peer" > are you referring to the "remote peer"? if > so please be explicit in the description. I think I've made the description clearer now. > b) how do you have a entry in 'idle' state? > what types of "resources" are you referring to > as not being allocated to the peer? obviously, > it wouldn't include resources used to represent > the mib table entry ;) > c) how long does 'idle' state usually persist? is > is generally so transient as to not be a useful > state to represent in the mib?? True, the idle state should not persist for very long at all unless the TRIP admin status was set to down. Then the idle state should be constant. > d) add a space in description of 'established' value. > "NOTIFICATION,and" -> "NOTIFICATION, and" done > 16) tripPeerAdminStatus... > a) is there a valid DEFVAL for this object or must > it be given for row creation to succeed? if the > latter is the case, mention that in RowStatus object. Gave it a defval of up(1) > b) what is the relationship between values of > tripPeerAdminStatus and the values of tripPeerState? > down -> idle?? > > ( i believe i asked about this before and david was > going to look into it. ) Fixed in comments. If tripPeerAdminStatus is down, then the state would be idle(1). > 17) tripPeerConnectRetryInterval... > DESCRIPTION says... > "Attempt to set this value higher than the max > retry should not be allowed." > state more strongly... "will not be allowed". done > 18) tripPeerDisableTimer... > should "of the peer" be "of the remote peer"? done > 19) tripPeerStorage... > again, the issue of what about platforms that may > not be able to do nonVolatile? seems this needs > to be generally addressed throughout the mib. done. It is not a requirement that this storage be non volatile. > 20) tripPeerRowStatus... > the presense of this object would indicate that this > table can be provisioned. must it be or can some > of these entries be learned via the workings of the > protocol? Some entries can be learned. I will make this clear in the description. > 21) tripPeerStatsTable... > a) "stats" -> "statistics" > b) qualify when "this peer" or "the peer" is > referring to "remote" peer. total messages > counter objects are explicit while the other > objects in the table aren't. done > 22) tripPeerFsmEstablishedTime... > say "entered 'established' tripPeerState." done > 23) tripRouteAddress... > can you explain to me exactly how the 105 size limit > was reached? i presume it has something to do with > the size of each index component and the overall object > identifier length for objects in this table. i > didn't attempt to do the math, so could you summerize? > you say "prefix"... it this then some limited form > of the address - limited due to SMI issues? Here is what the RFC says: Address: This is an address (prefix) of the family type given by Address Family. The octet length of the address is variable and is determined by the length field of the route. It is limited because of SMI issues. Although I understand that this limitation might go away soon. > 24) tripRouteTRIBMask... > please expand TRIB acronym on first use. > any rfc 3219 reference for these type bits? > what does each type mean - more than just > "adj-TRIBs-ins". made the description clearer. > 25) tripRouteLocalPref.... > any REFERENCE for this? yes, fixed. > 26) tripRouteAdvertisementPath & tripRouteRoutedPath... > a) any REFERENCE for this? yes > b) say "sequence of TripItads" rather than integers. > that will establish what per itad boundaries are > w/in the octet string (ie, ever 4 octets). > c) i presume you mean each itad is in network byte order, > right? but what is the ordering of the entire sequence > of itads? which end of the overall octet string do you > start reading the path from? > I believe it a sequence from local to remote. > 27) tripRouteAtomicAggregation... > not specific to this route table object, but in > general does the capability represented by this > object need to be made configurable somewhere? This is not a configurable item. It is a boolean based on the decision of an LS selection of a route. > 28) tripRouteWithdrawn... > how is this removal of a route accomplished? The transmitting LS has determined that a route should no longer be advertised, and is propagating this information to its peers. > 29) how many route table entries can there be in a system? I think it virtually unlimited depending on available resources. Should this be stated somewhere? > 30) how many communities can be associated with a route? Again I think it is resource dependent. > > i probably have other comments on remaining portions of > the mib and draft doc, but i have to stop now. i'll > email more tomorrow. > > kevin > > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Kevin R. Lingle 919.392.2029 > checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ > Sometimes I think I understand everything, then I regain consciousness. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Nov 21 11:10:44 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 LAA08077 for ; Thu, 21 Nov 2002 11:10:42 -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 gALFj7217077; Thu, 21 Nov 2002 10:45:07 -0500 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id gALFiD217058 for ; Thu, 21 Nov 2002 10:44:13 -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 gALFiBhN003359 for ; Thu, 21 Nov 2002 10:44:11 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id C81DF443A6; Thu, 21 Nov 2002 10:44:05 -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 9C7B6443A4 for ; Thu, 21 Nov 2002 10:44:05 -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 SMTP id gALFi4a69661 for ; Thu, 21 Nov 2002 10:44:04 -0500 (EST) Received: from tomts10-srv.bellnexxia.net ([209.226.175.54]) by dusty; Thu Nov 21 10:43:59 EST 2002 Received: from DIZZY2 ([64.230.2.62]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021121154401.WBMC9064.tomts10-srv.bellnexxia.net@DIZZY2>; Thu, 21 Nov 2002 10:44:01 -0500 Message-ID: <003201c29174$f96b7c40$3e02e640@DIZZY2> From: "David Zinman" To: "Kevin Lingle" , , References: <3DDAA14B.723C296E@cisco.com> Subject: Re: [Iptel] comments on draft-ietf-iptel-trip-mib-04.txt - Part 1 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 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 21 Nov 2002 10:45:10 -0500 Content-Transfer-Encoding: 7bit inline. Kevin, Great idea to combine tripRouteTypeTable and tripPeerRouteTypeTable. I wish I had seen that. DZ ----- Original Message ----- From: "Kevin Lingle" To: ; Sent: Tuesday, November 19, 2002 3:38 PM Subject: [Iptel] comments on draft-ietf-iptel-trip-mib-04.txt - Part 1 > hi, > > i have some comments on the latest version of this I-D. > > Section 6.1 - TRIP-TC module > ---------------------------- > 1) TC TripApplProtocol DESCRIPTION... > change "document" to "MIB module" Done > > 2) TC TripSendReceiveMode... > can you explain each enumerated value w/in the DESCRIPTION? > eg, > "The operational mode of the TRIP applications. > > sendReceive(1) : > sendOnly(2) : > receiveOnly(3) : " > I've added the text to the DESCRIPTION clause, but I'm not sure there is anything left to add as far as descriptions, they are pretty self- explanatory. > > Section 6.2 - TRIP-MIB module > ----------------------------- > 1) tripCfgTable... > Thee table DESCRIPTION says.. > "The objects in this table should be nonVolatile and > survive reboot." > > - why don't you have a object of type StorageType in > this table as you do for others? seems it should > for consistency since you mention it in the descr > here. such an object would only need r/o access. done, made this object with r/w access. > - what if a platform cannot provide NV storage of > the info in this table across reboots? is this > a requirment formalized by TRIP or more "desired" > behavior? ie, is it really SHOULD or MUST? The "desired" behavior of this object is stated by the defval nonVolatile. I think this should be enough. > 2) tripCfgProtocolVersion... > consider moving "RFC3219" to a REFERENCE clause. > (i made a similar comment before wrt referencing > I-D for this object) done > 3) tripOperStatus... > we discussed this a bit in a previous version of > the mib. i asked you to consider another operstatus > value to reflect when there was a fault in the system. > you asked whether we really needed that because faults > will be covered by notifications. i responded with > reasons why that answer wasn't sufficient. of course > i left it as your call, so i guess i should just shut up. > reading the mib again, though, the same thing struck me. > it wasn't until i reviewed my email archive did i discover > we'd already been over this issue. > > exactly how is this handled by notifications? which > notification reflects a general fault with the trip LS? I think you mean tripCfgOperStatus. I'm not sure what happened here, this issue may have fallen through the cracks. Sorry. I will add a 'faulty' state. > > > 4) tripCfgAddrInetAddrType... > "tripAddr" -> "tripCfgAddr" > > 5) tripCfgAddr... > i'd generalize "IP address" to just "address" and > add words referring back to the InetAddrType object > as the indicator of what type of address this object is. done > 6) tripCfgPort... > why is port configurable (r/w) while address object > isn't? I've lost much of my email since these were written, but I seem to remember talking about this with Dave W. I believe that the consesus was to allow the user the flexibility to use whatever port was needed, but allowing a change of inet addr would impact too much on the TRIP network. Any TRIP experts to set me straight on this? > 7) tripCfgMinItadOriginationInterval... > "report" -> "reports" > > 8) tripCfgSendReceiveMode... > "trip" -> "TRIP" > > 9) tripRouteTypeProtocolId... > this object contains the following in the DESCRIPTION: > "The size value of 116 has been assigned due to the > sub identifier of object types length limitation as > defined in SMIv2." > > what does that statement mean wrt this object? > the SYNTAX TripApplProtocol doesn't shed any light. > > i'm confused. maybe the next comment will make > this all a moot point... read on. I changed the type of TripApplProtocol to integer. I missed fixing that comment. > 10) tripRouteTypeTable vs. tripPeerRouteTypeTable > can't these tables be combined? add one additional > object to differentiate "remote" from "local" and > then you'd no longer need the address family objects > form both tables to be both read-only AND part of > the INDEX clause... it could truely be the more > "correct" not-accessible ;) > > see the attached file for a stab at what a combined > table might look like. That's a great idea. My only concern is that much of the info for the local entry is redundant, but.... it's better than a redundant table. Thanks, I'll make the change. > 11) tripSupportedCommunityTable... > is "The TRIP Communities attribute" the same as > the tripSupportedCommunityId object used to index > this table? is so, make is clearer that the > indexing object of this table is that attribute. Made the description clearer. > 12) tripSupportedCommunityEntry... > need a period at the end of the DESCRIPTION. done > 13) tripSupportedCommunityStorage... > is it a TRIP requirement (in a protocol sense) for > such information to be NV? will a platform that can't > meet such requirements be considered non-compliant? it is not a requirement. Fixed in description. > 14) tripPeerTable... > presumably entries in this table are remote peers only, right? yes > 15) tripPeerState... > a) be more clear on local vs. remote references. > when you say "to the peer" or "from the peer" > are you referring to the "remote peer"? if > so please be explicit in the description. I think I've made the description clearer now. > b) how do you have a entry in 'idle' state? > what types of "resources" are you referring to > as not being allocated to the peer? obviously, > it wouldn't include resources used to represent > the mib table entry ;) > c) how long does 'idle' state usually persist? is > is generally so transient as to not be a useful > state to represent in the mib?? True, the idle state should not persist for very long at all unless the TRIP admin status was set to down. Then the idle state should be constant. > d) add a space in description of 'established' value. > "NOTIFICATION,and" -> "NOTIFICATION, and" done > 16) tripPeerAdminStatus... > a) is there a valid DEFVAL for this object or must > it be given for row creation to succeed? if the > latter is the case, mention that in RowStatus object. Gave it a defval of up(1) > b) what is the relationship between values of > tripPeerAdminStatus and the values of tripPeerState? > down -> idle?? > > ( i believe i asked about this before and david was > going to look into it. ) Fixed in comments. If tripPeerAdminStatus is down, then the state would be idle(1). > 17) tripPeerConnectRetryInterval... > DESCRIPTION says... > "Attempt to set this value higher than the max > retry should not be allowed." > state more strongly... "will not be allowed". done > 18) tripPeerDisableTimer... > should "of the peer" be "of the remote peer"? done > 19) tripPeerStorage... > again, the issue of what about platforms that may > not be able to do nonVolatile? seems this needs > to be generally addressed throughout the mib. done. It is not a requirement that this storage be non volatile. > 20) tripPeerRowStatus... > the presense of this object would indicate that this > table can be provisioned. must it be or can some > of these entries be learned via the workings of the > protocol? Some entries can be learned. I will make this clear in the description. > 21) tripPeerStatsTable... > a) "stats" -> "statistics" > b) qualify when "this peer" or "the peer" is > referring to "remote" peer. total messages > counter objects are explicit while the other > objects in the table aren't. done > 22) tripPeerFsmEstablishedTime... > say "entered 'established' tripPeerState." done > 23) tripRouteAddress... > can you explain to me exactly how the 105 size limit > was reached? i presume it has something to do with > the size of each index component and the overall object > identifier length for objects in this table. i > didn't attempt to do the math, so could you summerize? > you say "prefix"... it this then some limited form > of the address - limited due to SMI issues? Here is what the RFC says: Address: This is an address (prefix) of the family type given by Address Family. The octet length of the address is variable and is determined by the length field of the route. It is limited because of SMI issues. Although I understand that this limitation might go away soon. > 24) tripRouteTRIBMask... > please expand TRIB acronym on first use. > any rfc 3219 reference for these type bits? > what does each type mean - more than just > "adj-TRIBs-ins". made the description clearer. > 25) tripRouteLocalPref.... > any REFERENCE for this? yes, fixed. > 26) tripRouteAdvertisementPath & tripRouteRoutedPath... > a) any REFERENCE for this? yes > b) say "sequence of TripItads" rather than integers. > that will establish what per itad boundaries are > w/in the octet string (ie, ever 4 octets). > c) i presume you mean each itad is in network byte order, > right? but what is the ordering of the entire sequence > of itads? which end of the overall octet string do you > start reading the path from? > I believe it a sequence from local to remote. > 27) tripRouteAtomicAggregation... > not specific to this route table object, but in > general does the capability represented by this > object need to be made configurable somewhere? This is not a configurable item. It is a boolean based on the decision of an LS selection of a route. > 28) tripRouteWithdrawn... > how is this removal of a route accomplished? The transmitting LS has determined that a route should no longer be advertised, and is propagating this information to its peers. > 29) how many route table entries can there be in a system? I think it virtually unlimited depending on available resources. Should this be stated somewhere? > 30) how many communities can be associated with a route? Again I think it is resource dependent. > > i probably have other comments on remaining portions of > the mib and draft doc, but i have to stop now. i'll > email more tomorrow. > > kevin > > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Kevin R. Lingle 919.392.2029 > checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ > Sometimes I think I understand everything, then I regain consciousness. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Nov 22 08:20: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 IAA24395 for ; Fri, 22 Nov 2002 08:20:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAMDMoI15722 for iptel-archive@odin.ietf.org; Fri, 22 Nov 2002 08:22:50 -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 gAMDMnv15719 for ; Fri, 22 Nov 2002 08: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 IAA24378 for ; Fri, 22 Nov 2002 08:20:06 -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 gAMDMZv15694; Fri, 22 Nov 2002 08:22: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 gAMDK4v15619 for ; Fri, 22 Nov 2002 08:20:04 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24343 for ; Fri, 22 Nov 2002 08:17:05 -0500 (EST) Received: from cs.columbia.edu (dclient1.netlab.uky.edu [204.198.76.97]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gAMDJjFT026426 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Nov 2002 08:19:45 -0500 (EST) Message-ID: <3DDD524A.3020007@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: Mpierce1@aol.com CC: iptel@ietf.org Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers References: <86.2387d311.2b0d2eea@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: Thu, 21 Nov 2002 16:38:18 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit M. Pierce wrote: > [MAP] I think one needs to look at the intended use of this tel:uri. I > think of the best example (certainly one of the valid ones) is that the > tel:uri is the real information to dial a call that is "behind" a link > on a web page. In this case, anyone anywhere in the world may try to > place a call by clicking on this link. Therefore, the contents/format of > the tel:uri should not depend on whether or not your local national > agreements allows the call to be made. The format needs to be one single > global format (E.164-type format works well) and the local user > agent/device needs to be able to figure out from the information in the > tel:uri as well as knowledge of where it is to decide whether or not the > call can be made (or even how to make it). > > The fact that an 800 number can be represented as an E.164 number is not > unfortunate - I think it is a big help here. > > I suggest that the rule is that any number that can be represented in > the E.164 format MUST be done this way. (A slight > strengthening/clarification of the current text.) This means that an > "800" number would never have a context included, just as no other E.164 > number needs one. This removes some of the difficulties with the current > definition. I think treating tel URIs consistently as identifiers ("URN") helps conceptually. After all, if I specify an ISBN number (another URN), it is globally unique, but there is no guarantee that my local book store can order the book or that the library carries it. Similarly, there are any number of reasons that a non-800 E.164 number can fail: administrative prohibition, number disconnected, invalid number, local outbound call filtering, etc. Thus, the important consideration is only "is this number unique without a context"? Thus, a context would be needed if +1-800-something refers to two logically different entities in Canada and the US. (Obviously, an 800 number may end up in many different locations depending on the source of the call, but that's not the problem.) I don't know if that's possible. To put it more concretely: will the same 800# ever be assigned to two different entities, as in 1-800-123-4567 reaches PizzaHut if dialed in New York and 1-800-123-4567 reaches Domino's if dialed in New Jersey and 1-800-123-4567 reaches WeightWatchers if dialed in Canada > On the other hand, a more complex web page/user agent may include logic > (Java Script?) to provide a single point to click, and the user > agent/device would know where it is (within the numbering plans) or the > user would have told it and the UA would figure out which one of many > internal numbers to use to place the call. Each of these internal > numbers would be in the form of a tel:uri. We need a DHCP option that conveys the local area code! (Sorry, inside joke for the Geopriv crowd.) > > Mike Pierce > Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Nov 22 08:20: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 IAA24408 for ; Fri, 22 Nov 2002 08:20:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAMDMs215739 for iptel-archive@odin.ietf.org; Fri, 22 Nov 2002 08:22:54 -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 gAMDMsv15736 for ; Fri, 22 Nov 2002 08:22:54 -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 IAA24382 for ; Fri, 22 Nov 2002 08:20: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 gAMDMmv15710; Fri, 22 Nov 2002 08:22:48 -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 gAMDK7v15625 for ; Fri, 22 Nov 2002 08:20:07 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24346 for ; Fri, 22 Nov 2002 08:17:23 -0500 (EST) Received: from cs.columbia.edu (dclient1.netlab.uky.edu [204.198.76.97]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gAMDJxFT026506 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Nov 2002 08:19:59 -0500 (EST) Message-ID: <3DDD6A0C.4060809@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: Mpierce1@aol.com CC: jdrosen@dynamicsoft.com, iptel@ietf.org Subject: Re: [Iptel] comments on rfc2806bis References: <10e.1a680a8e.2b0c004c@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: Thu, 21 Nov 2002 18:19:40 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Again, the view of tel as an identifier might help here. I agree that for E.164, this should be done like a subaddress, which it seems closely related to. There are two usages for tel URIs: - as a unique identifier; in that case, comparison would take it into account. - as a way to place a call; depending on the type of equipment dialing the number, it would be ignored or dialed. After all, ISDN subaddresses are also pretty meaningless to non-ISDN devices. Related question: I suspect that having both subaddress and extension wouldn't make any sense, but is this a hard fact? >> 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? > > I think of a PBX extension as being sort of the same functionality in > some cases as the ISDN subaddress. Since the way to carry ISDN > subaddress is included, it seems reasonable to be able to include PBX > extensions (which are not part of the E.164 address). > > There are maybe two cases: > > 1. carrying just a PBX extension (say within the PBX itself) - I believe > this can be carried as "local". > > 2. carrying a PBX extension in addition to the full E.164 number of the > PBX. This is what was referred to above as "cannot be specified". > > Of course, trying to do case 2 seems to lead to a practical problem, > since the protocol issues at an interworking point (to traditional PSTN > signaling schemes in the US) really don't support the use of this PBX > extension in the forwarded signaling, so one could ask, "Why bother > including it in the tel:uri?". > > In some other countries, the situation is a little different (relates to > use of overlap). Because of the old equipment, it was possible to tack > the "PBX extension" onto the number used to get to the PBX, and directly > dial it, meaning that the total number of digits could exceed the > previous 12-digit max. With the current 15-digit max, I don't know if > any case in the world could exceed this. I hope not. If not, the PBX > extension is included as part of the E.164 number. > > Mike Pierce > Artel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Nov 22 13:27:04 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 NAA00802 for ; Fri, 22 Nov 2002 13:27:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAMITIm00749 for iptel-archive@odin.ietf.org; Fri, 22 Nov 2002 13:29: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 gAMITIv00745 for ; Fri, 22 Nov 2002 13:29: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 NAA00798 for ; Fri, 22 Nov 2002 13:26: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 gAMIT3v00734; Fri, 22 Nov 2002 13:29: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 gAMISTv00710 for ; Fri, 22 Nov 2002 13:28:29 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00784 for ; Fri, 22 Nov 2002 13:25:43 -0500 (EST) 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 gAMISEA23279; Fri, 22 Nov 2002 12:28:14 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Nov 2002 10:28:01 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20519687A@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Henning Schulzrinne'" , "'Mpierce1@aol.com'" Cc: "'iptel@ietf.org'" Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29254.E34B8762" 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, 22 Nov 2002 10:28:00 -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_01C29254.E34B8762 Content-Type: text/plain In other words, if 1-800 numbers are unique they can be tought of as E.164. If they are not unique, then they need to be tought of as local number with an associated context. I might be wrong, but I believe that the first case is the right one. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, November 21, 2002 1:38 PM > To: Mpierce1@aol.com > Cc: iptel@ietf.org > Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers > > > M. Pierce wrote: > > > > [MAP] I think one needs to look at the intended use of this > tel:uri. I > > think of the best example (certainly one of the valid ones) > is that the > > tel:uri is the real information to dial a call that is > "behind" a link > > on a web page. In this case, anyone anywhere in the world > may try to > > place a call by clicking on this link. Therefore, the > contents/format of > > the tel:uri should not depend on whether or not your local national > > agreements allows the call to be made. The format needs to > be one single > > global format (E.164-type format works well) and the local user > > agent/device needs to be able to figure out from the > information in the > > tel:uri as well as knowledge of where it is to decide > whether or not the > > call can be made (or even how to make it). > > > > The fact that an 800 number can be represented as an E.164 > number is > > not > > unfortunate - I think it is a big help here. > > > > I suggest that the rule is that any number that can be > represented in > > the E.164 format MUST be done this way. (A slight > > strengthening/clarification of the current text.) This > means that an > > "800" number would never have a context included, just as > no other E.164 > > number needs one. This removes some of the difficulties > with the current > > definition. > > I think treating tel URIs consistently as identifiers ("URN") helps > conceptually. After all, if I specify an ISBN number (another > URN), it > is globally unique, but there is no guarantee that my local > book store > can order the book or that the library carries it. > > Similarly, there are any number of reasons that a non-800 > E.164 number > can fail: administrative prohibition, number disconnected, invalid > number, local outbound call filtering, etc. > > Thus, the important consideration is only "is this number > unique without > a context"? Thus, a context would be needed if > +1-800-something refers > to two logically different entities in Canada and the US. > (Obviously, an > 800 number may end up in many different locations depending on the > source of the call, but that's not the problem.) I don't know > if that's > possible. To put it more concretely: will the same 800# ever > be assigned > to two different entities, as in > > 1-800-123-4567 reaches PizzaHut if dialed in New York > and > 1-800-123-4567 reaches Domino's if dialed in New Jersey > and > 1-800-123-4567 reaches WeightWatchers if dialed in Canada > > > On the other hand, a more complex web page/user agent may include > > logic > > (Java Script?) to provide a single point to click, and the user > > agent/device would know where it is (within the numbering > plans) or the > > user would have told it and the UA would figure out which > one of many > > internal numbers to use to place the call. Each of these internal > > numbers would be in the form of a tel:uri. > > We need a DHCP option that conveys the local area code! > (Sorry, inside > joke for the Geopriv crowd.) > > > > > > Mike Pierce > > Artel > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www.ietf.org/mailman/listinfo/iptel > ------_=_NextPart_001_01C29254.E34B8762 Content-Type: text/html RE: AW: [Iptel] comments on rfc2806bis - 800 numbers

In other words, if 1-800 numbers are unique they can be tought of
as E.164.

If they are not unique, then they need to be tought of as local
number with an associated context.

I might be wrong, but I believe that the first case is the right one.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Thursday, November 21, 2002 1:38 PM
> To: Mpierce1@aol.com
> Cc: iptel@ietf.org
> Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers
>
>
> M. Pierce wrote:
>
>
> > [MAP] I think one needs to look at the intended use of this
> tel:uri. I
> > think of the best example (certainly one of the valid ones)
> is that the
> > tel:uri is the real information to dial a call that is
> "behind" a link
> > on a web page. In this case, anyone anywhere in the world
> may try to
> > place a call by clicking on this link. Therefore, the
> contents/format of
> > the tel:uri should not depend on whether or not your local national
> > agreements allows the call to be made. The format needs to
> be one single
> > global format (E.164-type format works well) and the local user
> > agent/device needs to be able to figure out from the
> information in the
> > tel:uri as well as knowledge of where it is to decide
> whether or not the
> > call can be made (or even how to make it).
> >
> > The fact that an 800 number can be represented as an E.164
> number is
> > not
> > unfortunate - I think it is a big help here.
> >
> > I suggest that the rule is that any number that can be
> represented in
> > the E.164 format MUST be done this way. (A slight
> > strengthening/clarification of the current text.) This
> means that an
> > "800" number would never have a context included, just as
> no other E.164
> > number needs one. This removes some of the difficulties
> with the current
> > definition.
>
> I think treating tel URIs consistently as identifiers ("URN") helps
> conceptually. After all, if I specify an ISBN number (another
> URN), it
> is globally unique, but there is no guarantee that my local
> book store
> can order the book or that the library carries it.
>
> Similarly, there are any number of reasons that a non-800
> E.164 number
> can fail: administrative prohibition, number disconnected, invalid
> number, local outbound call filtering, etc.
>
> Thus, the important consideration is only "is this number
> unique without
> a context"? Thus, a context would be needed if
> +1-800-something refers
> to two logically different entities in Canada and the US.
> (Obviously, an
> 800 number may end up in many different locations depending on the
> source of the call, but that's not the problem.) I don't know
> if that's
> possible. To put it more concretely: will the same 800# ever
> be assigned
> to two different entities, as in
>
> 1-800-123-4567 reaches PizzaHut if dialed in New York
> and
> 1-800-123-4567 reaches Domino's if dialed in New Jersey
> and
> 1-800-123-4567 reaches WeightWatchers if dialed in Canada
>
> > On the other hand, a more complex web page/user agent may include
> > logic
> > (Java Script?) to provide a single point to click, and the user
> > agent/device would know where it is (within the numbering
> plans) or the
> > user would have told it and the UA would figure out which
> one of many
> > internal numbers to use to place the call. Each of these internal
> > numbers would be in the form of a tel:uri.
>
> We need a DHCP option that conveys the local area code!
> (Sorry, inside
> joke for the Geopriv crowd.)
>
>
> >
> > Mike Pierce
> > Artel
>
>
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www.ietf.org/mailman/listinfo/iptel
>

------_=_NextPart_001_01C29254.E34B8762-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Nov 22 15:41: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 PAA03712 for ; Fri, 22 Nov 2002 15:41:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAMKheR08267 for iptel-archive@odin.ietf.org; Fri, 22 Nov 2002 15:43:40 -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 gAMKhev08264 for ; Fri, 22 Nov 2002 15:43: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 PAA03688 for ; Fri, 22 Nov 2002 15:40: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 gAMKh9v08251; Fri, 22 Nov 2002 15: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 gAMKgkv08227 for ; Fri, 22 Nov 2002 15:42:46 -0500 Received: from apollo.taqua.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03622 for ; Fri, 22 Nov 2002 15:39:43 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: Thread-Topic: draft meeting iptel meeting minutes from IETF 55 Thread-Index: AcKSZ1gH/uuPMv4fEdaZ2wACswTPbQ== From: "Bender, Andrew" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAMKgkv08228 Subject: [Iptel] draft meeting iptel meeting minutes from IETF 55 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, 22 Nov 2002 15:41:07 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Notes from the iptel wg meeting are included below. I have tried to capture everything that transpired... in some cases I may have paraphrased mic dialog. Mic comments are delimited by '-'. New question threads start with '*'. If you didn't give your name at the mic, or I didn't otherwise know who you were, you may be a "somebody". If you would like me to fix this, or believe I did not capture your comments accurately, please email. Regards, Andrew Bender taqua.com --- *** *iptel *** 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 -tg issues -cpc / oli issues no amendments/comments ; agenda approved Status: -management changes cullen jennings new co chair rosenberg doing lousy job :) more work (uri) coming iesg has asked us to take on tel uri, and in doing so complete three drafts there is a new mailing list - subscriptions to the old list have not been automatically migrated existing work items: -trip mib expert review conducted revised version of draft produced addressing comments more comments since revision from list one more rev of this draft expected to address these official iesg last call after all of this wglc already completed -tgrep new version of the draft has been submitted sorely needs expert review lack of participation in wg to look over provide detailed comments solves an important problem: preregister for a block of dn's jonathan-i'm always having to tell people on the mailing list why you can't just (ab)use register new work items: all tel url items, and: tel url: draft-yu-tel-url-06 2806 bis: draft-antti-rfc2806bis-06 h323 url scheme: draft-levin-iptel-h323-url-scheme-04 when there is consensus on which items will be delivered, cullen and jonathan (chairs) will update the charter -tgrep issues presentation- dhaval n shah- -updates tgrep is an auxiliary protocol, no longer a subset of trip - this has changed support for carrier and trunkgroup attributes, address families added multiple address family handling support is included, but currently only one at a time is required updated route consolidation section country codes have been added to the cic -open issues thresholding scheme- leave in, or put in more details? *cullen-this might be an implementation issue jonathan-proposed a bcp item in the past, but scott pointed out that we don't have enough field experience trunk group length-set at 128 bytes, derived from itu *jonathan-is this big enough? jon peterson-30 bytes should be enough should carrier code be binary or ascii? (currently favoring binary) *somebody-ascii will do jon peterson-agree *jonathan-please provide comments. otherwise we will have to assign reviewers jon-i can publish the notes I have been giving to dhaval privately, but I am otherwise out of issues -2806bis: tel uri presentation- henning schulzrinne- this has undergone a significant number of changes -status changes: narrow the scope of the uri significantly uri comparisons should be case insensitive, but use lower case parameters bnf cleanup remove order dependence specify preferred ordering may need ed cleanup otherwise ready for wglc -open issue:context two approaches: dns and tel no prefix space 1.dns tel:7042;phone=context=context=cs.clumbia.edu 2.prefix: choose lowest number in range, or smallest prefix 3. should a prefix list be supported, of the form: phone=context=+31,+49 this is sometimes needed because there are cases where freephone can span country codes now *jon-there are 800's domestically that are scoped to bell operating companies / latas, etc. henning-don't think it is realistic to generalize uri to accommodate this jon-been uncomfortable with the idea of context, but pstn doesn't have this. e.g. phone number on found piece of paper has no context, and may not work if you were to arbitrarily use it at a terminal, etc. *henning-number ranges can't be easily conveyed / correctly implied by prefixes;i.e. range of DN's *jon-there should be a way to describe the private dialing plan *lawrence conroy-understand jon's concern. went through this in pint. dns is the 'least bad' choice. there is the potential for confusion with private number plans. ibm internal vs ibm external, etc. *jonathan-I ask myself: does this problem exist elsewhere? yes, i.e. 1918 address used in an http url, that are is in an email to another domain. the practical solution for this case has been that you only find / use a url in the context it is valid. Otherwise, as an endpoint, I have to be configured with what my scope is, and that is a fair configuration burden. *henning-could we take a more radical step that says we can't use local scopes? jonathan-no. just don't send urls out of scope. dave oran-agree with everything that jonathan said, except about the complexity of configuration. e.g. everybody has speed dials that have context. punt on this problem. *henning-context would prevent much of the silliness that happens today. there used to be a tv: url, channel scopes were the issue there. my take is first do no harm, but more info is better than no info *lawrence conroy-there is a change here. in the original 2806, it says if you don't know if you are in this context, then don't use the url. henning-this is simply an issue of the default behavior lawrence conroy-if you actually ring the wrong number, this is a problem in some locales. also, i see value in the prefix context, but not others, in general. *jonathan-this is not a tel url-specific problem. this feels to me like a bigger url issue for somebody else to solve. this draft is devoid of semantics on uri processing. dave oran-semantics are: you cant put an @ in it jonathan-need more discussion henning-tel url is more like a urn, should be treated as such somebody-seems like a fairly useful feature. -open issue:global numbers are of the form: +cc-xxxxx these require no context freephone numbers are perceived as global, but are local. however, this may change in the future, may not need to undertake special handling -draft progression planned for draft standard where do we go from here? one idea: trim down so there is a reasonable chance of getting this implemented need an interop matrix of some sort would appreciate it if folks using the url would contact me l conroy-jonathan pointed out that semantics are needed. can think of three scenarios where this might be used... should not go to draft standard since it is a radical change in the expected behavior of clients; this breaks private clients; it breaks 2806 compliant implementations jonathan-can anyone verify that in order to pursue draft standard, all normatives have to be at that level? somebody-yes jonathan-well what about RFC2396 (URI generic syntax)? this is not draft standard. I will speak with ad's as to what their position is on moving this work forward l conroy-i am aware of at least one existing implementation that would break with the 2806bis mods, although it is an internal subsystem jonathan- there is no formal requirement that this has to be backwards compatible. that is up to us to decide. henning-don't want to spend more years iterating this. want to make sure that our gating conditions are met first, as to assure quick passage -we will have to bump cpc stuff, because we are behind on time. take this to the list. will ask for more time at the next IETF session -trunk group open issues presentation- vijay gurbani- -motivation for this work if you have proxy and multiple gateways, you need to indicate what trunk group you want the call to go out on also true in reverse -issue 1 should trunk group indication be carried in tel uri? (vs sip uri) right now it is in tel uri -issue 2 global or local namespaces? most trunk groups are locally scoped. *somebody-left it as a local issue for coordination in tgrep *henning-having double equals is not a good idea vijay-not the first place this has been done... rohan-double equal is currently legal, also, in interop, found a number of other thing that although illegal, would help. -issue 3 originating and terminating trunk group should be able to appear separately but concurrently in sip uri for the originating case could use contact header (but this is the address of record) for terminating / destination use request uri *jonathan-there are no semantics for tel url, but you are specing that for sip jon-some amount is desirable jonathan-semantics are clear / implicit. if the semantics are well defined enough, you don't need to do anything special to make it work for sip dave oran-you are underestimating the perversity of the implementers -issue4 sip uri should be able to specify outbound trunk groups Items: -do we want to have a draft to extend the tel url to include trunk group? need to decide -richard shockey requested that enum work this be punted to iptel -gwloc-slp draft this was trying to solve a different problem than trip/tgrep so it was allowed to continue will still proceed as an individual work, if its scope has not changed Open Mic: won't try to take hums here. *jon-i submitted the tel cpc draft for discussion only... don't think it should necessarily be a chartered item *l conroy- tel url may have a local number, but enum may not. *brit-h323 version 05 is a pressing issue jonathan-this was in rfc editor's queue but pulled back. this should be one of the first things that should be complete brit-this was submitted to all of the relevant mailing lists 2 weeks ago *dave-one option for this wg is to declare victory and have wg go to sleep... not take action and go to sleep. rohan-could take a hum for mib, then send everything to transport area. i don't think that is a good idea dave-no, some just go to sleep jonathan-iesg asked us to do three things, we should do those. *rohan-i'm cool with making h323 an item, but is this entangled with annex o jonathan-this is only an issue if changes or updates will be disallowed brit-annex o still waits for tel url jonathan-is it possible to feedback changes to itu? brit-only if there are faults in draft jonathan-we have to discuss this with ad's et al. brit-why can't we do a hum? jonathan-iesg told us to take this on, presumably not just hand it back again *shockey?-why not just go to wglc. lots of these things have been in review for a long time thank you. sign the blue sheets, send in your ietf membership dues, etc. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Sat Nov 23 05: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 FAA26639 for ; Sat, 23 Nov 2002 05:46:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gANAmI220607 for iptel-archive@odin.ietf.org; Sat, 23 Nov 2002 05:48: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 gANAmIv20604 for ; Sat, 23 Nov 2002 05:48: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 FAA26634 for ; Sat, 23 Nov 2002 05: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 gANAm9v20594; Sat, 23 Nov 2002 05:48: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 gANAl9v20577 for ; Sat, 23 Nov 2002 05:47:09 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26618 for ; Sat, 23 Nov 2002 05:43:23 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Nov 2002 10:46:03 -0000 Received: from babelfish.srmr.co.uk (percy.roke.co.uk [193.118.192.111]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W7Y8WFQ3; Sat, 23 Nov 2002 10:46:01 -0000 From: "Conroy, Lawrence (SMTP)" To: iptel@ietf.org Cc: "Bender, Andrew" Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: References: Subject: Re: [Iptel] draft meeting iptel meeting minutes from IETF 55 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: Sat, 23 Nov 2002 05:45:46 -0500 >Notes from the iptel wg meeting are included below. > >I have tried to capture everything that transpired... in some cases >I may have paraphrased mic dialog. > >Mic comments are delimited by '-'. New question threads >start with '*'. If you didn't give your name at the mic, or I didn't >otherwise know who you were, you may be a "somebody". If you would >like me to fix this, or believe I did not capture your comments >accurately, please email. > >Regards, >Andrew Bender >taqua.com Hi Andrew, Good Work! Even if no-one else remembers to spell it out, Many Thanks. BTW.... c/brit/Orit/ (although images of Britt Ekland float into jetlagged mind :) atb, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Nov 25 06:18: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 GAA24416 for ; Mon, 25 Nov 2002 06:18:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPBKN526237 for iptel-archive@odin.ietf.org; Mon, 25 Nov 2002 06:20: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 gAPBKNv26234 for ; Mon, 25 Nov 2002 06:20: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 GAA24411 for ; Mon, 25 Nov 2002 06:17: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 gAPBKCv26225; Mon, 25 Nov 2002 06:20: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 gAPBJwv26180 for ; Mon, 25 Nov 2002 06:19:58 -0500 Received: from plmler4.mail.eds.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24408 for ; Mon, 25 Nov 2002 06:17:15 -0500 (EST) Received: from plmlir1.mail.eds.com (plmlir1-2.mail.eds.com [199.228.142.131]) by plmler4.mail.eds.com (8.11.6/8.11.6) with ESMTP id gAPBJvP14607 for ; Mon, 25 Nov 2002 05:19:57 -0600 Received: from plmlir1.mail.eds.com (localhost [127.0.0.1]) by plmlir1.mail.eds.com (8.11.6/8.11.6) with ESMTP id gAPBJuR07127 for ; Mon, 25 Nov 2002 05:19:56 -0600 (CST) Received: from USPLM001.examhub.exch.eds.com (uspla005.txpln.us.eds.com [148.94.64.102]) by plmlir1.mail.eds.com (8.11.6/8.11.6) with ESMTP id gAPBJt007123 for ; Mon, 25 Nov 2002 05:19:55 -0600 (CST) Received: by uspla005.txpln.us.eds.com with Internet Mail Service (5.5.2655.51) id ; Mon, 25 Nov 2002 05:19:55 -0600 Message-ID: <2BE915A69EF4D2119A0800805FF5E05012A246F1@BRSPM201> From: "Crizza, Roberto" To: "'iptel@ietf.org'" Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.51) 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, 25 Nov 2002 05:17:56 -0600 Team We don't have this kind of prblem in my country Brazil, the toll free number here is "0800" but it is unique for the hole country, the carrier never assign the same number to different company the string is 0800 xxx yyyy. Roberto Crizza EDS do Brasil ----- Original Message ----- From: Crizza, Roberto To: Ieee (E-mail) Sent: Friday, November 22, 2002 3:13 PM Subject: FW: AW: [Iptel] comments on rfc2806bis - 800 numbers > > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, November 21, 2002 19:38 > To: Mpierce1@aol.com > Cc: iptel@ietf.org > Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers > > > M. Pierce wrote: > > > > [MAP] I think one needs to look at the intended use of this tel:uri. I > > think of the best example (certainly one of the valid ones) is that the > > tel:uri is the real information to dial a call that is "behind" a link > > on a web page. In this case, anyone anywhere in the world may try to > > place a call by clicking on this link. Therefore, the contents/format of > > the tel:uri should not depend on whether or not your local national > > agreements allows the call to be made. The format needs to be one single > > global format (E.164-type format works well) and the local user > > agent/device needs to be able to figure out from the information in the > > tel:uri as well as knowledge of where it is to decide whether or not the > > call can be made (or even how to make it). > > > > The fact that an 800 number can be represented as an E.164 number is not > > unfortunate - I think it is a big help here. > > > > I suggest that the rule is that any number that can be represented in > > the E.164 format MUST be done this way. (A slight > > strengthening/clarification of the current text.) This means that an > > "800" number would never have a context included, just as no other E.164 > > number needs one. This removes some of the difficulties with the current > > definition. > > I think treating tel URIs consistently as identifiers ("URN") helps > conceptually. After all, if I specify an ISBN number (another URN), it > is globally unique, but there is no guarantee that my local book store > can order the book or that the library carries it. > > Similarly, there are any number of reasons that a non-800 E.164 number > can fail: administrative prohibition, number disconnected, invalid > number, local outbound call filtering, etc. > > Thus, the important consideration is only "is this number unique without > a context"? Thus, a context would be needed if +1-800-something refers > to two logically different entities in Canada and the US. (Obviously, an > 800 number may end up in many different locations depending on the > source of the call, but that's not the problem.) I don't know if that's > possible. To put it more concretely: will the same 800# ever be assigned > to two different entities, as in > > 1-800-123-4567 reaches PizzaHut if dialed in New York > and > 1-800-123-4567 reaches Domino's if dialed in New Jersey > and > 1-800-123-4567 reaches WeightWatchers if dialed in Canada > > > On the other hand, a more complex web page/user agent may include logic > > (Java Script?) to provide a single point to click, and the user > > agent/device would know where it is (within the numbering plans) or the > > user would have told it and the UA would figure out which one of many > > internal numbers to use to place the call. Each of these internal > > numbers would be in the form of a tel:uri. > > We need a DHCP option that conveys the local area code! (Sorry, inside > joke for the Geopriv crowd.) > > > > > > 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 Nov 25 09:46: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 JAA00879 for ; Mon, 25 Nov 2002 09:46:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPEmF305417 for iptel-archive@odin.ietf.org; Mon, 25 Nov 2002 09:48: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 gAPEmFv05414 for ; Mon, 25 Nov 2002 09:48: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 JAA00847 for ; Mon, 25 Nov 2002 09:45: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 gAPEm5v05406; Mon, 25 Nov 2002 09:48: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 gAPElov05379 for ; Mon, 25 Nov 2002 09:47:50 -0500 Received: from imo-d04.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00829 for ; Mon, 25 Nov 2002 09:45:05 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d04.mx.aol.com (mail_out_v34.13.) id 7.104.205005b1 (4206); Mon, 25 Nov 2002 09:47:39 -0500 (EST) Message-ID: <104.205005b1.2b13920b@aol.com> Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers To: hgs@cs.columbia.edu CC: iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_104.205005b1.2b13920b_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, 25 Nov 2002 09:47:39 EST --part1_104.205005b1.2b13920b_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/22/2002 8:19:59 AM Eastern Standard Time, hgs@cs.columbia.edu writes: > Thus, the important consideration is only "is this number unique without > a context"? Thus, a context would be needed if +1-800-something refers > to two logically different entities in Canada and the US. (Obviously, an > 800 number may end up in many different locations depending on the > source of the call, but that's not the problem.) I don't know if that's > possible. To put it more concretely: will the same 800# ever be assigned > to two different entities, as in > > 1-800-123-4567 reaches PizzaHut if dialed in New York > and > 1-800-123-4567 reaches Domino's if dialed in New Jersey > and > 1-800-123-4567 reaches WeightWatchers if dialed in Canada > [MAP] A long, long time ago in the history of telephony (about 20 years ago), Intra-state WATS numbers were indicated by the digit 2 in the 6th position (800-nn2-), so presumably the same number could be assigned in multiple places. (Ads would often say "In New York, dial 1-800-452-1234, elsewhere dial 1-800-678-1234.") I don't know if this is still possible, but it seems likely. There is no reason why the actual routing of any telephone number can't be dependent on the location of the originator. (911 certainly works this way.) I believe the case above (a single number reaching different Pizza Huts depending on where you are) is possible. If so, it's not just a function of which state you're in. I wouldn't want the store in NYC to deliver a pizza to me in Albany:>) I think this issue brings us back to the question of what the "context" is for. The current draft describes its use to "provide a unique identifier that lets a client know whether it can interpet the local number or not". It then states "It has not [sic] other meaning or function." The problem is that other implied uses seem to be to influence the routing of a call. The "context" included in the tel:uri is really just an extra check that the receiver can use to verify that it should be able to understand the number when it is not a globally defined one like E.164. However, I would still believe that, in the proper case, all the routing that was done to get it there should be correct (and should not use "context"). In this case of 800 numbers, the routing itself can not be dependent on an additional "context" that the originator puts with the number, which they think represents the intended destination. The originator doesn't know this. The "context" for routing is the orginator's location. Now, if we want to solve the bigger problem of not knowing where the originator of a call is by requiring them to enter some information to identify where they are, that's another issue, but I don't think anyone would want to do that. Mike Pierce Artel --part1_104.205005b1.2b13920b_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/22/2002 8:19:59 AM Eastern Standard Time, hgs@cs.columbia.edu writes:


Thus, the important consideration is only "is this number unique without
a context"? Thus, a context would be needed if +1-800-something refers
to two logically different entities in Canada and the US. (Obviously, an
800 number may end up in many different locations depending on the
source of the call, but that's not the problem.) I don't know if that's
possible. To put it more concretely: will the same 800# ever be assigned
to two different entities, as in

1-800-123-4567 reaches PizzaHut if dialed in New York
and
1-800-123-4567 reaches Domino's if dialed in New Jersey
and
1-800-123-4567 reaches WeightWatchers if dialed in Canada



[MAP] A long, long time ago in the history of telephony (about 20 years ago), Intra-state WATS numbers were indicated by the digit 2 in the 6th position (800-nn2-), so presumably the same number could be assigned in multiple places. (Ads would often say "In New York, dial 1-800-452-1234, elsewhere dial 1-800-678-1234.") I don't know if this is still possible, but it seems likely. There is no reason why the actual routing of any telephone number can't be dependent on the location of the originator. (911 certainly works this way.)

I believe the case above (a single number reaching different Pizza Huts depending on where you are) is possible. If so, it's not just a function of which state you're in. I wouldn't want the store in NYC to deliver a pizza to me in Albany:>)

I think this issue brings us back to the question of what the "context" is for. The current draft describes its use to "provide a unique identifier that lets a client know whether it can interpet the local number or not". It then states "It has not [sic] other meaning or function." The problem is that other implied uses seem to be to influence the routing of a call.

The "context" included in the tel:uri is really just an extra check that the receiver can use to verify that it should be able to understand the number when it is not a globally defined one like E.164. However, I would still believe that, in the proper case, all the routing that was done to get it there should be correct (and should not use "context"). In this case of 800 numbers, the routing itself can not be dependent on an additional "context" that the originator puts with the number, which they think represents the intended destination. The originator doesn't know this. The "context" for routing is the orginator's location.

Now, if we want to solve the bigger problem of not knowing where the originator of a call is by requiring them to enter some information to identify where they are, that's another issue, but I don't think anyone would want to do that.

Mike Pierce
Artel

--part1_104.205005b1.2b13920b_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Nov 25 09:57: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 JAA01680 for ; Mon, 25 Nov 2002 09:57:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPF0CB05834 for iptel-archive@odin.ietf.org; Mon, 25 Nov 2002 10:00: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 gAPF0Cv05831 for ; Mon, 25 Nov 2002 10:00: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 JAA01658 for ; Mon, 25 Nov 2002 09:57: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 gAPF04v05819; Mon, 25 Nov 2002 10: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 gAPExsv05764 for ; Mon, 25 Nov 2002 09:59:54 -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 JAA01636 for ; Mon, 25 Nov 2002 09:57:08 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gAPEwpEV002332; Mon, 25 Nov 2002 09:58:51 -0500 (EST) From: Scott Bradner Message-Id: <200211251458.gAPEwpEV002332@newdev.harvard.edu> To: hgs@cs.columbia.edu, Mpierce1@aol.com Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers Cc: iptel@ietf.org In-Reply-To: <104.205005b1.2b13920b@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, 25 Nov 2002 09:58:51 -0500 (EST) > I believe the case above (a single number reaching different Pizza Huts > depending on where you are) is possible yes Scott _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Nov 25 10:17: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 KAA02833 for ; Mon, 25 Nov 2002 10:17:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPFJFl07288 for iptel-archive@odin.ietf.org; Mon, 25 Nov 2002 10:19: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 gAPFJFv07285 for ; Mon, 25 Nov 2002 10:19: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 KAA02793 for ; Mon, 25 Nov 2002 10:16:28 -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 gAPFJ1v07272; Mon, 25 Nov 2002 10:19: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 gAPFIxv07257 for ; Mon, 25 Nov 2002 10:18:59 -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 KAA02780 for ; Mon, 25 Nov 2002 10:16:11 -0500 (EST) content-class: urn:content-classes:message Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29496.65BCAF9C" Message-ID: <06CF906FE3998C4E944213062009F1620248D9@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Iptel] comments on rfc2806bis - 800 numbers Thread-Index: AcKUkjRfWQm0kaS3T7ahd5MflxroNQAAI2JA From: "Stastny Richard" To: , Cc: 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, 25 Nov 2002 16:21:59 +0100 This is a multi-part message in MIME format. ------_=_NextPart_001_01C29496.65BCAF9C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If we talk about the context of the tel: URI scheme, we first need to talk about the "context" in which we will use this URI: =20 e.g.=20 used as a tel URI in an Enumservice used as a tel URI in a SIP message=20 used on a webpage to click on. =20 Lets take the following scenario (derived from a normal 800 IN service) If you see dial 800 xxx to get a Pizza what happens is (simplified):=20 you dial the 800 xxx number, your network is querying the IN service to get the service provider hosting the 800 service to get a CIC the call is routed according to the CIC to the service provider The service provider network is again making an IN query to find out to which PSTN number the call should be routed: this is now the tricky part: this routing may be dependant on your origination (context), time-of-day, date, etc. So what happens is, that your context is matched to the context=20 of the PSTN number. =20 Back again to the tel: URI =20 If you click on w webpage on a tel URI, it will be always be IMHO without context (for Pizza dial 800 xxx). We do not IN services with webpages. =20 In a sip proxy querying an IN services or ENUM this may be different. =20 In ENUM I may have 10 NAPTRs with PSTN tel URIs for the same 800 number with different context. =20 the SIP proxy querying ENUM may now match the context of the Tel URIs in the NAPTRs with the context retreived from your origination. =20 The problem here is: how is the context of your origination defined? By your number (does work anymore if you can have IP phones ion DSL in Montana with a New Work area code), the context of the sip proxy? ( could be anywhere), or what you configure (could be wrong). =20 So in this scenario we are not using the context with the 800 number at all, but with the PSTN numbers associated. =20 The other way would be to really let the user do the IN service: if in Montana click this if in New York click this =20 In this case the context of the 800 number need to be on the webpage, the context need to be transferred in SIP and then matched to the context in ENUM. =20 regards Richard Stastny =20 -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]=20 Sent: Monday, November 25, 2002 3:48 PM To: hgs@cs.columbia.edu Cc: iptel@ietf.org Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers =09 =09 In a message dated 11/22/2002 8:19:59 AM Eastern Standard Time, hgs@cs.columbia.edu writes:=20 =09 =09 =09 Thus, the important consideration is only "is this number unique without=20 a context"? Thus, a context would be needed if +1-800-something refers=20 to two logically different entities in Canada and the US. (Obviously, an=20 800 number may end up in many different locations depending on the=20 source of the call, but that's not the problem.) I don't know if that's=20 possible. To put it more concretely: will the same 800# ever be assigned=20 to two different entities, as in=20 =09 1-800-123-4567 reaches PizzaHut if dialed in New York=20 and=20 1-800-123-4567 reaches Domino's if dialed in New Jersey=20 and=20 1-800-123-4567 reaches WeightWatchers if dialed in Canada=20 =09 =09 =09 [MAP] A long, long time ago in the history of telephony (about 20 years ago), Intra-state WATS numbers were indicated by the digit 2 in the 6th position (800-nn2-), so presumably the same number could be assigned in multiple places. (Ads would often say "In New York, dial 1-800-452-1234, elsewhere dial 1-800-678-1234.") I don't know if this is still possible, but it seems likely. There is no reason why the actual routing of any telephone number can't be dependent on the location of the originator. (911 certainly works this way.)=20 =09 I believe the case above (a single number reaching different Pizza Huts depending on where you are) is possible. If so, it's not just a function of which state you're in. I wouldn't want the store in NYC to deliver a pizza to me in Albany:>)=20 =09 I think this issue brings us back to the question of what the "context" is for. The current draft describes its use to "provide a unique identifier that lets a client know whether it can interpet the local number or not". It then states "It has not [sic] other meaning or function." The problem is that other implied uses seem to be to influence the routing of a call.=20 =09 The "context" included in the tel:uri is really just an extra check that the receiver can use to verify that it should be able to understand the number when it is not a globally defined one like E.164. However, I would still believe that, in the proper case, all the routing that was done to get it there should be correct (and should not use "context"). In this case of 800 numbers, the routing itself can not be dependent on an additional "context" that the originator puts with the number, which they think represents the intended destination. The originator doesn't know this. The "context" for routing is the orginator's location.=20 =09 Now, if we want to solve the bigger problem of not knowing where the originator of a call is by requiring them to enter some information to identify where they are, that's another issue, but I don't think anyone would want to do that.=20 =09 Mike Pierce=20 Artel=20 =09 =09 ------_=_NextPart_001_01C29496.65BCAF9C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
If we=20 talk about the context of the tel: URI scheme, we first need to=20 talk
about=20 the "context" in which we will use this URI:
 
e.g.=20
used=20 as a tel URI in an Enumservice
used=20 as a tel URI in a SIP message
used=20 on a webpage to click on.
 
Lets=20 take the following scenario (derived from a normal 800 IN=20 service)
If you=20 see dial 800 xxx to get a Pizza
what=20 happens is (simplified):
you=20 dial the 800 xxx number,
your=20 network is querying the IN service to get the service=20 provider
hosting the 800 service to get a CIC
the=20 call is routed according to the CIC to the service = provider
The=20 service provider network is again making an IN query to find=20 out
to=20 which PSTN number the call should be routed:
this=20 is now the tricky part: this routing may be dependant on=20 your
origination (context), time-of-day, date, = etc.
So=20 what happens is, that your context is matched to the context=20
of the=20 PSTN number.
 
Back=20 again to the tel: URI
 
If you=20 click on w webpage on a tel URI, it will be always be IMHO=20 without
context (for Pizza dial 800 xxx). We do not IN services with=20 webpages.
 
In a=20 sip proxy querying an IN services or ENUM this may be=20 different.
 
In=20 ENUM I may have 10 NAPTRs with PSTN tel URIs
for=20 the same 800 number with different context.
 
the=20 SIP proxy querying ENUM may now match the context of = the
Tel=20 URIs in the NAPTRs with the context retreived from your=20 origination.
 
The=20 problem here is: how is the context of your origination=20 defined?
By=20 your number (does work anymore if you can have IP phones ion=20 DSL
in=20 Montana with a New Work area code), the context of the = sip proxy?=20 (
could=20 be anywhere), or what you configure (could be = wrong).
 
So in=20 this scenario we are not using the context with the 800 number=20 at
all,=20 but with the PSTN numbers associated.
 
The=20 other way would be to really let the user do the IN = service:
if in=20 Montana click this
if in=20 New York click this
 
In=20 this case the context of the 800 number need to be on = the
webpage, the context need to be transferred in SIP and then=20 matched
to the=20 context in ENUM.
 
regards
Richard Stastny
 
-----Original Message-----
From: = Mpierce1@aol.com=20 [mailto:Mpierce1@aol.com]
Sent: Monday, November 25, 2002 = 3:48=20 PM
To: hgs@cs.columbia.edu
Cc:=20 iptel@ietf.org
Subject: Re: AW: [Iptel] comments on = rfc2806bis - 800=20 numbers

In a=20 message dated 11/22/2002 8:19:59 AM Eastern Standard Time, = hgs@cs.columbia.edu=20 writes:


Thus, the important consideration is only "is this = number unique=20 without
a context"? Thus, a context would be needed if = +1-800-something=20 refers
to two logically different entities in Canada and the US. = (Obviously, an
800 number may end up in many different locations = depending on the
source of the call, but that's not the = problem.) I=20 don't know if that's
possible. To put it more concretely: will = the same=20 800# ever be assigned
to two different entities, as in=20

1-800-123-4567 reaches PizzaHut if dialed in New York =
and=20
1-800-123-4567 reaches Domino's if dialed in New Jersey
and=20
1-800-123-4567 reaches WeightWatchers if dialed in Canada=20



[MAP] A long, = long time ago in=20 the history of telephony (about 20 years ago), Intra-state WATS = numbers were=20 indicated by the digit 2 in the 6th position (800-nn2-), so presumably = the=20 same number could be assigned in multiple places. (Ads would often say = "In New=20 York, dial 1-800-452-1234, elsewhere dial 1-800-678-1234.") I don't = know if=20 this is still possible, but it seems likely. There is no reason why = the actual=20 routing of any telephone number can't be dependent on the location of = the=20 originator. (911 certainly works this way.)

I believe the case = above=20 (a single number reaching different Pizza Huts depending on where you = are) is=20 possible. If so, it's not just a function of which state you're in. I = wouldn't=20 want the store in NYC to deliver a pizza to me in Albany:>) =

I think=20 this issue brings us back to the question of what the "context" is = for. The=20 current draft describes its use to "provide a unique identifier that = lets a=20 client know whether it can interpet the local number or not". It then = states=20 "It has not [sic] other meaning or function." The problem is that = other=20 implied uses seem to be to influence the routing of a call. =

The=20 "context" included in the tel:uri is really just an extra check that = the=20 receiver can use to verify that it should be able to understand the = number=20 when it is not a globally defined one like E.164. However, I would = still=20 believe that, in the proper case, all the routing that was done to get = it=20 there should be correct (and should not use "context"). In this case = of 800=20 numbers, the routing itself can not be dependent on an additional = "context"=20 that the originator puts with the number, which they think represents = the=20 intended destination. The originator doesn't know this. The "context" = for=20 routing is the orginator's location.

Now, if we want to solve = the=20 bigger problem of not knowing where the originator of a call is by = requiring=20 them to enter some information to identify where they are, that's = another=20 issue, but I don't think anyone would want to do that.

Mike = Pierce=20
Artel

=00 ------_=_NextPart_001_01C29496.65BCAF9C-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Nov 25 14:00: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 OAA17572 for ; Mon, 25 Nov 2002 14:00:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPJ2St22296 for iptel-archive@odin.ietf.org; Mon, 25 Nov 2002 14:02:28 -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 gAPJ2Rv22293 for ; Mon, 25 Nov 2002 14:02:27 -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 NAA17535 for ; Mon, 25 Nov 2002 13:59: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 gAPJ2Dv22285; Mon, 25 Nov 2002 14:02: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 gAPJ1Av22245 for ; Mon, 25 Nov 2002 14:01:10 -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 NAA17509 for ; Mon, 25 Nov 2002 13:58:22 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAPJ0Px22564; Mon, 25 Nov 2002 11:00:25 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Nov 2002 11:00:26 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2051FC00A@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Scott Bradner'" , "'hgs@cs.columbia.edu'" , "'Mpierce1@aol.com'" Cc: "'iptel@ietf.org'" Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C294B4.E9AE43B2" 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, 25 Nov 2002 11:00:25 -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_01C294B4.E9AE43B2 Content-Type: text/plain Scott's answer is good, but I'm not sure if the question was right. In that particular example, there could be some sort of call distribution service that directs the call to different Pizza Hut locations based on call origination. The 1-800 number would be directed to other E.164 numbers based on call origination. But the 1-800 could still be assigned only once to Pizza Hut and thus be unique. This is not in my opinion any different than having an alias address in SIP that can route calls to a variety of location depending on factors such as call origination. I assume that the scenario where a 1-800 reaches different Pizza Huts based on where you are calling from would be very common. I don't think there is any problem with this scenario: we can do this today even if we consider the 1-800 number to be a unique E.164 number. The real question is can a unique 1-800 number be re-assigned to multiple different entities? Could a call to a 1-800 number placed from one location reach a Pizza-Hut in New York, and reach an a municipal information line in Santa Cruz, CA? Can PizzaHut and Santa Cruz each apply and obtain the same number independently?. If the answer is yes, then an 1-800 number is NOT an E.164 and will have to be treated as a local number in 2806. I don't believe that the second case is the one we are confronted with. I believe that the 1-800 are in fact E.164 numbers, and that they can not be assigned twice to different entities (even accross countries such as Canada/US/Caraibeans which share the same country code). If this is the case, I think the 1-800 issue is solved. > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Monday, November 25, 2002 6:59 AM > To: hgs@cs.columbia.edu; Mpierce1@aol.com > Cc: iptel@ietf.org > Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers > > > > I believe the case above (a single number reaching different Pizza > > Huts > > depending on where you are) is possible > > yes > > Scott > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www.ietf.org/mailman/listinfo/iptel > ------_=_NextPart_001_01C294B4.E9AE43B2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: AW: [Iptel] comments on rfc2806bis - 800 numbers

Scott's answer is good, but I'm not sure if the = question was right.

In that particular example, there could be some sort = of call distribution service
that directs the call to different Pizza Hut = locations based on call origination.
The 1-800 number would be directed to other E.164 = numbers based on call origination.
But the 1-800 could still be assigned only once to = Pizza Hut and thus be unique. This
is not in my opinion any different than having an = alias address in SIP that can route
calls to a variety of location depending on factors = such as call origination. I assume
that the scenario where a 1-800 reaches different = Pizza Huts based on where you
are calling from would be very common. I don't think = there is any problem with this
scenario: we can do this today even if we consider = the 1-800 number to be a unique
E.164 number.

The real question is can a unique 1-800 number be = re-assigned to multiple different entities?
Could a call to a 1-800 number placed from one = location reach a Pizza-Hut in New York,
and reach an a municipal information line in Santa = Cruz, CA? Can PizzaHut and Santa Cruz
each apply and obtain the same number = independently?. If the answer is yes, then an
1-800 number is NOT an E.164 and will have to be = treated as a local number in
2806.

I don't believe that the second case is the one we = are confronted with. I believe that the
1-800 are in fact E.164 numbers, and that they can = not be assigned twice to different entities
(even accross countries such as Canada/US/Caraibeans = which share the same country code).
If this is the case, I think the 1-800 issue is = solved.



> -----Original Message-----
> From: Scott Bradner [mailto:sob@harvard.edu]
> Sent: Monday, November 25, 2002 6:59 AM
> To: hgs@cs.columbia.edu; = Mpierce1@aol.com
> Cc: iptel@ietf.org
> Subject: Re: AW: [Iptel] comments on rfc2806bis = - 800 numbers
>
>
> > I believe the case above (a single number = reaching different Pizza
> > Huts
> > depending on where you are) is = possible
>
> yes
>
> Scott
> = _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www.ietf.org/mailman/listinfo/iptel=
>

------_=_NextPart_001_01C294B4.E9AE43B2-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Nov 25 14:05:57 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 OAA17995 for ; Mon, 25 Nov 2002 14:05:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPJ8Dg23131 for iptel-archive@odin.ietf.org; Mon, 25 Nov 2002 14:08: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 gAPJ8Cv23128 for ; Mon, 25 Nov 2002 14:08: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 OAA17973 for ; Mon, 25 Nov 2002 14:05:26 -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 gAPJ81v23119; Mon, 25 Nov 2002 14:08: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 gAPJ7sv23105 for ; Mon, 25 Nov 2002 14:07:54 -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 OAA17967 for ; Mon, 25 Nov 2002 14:05:07 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gAPJ6iTW003734; Mon, 25 Nov 2002 14:06:44 -0500 (EST) From: Scott Bradner Message-Id: <200211251906.gAPJ6iTW003734@newdev.harvard.edu> To: audet@nortelnetworks.com, hgs@cs.columbia.edu, Mpierce1@aol.com, sob@harvard.edu Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers Cc: iptel@ietf.org In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D2051FC00A@zsc3c030.us.nortel.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, 25 Nov 2002 14:06:44 -0500 (EST) > I believe that the > 1-800 are in fact E.164 numbers, and that they can not be assigned twice to > different entities would that not be just a matter of populating the backroom databases? having geographicly-specific data in the mapping database is already there so it would seem to me that it does not matter if the entries represent the same or different organizations Scott _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon Nov 25 14:18: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 OAA18835 for ; Mon, 25 Nov 2002 14:18:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPJLEW23809 for iptel-archive@odin.ietf.org; Mon, 25 Nov 2002 14:21: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 gAPJLEv23806 for ; Mon, 25 Nov 2002 14:21: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 OAA18817 for ; Mon, 25 Nov 2002 14:18: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 gAPJL3v23790; Mon, 25 Nov 2002 14:21: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 gAPJKNv23765 for ; Mon, 25 Nov 2002 14:20:23 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18749 for ; Mon, 25 Nov 2002 14:17:36 -0500 (EST) 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 gAPJJjU08781; Mon, 25 Nov 2002 13:19:45 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Nov 2002 11:19:32 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2051FC0AB@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Scott Bradner'" , "'hgs@cs.columbia.edu'" , "'Mpierce1@aol.com'" Cc: "'iptel@ietf.org'" Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C294B7.93618304" 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, 25 Nov 2002 11:19:29 -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_01C294B7.93618304 Content-Type: text/plain Right, it wouldn't matter as long as they both are willing to share the same number (which may not be typical today, but it is certainly possible). I guess one could call this sub-leasing of phone numbers. Again, to me this is no different than having, say, an alias in SIP for my_local_supplier@foo.com which sends request to various vendors depending on geography (or any other criteria such as time-of-day). > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Monday, November 25, 2002 11:07 AM > To: Audet, Francois [SC100:4K02:EXCH]; hgs@cs.columbia.edu; > Mpierce1@aol.com; sob@harvard.edu > Cc: iptel@ietf.org > Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers > > > > I believe that the > > 1-800 are in fact E.164 numbers, and that they can not be assigned > > twice to different entities > > would that not be just a matter of populating the backroom > databases? having geographicly-specific data in the mapping > database is already there so it would seem to me that it does > not matter if the entries represent the same or different > organizations > > Scott > ------_=_NextPart_001_01C294B7.93618304 Content-Type: text/html RE: AW: [Iptel] comments on rfc2806bis - 800 numbers

Right, it wouldn't matter as long as they both are willing
to share the same number (which may not be typical today, but
it is certainly possible). I guess one could call this
sub-leasing of phone numbers.

Again, to me this is no different than having, say, an
alias in SIP for my_local_supplier@foo.com which sends
request to various vendors depending on geography (or
any other criteria such as time-of-day).

> -----Original Message-----
> From: Scott Bradner [mailto:sob@harvard.edu]
> Sent: Monday, November 25, 2002 11:07 AM
> To: Audet, Francois [SC100:4K02:EXCH]; hgs@cs.columbia.edu;
> Mpierce1@aol.com; sob@harvard.edu
> Cc: iptel@ietf.org
> Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers
>
>
> > I believe that the
> > 1-800 are in fact E.164 numbers, and that they can not be assigned
> > twice to different entities
>
> would that not be just a matter of populating the backroom
> databases? having geographicly-specific data in the mapping
> database is already there so it would seem to me that it does
> not matter if the entries represent the same or different
> organizations
>
> Scott
>

------_=_NextPart_001_01C294B7.93618304-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Wed Nov 27 15:17: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 PAA26653 for ; Wed, 27 Nov 2002 15:17:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARKJLM22112 for iptel-archive@odin.ietf.org; Wed, 27 Nov 2002 15: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 gARKJLv22109 for ; Wed, 27 Nov 2002 15: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 PAA26624 for ; Wed, 27 Nov 2002 15:16: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 gARKJGv22101; Wed, 27 Nov 2002 15:19: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 gARKIjv22068 for ; Wed, 27 Nov 2002 15:18:45 -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 PAA26544 for ; Wed, 27 Nov 2002 15:15: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 gARKIoP9026986; Wed, 27 Nov 2002 15:18:50 -0500 (EST) Received: from mhammer-w2k01.cisco.com (hrn2-dhcp-161-44-87-84.cisco.com [161.44.87.84]) by cia.cisco.com (Mirapoint) with ESMTP id ABJ54635; Wed, 27 Nov 2002 15:08:15 -0500 (EST) Message-Id: <4.3.2.7.2.20021127135726.00b21a58@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Scott Bradner From: Michael Hammer Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers Cc: audet@nortelnetworks.com, hgs@cs.columbia.edu, Mpierce1@aol.com, sob@harvard.edu, iptel@ietf.org In-Reply-To: <200211251906.gAPJ6iTW003734@newdev.harvard.edu> References: <2F1FC1DEA077D5119FAD00508BCFD6D2051FC00A@zsc3c030.us.nortel.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: Wed, 27 Nov 2002 15:18:21 -0500 I have one major issue with an assumption underlying this conversation: that the discussion is based on the premise that location information can be inferred from the telephone number, and worse that the location of the source telephone number is in reality where on the Internet one is initiating the call. I hope that as phone numbers become less geographic meaningful, the use of explicit geographic parameters (with source permission, of course) can be used instead. In a sense the Web-based click here if ... heads in that direction. Mike At 02:06 PM 11/25/2002 -0500, Scott Bradner wrote: > > I believe that the > > 1-800 are in fact E.164 numbers, and that they can not be assigned twice to > > different entities > >would that not be just a matter of populating the backroom databases? >having geographicly-specific data in the mapping database is >already there so it would seem to me that it does not matter >if the entries represent the same or different organizations > >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 Wed Nov 27 15:31: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 PAA26963 for ; Wed, 27 Nov 2002 15:31:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARKY7722723 for iptel-archive@odin.ietf.org; Wed, 27 Nov 2002 15: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 gARKY7v22720 for ; Wed, 27 Nov 2002 15:34: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 PAA26922 for ; Wed, 27 Nov 2002 15:31: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 gARKY2v22696; Wed, 27 Nov 2002 15:34: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 gARKXQv22658 for ; Wed, 27 Nov 2002 15:33:26 -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 PAA26883 for ; Wed, 27 Nov 2002 15:30:37 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gARKWHxs015075; Wed, 27 Nov 2002 15:32:17 -0500 (EST) From: Scott Bradner Message-Id: <200211272032.gARKWHxs015075@newdev.harvard.edu> To: mhammer@cisco.com, sob@harvard.edu Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers Cc: audet@nortelnetworks.com, hgs@cs.columbia.edu, iptel@ietf.org, Mpierce1@aol.com In-Reply-To: <4.3.2.7.2.20021127135726.00b21a58@cia.cisco.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, 27 Nov 2002 15:32:17 -0500 (EST) > I have one major issue with an assumption underlying this > conversation: that the discussion is based on the premise that location > information can be inferred from the telephone number 1/ the conversation was about assigning the same number in multiple areas and my assertion is that it can be done (in fact is done) 2/ I am specifically not making any assumption that you can find out anything useful about the location of an IP (or cellular) phone from its number Scott ---- >From mhammer@cisco.com Wed Nov 27 15:17:53 2002 X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Nov 2002 15:18:21 -0500 To: Scott Bradner From: Michael Hammer Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers Cc: audet@nortelnetworks.com, hgs@cs.columbia.edu, Mpierce1@aol.com, sob@harvard.edu, iptel@ietf.org In-Reply-To: <200211251906.gAPJ6iTW003734@newdev.harvard.edu> References: <2F1FC1DEA077D5119FAD00508BCFD6D2051FC00A@zsc3c030.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I have one major issue with an assumption underlying this conversation: that the discussion is based on the premise that location information can be inferred from the telephone number, and worse that the location of the source telephone number is in reality where on the Internet one is initiating the call. I hope that as phone numbers become less geographic meaningful, the use of explicit geographic parameters (with source permission, of course) can be used instead. In a sense the Web-based click here if ... heads in that direction. Mike At 02:06 PM 11/25/2002 -0500, Scott Bradner wrote: > > I believe that the > > 1-800 are in fact E.164 numbers, and that they can not be assigned twice to > > different entities > >would that not be just a matter of populating the backroom databases? >having geographicly-specific data in the mapping database is >already there so it would seem to me that it does not matter >if the entries represent the same or different organizations > >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 Wed Nov 27 16:20: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 QAA28169 for ; Wed, 27 Nov 2002 16:20:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARLNEe25633 for iptel-archive@odin.ietf.org; Wed, 27 Nov 2002 16:23: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 gARLNEv25630 for ; Wed, 27 Nov 2002 16:23: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 QAA28148 for ; Wed, 27 Nov 2002 16:20: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 gARLN5v25621; Wed, 27 Nov 2002 16: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 gARLMwv25605 for ; Wed, 27 Nov 2002 16:22:58 -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 QAA28145 for ; Wed, 27 Nov 2002 16:20:08 -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 gARLN5lq003597; Wed, 27 Nov 2002 16:23:05 -0500 (EST) Received: from mhammer-w2k01.cisco.com (hrn2-dhcp-161-44-87-84.cisco.com [161.44.87.84]) by cia.cisco.com (Mirapoint) with ESMTP id ABJ55373; Wed, 27 Nov 2002 16:12:30 -0500 (EST) Message-Id: <4.3.2.7.2.20021127160159.05442be0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Scott Bradner 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, Mpierce1@aol.com In-Reply-To: <200211272032.gARKWHxs015075@newdev.harvard.edu> References: <4.3.2.7.2.20021127135726.00b21a58@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: Wed, 27 Nov 2002 16:22:36 -0500 Scott, This was not aimed at you personally. You are not doing 2/ but others are. By saying same number assigned in multiple areas, do you mean numbers without country code prefixes? Mike At 03:32 PM 11/27/2002 -0500, Scott Bradner wrote: > > I have one major issue with an assumption underlying this > > conversation: that the discussion is based on the premise that location > > information can be inferred from the telephone number > >1/ the conversation was about assigning the same number in > multiple areas and my assertion is that it can be done > (in fact is done) > >2/ I am specifically not making any assumption that you can find > out anything useful about the location of an IP (or cellular) > phone from its number > >Scott > >---- > >From mhammer@cisco.com Wed Nov 27 15:17:53 2002 >X-Sender: mhammer@cia.cisco.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >Date: Wed, 27 Nov 2002 15:18:21 -0500 >To: Scott Bradner >From: Michael Hammer >Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers >Cc: audet@nortelnetworks.com, hgs@cs.columbia.edu, Mpierce1@aol.com, > sob@harvard.edu, iptel@ietf.org >In-Reply-To: <200211251906.gAPJ6iTW003734@newdev.harvard.edu> >References: <2F1FC1DEA077D5119FAD00508BCFD6D2051FC00A@zsc3c030.us.nortel.com> >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii"; format=flowed > >I have one major issue with an assumption underlying this >conversation: that the discussion is based on the premise that location >information can be inferred from the telephone number, and worse that the >location of the source telephone number is in reality where on the Internet >one is initiating the call. > >I hope that as phone numbers become less geographic meaningful, the use of >explicit geographic parameters (with source permission, of course) can be >used instead. In a sense the Web-based click here if ... heads in that >direction. > >Mike > > >At 02:06 PM 11/25/2002 -0500, Scott Bradner wrote: > > > I believe that the > > > 1-800 are in fact E.164 numbers, and that they can not be assigned > twice to > > > different entities > > > >would that not be just a matter of populating the backroom databases? > >having geographicly-specific data in the mapping database is > >already there so it would seem to me that it does not matter > >if the entries represent the same or different organizations > > > >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 Fri Nov 29 09:07: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 JAA00035 for ; Fri, 29 Nov 2002 09:07:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gATEA9l01974 for iptel-archive@odin.ietf.org; Fri, 29 Nov 2002 09:10: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 gATEA9v01971 for ; Fri, 29 Nov 2002 09:10: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 JAA00026 for ; Fri, 29 Nov 2002 09:07: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 gATE9av01948; Fri, 29 Nov 2002 09:09: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 gATE6bv01281 for ; Fri, 29 Nov 2002 09:06:37 -0500 Received: from apollo.taqua.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29955 for ; Fri, 29 Nov 2002 09:03:48 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Iptel] draft meeting iptel meeting minutes from IETF 55 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Iptel] draft meeting iptel meeting minutes from IETF 55 Thread-Index: AcKS3VysmcEsIAFwRUCdfkBOb1tzPgE0hw6w From: "Bender, Andrew" To: "Conroy, Lawrence (SMTP)" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gATE6bv01282 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, 29 Nov 2002 09:05:16 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > > Hi Andrew, > Good Work! > Even if no-one else remembers to spell it out, Many Thanks. Thanks much. The chairs have already been too profuse in their praise. > BTW.... > > c/brit/Orit/ Right... how embarrassing; apologies to Orit. This should have occurred to me after I read the draft. I haven't got any other comments besides those from Larry over the past week, so I'm assuming we're all okay here... the final version is below. Regards, Andrew Bender taqua.com --- *** *iptel *** 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 -tg issues -cpc / oli issues no amendments/comments ; agenda approved Status: -management changes cullen jennings new co chair rosenberg doing lousy job :) more work (uri) coming iesg has asked us to take on tel uri, and in doing so complete three drafts there is a new mailing list - subscriptions to the old list have not been automatically migrated existing work items: -trip mib expert review conducted revised version of draft produced addressing comments more comments since revision from list one more rev of this draft expected to address these official iesg last call after all of this wglc already completed -tgrep new version of the draft has been submitted sorely needs expert review lack of participation in wg to look over provide detailed comments solves an important problem: preregister for a block of dn's jonathan-i'm always having to tell people on the mailing list why you can't just (ab)use register new work items: all tel url items, and: tel url: draft-yu-tel-url-06 2806 bis: draft-antti-rfc2806bis-06 h323 url scheme: draft-levin-iptel-h323-url-scheme-04 when there is consensus on which items will be delivered, cullen and jonathan (chairs) will update the charter -tgrep issues presentation- dhaval n shah- -updates tgrep is an auxiliary protocol, no longer a subset of trip - this has changed support for carrier and trunkgroup attributes, address families added multiple address family handling support is included, but currently only one at a time is required updated route consolidation section country codes have been added to the cic -open issues thresholding scheme- leave in, or put in more details? *cullen-this might be an implementation issue jonathan-proposed a bcp item in the past, but scott pointed out that we don't have enough field experience trunk group length-set at 128 bytes, derived from itu *jonathan-is this big enough? jon peterson-30 bytes should be enough should carrier code be binary or ascii? (currently favoring binary) *somebody-ascii will do jon peterson-agree *jonathan-please provide comments. otherwise we will have to assign reviewers jon-i can publish the notes I have been giving to dhaval privately, but I am otherwise out of issues -2806bis: tel uri presentation- henning schulzrinne- this has undergone a significant number of changes -status changes: narrow the scope of the uri significantly uri comparisons should be case insensitive, but use lower case parameters bnf cleanup remove order dependence specify preferred ordering may need ed cleanup otherwise ready for wglc -open issue:context two approaches: dns and tel no prefix space 1.dns tel:7042;phone=context=context=cs.clumbia.edu 2.prefix: choose lowest number in range, or smallest prefix 3. should a prefix list be supported, of the form: phone=context=+31,+49 this is sometimes needed because there are cases where freephone can span country codes now *jon-there are 800's domestically that are scoped to bell operating companies / latas, etc. henning-don't think it is realistic to generalize uri to accommodate this jon-been uncomfortable with the idea of context, but pstn doesn't have this. e.g. phone number on found piece of paper has no context, and may not work if you were to arbitrarily use it at a terminal, etc. *henning-number ranges can't be easily conveyed / correctly implied by prefixes;i.e. range of DN's *jon-there should be a way to describe the private dialing plan *lawrence conroy-understand jon's concern. went through this in pint. dns is the 'least bad' choice. there is the potential for confusion with private number plans. ibm internal vs ibm external, etc. *jonathan-I ask myself: does this problem exist elsewhere? yes, i.e. 1918 address used in an http url, that are is in an email to another domain. the practical solution for this case has been that you only find / use a url in the context it is valid. Otherwise, as an endpoint, I have to be configured with what my scope is, and that is a fair configuration burden. *henning-could we take a more radical step that says we can't use local scopes? jonathan-no. just don't send urls out of scope. dave oran-agree with everything that jonathan said, except about the complexity of configuration. e.g. everybody has speed dials that have context. punt on this problem. *henning-context would prevent much of the silliness that happens today. there used to be a tv: url, channel scopes were the issue there. my take is first do no harm, but more info is better than no info *lawrence conroy-there is a change here. in the original 2806, it says if you don't know if you are in this context, then don't use the url. henning-this is simply an issue of the default behavior lawrence conroy-if you actually ring the wrong number, this is a problem in some locales. also, i see value in the prefix context, but not others, in general. *jonathan-this is not a tel url-specific problem. this feels to me like a bigger url issue for somebody else to solve. this draft is devoid of semantics on uri processing. dave oran-semantics are: you cant put an @ in it jonathan-need more discussion henning-tel url is more like a urn, should be treated as such somebody-seems like a fairly useful feature. -open issue:global numbers are of the form: +cc-xxxxx these require no context freephone numbers are perceived as global, but are local. however, this may change in the future, may not need to undertake special handling -draft progression planned for draft standard where do we go from here? one idea: trim down so there is a reasonable chance of getting this implemented need an interop matrix of some sort would appreciate it if folks using the url would contact me l conroy-jonathan pointed out that semantics are needed. can think of three scenarios where this might be used... should not go to draft standard since it is a radical change in the expected behavior of clients; this breaks private clients; it breaks 2806 compliant implementations jonathan-can anyone verify that in order to pursue draft standard, all normatives have to be at that level? somebody-yes jonathan-well what about RFC2396 (URI generic syntax)? this is not draft standard. I will speak with ad's as to what their position is on moving this work forward l conroy-i am aware of at least one existing implementation that would break with the 2806bis mods, although it is an internal subsystem jonathan- there is no formal requirement that this has to be backwards compatible. that is up to us to decide. henning-don't want to spend more years iterating this. want to make sure that our gating conditions are met first, as to assure quick passage -we will have to bump cpc stuff, because we are behind on time. take this to the list. will ask for more time at the next IETF session -trunk group open issues presentation- vijay gurbani- -motivation for this work if you have proxy and multiple gateways, you need to indicate what trunk group you want the call to go out on also true in reverse -issue 1 should trunk group indication be carried in tel uri? (vs sip uri) right now it is in tel uri -issue 2 global or local namespaces? most trunk groups are locally scoped. *somebody-left it as a local issue for coordination in tgrep *henning-having double equals is not a good idea vijay-not the first place this has been done... rohan-double equal is currently legal, also, in interop, found a number of other thing that although illegal, would help. -issue 3 originating and terminating trunk group should be able to appear separately but concurrently in sip uri for the originating case could use contact header (but this is the address of record) for terminating / destination use request uri *jonathan-there are no semantics for tel url, but you are specing that for sip jon-some amount is desirable jonathan-semantics are clear / implicit. if the semantics are well defined enough, you don't need to do anything special to make it work for sip dave oran-you are underestimating the perversity of the implementers -issue4 sip uri should be able to specify outbound trunk groups Items: -do we want to have a draft to extend the tel url to include trunk group? need to decide -richard shockey requested that enum work this be punted to iptel -gwloc-slp draft this was trying to solve a different problem than trip/tgrep so it was allowed to continue will still proceed as an individual work, if its scope has not changed Open Mic: won't try to take hums here. *jon-i submitted the tel cpc draft for discussion only... don't think it should necessarily be a chartered item *l conroy- tel url may have a local number, but enum may not. *orit-h323 version 05 is a pressing issue jonathan-this was in rfc editor's queue but pulled back. this should be one of the first things that should be complete orit-this was submitted to all of the relevant mailing lists 2 weeks ago *dave-one option for this wg is to declare victory and have wg go to sleep... not take action and go to sleep. rohan-could take a hum for mib, then send everything to transport area. i don't think that is a good idea dave-no, some just go to sleep jonathan-iesg asked us to do three things, we should do those. *rohan-i'm cool with making h323 an item, but is this entangled with annex o jonathan-this is only an issue if changes or updates will be disallowed orit-annex o still waits for tel url jonathan-is it possible to feedback changes to itu? orit-only if there are faults in draft jonathan-we have to discuss this with ad's et al. orit-why can't we do a hum? jonathan-iesg told us to take this on, presumably not just hand it back again *shockey?-why not just go to wglc. lots of these things have been in review for a long time thank you. sign the blue sheets, send in your ietf membership dues, etc. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Nov 29 13:14: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 NAA04733 for ; Fri, 29 Nov 2002 13:14:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gATIGiM13701 for iptel-archive@odin.ietf.org; Fri, 29 Nov 2002 13:16: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 gATIGiv13698 for ; Fri, 29 Nov 2002 13:16: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 NAA04726 for ; Fri, 29 Nov 2002 13:13: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 gATIBEv13520; Fri, 29 Nov 2002 13:11: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 gATI8Zv13421 for ; Fri, 29 Nov 2002 13:08:35 -0500 Received: from imo-d09.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04475 for ; Fri, 29 Nov 2002 13:05:45 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d09.mx.aol.com (mail_out_v34.13.) id c.12f.1c56204d (3699); Fri, 29 Nov 2002 13:08:04 -0500 (EST) Message-ID: <12f.1c56204d.2b190703@aol.com> Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers To: mhammer@cisco.com, sob@harvard.edu CC: audet@nortelnetworks.com, hgs@cs.columbia.edu, iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_12f.1c56204d.2b190703_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, 29 Nov 2002 13:08:03 EST --part1_12f.1c56204d.2b190703_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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 --part1_12f.1c56204d.2b190703_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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
--part1_12f.1c56204d.2b190703_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Nov 29 14:26:20 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 OAA06125 for ; Fri, 29 Nov 2002 14:26:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gATJSeg16392 for iptel-archive@odin.ietf.org; Fri, 29 Nov 2002 14:28:40 -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 gATJSev16389 for ; Fri, 29 Nov 2002 14:28: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 OAA06105 for ; Fri, 29 Nov 2002 14:25:48 -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 gATJS5v16378; Fri, 29 Nov 2002 14:28: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 gATJRSv16351 for ; Fri, 29 Nov 2002 14:27:28 -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 OAA06102 for ; Fri, 29 Nov 2002 14:24:36 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gATJR60R006578; Fri, 29 Nov 2002 11:27:06 -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 ABI86687; Fri, 29 Nov 2002 11:24:44 -0800 (PST) Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers Content-Type: multipart/alternative; boundary=Apple-Mail-19-161255322 Mime-Version: 1.0 (Apple Message framework v548) Cc: mhammer@cisco.com, sob@harvard.edu, audet@nortelnetworks.com, hgs@cs.columbia.edu, iptel@ietf.org To: Mpierce1@aol.com From: Rohan Mahy In-Reply-To: <12f.1c56204d.2b190703@aol.com> Message-Id: <7A852507-03D0-11D7-9AE1-0003938AF740@cisco.com> 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: Fri, 29 Nov 2002 11:26:37 -0800 --Apple-Mail-19-161255322 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, So far, everyone seems to agree that as long as numbers are unique,=20 they don/t require the context parameter. I don't think anything in=20 your mail contradicts that. Comments inline. thanks, -rohan On Friday, November 29, 2002, at 10:08 AM, Mpierce1@aol.com wrote: > In a message dated 11/27/2002 4:23:11 PM Eastern Standard Time,=20 > 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=20 > related to free-phone (e.g. 800) numbers: > > 1. In the US (and Canada), 800 numbers have often been applicable for=20= > calls originating only from certain areas, i.e., only US, a group of=20= > states, a single state, etc. This (theoretically) allows the same=20 > number to be assigned in different areas to completely different users=20= > with completely separate routing. I suspect this is still allowed. Can someone provide a definitive answer on this question? In my=20 (fairly limited) experience, numbers which are assigned to a specific=20 region play an error message, rather than being routed to orthogonal=20 organizations. If this is indeed the case, it is totally reasonable to=20= refer to these numbers as ordinary tel:+1800nnnnnnn URIs with no=20 additional context. Reachability is not a concern for a URI, only=20 uniqueness. For example, most folks cannot reach: http://wwwin.cisco.com even=20 though it is a valid URI. > 2. An 800 number (in the US/Canada) can be assigned which uses=20 > "Intelligent Network" capabilities with a data base lookup so that the=20= > actual routing is a function of the originator's location (i.e.,=20 > calling party number). (Example: route to nearest Pizza Hut.) It is useful to use a URI to refer to such a number "in general", or to=20= refer to a specific instance. I think it is perfectly legitimate to=20 publish both of the following URIs: tel:+18002224357 tel:+18002224357;context=3D+1831452 the first is a URI for roadside assistance for the American Automobile=20= Association (1-800-AAA-HELP for those stateside). I can publish this=20 URI on a web page with the disclaimer that it is only reachable in the=20= US. Even though it will reach different instances of AAA for different=20= callers, it still refers to a specific thing (it is still unique) The second refers to the the specific AAA call center that handles=20 calls for my (unported) prefix. I don't see much need for this usage,=20= but I see no reason to prohibit its use either. Please note also, that I can call some +1 800 numbers from outside=20 North America. I have called American Express from a random variety of=20= countries in Europe and Asia by just dialing the equivalent of=20 +18008014941. This number is not only globally unique, but also=20 reachable from a variety of countries outside any describable context. > 3. The same 800 number may be allocated to the same company for use in=20= > multiple countries. I'm looking for examples. The use of the number=20 > depends on the location of the calling party. It is normally called=20 > only when in one of those countries (without dialing a Country Code).=20= > Dialing from outside the country, using the Country Code, is=20 > theoretically possible, if allowed by agreements between the > = countries. we don't really care much about countries, we care about prefixes. If=20= someone has the same number in multiple prefixes, then they are free to=20= publish as few or as many of these URIs as they would like. They are=20 all unique. > 4. The "International Freephone Service" uses the "800" in place of=20 > the Country Code followed by 8 digits, that is, the assigned "IFS"=20 > number is truly "global", however there is certainly still no=20 > guarantee that it can be called from everywhere in the globe. ITU-T=20 > only requires that it be used "between two or more countries". Use of=20= > these numbers requires that the user be located within the assigned=20 > countries. As long as +800xxxxxxxx is unique, then this is a totally valid URI. =20 as I said > Of course, all of these uses are based on knowing the originator's=20 > location (or more precisely, the location of the equipment handling=20 > the call set-up). > > Mapping this to the Internet case where there is no knowledge of the=20= > location of the caller is a real challenge. I think that one reason=20 > for the "context" being applied with such "800" numbers in 2806bis was=20= > to get around this problem - that is - for the originator to indicate=20= > 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=20= > are) wants to call an "800-234-567" number in Germany. They put in the=20= > "800" number and separately code the "49" country code for Germany in=20= > "context". They could just as well represent the desired number as=20 > +49-800-234-567 =A0(One could apply the same reasoning to a regular=20 > number in the US and put in only the final 7 digits, and code +1 and=20= > 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=20 > destination +49-800-234-567 (full number) and puts their own location=20= > (e.g., +1-410) in "context, meaning where they are physically located=20= > (independent from their "identity"). The destination could use this=20 > "context" to decide whether or not it should handle the call. This is=20= > similar to the use of "context" when dealing with "private" numbers in=20= > which the originator codes their own, and the other end can use it as=20= > a check. > > Another example of the use of "context" which is implied in the draft=20= > is the ability to codes multiple "context" values, for example, the=20 > originator codes the number as +49-800-234-567 and codes the "context"=20= > with both 49 for Germany and 44 for UK. While it is certainly possible=20= > for the same number to be assigned to the same company in both=20 > countries, it has never been clear to me what function (multiple=20 > contexts) this would serve. Would an 800 number valid in the entire US=20= > then require the "context" to include every possible area code? > > > Mike Pierce > Artel --Apple-Mail-19-161255322 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, So far, everyone seems to agree that as long as numbers are unique, they don/t require the context parameter. I don't think anything in your mail contradicts that. Comments inline. thanks, -rohan On Friday, November 29, 2002, at 10:08 AM, Mpierce1@aol.com wrote: ArialIn 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? = Arial0000,0000,0000[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. Can someone provide a definitive answer on this question? In my (fairly limited) experience, numbers which are assigned to a specific region play an error message, rather than being routed to orthogonal organizations. If this is indeed the case, it is totally reasonable to refer to these numbers as ordinary tel:+1800nnnnnnn URIs with no additional context. Reachability is not a concern for a URI, only uniqueness. For example, most folks cannot reach: http://wwwin.cisco.com even though it is a valid URI. = Arial0000,0000,00002. 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.) It is useful to use a URI to refer to such a number "in general", or to refer to a specific instance. I think it is perfectly legitimate to publish both of the following URIs:=20 tel:+18002224357=20 tel:+18002224357;context=3D+1831452 the first is a URI for roadside assistance for the American Automobile Association (1-800-AAA-HELP for those stateside). I can publish this URI on a web page with the disclaimer that it is only reachable in the US. Even though it will reach different instances of AAA for different callers, it still refers to a specific thing (it is still unique) The second refers to the the specific AAA call center that handles calls for my (unported) prefix. I don't see much need for this usage, but I see no reason to prohibit its use either. Please note also, that I can call some +1 800 numbers from outside North America. I have called American Express from a random variety of countries in Europe and Asia by just dialing the equivalent of +18008014941. This number is not only globally unique, but also reachable from a variety of countries outside any describable context. = Arial0000,0000,00003. 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. we don't really care much about countries, we care about prefixes. If someone has the same number in multiple prefixes, then they are free to publish as few or as many of these URIs as they would like. They are all unique. = Arial0000,0000,00004. 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. As long as +800xxxxxxxx is unique, then this is a totally valid URI.=20 as I said=20 = Arial0000,0000,0000Of 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 =A0(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 = --Apple-Mail-19-161255322-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri Nov 29 15:08:16 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 PAA06988 for ; Fri, 29 Nov 2002 15:08:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gATKAbf18574 for iptel-archive@odin.ietf.org; Fri, 29 Nov 2002 15:10:37 -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 gATKAbv18571 for ; Fri, 29 Nov 2002 15:10:37 -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 PAA06980 for ; Fri, 29 Nov 2002 15:07: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 gATKA4v18548; Fri, 29 Nov 2002 15: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 gATK93v18513 for ; Fri, 29 Nov 2002 15:09:03 -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 PAA06945 for ; Fri, 29 Nov 2002 15:06:10 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gATK7hN11894; Fri, 29 Nov 2002 12:07:43 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Nov 2002 12:07:43 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2052EFC58@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Rohan Mahy'" , "'Mpierce1@aol.com'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" Cc: "'mhammer@cisco.com'" , "'sob@harvard.edu'" , "'hgs@cs.columbia.edu'" , "'iptel@ietf.org'" Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C297E2.F584727A" 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, 29 Nov 2002 12:07:36 -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_01C297E2.F584727A Content-Type: text/plain Agreed with what you said. I think the core of the problem is no one seems sure if 1-800 in North America are uniquely assigned. We do know that there are restrictions on where the number can be reached from. We also know that the call can terminate on different end-use depending on things like call origination location, time of day, etc. But we can't seem to get a definitive answer to the question of can a 1-800 be assigned to more than one entity, and thus not to be unique. We thus still don't know if 1-800 numbers are E.164 numbers (and thus unique) or an artifact of the dialling plans used in North America (and thus requiring a context). We are certainly getting conflicting information. I wonder if somebody from the NANP administrator could help us... -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Friday, November 29, 2002 11:27 AM To: Mpierce1@aol.com Cc: mhammer@cisco.com; sob@harvard.edu; Audet, Francois [SC100:4K02:EXCH]; hgs@cs.columbia.edu; iptel@ietf.org Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers Hi, So far, everyone seems to agree that as long as numbers are unique, they don/t require the context parameter. I don't think anything in your mail contradicts that. Comments inline. thanks, -rohan On Friday, November 29, 2002, at 10:08 AM, 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. Can someone provide a definitive answer on this question? In my (fairly limited) experience, numbers which are assigned to a specific region play an error message, rather than being routed to orthogonal organizations. If this is indeed the case, it is totally reasonable to refer to these numbers as ordinary tel:+1800nnnnnnn URIs with no additional context. Reachability is not a concern for a URI, only uniqueness. For example, most folks cannot reach: http://wwwin.cisco.com even though it is a valid URI. 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.) It is useful to use a URI to refer to such a number "in general", or to refer to a specific instance. I think it is perfectly legitimate to publish both of the following URIs: tel:+18002224357 tel:+18002224357;context=+1831452 the first is a URI for roadside assistance for the American Automobile Association (1-800-AAA-HELP for those stateside). I can publish this URI on a web page with the disclaimer that it is only reachable in the US. Even though it will reach different instances of AAA for different callers, it still refers to a specific thing (it is still unique) The second refers to the the specific AAA call center that handles calls for my (unported) prefix. I don't see much need for this usage, but I see no reason to prohibit its use either. Please note also, that I can call some +1 800 numbers from outside North America. I have called American Express from a random variety of countries in Europe and Asia by just dialing the equivalent of +18008014941. This number is not only globally unique, but also reachable from a variety of countries outside any describable context. 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. we don't really care much about countries, we care about prefixes. If someone has the same number in multiple prefixes, then they are free to publish as few or as many of these URIs as they would like. They are all unique. 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. As long as +800xxxxxxxx is unique, then this is a totally valid URI. as I said 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 ------_=_NextPart_001_01C297E2.F584727A Content-Type: text/html Message
Agreed with what you said.
 
I think the core of the problem is no one seems sure if 1-800 in North America are uniquely assigned. We do know that there are restrictions on where the number can be reached from. We also know that the call can terminate on different end-use depending on things like call origination location, time of day, etc.
 
But we can't seem to get a definitive answer to the question of can a 1-800 be assigned to more than one entity, and thus not to be unique. We thus still don't know if 1-800 numbers are E.164 numbers (and thus unique) or an artifact of the dialling plans used in North America (and thus requiring a context). We are certainly getting conflicting information.
 
I wonder if somebody from the NANP administrator could help us...
-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Friday, November 29, 2002 11:27 AM
To: Mpierce1@aol.com
Cc: mhammer@cisco.com; sob@harvard.edu; Audet, Francois [SC100:4K02:EXCH]; hgs@cs.columbia.edu; iptel@ietf.org
Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers

Hi,


So far, everyone seems to agree that as long as numbers are unique, they don/t require the context parameter. I don't think anything in your mail contradicts that. Comments inline.


thanks,

-rohan


On Friday, November 29, 2002, at 10:08 AM, 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.


Can someone provide a definitive answer on this question? In my (fairly limited) experience, numbers which are assigned to a specific region play an error message, rather than being routed to orthogonal organizations. If this is indeed the case, it is totally reasonable to refer to these numbers as ordinary tel:+1800nnnnnnn URIs with no additional context. Reachability is not a concern for a URI, only uniqueness.


For example, most folks cannot reach: http://wwwin.cisco.com even though it is a valid URI.


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.)


It is useful to use a URI to refer to such a number "in general", or to refer to a specific instance. I think it is perfectly legitimate to publish both of the following URIs:


tel:+18002224357

tel:+18002224357;context=+1831452


the first is a URI for roadside assistance for the American Automobile Association (1-800-AAA-HELP for those stateside). I can publish this URI on a web page with the disclaimer that it is only reachable in the US. Even though it will reach different instances of AAA for different callers, it still refers to a specific thing (it is still unique)


The second refers to the the specific AAA call center that handles calls for my (unported) prefix. I don't see much need for this usage, but I see no reason to prohibit its use either.


Please note also, that I can call some +1 800 numbers from outside North America. I have called American Express from a random variety of countries in Europe and Asia by just dialing the equivalent of +18008014941. This number is not only globally unique, but also reachable from a variety of countries outside any describable context.


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.


we don't really care much about countries, we care about prefixes. If someone has the same number in multiple prefixes, then they are free to publish as few or as many of these URIs as they would like. They are all unique.


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.


As long as +800xxxxxxxx is unique, then this is a totally valid URI. as I said


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

------_=_NextPart_001_01C297E2.F584727A-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Sat Nov 30 06:07: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 GAA02411 for ; Sat, 30 Nov 2002 06:07:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAUB9f932453 for iptel-archive@odin.ietf.org; Sat, 30 Nov 2002 06:09: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 gAUB9ev32450 for ; Sat, 30 Nov 2002 06:09:41 -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 GAA02399 for ; Sat, 30 Nov 2002 06:06: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 gAUB98v32361; Sat, 30 Nov 2002 06:09: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 gAUB3vv31588 for ; Sat, 30 Nov 2002 06:03:57 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02294 for ; Sat, 30 Nov 2002 06:01:10 -0500 (EST) Received: from cs.columbia.edu (dclient13.netlab.uky.edu [204.198.76.127]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gAUB3t4e022405 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 30 Nov 2002 06:03:56 -0500 (EST) Message-ID: <3DE89A9A.1020902@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] Summary of +1-800 for tel URI discussion 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: Sat, 30 Nov 2002 06:01:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Let me try to summarize the +1-800 discussion. - There are some +1-800 numbers that only work regionally, e.g., in a single state or area code. This is not a (major) issue since this is similar to other call filtering mechanisms or failures. Context is helpful, but not necessary. - There is no problem with +1-800 numbers 'owned' *by the same organization* reaching different terminals or non-800 numbers. This is not a URI problem and outside the scope of tel URIs. (There may be practical problems if the gateway is located in a different place than the caller; somebody ordering pizza in Brooklyn may get connected to the PizzaHut in Denver.) Apparently, there are also some numbers (particularly vanity numbers) that are intentionally shared by different organizations (1-800-LAWYER, I think). See http://www.hurt911.org/page15-vanity.html or http://lawyer-attorney-advertising-marketing.com/1-800-marketing.html - There may be some +1-800 numbers that are regionally re-used, i.e., are re-assigned to completely different entities. Thus, dialing +1-800-555-1212 might reach a wedding organizer in Pennsylvania and a divorce lawyer in Reno, Nevada. If this number is seen by a gateway (and, to a lesser extent, put on a web page), rather unexpected things could happen. Solution: Provide context so that the gateway, which usually knows which area code it is in, can decide whether this is valid or not (or a SIP proxy can route the request to a gateway where it is valid). I wonder if anybody has seen a real example of such numbers. Like all local numbers, one can't avoid certain problems. If a user in Nevada clicks on "Divorces" (NV only), but the call is actually handed to a gateway in Pennsylvania, you will get the PA version of the number, unless the context hints that this number should not be used there. 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.) Please let me know if I missed any aspect of this discussion or if you disagree with the conclusion. Henning _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Sat Nov 30 13:26: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 NAA09610 for ; Sat, 30 Nov 2002 13:26:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAUISsR16599 for iptel-archive@odin.ietf.org; Sat, 30 Nov 2002 13:28:54 -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 gAUISrv16596 for ; Sat, 30 Nov 2002 13:28:53 -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 NAA09575 for ; Sat, 30 Nov 2002 13:26: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 gAUISKv16581; Sat, 30 Nov 2002 13:28: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 gAUIRtv16550 for ; Sat, 30 Nov 2002 13:27:55 -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 NAA09564 for ; Sat, 30 Nov 2002 13:25:04 -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 gAUIRR0J024617; Sat, 30 Nov 2002 10:27:27 -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 ABI91440; Sat, 30 Nov 2002 10:25:20 -0800 (PST) Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion 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: <3DE89A9A.1020902@cs.columbia.edu> Message-Id: <6DF23460-0491-11D7-9AE1-0003938AF740@cisco.com> 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: Sat, 30 Nov 2002 10:27:49 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning, 1-800-DIENTES or 1-800-LAWYER still qualify as a single organization (the referring agency/coorperative/whatever). Also, nobody has demonstrated concretely that any number exists which is orthogonally reused (your Nevada divorce/Pennsylvania wedding example). I expect that we can get a definitive answer from NANPA fairly quickly. 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. thanks, -rohan On Saturday, November 30, 2002, at 03:01 AM, Henning Schulzrinne wrote: > Let me try to summarize the +1-800 discussion. > > - There are some +1-800 numbers that only work regionally, e.g., in a > single state or area code. This is not a (major) issue since this is > similar to other call filtering mechanisms or failures. Context is > helpful, but not necessary. > > - There is no problem with +1-800 numbers 'owned' *by the same > organization* reaching different terminals or non-800 numbers. This is > not a URI problem and outside the scope of tel URIs. (There may be > practical problems if the gateway is located in a different place than > the caller; somebody ordering pizza in Brooklyn may get connected to > the PizzaHut in Denver.) > > Apparently, there are also some numbers (particularly vanity numbers) > that are intentionally shared by different organizations > (1-800-LAWYER, I think). See http://www.hurt911.org/page15-vanity.html > or > http://lawyer-attorney-advertising-marketing.com/1-800-marketing.html > > - There may be some +1-800 numbers that are regionally re-used, i.e., > are re-assigned to completely different entities. Thus, dialing > +1-800-555-1212 might reach a wedding organizer in Pennsylvania and a > divorce lawyer in Reno, Nevada. If this number is seen by a gateway > (and, to a lesser extent, put on a web page), rather unexpected things > could happen. > > Solution: Provide context so that the gateway, which usually knows > which area code it is in, can decide whether this is valid or not (or > a SIP proxy can route the request to a gateway where it is valid). > > I wonder if anybody has seen a real example of such numbers. > > Like all local numbers, one can't avoid certain problems. If a user in > Nevada clicks on "Divorces" (NV only), but the call is actually handed > to a gateway in Pennsylvania, you will get the PA version of the > number, unless the context hints that this number should not be used > there. > > 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.) > > Please let me know if I missed any aspect of this discussion or if you > disagree with the conclusion. > > 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 Sat Nov 30 13:37: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 NAA09850 for ; Sat, 30 Nov 2002 13:37:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAUIdVD17398 for iptel-archive@odin.ietf.org; Sat, 30 Nov 2002 13:39: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 gAUIdVv17395 for ; Sat, 30 Nov 2002 13:39: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 NAA09801 for ; Sat, 30 Nov 2002 13:36: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 gAUId2v17369; Sat, 30 Nov 2002 13:39: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 gAUIcBv17349 for ; Sat, 30 Nov 2002 13:38:11 -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 NAA09795 for ; Sat, 30 Nov 2002 13: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 gAUIc6l8002888 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 30 Nov 2002 13: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 gAUIc5dG006279 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 30 Nov 2002 13:38:06 -0500 (EST) Message-ID: <3DE905EB.3070900@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] Another wrinkle: 700 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: Sat, 30 Nov 2002 13:39:39 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 From mailnull@www1.ietf.org Sat Nov 30 13:49: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 NAA10149 for ; Sat, 30 Nov 2002 13:49:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAUIqAh17791 for iptel-archive@odin.ietf.org; Sat, 30 Nov 2002 13:52: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 gAUIq9v17788 for ; Sat, 30 Nov 2002 13:52: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 NAA10146 for ; Sat, 30 Nov 2002 13:49: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 gAUIp5v17774; Sat, 30 Nov 2002 13:51: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 gAUIoXv17742 for ; Sat, 30 Nov 2002 13:50:33 -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 NAA10128 for ; Sat, 30 Nov 2002 13:47:42 -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 gAUIoPl8004609 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 30 Nov 2002 13:50: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 gAUIoOdG007019 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 30 Nov 2002 13:50:25 -0500 (EST) Message-ID: <3DE908CD.5050902@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: Rohan Mahy CC: iptel@ietf.org Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion References: <6DF23460-0491-11D7-9AE1-0003938AF740@cisco.com> In-Reply-To: <6DF23460-0491-11D7-9AE1-0003938AF740@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: Sat, 30 Nov 2002 13:51:57 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree. I had indeed considered 1-800-LAWYER as an example of the PizzaHut variety, even if my grouping of cases did not make this very clear. Are you asking NANPA? Rohan Mahy wrote: > Henning, > > 1-800-DIENTES or 1-800-LAWYER still qualify as a single organization > (the referring agency/coorperative/whatever). Also, nobody has > demonstrated concretely that any number exists which is orthogonally > reused (your Nevada divorce/Pennsylvania wedding example). I expect > that we can get a definitive answer from NANPA fairly quickly. 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. > > thanks, > -rohan > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Sat Nov 30 14:55: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 OAA11108 for ; Sat, 30 Nov 2002 14:55:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAUJw9Z19975 for iptel-archive@odin.ietf.org; Sat, 30 Nov 2002 14:58: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 gAUJw8v19972 for ; Sat, 30 Nov 2002 14:58: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 OAA11103 for ; Sat, 30 Nov 2002 14:55: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 gAUJu6v19918; Sat, 30 Nov 2002 14:56: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 gAUJtZv19895 for ; Sat, 30 Nov 2002 14:55:35 -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 OAA11076 for ; Sat, 30 Nov 2002 14:52:43 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gAUJsNn6022405; Sat, 30 Nov 2002 14:54:23 -0500 (EST) From: Scott Bradner Message-Id: <200211301954.gAUJsNn6022405@newdev.harvard.edu> To: hgs@cs.columbia.edu, rohan@cisco.com Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion Cc: iptel@ietf.org In-Reply-To: <6DF23460-0491-11D7-9AE1-0003938AF740@cisco.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: Sat, 30 Nov 2002 14:54:23 -0500 (EST) > 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 From mailnull@www1.ietf.org Sat Nov 30 15:07:32 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 PAA11270 for ; Sat, 30 Nov 2002 15:07:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAUK9rm20816 for iptel-archive@odin.ietf.org; Sat, 30 Nov 2002 15:09:53 -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 gAUK9rv20813 for ; Sat, 30 Nov 2002 15:09:53 -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 PAA11242 for ; Sat, 30 Nov 2002 15:07:01 -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 gAUK93v20799; Sat, 30 Nov 2002 15:09: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 gAUK80v20776 for ; Sat, 30 Nov 2002 15:08:00 -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 PAA11229 for ; Sat, 30 Nov 2002 15:05:08 -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 gAUK7nl8009590 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 30 Nov 2002 15:07:49 -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 gAUK7ldG012613 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 30 Nov 2002 15:07:48 -0500 (EST) Message-ID: <3DE91AF0.6050209@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: rohan@cisco.com, iptel@ietf.org Subject: Re: [Iptel] Summary of +1-800 for tel URI discussion References: <200211301954.gAUJsNn6022405@newdev.harvard.edu> 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: Sat, 30 Nov 2002 15:09:20 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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