From iptel-bounces@ietf.org Fri Apr 1 17:14:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27307 for ; Fri, 1 Apr 2005 17:14:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHUWd-0001kd-DB for iptel-web-archive@ietf.org; Fri, 01 Apr 2005 17:21:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHUNr-0008TA-Fo; Fri, 01 Apr 2005 17:12:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHUNo-0008T2-VH for iptel@megatron.ietf.org; Fri, 01 Apr 2005 17:12:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27211 for ; Fri, 1 Apr 2005 17:12:50 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHUVD-0001fn-3q for iptel@ietf.org; Fri, 01 Apr 2005 17:20:32 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j31MATKD027012; Fri, 1 Apr 2005 22:10:29 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 17:10:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Apr 2005 17:10:28 -0500 Message-ID: <165FCC93A820D240A62F98E028CEFED001451178@stntexch01.cis.neustar.com> Thread-Topic: Scope of *rn* parameter in the context of LNP Thread-Index: AcU1SfirsyuAG88xSuaHFAznr/QTdgAAHVdgAG77uOA= From: "Yu, James" To: X-OriginalArrivalTime: 01 Apr 2005 22:10:29.0617 (UTC) FILETIME=[9D78DE10:01C53707] X-Spam-Score: 1.0 (+) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: iptel@ietf.org, Gonzalo.Camarillo@Ericsson.com, "Peterson, Jon" Subject: [Iptel] RE: Scope of *rn* parameter in the context of LNP X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0793476255==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e This is a multi-part message in MIME format. --===============0793476255== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53707.9CAD7C26" This is a multi-part message in MIME format. ------_=_NextPart_001_01C53707.9CAD7C26 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chelliah, =20 I checked RFC3398. Yes, you detected an inconsistency between RFC3398 = and my I-D. =20 RFC3398 references my I-D that is not yet a RFC. My current I-D does = not use "npdi=3Dyes" (just "npdi") and the "rn" is either a global-rn = (global routing number) or local-rn (e.g., national number with +1 in = the rn-context). =20 RFC3398 needs to be corrected. =20 James -----Original Message----- From: Chelliah Sivachelvan (chelliah) [mailto:chelliah@cisco.com] Sent: Wednesday, March 30, 2005 12:05 PM To: chelliah@cisco.com; Yu, James Cc: iptel@ietf.org; Gonzalo.Camarillo@Ericsson.com; Peterson, Jon Subject: RE: Scope of *rn* parameter in the context of LNP Correction: The referenced RFC is 3398 not 3388. =20 Thanks! Chella _____ =20 From: Chelliah Sivachelvan (chelliah) [mailto:chelliah@cisco.com]=20 Sent: Wednesday, March 30, 2005 11:00 AM To: 'james.yu@neustar.biz' Cc: 'iptel@ietf.org'; 'Gonzalo.Camarillo@Ericsson.com'; = 'jon.peterson@neustar.biz' Subject: Scope of *rn* parameter in the context of LNP James: The current draft (draft-ietf-iptel-tel-np-04.txt) implies that the *rn* = parameter can contain global numbers (i.e., E.164 numbers) in the = context of LNP. This has also been illustrated in one of the examples in = section 6(c).=20 =20 But the scope of LNP is national; as such the scope of routing number = (LRN) is not a globally reachable number. Therefore, it must be treated = as a national number. RFC-3388 also makes a strong statement on this = very subject. Here is the excerpts from RFC-3388 (section 8.2.1.1 )=20 =20 "LRNs are necessarily national in scope, and consequently they MUST = NOT be preceded by a '+' in the 'rn=3D' field." =20 =20 We need to resolve the discrepancies between the two specs. =20 =20 Thanks! Chella =20 =20 Cisco Systems, 2200 East President George Bush Turnpike , Richardson, TX 75082 Tel: 469.255.1169 =20 ------_=_NextPart_001_01C53707.9CAD7C26 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Chelliah,
 
I=20 checked RFC3398.   Yes, you detected an inconsistency between = RFC3398=20 and my I-D.
 
RFC3398 references my I-D that is not yet a = RFC.   My=20 current I-D does not use "npdi=3Dyes" (just "npdi") and the "rn" is = either a=20 global-rn (global routing number)  or local-rn (e.g., national = number=20 with +1 in the rn-context).
 
RFC3398 needs to be corrected.
 
James
-----Original Message-----
From: Chelliah = Sivachelvan=20 (chelliah) [mailto:chelliah@cisco.com]
Sent: Wednesday, = March 30,=20 2005 12:05 PM
To: chelliah@cisco.com; Yu, = James
Cc:=20 iptel@ietf.org; Gonzalo.Camarillo@Ericsson.com; Peterson,=20 Jon
Subject: RE: Scope of *rn* parameter in the context of=20 LNP

Correction: The referenced RFC is 3398 not=20 3388.
 
Thanks!
Chella

From: Chelliah Sivachelvan = (chelliah)=20 [mailto:chelliah@cisco.com]
Sent: Wednesday, March 30, 2005 = 11:00=20 AM
To: 'james.yu@neustar.biz'
Cc: = 'iptel@ietf.org';=20 'Gonzalo.Camarillo@Ericsson.com';=20 'jon.peterson@neustar.biz'
Subject: Scope of *rn* parameter = in the=20 context of LNP

James:
The current=20 draft (draft-ietf-iptel-tel-np-04.txt) implies that the *rn*=20 parameter can contain global numbers (i.e., E.164 = numbers) in the=20 context of LNP. This has also been illustrated in one of the examples = in=20 section 6(c). 
 
But the scope of LNP is national; as such the scope = of routing=20 number (LRN) is not a globally reachable number. Therefore, it = must be=20 treated as a national number. RFC-3388 also makes a strong statement = on this=20 very subject. Here is the excerpts from RFC-3388 (section=20 8.2.1.1 )
 
  =20 "LRNs are necessarily national in scope, and = consequently they=20 MUST NOT be preceded by a '+' in the 'rn=3D'=20 field."
 
 
We need to resolve the discrepancies = between the two=20 specs.
 
  
Thanks!
Chella
           &n= bsp;=20
 
Cisco = Systems,
2200 East=20 President George Bush Turnpike ,
Richardson, TX 75082
Tel: 469.255.1169
 
------_=_NextPart_001_01C53707.9CAD7C26-- --===============0793476255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0793476255==-- From iptel-bounces@ietf.org Sat Apr 2 16:26:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27641 for ; Sat, 2 Apr 2005 16:26:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHqFp-0005Ym-UI for iptel-web-archive@ietf.org; Sat, 02 Apr 2005 16:34:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHq6i-0001Iu-AV; Sat, 02 Apr 2005 16:24:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHq6h-0001Ip-Gg for iptel@megatron.ietf.org; Sat, 02 Apr 2005 16:24:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27580 for ; Sat, 2 Apr 2005 16:24:36 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHqEI-0005TH-Q6 for iptel@ietf.org; Sat, 02 Apr 2005 16:32:31 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j32LOMKD029340; Sat, 2 Apr 2005 21:24:22 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 2 Apr 2005 16:24:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 2 Apr 2005 16:24:21 -0500 Message-ID: <165FCC93A820D240A62F98E028CEFED00145117C@stntexch01.cis.neustar.com> Thread-Topic: Scope of *rn* parameter in the context of LNP Thread-Index: AcU3TPGKqW6gNtWyQq2iPkKls60DiAAfWSQZ From: "Yu, James" To: X-OriginalArrivalTime: 02 Apr 2005 21:24:22.0679 (UTC) FILETIME=[56A96270:01C537CA] X-Spam-Score: 1.3 (+) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: iptel@ietf.org, "Peterson, Jon" , chelliah@cisco.com Subject: [Iptel] Re: Scope of *rn* parameter in the context of LNP X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1062667272==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd This is a multi-part message in MIME format. --===============1062667272== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C537CA.56285EC6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C537CA.56285EC6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is simpler to use the presence of "npdi" to indicate "yes".=20 -------------------------- Sent from my BlackBerry Wireless Handheld -----Original Message----- From: Gonzalo Camarillo To: Yu, James CC: chelliah@cisco.com ; iptel@ietf.org = ; Peterson, Jon Sent: Sat Apr 02 01:25:35 2005 Subject: Re: Scope of *rn* parameter in the context of LNP James, what was the reason for moving from "npdi=3Dyes" to only "npdi"? Thanks, Gonzalo Yu, James wrote: > Chelliah, > =20 > I checked RFC3398. Yes, you detected an inconsistency between = RFC3398=20 > and my I-D. > =20 > RFC3398 references my I-D that is not yet a RFC. My current I-D does = > not use "npdi=3Dyes" (just "npdi") and the "rn" is either a global-rn=20 > (global routing number) or local-rn (e.g., national number with +1 in = > the rn-context). > =20 > RFC3398 needs to be corrected. > =20 > James >=20 > -----Original Message----- > *From:* Chelliah Sivachelvan (chelliah) = [mailto:chelliah@cisco.com] > *Sent:* Wednesday, March 30, 2005 12:05 PM > *To:* chelliah@cisco.com; Yu, James > *Cc:* iptel@ietf.org; Gonzalo.Camarillo@Ericsson.com; Peterson, = Jon > *Subject:* RE: Scope of *rn* parameter in the context of LNP >=20 > Correction: The referenced RFC is 3398 not 3388. > =20 > Thanks! > Chella >=20 > = ------------------------------------------------------------------------ > *From:* Chelliah Sivachelvan (chelliah) = [mailto:chelliah@cisco.com] > *Sent:* Wednesday, March 30, 2005 11:00 AM > *To:* 'james.yu@neustar.biz' > *Cc:* 'iptel@ietf.org'; 'Gonzalo.Camarillo@Ericsson.com'; > 'jon.peterson@neustar.biz' > *Subject:* Scope of *rn* parameter in the context of LNP >=20 > James: > The current draft (draft-ietf-iptel-tel-np-04.txt) implies that = the > *rn* parameter can contain global numbers (i.e., E.164 numbers) in > the context of LNP. This has also been illustrated in one of the > examples in section 6(c).=20 > =20 > But the scope of LNP is national; as such the scope of routing > number (LRN) is not a globally reachable number. Therefore, it = must > be treated as a national number. RFC-3388 also makes a strong > statement on this very subject. Here is the excerpts from RFC-3388 > (section 8.2.1.1 ) > =20 > "LRNs are necessarily national in scope, and consequently they > MUST NOT be preceded by a '+' in the 'rn=3D' field." > =20 > =20 > We need to resolve the discrepancies between the two specs. > =20 > =20 > Thanks! > Chella > =20 > =20 > Cisco Systems, > 2200 East President George Bush Turnpike , > Richardson, TX 75082 > Tel: 469.255.1169 > =20 ------_=_NextPart_001_01C537CA.56285EC6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Scope of *rn* parameter in the context of LNP

It is simpler to use the presence of = “npdi” to indicate “yes”.
--------------------------
Sent from my BlackBerry Wireless Handheld


-----Original Message-----
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
To: Yu, James <james.yu@neustar.biz>
CC: chelliah@cisco.com <chelliah@cisco.com>; iptel@ietf.org = <iptel@ietf.org>; Peterson, Jon = <jon.peterson@neustar.biz>
Sent: Sat Apr 02 01:25:35 2005
Subject: Re: Scope of *rn* parameter in the context of LNP

James,

what was the reason for moving from "npdi=3Dyes" to only = "npdi"?

Thanks,

Gonzalo

Yu, James wrote:
> Chelliah,
> 
> I checked RFC3398.   Yes, you detected an inconsistency = between RFC3398
> and my I-D.
> 
> RFC3398 references my I-D that is not yet a RFC.   My = current I-D does
> not use "npdi=3Dyes" (just "npdi") and the = "rn" is either a global-rn
> (global routing number)  or local-rn (e.g., national number = with +1 in
> the rn-context).
> 
> RFC3398 needs to be corrected.
> 
> James
>
>     -----Original Message-----
>     *From:* Chelliah Sivachelvan (chelliah) [mailto:chelliah@cisco.com]
>     *Sent:* Wednesday, March 30, 2005 12:05 = PM
>     *To:* chelliah@cisco.com; Yu, James
>     *Cc:* iptel@ietf.org; = Gonzalo.Camarillo@Ericsson.com; Peterson, Jon
>     *Subject:* RE: Scope of *rn* parameter in = the context of LNP
>
>     Correction: The referenced RFC is 3398 not = 3388.
>     
>     Thanks!
>     Chella
>
>     = ------------------------------------------------------------------------<= BR> >     *From:* Chelliah Sivachelvan (chelliah) [mailto:chelliah@cisco.com]
>     *Sent:* Wednesday, March 30, 2005 11:00 = AM
>     *To:* 'james.yu@neustar.biz'
>     *Cc:* 'iptel@ietf.org'; = 'Gonzalo.Camarillo@Ericsson.com';
>     'jon.peterson@neustar.biz'
>     *Subject:* Scope of *rn* parameter in the = context of LNP
>
>     James:
>     The current draft = (draft-ietf-iptel-tel-np-04.txt) implies that the
>     *rn* parameter can contain global numbers = (i.e., E.164 numbers) in
>     the context of LNP. This has also been = illustrated in one of the
>     examples in section 6(c).
>     
>     But the scope of LNP is national; as such = the scope of routing
>     number (LRN) is not a globally reachable = number. Therefore, it must
>     be treated as a national number. RFC-3388 = also makes a strong
>     statement on this very subject. Here is the = excerpts from RFC-3388
>     (section 8.2.1.1 )
>     
>        "LRNs are = necessarily national in scope, and consequently they
>     MUST NOT be preceded by a '+' in the = 'rn=3D' field."
>     
>     
>     We need to resolve the discrepancies = between the two specs.
>     
>      
>     Thanks!
>     Chella
>           &nb= sp;    
>     
>     Cisco Systems,
>     2200 East President George Bush Turnpike = ,
>     Richardson, TX 75082
>     Tel: 469.255.1169
>     

------_=_NextPart_001_01C537CA.56285EC6-- --===============1062667272== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============1062667272==-- From iptel-bounces@ietf.org Sat Apr 2 21:04:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10765 for ; Sat, 2 Apr 2005 21:04:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHub2-000410-9l for iptel-web-archive@ietf.org; Sat, 02 Apr 2005 21:12:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHuPv-0004mw-0g; Sat, 02 Apr 2005 21:00:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHc5j-0006aH-WB for iptel@megatron.ietf.org; Sat, 02 Apr 2005 01:26:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02691 for ; Sat, 2 Apr 2005 01:26:42 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHcDD-0004nN-Cl for iptel@ietf.org; Sat, 02 Apr 2005 01:34:28 -0500 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j326PbO6017444; Sat, 2 Apr 2005 08:25:37 +0200 Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sat, 2 Apr 2005 08:25:36 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sat, 2 Apr 2005 08:25:36 +0200 Received: from [131.160.126.60] (rvi2-126-60.lmf.ericsson.se [131.160.126.60]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 78695189CC; Sat, 2 Apr 2005 09:25:35 +0300 (EEST) Message-ID: <424E3ADF.7040808@ericsson.com> Date: Sat, 02 Apr 2005 09:25:35 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Yu, James" References: <165FCC93A820D240A62F98E028CEFED001451178@stntexch01.cis.neustar.com> In-Reply-To: <165FCC93A820D240A62F98E028CEFED001451178@stntexch01.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2005 06:25:36.0246 (UTC) FILETIME=[C800B960:01C5374C] X-Spam-Score: 0.8 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 02 Apr 2005 21:00:45 -0500 Cc: iptel@ietf.org, "Peterson, Jon" , chelliah@cisco.com Subject: [Iptel] Re: Scope of *rn* parameter in the context of LNP X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit James, what was the reason for moving from "npdi=yes" to only "npdi"? Thanks, Gonzalo Yu, James wrote: > Chelliah, > > I checked RFC3398. Yes, you detected an inconsistency between RFC3398 > and my I-D. > > RFC3398 references my I-D that is not yet a RFC. My current I-D does > not use "npdi=yes" (just "npdi") and the "rn" is either a global-rn > (global routing number) or local-rn (e.g., national number with +1 in > the rn-context). > > RFC3398 needs to be corrected. > > James > > -----Original Message----- > *From:* Chelliah Sivachelvan (chelliah) [mailto:chelliah@cisco.com] > *Sent:* Wednesday, March 30, 2005 12:05 PM > *To:* chelliah@cisco.com; Yu, James > *Cc:* iptel@ietf.org; Gonzalo.Camarillo@Ericsson.com; Peterson, Jon > *Subject:* RE: Scope of *rn* parameter in the context of LNP > > Correction: The referenced RFC is 3398 not 3388. > > Thanks! > Chella > > ------------------------------------------------------------------------ > *From:* Chelliah Sivachelvan (chelliah) [mailto:chelliah@cisco.com] > *Sent:* Wednesday, March 30, 2005 11:00 AM > *To:* 'james.yu@neustar.biz' > *Cc:* 'iptel@ietf.org'; 'Gonzalo.Camarillo@Ericsson.com'; > 'jon.peterson@neustar.biz' > *Subject:* Scope of *rn* parameter in the context of LNP > > James: > The current draft (draft-ietf-iptel-tel-np-04.txt) implies that the > *rn* parameter can contain global numbers (i.e., E.164 numbers) in > the context of LNP. This has also been illustrated in one of the > examples in section 6(c). > > But the scope of LNP is national; as such the scope of routing > number (LRN) is not a globally reachable number. Therefore, it must > be treated as a national number. RFC-3388 also makes a strong > statement on this very subject. Here is the excerpts from RFC-3388 > (section 8.2.1.1 ) > > "LRNs are necessarily national in scope, and consequently they > MUST NOT be preceded by a '+' in the 'rn=' field." > > > We need to resolve the discrepancies between the two specs. > > > Thanks! > Chella > > > Cisco Systems, > 2200 East President George Bush Turnpike , > Richardson, TX 75082 > Tel: 469.255.1169 > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Apr 8 13:28:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15910 for ; Fri, 8 Apr 2005 13:28:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxPs-0001Xa-VC for iptel-web-archive@ietf.org; Fri, 08 Apr 2005 13:37:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJxGB-000872-MQ; Fri, 08 Apr 2005 13:27:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJsIe-0004JG-O8 for iptel@megatron.ietf.org; Fri, 08 Apr 2005 08:09:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10216 for ; Fri, 8 Apr 2005 08:09:23 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJsRP-0001Nu-Hi for iptel@ietf.org; Fri, 08 Apr 2005 08:18:28 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j38C9Bhb025403; Fri, 8 Apr 2005 14:09:19 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 14:09:10 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 14:09:09 +0200 Received: from [131.160.37.196] (EFO9N000L5C7100.lmf.ericsson.se [131.160.37.196]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F0681189CC; Fri, 8 Apr 2005 15:09:08 +0300 (EEST) Message-ID: <42567465.8050107@ericsson.com> Date: Fri, 08 Apr 2005 15:09:09 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Yu, James" References: <165FCC93A820D240A62F98E028CEFED00145117C@stntexch01.cis.neustar.com> In-Reply-To: <165FCC93A820D240A62F98E028CEFED00145117C@stntexch01.cis.neustar.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Apr 2005 12:09:09.0997 (UTC) FILETIME=[C53C01D0:01C53C33] X-Spam-Score: 0.8 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 08 Apr 2005 13:27:10 -0400 Cc: iptel@ietf.org, "Peterson, Jon" , chelliah@cisco.com Subject: [Iptel] Re: Scope of *rn* parameter in the context of LNP X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable If that is the only reason for the change and the change causes a=20 backward compatibility issue with RFC 3398, I would say that we keep the=20 npdi=3Dyes syntax. Gonzalo Yu, James wrote: > It is simpler to use the presence of =93npdi=94 to indicate =93yes=94. > -------------------------- > Sent from my BlackBerry Wireless Handheld >=20 >=20 > -----Original Message----- > From: Gonzalo Camarillo > To: Yu, James > CC: chelliah@cisco.com ; iptel@ietf.org=20 > ; Peterson, Jon > Sent: Sat Apr 02 01:25:35 2005 > Subject: Re: Scope of *rn* parameter in the context of LNP >=20 > James, >=20 > what was the reason for moving from "npdi=3Dyes" to only "npdi"? >=20 > Thanks, >=20 > Gonzalo >=20 > Yu, James wrote: > > Chelliah, > >=20 > > I checked RFC3398. Yes, you detected an inconsistency between RFC3= 398 > > and my I-D. > >=20 > > RFC3398 references my I-D that is not yet a RFC. My current I-D do= es > > not use "npdi=3Dyes" (just "npdi") and the "rn" is either a global-r= n > > (global routing number) or local-rn (e.g., national number with +1 = in > > the rn-context). > >=20 > > RFC3398 needs to be corrected. > >=20 > > James > > > > -----Original Message----- > > *From:* Chelliah Sivachelvan (chelliah) [mailto:chelliah@cisco.c= om] > > *Sent:* Wednesday, March 30, 2005 12:05 PM > > *To:* chelliah@cisco.com; Yu, James > > *Cc:* iptel@ietf.org; Gonzalo.Camarillo@Ericsson.com; Peterson, = Jon > > *Subject:* RE: Scope of *rn* parameter in the context of LNP > > > > Correction: The referenced RFC is 3398 not 3388. > > =20 > > Thanks! > > Chella > > > > =20 > -----------------------------------------------------------------------= - > > *From:* Chelliah Sivachelvan (chelliah) [mailto:chelliah@cisco.c= om] > > *Sent:* Wednesday, March 30, 2005 11:00 AM > > *To:* 'james.yu@neustar.biz' > > *Cc:* 'iptel@ietf.org'; 'Gonzalo.Camarillo@Ericsson.com'; > > 'jon.peterson@neustar.biz' > > *Subject:* Scope of *rn* parameter in the context of LNP > > > > James: > > The current draft (draft-ietf-iptel-tel-np-04.txt) implies that = the > > *rn* parameter can contain global numbers (i.e., E.164 numbers) = in > > the context of LNP. This has also been illustrated in one of the > > examples in section 6(c). > > =20 > > But the scope of LNP is national; as such the scope of routing > > number (LRN) is not a globally reachable number. Therefore, it m= ust > > be treated as a national number. RFC-3388 also makes a strong > > statement on this very subject. Here is the excerpts from RFC-33= 88 > > (section 8.2.1.1 ) > > =20 > > "LRNs are necessarily national in scope, and consequently the= y > > MUST NOT be preceded by a '+' in the 'rn=3D' field." > > =20 > > =20 > > We need to resolve the discrepancies between the two specs. > > =20 > > =20 > > Thanks! > > Chella > > =20 > > =20 > > Cisco Systems, > > 2200 East President George Bush Turnpike , > > Richardson, TX 75082 > > Tel: 469.255.1169 > > =20 >=20 --=20 Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Apr 8 13:38:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16813 for ; Fri, 8 Apr 2005 13:38:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxa2-00021c-DF for iptel-web-archive@ietf.org; Fri, 08 Apr 2005 13:47:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJxQX-0001q7-L3; Fri, 08 Apr 2005 13:37:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJxQU-0001ou-Jy for iptel@megatron.ietf.org; Fri, 08 Apr 2005 13:37:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16741 for ; Fri, 8 Apr 2005 13:37:47 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxZG-000206-Dp for iptel@ietf.org; Fri, 08 Apr 2005 13:46:56 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j38HbbNR025349 for ; Fri, 8 Apr 2005 12:37:38 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 8 Apr 2005 12:37:37 -0500 Message-ID: From: "Chaidez, Fidencio (Fidencio)" To: "'Gonzalo Camarillo'" , "Yu, James" Subject: RE: [Iptel] Re: Scope of *rn* parameter in the context of LNP Date: Fri, 8 Apr 2005 12:37:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org, chelliah@cisco.com, "Peterson, Jon" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: quoted-printable James, Gonzalo: You should proceed carefully. The npdi (without the "=3Dyes") syntax has been around in drafts for quite a while and, I'm sure, has been widely implemented. T1.679 (the U.S. equivalent of Q.1912.5), like RFC 3398, made the mistake of referencing this parameter even though it had not reached RFC status yet, but it did so based on more recent drafts that showed the npdi parameter by itself. Should allow for more discussion. Regards, Fidencio -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] Sent: Friday, April 08, 2005 7:09 AM To: Yu, James Cc: iptel@ietf.org; Peterson, Jon; chelliah@cisco.com Subject: [Iptel] Re: Scope of *rn* parameter in the context of LNP If that is the only reason for the change and the change causes a=20 backward compatibility issue with RFC 3398, I would say that we keep = the=20 npdi=3Dyes syntax. Gonzalo Yu, James wrote: > It is simpler to use the presence of =93npdi=94 to indicate = =93yes=94. > -------------------------- > Sent from my BlackBerry Wireless Handheld >=20 >=20 > -----Original Message----- > From: Gonzalo Camarillo > To: Yu, James > CC: chelliah@cisco.com ; iptel@ietf.org=20 > ; Peterson, Jon > Sent: Sat Apr 02 01:25:35 2005 > Subject: Re: Scope of *rn* parameter in the context of LNP >=20 > James, >=20 > what was the reason for moving from "npdi=3Dyes" to only "npdi"? >=20 > Thanks, >=20 > Gonzalo >=20 > Yu, James wrote: > > Chelliah, > >=20 > > I checked RFC3398. Yes, you detected an inconsistency between = RFC3398 > > and my I-D. > >=20 > > RFC3398 references my I-D that is not yet a RFC. My current I-D = does > > not use "npdi=3Dyes" (just "npdi") and the "rn" is either a = global-rn > > (global routing number) or local-rn (e.g., national number with = +1 in > > the rn-context). > >=20 > > RFC3398 needs to be corrected. > >=20 > > James > > > > -----Original Message----- > > *From:* Chelliah Sivachelvan (chelliah) = [mailto:chelliah@cisco.com] > > *Sent:* Wednesday, March 30, 2005 12:05 PM > > *To:* chelliah@cisco.com; Yu, James > > *Cc:* iptel@ietf.org; Gonzalo.Camarillo@Ericsson.com; = Peterson, Jon > > *Subject:* RE: Scope of *rn* parameter in the context of LNP > > > > Correction: The referenced RFC is 3398 not 3388. > > =20 > > Thanks! > > Chella > > > > =20 > = ------------------------------------------------------------------------= > > *From:* Chelliah Sivachelvan (chelliah) = [mailto:chelliah@cisco.com] > > *Sent:* Wednesday, March 30, 2005 11:00 AM > > *To:* 'james.yu@neustar.biz' > > *Cc:* 'iptel@ietf.org'; 'Gonzalo.Camarillo@Ericsson.com'; > > 'jon.peterson@neustar.biz' > > *Subject:* Scope of *rn* parameter in the context of LNP > > > > James: > > The current draft (draft-ietf-iptel-tel-np-04.txt) implies = that the > > *rn* parameter can contain global numbers (i.e., E.164 = numbers) in > > the context of LNP. This has also been illustrated in one of = the > > examples in section 6(c). > > =20 > > But the scope of LNP is national; as such the scope of routing > > number (LRN) is not a globally reachable number. Therefore, it = must > > be treated as a national number. RFC-3388 also makes a strong > > statement on this very subject. Here is the excerpts from = RFC-3388 > > (section 8.2.1.1 ) > > =20 > > "LRNs are necessarily national in scope, and consequently = they > > MUST NOT be preceded by a '+' in the 'rn=3D' field." > > =20 > > =20 > > We need to resolve the discrepancies between the two specs. > > =20 > > =20 > > Thanks! > > Chella > > =20 > > =20 > > Cisco Systems, > > 2200 East President George Bush Turnpike , > > Richardson, TX 75082 > > Tel: 469.255.1169 > > =20 >=20 --=20 Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Apr 13 04:35:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05599 for ; Wed, 13 Apr 2005 04:35:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLdVM-0008C7-Kz for iptel-web-archive@ietf.org; Wed, 13 Apr 2005 04:45:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLdEl-0007lc-N0; Wed, 13 Apr 2005 04:28:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLdEg-0007ji-Lw for iptel@megatron.ietf.org; Wed, 13 Apr 2005 04:28:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05281 for ; Wed, 13 Apr 2005 04:28:24 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLdOJ-00081Z-8f for iptel@ietf.org; Wed, 13 Apr 2005 04:38:31 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j3D8SDKD025693; Wed, 13 Apr 2005 08:28:13 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 04:28:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] Re: Scope of *rn* parameter in the context of LNP Date: Wed, 13 Apr 2005 04:28:12 -0400 Message-ID: <165FCC93A820D240A62F98E028CEFED0014511CE@stntexch01.cis.neustar.com> Thread-Topic: [Iptel] Re: Scope of *rn* parameter in the context of LNP Thread-Index: AcU8YbDaNexD2bBGRACJGgLo0Qac9ADoIPdQ From: "Yu, James" To: "Chaidez, Fidencio \(Fidencio\)" , "Gonzalo Camarillo" X-OriginalArrivalTime: 13 Apr 2005 08:28:13.0236 (UTC) FILETIME=[BBA78F40:01C54002] X-Spam-Score: 0.8 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org, chelliah@cisco.com, "Peterson, Jon" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable I suggest that we don't change anything in the current NP I-D. This is = because RFC3398 needs to correct the "rn" part and there are = implementations/standards that follow the latest version of the NP I-D. James -----Original Message----- From: Chaidez, Fidencio (Fidencio) [mailto:fchaidez@lucent.com] Sent: Friday, April 08, 2005 1:38 PM To: 'Gonzalo Camarillo'; Yu, James Cc: iptel@ietf.org; Peterson, Jon; chelliah@cisco.com Subject: RE: [Iptel] Re: Scope of *rn* parameter in the context of LNP James, Gonzalo: You should proceed carefully. The npdi (without the "=3Dyes") syntax has been around in drafts for quite a while and, I'm sure, has been widely implemented. T1.679 (the U.S. equivalent of Q.1912.5), like RFC 3398, made the mistake of referencing this parameter even though it had not reached RFC status yet, but it did so based on more recent drafts that showed the npdi parameter by itself. Should allow for more discussion. Regards, Fidencio -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] Sent: Friday, April 08, 2005 7:09 AM To: Yu, James Cc: iptel@ietf.org; Peterson, Jon; chelliah@cisco.com Subject: [Iptel] Re: Scope of *rn* parameter in the context of LNP If that is the only reason for the change and the change causes a=20 backward compatibility issue with RFC 3398, I would say that we keep the = npdi=3Dyes syntax. Gonzalo Yu, James wrote: > It is simpler to use the presence of "npdi" to indicate "yes". > -------------------------- > Sent from my BlackBerry Wireless Handheld >=20 >=20 > -----Original Message----- > From: Gonzalo Camarillo > To: Yu, James > CC: chelliah@cisco.com ; iptel@ietf.org=20 > ; Peterson, Jon > Sent: Sat Apr 02 01:25:35 2005 > Subject: Re: Scope of *rn* parameter in the context of LNP >=20 > James, >=20 > what was the reason for moving from "npdi=3Dyes" to only "npdi"? >=20 > Thanks, >=20 > Gonzalo >=20 > Yu, James wrote: > > Chelliah, > >=20 > > I checked RFC3398. Yes, you detected an inconsistency between = RFC3398 > > and my I-D. > >=20 > > RFC3398 references my I-D that is not yet a RFC. My current I-D = does > > not use "npdi=3Dyes" (just "npdi") and the "rn" is either a = global-rn > > (global routing number) or local-rn (e.g., national number with +1 = in > > the rn-context). > >=20 > > RFC3398 needs to be corrected. > >=20 > > James > > > > -----Original Message----- > > *From:* Chelliah Sivachelvan (chelliah) = [mailto:chelliah@cisco.com] > > *Sent:* Wednesday, March 30, 2005 12:05 PM > > *To:* chelliah@cisco.com; Yu, James > > *Cc:* iptel@ietf.org; Gonzalo.Camarillo@Ericsson.com; Peterson, = Jon > > *Subject:* RE: Scope of *rn* parameter in the context of LNP > > > > Correction: The referenced RFC is 3398 not 3388. > > =20 > > Thanks! > > Chella > > > > =20 > = ------------------------------------------------------------------------ > > *From:* Chelliah Sivachelvan (chelliah) = [mailto:chelliah@cisco.com] > > *Sent:* Wednesday, March 30, 2005 11:00 AM > > *To:* 'james.yu@neustar.biz' > > *Cc:* 'iptel@ietf.org'; 'Gonzalo.Camarillo@Ericsson.com'; > > 'jon.peterson@neustar.biz' > > *Subject:* Scope of *rn* parameter in the context of LNP > > > > James: > > The current draft (draft-ietf-iptel-tel-np-04.txt) implies that = the > > *rn* parameter can contain global numbers (i.e., E.164 numbers) = in > > the context of LNP. This has also been illustrated in one of = the > > examples in section 6(c). > > =20 > > But the scope of LNP is national; as such the scope of routing > > number (LRN) is not a globally reachable number. Therefore, it = must > > be treated as a national number. RFC-3388 also makes a strong > > statement on this very subject. Here is the excerpts from = RFC-3388 > > (section 8.2.1.1 ) > > =20 > > "LRNs are necessarily national in scope, and consequently = they > > MUST NOT be preceded by a '+' in the 'rn=3D' field." > > =20 > > =20 > > We need to resolve the discrepancies between the two specs. > > =20 > > =20 > > Thanks! > > Chella > > =20 > > =20 > > Cisco Systems, > > 2200 East President George Bush Turnpike , > > Richardson, TX 75082 > > Tel: 469.255.1169 > > =20 >=20 --=20 Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Apr 18 15:52:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcI8-0008I5-Rn; Mon, 18 Apr 2005 15:52:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcI4-0008F5-HI; Mon, 18 Apr 2005 15:52:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24542; Mon, 18 Apr 2005 15:52:14 -0400 (EDT) Message-Id: <200504181952.PAA24542@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 18 Apr 2005 15:52:14 -0400 Cc: iptel@ietf.org Subject: [Iptel] I-D ACTION:draft-ietf-iptel-tel-enumdi-01.txt X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : The ENUM Dip Indicator parameter for the "tel" URI Author(s) : R. Stastny, et al. Filename : draft-ietf-iptel-tel-enumdi-01.txt Pages : 12 Date : 2005-4-18 This document defines a new parameter "enumdi" in the "tel" Uniform Resource Identifier (URI) as defined in RFC3966 to support the handling of ENUM queries in SIP proxies, H.323 gatekeepers and other VoIP network elements. The presence of the "enumdi" parameter indicates to the VoIP network element receiving an URI containing an E.164 number that an ENUM query as defined in RFC3761 has already been performed on the E.164 number indicated by the previous VoIP network element. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-enumdi-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-tel-enumdi-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-tel-enumdi-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-18162001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-tel-enumdi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-tel-enumdi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-18162001.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --NextPart-- From iptel-bounces@ietf.org Mon Apr 18 18:44:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNeyJ-0004mr-WE; Mon, 18 Apr 2005 18:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNeyI-0004ml-62 for iptel@megatron.ietf.org; Mon, 18 Apr 2005 18:44:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20436 for ; Mon, 18 Apr 2005 18:43:59 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNf99-0007ZY-LI for iptel@ietf.org; Mon, 18 Apr 2005 18:55:18 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j3IMhdg3024009; Mon, 18 Apr 2005 17:43:39 -0500 (CDT) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j3IMhd600135; Mon, 18 Apr 2005 17:43:39 -0500 (CDT) Message-ID: <4264381C.10200@lucent.com> Date: Mon, 18 Apr 2005 17:43:40 -0500 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF IPTEL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: Subject: [Iptel] Finishing work on trunk-group X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Folks: I will really like to finish the remaing work on trunk-group. The I-D has been WGLC'd, and the current version (-03) is the version that includes comments raised and addressed during WGLC. Shortly after I posted -03, Paul K. pointed out a small discrepancy that is worth addressing (his email, which has mysteriously disappeared from the archives, is reproduced in its entirety at the end of this mail). I will like to resolve this point and move the I-D forward. Paul notes that the "phone-context" parameter may not be applicable to a global tel URI (i.e., +1...) -- it may be valid syntactically, but it is not the intent of rfc3966 that it appear as such (and we all know that in ABNF, what may be syntactically correct may not be semantically so). So, there are two ways around this: 1) Change the examples in the I-D to use local numbers, and not global numbers; 2) Have the I-D suggest an alternate means to approximate the reason we have used the "phone-context" parameter. That is, replace "phone-context" parameter with another parameter (see below for more on this). (1) is sweeping the problem under the rug; as such, I don't think we should go that route. That leaves us with (2). The reason we are using the "phone-context" parameter is to impose a namespace on the trunk group (the way the I-D defines it, a trunk group MUST have a "phone-context"), BUT, a "phone-context" cannot appear in a global tel URI. So, we simply define a new parameter -- call it "trunk-context" -- that has the same semantics as a "phone-context". This new parameter will be defined by the trunk-group I-D as such: par = parameter / extension / isdn-subaddress / trunk-group trunk-group = ";tgrp=" trunk-group-label ";trunk-context=" trunk-context trunk-group-label = *1( unreserved / escaped / trunk-group-unreserved ) trunk-group-unreserved = "/" / "&" / "+" / "$" trunk-context = descriptor descriptor = domainname / global-number-digits The new parameter replaces "phone-context", but provides the same semantics of imposing a namespace. I will like the WG to comment on this, or suggest alternative means. I think that this is a small enough change that assuming the WG agrees to it, I can rev the I-D and request the WG chairs to forward the I-D to IESG. Please send me your comments and/or concerns. Unless I hear otherwise, I will make the requisite change and, hopefully, finsish the pending work on trunk-group. Thank you. Begin Paul's original email ------ Subject: [Iptel] Re: draft-ietf-iptel-trunk-group-03 From: Paul Kyzivat Date: Wed, 16 Feb 2005 19:26:05 -0500 To: "Vijay K. Gurbani" , fluffy@cisco.com CC: iptel One thing concerns me in this draft: You are requiring use of the phone-context parameter, even with global numbers, such as: tel:+15555551212;phone-context=telco.example.com;tgrp=tg55 Now this may be debatable, but I believe that usage is currently invalid according to RFC3966. (Phone-context is only valid with a local-number.) Here is some of the ABNF from 3966: telephone-uri = "tel:" telephone-subscriber telephone-subscriber = global-number / local-number global-number = global-number-digits *par local-number = local-number-digits *par context *par context = ";phone-context=" descriptor par = parameter / extension / isdn-subaddress extension = ";ext=" 1*phonedigit isdn-subaddress = ";isub=" 1*uric parameter = ";" pname ["=" pvalue ] pname = 1*( alphanum / "-" ) Its arguable because "phone-context" can be parsed as both a 'context' and a 'parameter'. But I think it is pretty clear that isn't the intent. (And if it was, then semantically it would just be a parameer, not a context.) So I think you need to make a *change* rather than just an *extension* to 3966 if you want to use phone-context with global numbers. Paul End Paul's original email ------ Thanks, - 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@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Apr 18 19:06:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNfKE-00082o-Jq; Mon, 18 Apr 2005 19:06:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNfKD-00082O-Fx for iptel@megatron.ietf.org; Mon, 18 Apr 2005 19:06:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22229 for ; Mon, 18 Apr 2005 19:06:38 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNfV7-0000IQ-A8 for iptel@ietf.org; Mon, 18 Apr 2005 19:17:57 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 18 Apr 2005 19:17:17 -0400 X-IronPort-AV: i="3.92,111,1112587200"; d="scan'208"; a="45127250:sNHT30555892" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3IN6SRQ029181; Mon, 18 Apr 2005 19:06:28 -0400 (EDT) Received: from cisco.com ([161.44.79.173]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQS29935; Mon, 18 Apr 2005 19:06:27 -0400 (EDT) Message-ID: <42643D72.6030203@cisco.com> Date: Mon, 18 Apr 2005 19:06:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <4264381C.10200@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit Cc: IETF IPTEL WG Subject: [Iptel] Re: Finishing work on trunk-group X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Vijay, I only have one point, and I think it is just a matter of my needing a clarification of your intent. How do you imagine these parameters end up in a URI? I can only think of two ways: - a request is coming in from a gateway. It knows the trunk group and so can form the URI as a contact address, or whatever. - a request is going out toward a gateway. Initially the address is known as a phone number. Some server manages the gateway and is aware of the resources it contains and how they are named. It rewrites the R-URI, inserting tg and tg-context parameters. I'm thinking about the latter case, if it is even in scope. Then I am also thinking about the possiblity that the telephone number that is heading toward the gateway is a local rather than global number. From your syntax, I presume you believe that to be ok. For it to begin life as a local number, before having the tg added, it must have had a phone context. E.g. something like: tel:411;phone-context=+1 Now, when the proxy decides to insert the tg and tg-context, does the phone-context remain, or is it removed and *replaced* by the tg-context? Any clue what the relationship between the contexts might be? E.g. which of the following does the above become? tel:411;tg=3;tg-context=+1 tel:411;phone-context=+1;tg=3;tg-context=+1 tel:411;phone-context=+1;tg=3;tg-context=something.else I don't much care, as long as it works and makes sense. Maybe an example or two showing how this should work would help. Paul Vijay K. Gurbani wrote: > Folks: > > I will really like to finish the remaing work on trunk-group. > The I-D has been WGLC'd, and the current version (-03) is > the version that includes comments raised and addressed > during WGLC. > > Shortly after I posted -03, Paul K. pointed out a small > discrepancy that is worth addressing (his email, which has > mysteriously disappeared from the archives, is reproduced > in its entirety at the end of this mail). I will like to > resolve this point and move the I-D forward. > > Paul notes that the "phone-context" parameter may not be > applicable to a global tel URI (i.e., +1...) -- it may be > valid syntactically, but it is not the intent of rfc3966 that > it appear as such (and we all know that in ABNF, what may be > syntactically correct may not be semantically so). > > So, there are two ways around this: > > 1) Change the examples in the I-D to use local numbers, and not > global numbers; > 2) Have the I-D suggest an alternate means to approximate the > reason we have used the "phone-context" parameter. That is, > replace "phone-context" parameter with another parameter (see > below for more on this). > > (1) is sweeping the problem under the rug; as such, I don't think > we should go that route. That leaves us with (2). > > The reason we are using the "phone-context" parameter is to > impose a namespace on the trunk group (the way the I-D defines it, > a trunk group MUST have a "phone-context"), BUT, a "phone-context" > cannot appear in a global tel URI. So, we simply define a > new parameter -- call it "trunk-context" -- that has the same > semantics as a "phone-context". This new parameter will be > defined by the trunk-group I-D as such: > > par = parameter / extension / isdn-subaddress / trunk-group > > trunk-group = ";tgrp=" trunk-group-label ";trunk-context=" > trunk-context > trunk-group-label = *1( unreserved / escaped / > trunk-group-unreserved ) > trunk-group-unreserved = "/" / "&" / "+" / "$" > trunk-context = descriptor > descriptor = domainname / global-number-digits > > The new parameter replaces "phone-context", but provides the > same semantics of imposing a namespace. > > I will like the WG to comment on this, or suggest alternative > means. I think that this is a small enough change that > assuming the WG agrees to it, I can rev the I-D and request the > WG chairs to forward the I-D to IESG. > > Please send me your comments and/or concerns. Unless I hear > otherwise, I will make the requisite change and, hopefully, > finsish the pending work on trunk-group. > > Thank you. > > Begin Paul's original email ------ > > Subject: [Iptel] Re: draft-ietf-iptel-trunk-group-03 > From: Paul Kyzivat > Date: Wed, 16 Feb 2005 19:26:05 -0500 > To: "Vijay K. Gurbani" , fluffy@cisco.com > CC: iptel > > One thing concerns me in this draft: > > You are requiring use of the phone-context parameter, even with global > numbers, such as: > > tel:+15555551212;phone-context=telco.example.com;tgrp=tg55 > > Now this may be debatable, but I believe that usage is currently invalid > according to RFC3966. (Phone-context is only valid with a local-number.) > Here is some of the ABNF from 3966: > > telephone-uri = "tel:" telephone-subscriber > telephone-subscriber = global-number / local-number > global-number = global-number-digits *par > local-number = local-number-digits *par context *par > > context = ";phone-context=" descriptor > > par = parameter / extension / isdn-subaddress > extension = ";ext=" 1*phonedigit > isdn-subaddress = ";isub=" 1*uric > > parameter = ";" pname ["=" pvalue ] > pname = 1*( alphanum / "-" ) > > Its arguable because "phone-context" can be parsed as both a 'context' > and a 'parameter'. But I think it is pretty clear that isn't the intent. > (And if it was, then semantically it would just be a parameer, not a > context.) > > So I think you need to make a *change* rather than just an *extension* > to 3966 if you want to use phone-context with global numbers. > > Paul > > End Paul's original email ------ > > Thanks, > > - vijay _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Apr 19 10:49:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNu2M-00063T-Vs; Tue, 19 Apr 2005 10:49:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNu2L-00063O-Or for iptel@megatron.ietf.org; Tue, 19 Apr 2005 10:49:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17107 for ; Tue, 19 Apr 2005 10:49:11 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNuDN-0001pA-32 for iptel@ietf.org; Tue, 19 Apr 2005 11:00:38 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j3JEmulf023742; Tue, 19 Apr 2005 09:48:57 -0500 (CDT) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j3JEmtC19442; Tue, 19 Apr 2005 09:48:55 -0500 (CDT) Message-ID: <42651A57.3000201@lucent.com> Date: Tue, 19 Apr 2005 09:48:55 -0500 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Iptel] Re: Finishing work on trunk-group References: <4264381C.10200@lucent.com> <42643D72.6030203@cisco.com> In-Reply-To: <42643D72.6030203@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: IETF IPTEL WG X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Paul Kyzivat wrote: > How do you imagine these parameters end up in a URI? I can only think of > two ways: > > - a request is coming in from a gateway. It knows the trunk group and so > can form the URI as a contact address, or whatever. > > - a request is going out toward a gateway. Initially the address is > known as a phone number. Some server manages the gateway and is aware of > the resources it contains and how they are named. It rewrites the R-URI, > inserting tg and tg-context parameters. > > I'm thinking about the latter case, if it is even in scope. Paul: The latter case is actually what caused us to look into this in the first place. > Now, when the proxy decides to insert the tg and tg-context, does the > phone-context remain, or is it removed and *replaced* by the tg-context? > Any clue what the relationship between the contexts might be? [...] OK; I see your point. If it is a local number, it will have a phone- context added. This means that the trunk-context cannot replace phone-context, it acts as another qualifier. > I don't much care, as long as it works and makes sense. Maybe an example > or two showing how this should work would help. Sure; in the next rev, I will spell out the interaction between these with an example or so. Thanks, - 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@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Apr 25 15:41:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ9SS-0002Cw-Eg; Mon, 25 Apr 2005 15:41:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ9SR-0002Cm-6c for iptel@megatron.ietf.org; Mon, 25 Apr 2005 15:41:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16276 for ; Mon, 25 Apr 2005 15:41:24 -0400 (EDT) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DQ9ej-0005uK-9E for iptel@ietf.org; Mon, 25 Apr 2005 15:54:10 -0400 Received: (qmail 65905 invoked by uid 1014); 25 Apr 2005 19:41:02 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.83. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.034991 secs); 25 Apr 2005 19:41:02 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 25 Apr 2005 19:41:02 -0000 From: "Shan Lu" To: "'Vijay K. Gurbani'" Subject: RE: [Iptel] Re: Finishing work on trunk-group Date: Mon, 25 Apr 2005 15:40:29 -0400 Message-ID: <002601c549ce$a3180c40$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <42651A57.3000201@lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: 'IETF IPTEL WG' X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] >On Behalf Of Vijay K. Gurbani >Sent: Tuesday, April 19, 2005 10:49 AM >To: Paul Kyzivat >Cc: IETF IPTEL WG >Subject: Re: [Iptel] Re: Finishing work on trunk-group > > > >OK; I see your point. If it is a local number, it will have a phone- >context added. This means that the trunk-context cannot replace >phone-context, it acts as another qualifier. > >> I don't much care, as long as it works and makes sense. >Maybe an example >> or two showing how this should work would help. Vijay, I support adding "trunk-context". But I would prefer to allow "tel:411;phone-context=foo.com;tgrp=abc123" as a valid format. If "trunk-context" is present, it defines context for the trunk group. If not, "phone-context" serves that purpose. Often times, tel uri is carried in sip uri. The userinfo portion already looks ugly w/o "trunk-context" :-) > >Sure; in the next rev, I will spell out the interaction between >these with an example or so. Would you be able to post your text/example to list before submitting new rev? It may save another round of commenting. Thanks, Shan Lu > >Thanks, > >- 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@ietf.org >https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel