From mailnull@www1.ietf.org Thu May 1 03:47:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01419 for ; Thu, 1 May 2003 03:47:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h417rc531908 for iptel-archive@odin.ietf.org; Thu, 1 May 2003 03:53:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h417rb831905 for ; Thu, 1 May 2003 03:53:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01386 for ; Thu, 1 May 2003 03:47:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8ok-00076o-00 for iptel-web-archive@ietf.org; Thu, 01 May 2003 03:49:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B8ok-00076j-00 for iptel-web-archive@ietf.org; Thu, 01 May 2003 03:49:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h417rA831868; Thu, 1 May 2003 03:53:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h417hM831461 for ; Thu, 1 May 2003 03:43:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01191 for ; Thu, 1 May 2003 03:36:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8ek-00073a-00 for iptel@ietf.org; Thu, 01 May 2003 03:39:02 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19B8ee-000736-00 for iptel@ietf.org; Thu, 01 May 2003 03:38:56 -0400 Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h417cjdh004812; Thu, 1 May 2003 03:38:46 -0400 (EDT) Message-ID: <3EB0A03F.5040405@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dhaval N. Shah" CC: "Vijay K. Gurbani" , manjax@cisco.com, rajneesh@cisco.com, hsalama@cisco.com, iptel@ietf.org Subject: Re: [Iptel] Review of TGREP -01 References: <4.3.2.7.2.20030417145612.02f66750@mira-sjc5-5.cisco.com> In-Reply-To: <4.3.2.7.2.20030417145612.02f66750@mira-sjc5-5.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: Thu, 01 May 2003 00:19:11 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dhaval N. Shah wrote: > > ###dhaval: Section 4 covers this but thanks for pointing out since > I noticed a reference error from Section 4 (it should be pointing to > sections > 3.1, 3.2 etc. versus 4.1, 4.2 etc.) > >> address families being discussed in the I-D have presumably been >> send to IANA and are in the processing queue. > > > ###dhaval: Haven't sent anything to IANA yet. Jonathan, could you guide > us on this? These new attributes will be registered under the existing TRIP registries. Based on the IANA procedures in RFC 3219, this requires a standards track RFC. So, tgrep has to have an IANA section which provides the registration information as required in rfc3219. When the RFC is published, IANA will create the entries in the registry as part of the process. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From extest-admin@lists.bell-labs.com Thu May 1 06:32:29 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04798 for ; Thu, 1 May 2003 06:32:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h41AZaR14203 for ; Thu, 1 May 2003 06:35:36 -0400 Date: Thu, 1 May 2003 06:35:36 -0400 Message-Id: <200305011035.h41AZaR14203@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 Thu May 1 11:38:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17718 for ; Thu, 1 May 2003 11:38:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41FihM28561 for iptel-archive@odin.ietf.org; Thu, 1 May 2003 11:44:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Fih828558 for ; Thu, 1 May 2003 11:44:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17691 for ; Thu, 1 May 2003 11:38:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGAU-0002uJ-00 for iptel-web-archive@ietf.org; Thu, 01 May 2003 11:40:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BGAU-0002u7-00 for iptel-web-archive@ietf.org; Thu, 01 May 2003 11:40:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FiI828505; Thu, 1 May 2003 11:44:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FhA828111 for ; Thu, 1 May 2003 11:43:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17365 for ; Thu, 1 May 2003 11:32:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BG53-0002oU-00 for iptel@ietf.org; Thu, 01 May 2003 11:34:41 -0400 Received: from mail1.acmepacket.com ([63.67.143.10] helo=acmepacket.com) by ietf-mx with esmtp (Exim 4.12) id 19BG4x-0002oO-00 for iptel@ietf.org; Thu, 01 May 2003 11:34:35 -0400 Received: from RPORTER [63.67.143.2] by acmepacket.com (SMTPD32-7.14) id AE9537F20272; Thu, 01 May 2003 11:34:45 -0400 Message-ID: <011501c30ff7$e097a840$2a00000a@RPORTER> From: "Rick W. Porter" To: "IPTEL" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01C30FD6.59723220" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Iptel] comments on draft-ietf-iptel-tgrep-01 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, 1 May 2003 11:39:39 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_0112_01C30FD6.59723220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 Sections 3.9 and 3.9.6 seem to conflict regarding the need for a call = routing database on the gateway. I believe that 3.9 should talk about a = limited call routing database, since a GW won't need many of the TRIBs. = However, 3.9.6 makes a pretty good case for needing Adj-TRIB-GW-Out's. I = do not understand how the number of TRIP LSs would change the need for = an Adj-TRIP-GW-Out per TRIP LS. Please correct me if I'm missing = something. Thanks, Rick ------=_NextPart_000_0112_01C30FD6.59723220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Sections 3.9 and 3.9.6 seem to conflict = regarding=20 the need for a call routing database on the gateway. I believe = that=20 3.9 should talk about a limited call routing database, since a GW won't = need=20 many of the TRIBs.  However, 3.9.6 makes a pretty good case for = needing=20 Adj-TRIB-GW-Out's. I do not understand how the number of TRIP LSs would = change=20 the need for an Adj-TRIP-GW-Out per TRIP LS.  Please correct me if = I'm=20 missing something.
 
Thanks,
Rick
 
 
------=_NextPart_000_0112_01C30FD6.59723220-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri May 2 15:28:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28716 for ; Fri, 2 May 2003 15:28:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42JYsN19866 for iptel-archive@odin.ietf.org; Fri, 2 May 2003 15:34:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42JYs819863 for ; Fri, 2 May 2003 15:34:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28673 for ; Fri, 2 May 2003 15:27:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BgEE-00073L-00 for iptel-web-archive@ietf.org; Fri, 02 May 2003 15:29:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BgED-00073C-00 for iptel-web-archive@ietf.org; Fri, 02 May 2003 15:29:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42JYF819804; Fri, 2 May 2003 15:34:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42JXg819729 for ; Fri, 2 May 2003 15:33:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28477 for ; Fri, 2 May 2003 15:24:53 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BgBT-0006zi-00 for iptel@ietf.org; Fri, 02 May 2003 15:27:03 -0400 Received: from imo-m04.mx.aol.com ([64.12.136.7]) by ietf-mx with esmtp (Exim 4.12) id 19BgBE-0006zL-00 for iptel@ietf.org; Fri, 02 May 2003 15:26:48 -0400 Received: from Mpierce1@aol.com by imo-m04.mx.aol.com (mail_out_v34.22.) id l.1d2.8cc3094 (4446) for ; Fri, 2 May 2003 15:26:23 -0400 (EDT) Message-ID: <1d2.8cc3094.2be4205f@aol.com> To: iptel@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1d2.8cc3094.2be4205f_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Subject: [Iptel] Comments on 2806bis-08 (tel:uri) Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 2 May 2003 15:26:23 EDT --part1_1d2.8cc3094.2be4205f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I believe there is one major issue remaining unresolved in this draft concerning the representation of "service codes" with a context. "Service codes" in this sense must include every dialable string which is not part of an E.164 number nor part of a local dial plan within a unique context such as a PBX. Most discussion has focused on numbers such as 911 in the US and various emergency numbers around the world. However, there are many other numbers that might fit in this category that need to be coded into the tel:uri in this manner, including "0" and various #xx and *xx codes. As presented in San Francisco and stated in the draft, the intention of the tel:uri is that the combination of the local number and the context becomes globally unique. The representation of an E.164 number and the representation of a local number with a unique context certainly achieves this. However, the representation of a service code, such as 911, with a context that simply identifies the country, does not provide a "unique" identification. While 911 means "route to the emergency center" in (most of) the US, it means completely different destinations depending on where dialed. Many other such service codes, such as 811, are not even standard across the US, so, while it might mean "route to telephone company business office" in many places, it could mean something completely different in other areas or within another local exchange carrier's network in the same area. This is especially confusing, since the leading "+" is defined in 5.1.3 as being the leading character of a globally unique number, which "Must be comprised with the country code and national [significant] numbers as specified in E.164". Confusion is also caused by attempting to consider such "service codes" as "local numbers". Since these "service codes" are not part of the E.164 plan and are generally only meaningful in relation to the physical location of the dialer (or their perceived service point), it would never be correct to code them with something that comes from the E.164 dial plan, that is, the country code. In fact, the only thing that would make the representation unique and truely meaningfull would be an identification of the actual location, but that is clearly beyond the intention (or possibility) of the tel:uri. In order to resolve this dilemma, it appears that the only solution is to provide an explicit way to indicate that the string of digits included in "local-number" has no known context, for example, by including: "phone-context = none" I suspect that simply leaving out the phone-context in this case would not be a good idea. I would code this as: subscriber = global-number / local-number / service-code service-code = local-number-digits *par "phone-context = none" *par Mike Pierce --part1_1d2.8cc3094.2be4205f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I believe there is one ma= jor issue remaining unresolved in this draft concerning the representation o= f "service codes" with a context.

"Service codes" in this sense must include every dialable string which i= s not part of an E.164 number nor part of a local dial plan within a unique=20= context such as a PBX. Most discussion has focused on numbers such as 911 in= the US and various emergency numbers around the world. However, there are m= any other numbers that might fit in this category that need to be coded into= the tel:uri in this manner, including "0" and various #xx and *xx codes.

As presented in San Francisco and stated in the draft, the intention of=20= the tel:uri is that the combination of the local number and the context beco= mes globally unique. The representation of an E.164 number and the represent= ation of a local number with a unique context certainly achieves this. Howev= er, the representation of a service code, such as 911, with a context that s= imply identifies the country, does not provide a "unique" identification. Wh= ile 911 means "route to the emergency center" in (most of) the US, it means=20= completely different destinations depending on where dialed. Many other such= service codes, such as 811, are not even standard across the US, so, while=20= it might mean "route to telephone company business office" in many places, i= t could mean something completely different in other areas or within another= local exchange carrier's network in the same area.

This is especially confusing, since the leading "+" is defined in 5.1.3=20= as being the leading character of a globally unique number, which "Must be c= omprised with the country code and national [significant] numbers as specifi= ed in E.164". Confusion is also caused by attempting to consider such "servi= ce codes" as "local numbers".

Since these "service codes" are not part of the E.164 plan and are gener= ally only meaningful in relation to the physical location of the dialer (or=20= their perceived service point), it would never be correct to code them with=20= something that comes from the E.164 dial plan, that is, the country code. In= fact, the only thing that would make the representation unique and truely m= eaningfull would be an identification of the actual location, but that is cl= early beyond the intention (or possibility) of the tel:uri.

In order to resolve this dilemma, it appears that the only solution is t= o provide an explicit way to indicate that the string of digits included in=20= "local-number" has no known context, for example, by including:

"phone-context =3D none"

I suspect that simply leaving out the phone-context in this case would n= ot be a good idea.

I would code this as:

subscriber =3D global-number / local-number / service-code
service-code =3D local-number-digits *par "phone-context =3D none" *par

Mike Pierce
--part1_1d2.8cc3094.2be4205f_boundary-- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri May 2 15:57:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00015 for ; Fri, 2 May 2003 15:57:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42K4UF22214 for iptel-archive@odin.ietf.org; Fri, 2 May 2003 16:04:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42K4U822211 for ; Fri, 2 May 2003 16:04:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29999 for ; Fri, 2 May 2003 15:57:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bggr-0007Mz-00 for iptel-web-archive@ietf.org; Fri, 02 May 2003 15:59:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Bggr-0007Mw-00 for iptel-web-archive@ietf.org; Fri, 02 May 2003 15:59:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42K47822200; Fri, 2 May 2003 16:04:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42K3V822177 for ; Fri, 2 May 2003 16:03:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29934 for ; Fri, 2 May 2003 15:56:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bgff-0007L2-00 for iptel@ietf.org; Fri, 02 May 2003 15:58:15 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19BgfT-0007Kl-00 for iptel@ietf.org; Fri, 02 May 2003 15:58:04 -0400 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h42JwBjS006664 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 2 May 2003 15:58:12 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h42JwBcE026323; Fri, 2 May 2003 15:58:11 -0400 (EDT) Message-ID: <3EB2CDB0.10107@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: iptel@ietf.org Subject: Re: [Iptel] Comments on 2806bis-08 (tel:uri) References: <1d2.8cc3094.2be4205f@aol.com> In-Reply-To: <1d2.8cc3094.2be4205f@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 May 2003 15:57:36 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Comments inline. Mpierce1@aol.com wrote: > 911, with a context that simply identifies the country, does not provide > a "unique" identification. While 911 means "route to the emergency > center" in (most of) the US, it means completely different destinations > depending on where dialed. Many other such service codes, such as 811, 911 and 811 are very different in this context. 911 is *logically* the same wherever it is dialed within +1. This is no different than dialing some 800# for a chain store and being connected to the local branch, based on the calling number. (We had this discussion before the last meeting, I believe.) Thus, the problem exists only for numbers that indeed mean something different depending on where the call is being placed. As discussed in the 800# context, it does *not* matter if the number is not universally reachable (many 800# are only reachable within a certain geographic area). Thus, the only case that's left is the case where some number means "road service" in CA and "phone repair" in NY. I don't know whether 811 falls into this category; according to http://www.nanpa.com/number_resource_info/n11_codes.html, 811 seems to have a well-recognized meaning ('business office'), but is not FCC-recognized. Beyond the N11 numbers and the various *99=highway patrol numbers, there are also vertical service codes (http://www.nanpa.com/number_resource_info/vertical_service.html). Examples include *66 and *72. These aren't really identifiers for telephone subscribers, so my inclination would be to explicitly declare them out of scope. I can see no useful application in the context of a URN such as the tel: schema. Thus, after winnowing down 'service codes' to the subclass of "numbers that identify subscribers/PSTN endpoints and mean different things in different places", Mike's concern remains. > Since these "service codes" are not part of the E.164 plan and are > generally only meaningful in relation to the physical location of the > dialer (or their perceived service point), it would never be correct to > code them with something that comes from the E.164 dial plan, that is, > the country code. In fact, the only thing that would make the > representation unique and truely meaningfull would be an identification > of the actual location, but that is clearly beyond the intention (or > possibility) of the tel:uri. I disagree. This only has to be precise enough to avoid misunderstandings. Thus, tagging this with ones own phone number, for example, would be sufficient. > > In order to resolve this dilemma, it appears that the only solution is > to provide an explicit way to indicate that the string of digits > included in "local-number" has no known context, for example, by including: > > "phone-context = none" > > I suspect that simply leaving out the phone-context in this case would > not be a good idea. I don't like this idea since it removes the uniqueness property which is central to tel URIs and their URNness. If the unique identifier can't be made to work (I believe it can), I would much rather tell people that they should not use tel: for service numbers of the small class described above and then use something like sip:*77@mygateway.com which is unambiguous, since it means "direct call to whatever *77 means for the carrier mygateway.com". Henning _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Fri May 9 23:44:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10977 for ; Fri, 9 May 2003 23:44:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4A3smA08716 for iptel-archive@odin.ietf.org; Fri, 9 May 2003 23:54:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4A3sl808713 for ; Fri, 9 May 2003 23:54:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10974 for ; Fri, 9 May 2003 23:44:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ELJD-0001aU-00 for iptel-web-archive@ietf.org; Fri, 09 May 2003 23:46:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ELJC-0001aQ-00 for iptel-web-archive@ietf.org; Fri, 09 May 2003 23:46:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4A3sE808668; Fri, 9 May 2003 23:54:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4A3rg808606 for ; Fri, 9 May 2003 23:53:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10903 for ; Fri, 9 May 2003 23:42:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ELIA-0001ZY-00 for iptel@ietf.org; Fri, 09 May 2003 23:44:58 -0400 Received: from [63.101.52.22] (helo=apollo.taqua.com) by ietf-mx with esmtp (Exim 4.12) id 19ELI9-0001ZV-00 for iptel@ietf.org; Fri, 09 May 2003 23:44:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Iptel] Comments on 2806bis-08 (tel:uri) Message-ID: Thread-Topic: [Iptel] Comments on 2806bis-08 (tel:uri) Thread-Index: AcMQ5voqk+i12VMIR5O6n191cxdkgwFvwhtg From: "Bender, Andrew" To: "Henning Schulzrinne" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4A3rg808607 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, 9 May 2003 23:46:04 -0400 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, May 02, 2003 3:58 PM > To: Mpierce1@aol.com > Cc: iptel@ietf.org > Subject: Re: [Iptel] Comments on 2806bis-08 (tel:uri) > > Beyond the N11 numbers and the various *99=highway patrol numbers, > there are also vertical service codes > (http://www.nanpa.com/number_resource_info/vertical_service.html). > Examples include *66 and *72. These aren't really identifiers for > telephone subscribers, so my inclination would be to explicitly > declare them out of scope. I can see no useful application in the > context of a URN such as the tel: schema. Thus you make handling of vertical service codes by events or in-band compulsory vs using the URI? Is this the intention? Is this unnecessarily limiting? Regards, Andrew Bender taqua.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Sat May 10 08:52:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00374 for ; Sat, 10 May 2003 08:52:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4AD2p421281 for iptel-archive@odin.ietf.org; Sat, 10 May 2003 09:02:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4AD2p821278 for ; Sat, 10 May 2003 09:02:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00370 for ; Sat, 10 May 2003 08:51:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ETrQ-0003zI-00 for iptel-web-archive@ietf.org; Sat, 10 May 2003 08:53:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ETrP-0003zF-00 for iptel-web-archive@ietf.org; Sat, 10 May 2003 08:53:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4AD2X821254; Sat, 10 May 2003 09:02:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4AD1d821225 for ; Sat, 10 May 2003 09:01:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00355 for ; Sat, 10 May 2003 08:50:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ETqF-0003yp-00 for iptel@ietf.org; Sat, 10 May 2003 08:52:43 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19ETqE-0003ym-00 for iptel@ietf.org; Sat, 10 May 2003 08:52:42 -0400 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h4ACrejS015652 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 10 May 2003 08:53:41 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h4ACrctn005998; Sat, 10 May 2003 08:53:38 -0400 (EDT) Message-ID: <3EBCF581.4040509@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bender, Andrew" CC: Mpierce1@aol.com, iptel@ietf.org Subject: Re: [Iptel] Comments on 2806bis-08 (tel:uri) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 May 2003 08:50:09 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Thus you make handling of vertical service codes by events or in-band > compulsory vs using the URI? Is this the intention? Is this > unnecessarily limiting? I think there are four possibilities: 1) Declare *XX out of scope for now; we can add this later once we figure out a clean way to do this and there has been a demonstrated need. I think this can be justified if *XX can be consistently treated as identifying a logical endpoint and is a call endpoint. I don't use these rip-off codes much, but they seem to come in two flavors: one just does something (changes setting), but there is no call to anywhere. The other kind invokes some kind of IVR-based service that prompts for information or delivers information. *51 (Who Called Me?) may be an example. 2) Declare it out of scope since they don't fit the 2806 URN-like model of identifiers of telephone end system. Instead, KPML, 2833, SIP URIs or similar mechanisms should be used, just like any other in-band service invocation (aka DTMF). After all, once we start adding *XX, there is no logical reason not to add other DTMF service sequences, e.g., voice mail sequences. (For SIP URIs, there is no doubt as to who should do what and this fits pretty well with the model of special user-name parts of SIP URIs that invoke services.) 3) Ignore the conceptual problems and treat them as local numbers, with a context. 4) Define a new URI that explicitly deals with dial strings. I think such a URI is a bad idea (we don't have URIs that encode telnet sequences of characters, either), but others may consider this attractive. My preference is (2), but I'd welcome feedback. I would prefer that this debate not delay progress indefinitely. > > Regards, Andrew Bender taqua.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From mailnull@www1.ietf.org Tue May 13 09:33:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11588 for ; Tue, 13 May 2003 09:33:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DCxsg21864 for iptel-archive@odin.ietf.org; Tue, 13 May 2003 08:59:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DCxsB21861 for ; Tue, 13 May 2003 08:59:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11545 for ; Tue, 13 May 2003 09:33:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FZw6-0003yN-00 for iptel-web-archive@ietf.org; Tue, 13 May 2003 09:35:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FZw5-0003yJ-00 for iptel-web-archive@ietf.org; Tue, 13 May 2003 09:35:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DCxTB21816; Tue, 13 May 2003 08:59:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DClFB21005 for ; Tue, 13 May 2003 08:47:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10974 for ; Tue, 13 May 2003 09:20:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FZjr-0003oD-00 for iptel@ietf.org; Tue, 13 May 2003 09:22:39 -0400 Received: from mail1.acmepacket.com ([63.67.143.10] helo=acmepacket.com) by ietf-mx with esmtp (Exim 4.12) id 19FZjr-0003oA-00 for iptel@ietf.org; Tue, 13 May 2003 09:22:39 -0400 Received: from BPenfield [127.0.0.1] by acmepacket.com (SMTPD32-8.00) id A1E0464012E; Tue, 13 May 2003 09:23:44 -0400 Message-ID: <003e01c31952$dec019d0$2300000a@BPenfield> From: "Bob Penfield" To: 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.2727.1300 Content-Transfer-Encoding: 7bit Subject: [Iptel] comments on draft-ietf-iptel-tgrep-01.txt Sender: iptel-admin@ietf.org Errors-To: iptel-admin@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Telephony List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 May 2003 09:23:40 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I apologize for lateness of these comments and for any duplicates. In general, The relationships and differences between TRIP and TGREP are too vague. This spec does contain protocol procedures and requirements for TRIP as well as for TGREP since it introduces new attributes and address families that can be used in TRIP. I recommend presenting the overall architecture in the introduction and clearly defining the elements of the model (LS, TGREP Speaker/Gateway, TGREP Receiver, etc.) and use those terms consistently throughout the spec so that it is clear which requirements apply to which elements. For example, when it talks about originating and disseminating attributes, it should be clear who is allowed to do what. Section 3.2: The "MUST NOT" is a duplicate of the requirement in section 3.2.5. Remove "unless the LS is sure...", MUST NOT means NEVER. If you want to emphasize the fact that the attribute is not propagated, I suggest text along the lines of "When the AvailableCircuits attribute is received in a route, it is not propagated (see section 3.2.5)". Section 3.3: The "MUST NOT be propagated" duplicates the requirement in section 3.3.5 (see 3.2 comment above). Section 3.3.1: suggest adding "within some window of time" (or words to that affect to "...represents total number of attempted calls...". Section 3.3.5: remove "in most cases" since the MUST NOT makes it unsuitable in all cases. Section 3.4.5: change ".. this attribute should disseminate.." to ".. this attribute SHOULD disseminate ...". Section 3.6: change "... that the gateway can complete calls to" to "... that the gateway uses to complete calls". The carrier is a transport, not a destination. Section 3.6.1: The carrier length should be variable. The carrier is usually derived from dialed digits, thus deployments will likely use the carrier codes used in dialing as TGREP carriers to avoid the additional overhead of mapping dialed carrier codes to TGREP carrier codes. The US uses 5-digit carrier codes in dialing (e.g. 10288 for AT&T as in 1010288). Is it to be assumed that for country code of less than three digits that the 3-octet country-code is padded with NULL bytes? Section 3.7.1: page 15: The syntax of the Carrier Address Family should match the syntax of the Carrier Attribute. Section 3.9: change "A gateway uses TRIP" to "A gateway uses TGREP". Section 4: The fact that TRIP and TGREP should share the IANA registry for capabilities, attributes, address families, and protocols needs to be clearly specified. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon May 19 10:23:43 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22919 for ; Mon, 19 May 2003 10:23:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h4JDv3R00990; Mon, 19 May 2003 09:57:03 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h4JDe6R00769 for ; Mon, 19 May 2003 09:40:06 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h4JDdoHa045557 for ; Mon, 19 May 2003 09:39:50 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 8970F443A4; Mon, 19 May 2003 09:39:41 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 52797443A7 for ; Mon, 19 May 2003 09:39:41 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h4JDdbc6071758 for ; Mon, 19 May 2003 09:39:37 -0400 (EDT) Received: from relay2.clb.oleane.net (relay2.clb.oleane.net [213.56.31.22]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h4JDbdEQ029714 for ; Mon, 19 May 2003 09:37:41 -0400 (EDT) Received: from oleane ([194.250.212.114]) by relay2.clb.oleane.net with SMTP id h4JDdMl4003524 for ; Mon, 19 May 2003 15:39:22 +0200 Message-ID: <10b201c31e0c$99c6f6a0$0601a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_10AF_01C31E1D.5D1D6C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [IPTEL] International SIP 2004 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, 19 May 2003 15:43:16 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_10AF_01C31E1D.5D1D6C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable International SIP 2004, January 20-23, Paris France After a setback in 2002 over 2001, explained by the difficult economic = context plaguing the telecom industry, International SIP 2003 clearly = recaptured the interest of the VoIP community.=20 Don't miss the 2004 edition. The call for papers dead line has been extendeed to June 15. Please get all details at: http://www.upperside.fr/sip2004/sip2004cfp.htm ------=_NextPart_000_10AF_01C31E1D.5D1D6C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
International SIP 2004, January 20-23, = Paris=20 France
 
After a setback in 2002 over 2001, = explained by the=20 difficult economic context plaguing the telecom industry, International = SIP 2003=20 clearly recaptured the interest of the VoIP community.
Don't miss = the 2004=20 edition.
 
The call for papers dead line has been = extendeed to=20 June 15.
Please get all details at:
http://www.uppers= ide.fr/sip2004/sip2004cfp.htm
 
 
------=_NextPart_000_10AF_01C31E1D.5D1D6C00-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From mailnull@www1.ietf.org Mon May 19 13:03:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27322 for ; Mon, 19 May 2003 13:03:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JGWcp32530 for iptel-archive@odin.ietf.org; Mon, 19 May 2003 12:32:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JGWcB32527 for ; Mon, 19 May 2003 12:32:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27305 for ; Mon, 19 May 2003 13:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ho4F-00053C-00 for iptel-web-archive@ietf.org; Mon, 19 May 2003 13:04:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ho4E-000538-00 for iptel-web-archive@ietf.org; Mon, 19 May 2003 13:04:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JGWBB32498; Mon, 19 May 2003 12:32:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JGVKB32466 for ; Mon, 19 May 2003 12:31:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27275 for ; Mon, 19 May 2003 13:01:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ho2z-00052X-00 for iptel@ietf.org; Mon, 19 May 2003 13:03:37 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Ho2t-00052F-00 for iptel@ietf.org; Mon, 19 May 2003 13:03:31 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4JH3kdh014466 for ; Mon, 19 May 2003 13:03:47 -0400 (EDT) Message-ID: <3EC90E6E.9010002@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: list iptel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Iptel] work item on relationship of enum/trip/sip 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, 19 May 2003 13:03:42 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, During the IESG/IAB review of our up to date charter, one of the issues that came up was the relationship of trip and tgrep to enum and some of the SIP DNS procedures. It was clear from the resulting discussion that this was more than just a charter text issue. Rather, an informational document is really needed that puts these things together and explains their relationship. We have had drafts submitted in the past which have covered similar territory. For example: http://www.watersprings.org/pub/id/draft-ymbk-enum-trip-00.txt So, some questions for the group: 1. would you be interested in such a document being produced? 2. would you be interested in actively contributing to such a document - that means authoring text, editing, reviewing, etc? Please respond either to cullen or myself, or to the list, within the next week. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel