From mailman-bounces@ietf.org Sat Jan 1 06:32:06 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 GAA11750 for ; Sat, 1 Jan 2005 06:32:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ckhg8-0007dn-LH for iptel-web-archive@ietf.org; Sat, 01 Jan 2005 06:44:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgL0-000388-2U for iptel-web-archive@ietf.org; Sat, 01 Jan 2005 05:18:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: iptel-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:05:37 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org 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, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for iptel-web-archive@ietf.org: List Password // URL ---- -------- iptel@ietf.org aroxgu https://www1.ietf.org/mailman/options/iptel/iptel-web-archive%40ietf.org From iptel-bounces@ietf.org Thu Jan 6 16:15:16 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 QAA19101 for ; Thu, 6 Jan 2005 16:15:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmfBJ-0001Qv-S6 for iptel-web-archive@ietf.org; Thu, 06 Jan 2005 16:28:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmeYc-0000EG-Hb; Thu, 06 Jan 2005 15:48:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmeUo-0006R3-8e for iptel@megatron.ietf.org; Thu, 06 Jan 2005 15:44: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 PAA14705 for ; Thu, 6 Jan 2005 15:44:36 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmehe-0008AB-CA for iptel@ietf.org; Thu, 06 Jan 2005 15:57:55 -0500 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 j06Ki26C021172; Thu, 6 Jan 2005 14:44:03 -0600 (CST) 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 j06Ki2q24761; Thu, 6 Jan 2005 14:44:02 -0600 (CST) Message-ID: <41DDA312.2070508@lucent.com> Date: Thu, 06 Jan 2005 14:44:02 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shan Lu Subject: Re: [Iptel] Finalizing trunk-group I-D References: <006001c4edf8$f40531f0$eb00000a@SAJAK> In-Reply-To: <006001c4edf8$f40531f0$eb00000a@SAJAK> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: "'IETF IPTEL WG'" , tu-sawada@kddi.com 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.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Shan Lu wrote: > Vijay, > > I like your proposal in spirit, but am weary of the (over)use of > "anonymous". Shan Lu: Sorry for the delayed response. Please see inline. > For everybody's benefit, you propose the following format when > calling party number is absent: > > Contact: , > > where the origination TG is "foo". [...] > OTOH, what we want is to convey to the recipient of Contact header the > following: the SIP URI userinfo in Contact is a "quasi-" tel URI in that any > subsequent fields following the first semi-colon must be treated as tel URI > parameters, including ";tgrp=". > > I believe a keyword different than "anonymous" serves this purpose better. > For example, we don't have to consider the subtle difference between > "presentation restricted" and "address unavailable". My suggestion is > "telurifmt", i.e.: > > Contact: . Personally, I have no problem with this; however, I am a little confused...I believe that we were avoiding registering a new token with IANA, hence "anonymous" was suggested since its use and semantics are well established in the field. Using "telurifmt" puts us back to the same place: what if "telurifmt" actually means something to someone? If you don't think this will be a problem, then I am more inclined to proceed on it and close this issue down. 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 Fri Jan 7 10:06:02 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 KAA18632 for ; Fri, 7 Jan 2005 10:06:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmvtf-0005KH-Dj for iptel-web-archive@ietf.org; Fri, 07 Jan 2005 10:19:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmvfV-00073Q-JG; Fri, 07 Jan 2005 10:04:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmvaC-0002rH-HB for iptel@megatron.ietf.org; Fri, 07 Jan 2005 09:59:20 -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 JAA18134 for ; Fri, 7 Jan 2005 09:59:18 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cmvn6-0004bE-Dn for iptel@ietf.org; Fri, 07 Jan 2005 10:12:47 -0500 Received: (qmail 62058 invoked by uid 1014); 7 Jan 2005 14:58:24 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.033121 secs); 07 Jan 2005 14:58:24 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 7 Jan 2005 14:58:24 -0000 From: "Shan Lu" To: "'Vijay K. Gurbani'" Subject: RE: [Iptel] Finalizing trunk-group I-D Date: Fri, 7 Jan 2005 09:59:51 -0500 Message-ID: <030a01c4f4c9$89f27a70$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <41DDA312.2070508@lucent.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: "'IETF IPTEL WG'" , tu-sawada@kddi.com 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.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] >On Behalf Of Vijay K. Gurbani >Sent: Thursday, January 06, 2005 3:44 PM >To: Shan Lu >Cc: 'IETF IPTEL WG'; tu-sawada@kddi.com >Subject: Re: [Iptel] Finalizing trunk-group I-D > > > >Personally, I have no problem with this; however, I am a >little confused...I believe that we were avoiding registering >a new token with IANA, hence "anonymous" was suggested since its use >and semantics are well established in the field. > True. But none of existing usages carries the same semantic we want for tgrp. Worse, they could interfere with each other. >Using "telurifmt" puts us back to the same place: what if >"telurifmt" actually means something to someone? > >If you don't think this will be a problem, then I am more >inclined to proceed on it and close this issue down. > Pick your favorite poison :-). My vote is for a new keyword different than "anonymous". Thanks, Shan Lu _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Jan 13 18:25:21 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 SAA05152 for ; Thu, 13 Jan 2005 18:25:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpEZU-0003jt-Tw for iptel-web-archive@ietf.org; Thu, 13 Jan 2005 18:40:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpEJ4-0003tr-W2; Thu, 13 Jan 2005 18:23:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpE3h-0000t2-Fl for iptel@megatron.ietf.org; Thu, 13 Jan 2005 18:07:17 -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 SAA03108 for ; Thu, 13 Jan 2005 18:07:14 -0500 (EST) Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpEI1-0003KH-5f for iptel@ietf.org; Thu, 13 Jan 2005 18:22:05 -0500 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 j0DN6iR2018948 for ; Thu, 13 Jan 2005 17:06:44 -0600 (CST) 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 j0DN6hr12697; Thu, 13 Jan 2005 17:06:43 -0600 (CST) Message-ID: <41E6FF04.9060100@lucent.com> Date: Thu, 13 Jan 2005 17:06:44 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) 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: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Subject: [Iptel] Is trunk group a new namespace? 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.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Folks, In order to close the last open issue with trunk-group, I had a series of email exchanges with the WG chairs, the results of which now need to go before the WG to decide how to move forward. The last open issue was how to resolve the case where an incoming call request does not have a calling party's number available. How do we indicate the originating trunk group? We had almost reached a solution in the form of the following URI: Contact: (the I-D exhorts originating trunk groups to go in the Contact header). In the email exchange with the WG chairs, Jonathan has suggested a couple of issues: first, the fact that a trunk group can exist without a phone number appears to imply that it is cannot be associated with a tel URI and may, in fact, indicate that this is a new resource complete with its own scheme. Something like: trgrp:trunk-group-id[:phone-number]@domain Second, saving the originating trunk group in the Contact header is not semantically correct; if the originating trunk group is to be used for routing, then Contact is not the semantically correct header to save this information in. Here is my take on these issues. The second one is easier to tackle, so let me try that first. Jonathan is accurate in pointing out the semantic use of Contact header. How- ever, we reached a decision long time ago in the life of the trunk-group I-D that we would like NOT to have parameters like ;o-tgrp=xxx;t-tgrp=yyy in the R-URI. Hence we decided to put the originating trunk group in the Contact header with the understanding that when it is used for routing in the reverse side, it will appear in the R-URI position. But what if it is used in routing on the initiating side? The first issue -- trunk-group being a new resource -- is an interesting one. It has ramificiations, if we decide to go that route. Where will it appear? In a new header(s)? as parameters to the R-URI or the Contact URI? We will need a short paragraph on how to convert trgrp URIs to sip URIs or tell URIs, ... So, we have some choices to make: Regarding putting originating trunk group information: do we want to leave it in the Contact header or find a new place for it? Regarding representing trunk group information itself: do we want hash out more abstractly the relationship between the trunk group and the phone number from a namespace prespective? To make matters worse, I will point out that we already have a few implementations that are following http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-02.txt. So depending on what we decide, the implementations will be impacted. Opinions and comments welcome. 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 Fri Jan 14 13:01:41 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 NAA01906 for ; Fri, 14 Jan 2005 13:01:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpW01-0000Aa-HO for iptel-web-archive@ietf.org; Fri, 14 Jan 2005 13:16:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpVeF-000403-FD; Fri, 14 Jan 2005 12:54:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpVb1-000321-Is for iptel@megatron.ietf.org; Fri, 14 Jan 2005 12:50:51 -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 MAA01329 for ; Fri, 14 Jan 2005 12:50:45 -0500 (EST) Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpVpQ-0008Qz-RG for iptel@ietf.org; Fri, 14 Jan 2005 13:05:46 -0500 Received: from localhost (smtp1.su.se [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id F310938169 for ; Fri, 14 Jan 2005 18:50:42 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20541-01-18 for ; Fri, 14 Jan 2005 18:50:35 +0100 (CET) Received: from [130.237.95.73] (choklad.it.su.se [130.237.95.73]) by smtp1.su.se (Postfix) with ESMTP id 9693D38063 for ; Fri, 14 Jan 2005 18:50:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: iptel@ietf.org From: =?ISO-8859-1?Q?Administrat=F6r?= Date: Fri, 14 Jan 2005 18:50:35 +0100 X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at av-in.su.se X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Subject: [Iptel] Implementing "language-switch" tag in CPL 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.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit I find the documentation of the language-switch tag (RFC3880 chapter 4.3) unclear. Lets take this example script (modified version of example in RFC 3880 chapter 12.5): ..... ..... ..... ..... There are several possible cases here: * the SIP request supplied no accept-language - execute the content of not-present. * the SIP request supplied accept-language that didn't match any of the languages, in this case spanish (es) and english (en) - execute the content of otherwise. * the SIP request supplied accept-language that matches e.g.: "Accept-Language: en, es;q=0.8 da;q=0.0" + if matching is done in regular switch order (as language-switch is documented to be a switch in the RFC - it's part of chapter 4 - "Switches") the first condition, would be matched so the caller would end up at a spanish operator, even though he/she has a higher q-value for "en" (= "en;q=1"). + This seams odd, as this would mean that the callers q-values are completely ignored, this interpretation also appears to be in contradiction with the statement "Languages with a 'q' value of 0 are also ignored." - RFC 3880 chapter 4.3. (why are q-value = 0 treated specially ?). + The HTTP 1.1 specification (in regards to accept-language) appears to imply that each condition is assigned a q-value - same as the matching language-range in the request or 0 if not supplied in the request. The condition with the largest q-value is then selected and executed - is this how it is supposed to work ? _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Jan 14 17:32:01 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 RAA02190 for ; Fri, 14 Jan 2005 17:32:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpaDf-0000eY-Qs for iptel-web-archive@ietf.org; Fri, 14 Jan 2005 17:47:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpZqA-0007MM-MD; Fri, 14 Jan 2005 17:22:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpZZq-0002qp-HE for iptel@megatron.ietf.org; Fri, 14 Jan 2005 17:05:54 -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 RAA29816 for ; Fri, 14 Jan 2005 17:05:52 -0500 (EST) Received: from cnr.cs.columbia.edu ([128.59.19.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpZoM-0008Sr-51 for iptel@ietf.org; Fri, 14 Jan 2005 17:20:54 -0500 Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j0EM5nPO020989; Fri, 14 Jan 2005 17:05:49 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j0EM5R8L020981; Fri, 14 Jan 2005 17:05:27 -0500 (EST) (envelope-from lennox) From: Jonathan Lennox Message-ID: <16872.16935.509579.820418@cnr.cs.columbia.edu> Date: Fri, 14 Jan 2005 17:05:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable To: =?ISO-8859-1?Q?Administrat=F6r?= Subject: Re: [Iptel] Implementing "language-switch" tag in CPL In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org 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.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable I agree that this is somewhat unfortunate. The problem is, fundamentally, that the "first-match" semantics of CPL switches don't mesh very well with the "best-match" semantics of HTTP/S= IP Accept-Language. To resolve this, I decided to just impose CPL's semantics, to keep CPL engines from having to scan an entire language-switch before deciding w= hich output to take. Conceivably this was the wrong choice; a CPL extension called something= like best-match-language-switch (in an appropriate namespace) might be in or= der. On Friday, January 14 2005, "Administrat=F6r" wrote to "iptel@ietf.org"= saying: > I find the documentation of the language-switch tag (RFC3880 chapter=20= > 4.3) unclear. Lets take this example script (modified version of=20 > example in RFC 3880 chapter 12.5): > =09..... > > > =09=09..... > > > > > > > > > > > > > > =09=09..... > > > =09..... >=20 > There are several possible cases here: >=20 > * the SIP request supplied no accept-language > - execute the content of not-present. >=20 > * the SIP request supplied accept-language that didn't match any of t= he=20 > languages, in this case spanish (es) and english (en) > - execute the content of otherwise. >=20 > * the SIP request supplied accept-language that matches e.g.: > "Accept-Language: en, es;q=3D0.8 da;q=3D0.0" >=20 > + if matching is done in regular switch order (as language-switch is=20= > documented to be a switch in the RFC - it's part of chapter 4 -=20 > "Switches") the first condition, would be=20= > matched so the caller would end up at a spanish operator, even though= =20 > he/she has a higher q-value for "en" (=3D "en;q=3D1"). >=20 > + This seams odd, as this would mean that the callers q-values are=20= > completely ignored, this interpretation also appears to be in=20 > contradiction with the statement "Languages with a 'q' value of 0 are= =20 > also ignored." - RFC 3880 chapter 4.3. (why are q-value =3D 0 treated= =20 > specially =3F). >=20 > + The HTTP 1.1 specification (in regards to accept-language) appears = to=20 > imply that each condition is assigned a=20= > q-value - same as the matching language-range in the request or 0 if=20= > not supplied in the request. The condition with the largest q-value i= s=20 > then selected and executed - is this how it is supposed to work =3F --=20 Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Jan 17 08:26:16 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 IAA03509 for ; Mon, 17 Jan 2005 08:26:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqX8f-00048w-Qq for iptel-web-archive@ietf.org; Mon, 17 Jan 2005 08:41:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqWoY-0003NR-BC; Mon, 17 Jan 2005 08:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqWiN-0002cw-0h for iptel@megatron.ietf.org; Mon, 17 Jan 2005 08:14: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 IAA02705 for ; Mon, 17 Jan 2005 08:14:36 -0500 (EST) Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqWxO-0003tk-UV for iptel@ietf.org; Mon, 17 Jan 2005 08:30:12 -0500 Received: from localhost (smtp1.su.se [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 1BD843810E; Mon, 17 Jan 2005 14:14:33 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14022-01-54; Mon, 17 Jan 2005 14:14:25 +0100 (CET) Received: from [130.237.95.73] (choklad.it.su.se [130.237.95.73]) by smtp1.su.se (Postfix) with ESMTP id 5B12838090; Mon, 17 Jan 2005 14:14:25 +0100 (CET) In-Reply-To: <16872.16935.509579.820418@cnr.cs.columbia.edu> References: <16872.16935.509579.820418@cnr.cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Administrat=F6r?= Subject: Re: [Iptel] Implementing "language-switch" tag in CPL Date: Mon, 17 Jan 2005 14:14:23 +0100 To: iptel@ietf.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at av-in.su.se X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: quoted-printable Cc: Jonathan Lennox 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.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable I don't have any real experience working in the RFC process, in regards to how and to what extent a RFC can be modified - but here are my thoughts and opinions about language-switches: * Replace it with "language-select", described below (or similar CPL Node). * Add "language-select" as some kind of extension. * is language-switch needed and truly useful or could it be made optional / removed from the RFC (3880) ?: - We, in this case Stockholm University how work on http://www.stacken.kth.se/projekt/yxa/ don't see any immediate need for this functionality, this may of course apply to other parties. - Are regular users actually going supply reasonable. "accepted-language" values, or will 90% of all phones send some kind of useless default or supply no values at all ? - For language-switch to be truly useful, almost all phone must supply correct values for "accepted-language", for CPL scripts to be able to rely on this information. ----------------------------------------------------------------------- Notes on proposed language-select below: * I tried to model it after "proxy" - with matching conditions "language" and "default" a no matching condition. ----------------------------------------------------------------------- Language Selects Language selects allow a CPL script to make decisions based on the languages in which the originator of the call wishes to communicate. They are summarized in Figure X. This a modified version of "language-switch" acting in a manner more compatible with other related RFCs like RFC 2616 (see chapter 14.4). Node: "language-select" Outputs: "language" Specific string to match Parameters: None Output: "language" Parameters: "matches" Match if the given language matches a language-range of the call. Output: "default" Parameters: none Figure X: Syntax of the "language-select" node Language selects take no parameters. The "language" output takes one parameter, "matches". The value of the parameter is a language-tag, as defined in RFC 3066. The caller may have specified a set of language-ranges, also as defined in RFC 3066. The match is done as follows: * Each language-tag (i.e. each "matches") is matched against the language-ranges supplied by the request, each language-tag value = is paired with the best "q" value found, "q" =3D 0 if no value was supplied. The "language" output with the best fit is then executed, best = fit: - select all "language"-"q" pairs, that have the maximum "q" = value. - select all the "language" outputs that have the highest number = of segements =3D number of "-" separators + 1. - if there are still identical matches the "language" output will be selected in the order they are declared in "language-select". * If no "language" output matches, the "default" output is selected. This happens if the request supplied no language information or if all the "language"-"q" pairs got "q" =3D 0. See RFC 3066 for the details of how language-ranges match language- tags. Briefly, a language-range matches a language-tag if it = exactly equals the tag, or if it exactly equals a prefix of the tag such = that the first character following the prefix is "-". If the caller specified the special language-range "*", it is = ignored for the purpose of matching. Languages with a "q" value of 0 are also ignored (). Usage of "language-select" with SIP The language-ranges for the "language-select" select are obtained from the SIP "Accept-Language" header field. The select is not- present if the initial SIP request did not contain this header = field. ----------------------------------------------------------------------- On 2005-01-14, at 23.05, Jonathan Lennox wrote: > I agree that this is somewhat unfortunate. > > The problem is, fundamentally, that the "first-match" semantics of CPL > switches don't mesh very well with the "best-match" semantics of=20 > HTTP/SIP > Accept-Language. > > To resolve this, I decided to just impose CPL's semantics, to keep CPL > engines from having to scan an entire language-switch before deciding=20= > which > output to take. > > Conceivably this was the wrong choice; a CPL extension called=20 > something like > best-match-language-switch (in an appropriate namespace) might be in=20= > order. > > On Friday, January 14 2005, "Administrat=F6r" wrote to = "iptel@ietf.org"=20 > saying: > >> I find the documentation of the language-switch tag (RFC3880 chapter >> 4.3) unclear. Lets take this example script (modified version of >> example in RFC 3880 chapter 12.5): >> ..... >> >> >> ..... >> >> >> >> >> >> >> >> >> >> >> >> >> >> ..... >> >> >> ..... >> >> There are several possible cases here: >> >> * the SIP request supplied no accept-language >> - execute the content of not-present. >> >> * the SIP request supplied accept-language that didn't match any of=20= >> the >> languages, in this case spanish (es) and english (en) >> - execute the content of otherwise. >> >> * the SIP request supplied accept-language that matches e.g.: >> "Accept-Language: en, es;q=3D0.8 da;q=3D0.0" >> >> + if matching is done in regular switch order (as language-switch is >> documented to be a switch in the RFC - it's part of chapter 4 - >> "Switches") the first condition, would be >> matched so the caller would end up at a spanish operator, even though >> he/she has a higher q-value for "en" (=3D "en;q=3D1"). >> >> + This seams odd, as this would mean that the callers q-values are >> completely ignored, this interpretation also appears to be in >> contradiction with the statement "Languages with a 'q' value of 0 are >> also ignored." - RFC 3880 chapter 4.3. (why are q-value =3D 0 treated >> specially ?). >> >> + The HTTP 1.1 specification (in regards to accept-language) appears=20= >> to >> imply that each condition is assigned a >> q-value - same as the matching language-range in the request or 0 if >> not supplied in the request. The condition with the largest q-value = is >> then selected and executed - is this how it is supposed to work ? > > --=20 > Jonathan Lennox > lennox@cs.columbia.edu > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Jan 17 12:22:19 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 MAA25141 for ; Mon, 17 Jan 2005 12:22:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqapC-0001X0-BQ for iptel-web-archive@ietf.org; Mon, 17 Jan 2005 12:37:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqaUE-00016v-HF; Mon, 17 Jan 2005 12:16:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqaFv-00061I-CP for iptel@megatron.ietf.org; Mon, 17 Jan 2005 12:01:31 -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 MAA23851 for ; Mon, 17 Jan 2005 12:01:28 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqaV0-00014T-Qe for iptel@ietf.org; Mon, 17 Jan 2005 12:17:07 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 17 Jan 2005 09:01:27 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [10.21.146.43] (sjc-vpn7-555.cisco.com [10.21.146.43]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0HH0t1M023791; Mon, 17 Jan 2005 09:00:56 -0800 (PST) Message-ID: <41EBEF46.6030500@cisco.com> Date: Mon, 17 Jan 2005 12:00:54 -0500 From: Flemming Andreasen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@ietf.org Subject: Re: [Iptel] Review of draft-ietf-iptel-tel-np-03.txt References: <41C74AE2.6000000@cisco.com> In-Reply-To: <41C74AE2.6000000@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA23851 Cc: Flemming Andreasen , Cullen Jennings , James Yu 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.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: quoted-printable Resend by request Flemming Andreasen wrote: > Greetings > > Below, please find review comments for draft-ietf-iptel-tel-np-03.txt.=20 > In general, I think the document is close to being done, but there are=20 > a few minor issues to address as well as some nits. > > > Non-Editorial > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > - Section 4, ABNF > The production for "global-hex-digits" ends with "*phonedigit-hex". I=20 > don't understand what that is for, not least considering the ensuing=20 > text for "local-rn" > > For a "local-rn", the routing number in the "rn" parameter MUST be > meaningful in terms of "rn-context". For example, if a national > routing number is in the "rn" parameter, the "rn-context" MUST > contain a valid E.164 country code after "+" if it is in the > "global-hex-digits" format. > > > > Section 5.1, 6th paragraph > "The network node SHALL ignore the "cic" parameter if it identifies a=20 > carrier or service provider associated with that node, or if that=20 > parameter contains a code for indicating that a geographic number is=20 > supplied (e.g., +1-0110 means "local, translated geographical=20 > telephone number provided"). ". Given the normative requirement, we=20 > either need some more text or references to explain how we determine=20 > if the parameter contains a code for indicating that a geographic=20 > number is supplied. > > Section 5.1, 6th paragraph > "The network node SHALL remove the "cic" parameter and look for the=20 > "rn" parameter for making the routing decision." I don't see why the=20 > network node SHALL remove the "cic" parameter and would in fact argue=20 > for at most a MAY. I agree it shall look for the "rn" parameter for=20 > making the routing decision though. > > Section 5.1, 9th and 10th paragraph. > Again, I don't see why "the network SHALL remove the "rn" parameter". > > Section 5.2.4, 1st paragraph > "A Public Switched Telephone Network (PSTN) gateway needs to convert > between SS7 ISUP and the VoIP protocol such as SIP or H.323. This > type of network node SHALL add the corresponding information from > the ISUP to the defined parameters to the "tel" URI for routing and > the "tel" URI associated with the caller and vice versa." > I disagree with the latter part ("and the "tel" URI associated with=20 > the caller and vice versa"). We are getting into privacy and security=20 > related issues and hence cannot make it mandatory for all. > > Section 7 > Need to add security considerations for using the extensions for the=20 > caller (JIP considerations) > > > Editorial and/or nits: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > - Global > Three spaces after period in several places. > Not sure if formatting adheres to RFC Editor guidelines (at least I=20 > can't get it to print with proper page breaks) > > - Abstract > Should not describe the actual extension parameters in the abstract=20 > but rather describe the problem and outline the solution. > > - Abstract "that NP database dip" =3D> "that an NP database dip" > ^^ > - Section 2, 1st paragraph > "It has been identified that NP has impacts on several=20 > works-in-progress at the IETF." =3D> > > "NP impacts call signaling." or something like that. > > - Section 2, 3rd paragraph > "call set up" =3D> "call setup" > > - Section 2, 5th paragraph > The sentence > "Section 5 describes the rules for a network node that deals with=20 > some or all of the defined parameters in a "tel" URI" > is not accurate since we are only talking about some specific=20 > extensions here. The phrase "defined parameters" is used throughout=20 > the document to refer to the extensions defined in this document. I'd=20 > suggest using another more accurate phrase throughout. > > - Section 4, 1st paragraph > Add some words explaining how this ABNF simply defines new parameters=20 > in accordance with the ABNF for "tel" URI provided in RFC 3966. > > - Section 4, 5th paragraph > "...the routing number in the "rn" parameter MUST be meaningful in=20 > terms of "rn-context". Although the example that follows helps clarify=20 > it for E.164 numbers, it is in general not well defined what=20 > "meamingful" means. Please rephrase to make it clearer. > > - Section 4, last paragraph > "...the CIC value in the "cic" parameter MUST be meaningful in terms=20 > of "cic-context". Semantics unclear - please rephrase to make it cleare= r. > > Section 5.1, 4th paragraph > "or routing information" =3D> "or routing number information" (?) > > Section 5.1, last paragraph > "making routing decision" =3D> "making routing decisions" > ^ > "set to do so or may route the call to a designated network node that=20 > will access the NP database or may route the call" =3D> > ^^ > "set to do so, it may route the call to a designated network node that=20 > will access the NP database, or it may route the call" > =20 > ^^^ = =20 > ^ ^^ > > Section 5.2.2, 6th paragraph > "telephone number that is the typical case for the second freephone=20 > database access, the" =3D> > > "telephone number (which is the typical case for the second freephone=20 > database access), the" > =20 > ^^^^^^ ^ > > Section 5.2.3, 2nd paragraph > "For example, if the network node is a PSTN gateway that receives an=20 > ISUP message that contains the JIP, the "rn" parameter in the "tel"=20 > URI would normally contain the correct location information." Please=20 > rephrase (it is the ISUP message that contains the correct location=20 > information which is therefore placed in the "rn" parameter in the=20 > "tel" URI). > > > Section 5.2.4, 2nd paragraph > "put it after the "tel:" in the "tel" URI that is used for routing" =3D= > > > "put it in the global-number-digits or local-number-digits (see RFC=20 > 3966) part of the "tel" URI that is used for routing" > =20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^ > > Section 5.2.4, 3rd paragraph > "put it after "tel:" in the "tel" URI that is used for routing" =3D> > > "put it in the global-number-digits or local-number-digits (see RFC=20 > 3966) part of the "tel" URI that is used for routing" > =20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^ > > Section 5.2.4, 3rd paragraph > "No "rn" SHALL appear in the "tel" URI." =3D> > > "An "rn" SHALL NOT appear in the "tel" URI." > ^^ ^^^ > > Section 5.2.4, 3rd paragraph > "It is outside the scope of this document how to include the "rn"=20 > parameter if the local policies require the network node to do so." I=20 > don't follow - the previous sentence just said that you are not=20 > allowed to do so. > > Section 6, example B > "provider=C6s" =3D> "provider's" > > Section 6, example E > " E. A "tel" URI, tel:+1-202-533-1234;rn=3D+1-202-000-0000;npdi, cont= ains > an invalid routing number (e.g., no routing information on "+1- > 202-000"), " > Example seems to assume prefix-based routing - might be good to=20 > clarify that. > > Section 8 and 9 > There are gaps in the reference numbers. In general, it would probably=20 > be better to use symbolic references instead of plain numbers. > 2806bis-09 is now RFC 3966. > > > -- Flemming > > > > _______________________________________________ > 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 Jan 17 14:15: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 OAA05078 for ; Mon, 17 Jan 2005 14:15:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqcab-0004PI-AS for iptel-web-archive@ietf.org; Mon, 17 Jan 2005 14:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqcKK-0002gW-6k; Mon, 17 Jan 2005 14:14:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqcDf-00028E-L2 for iptel@megatron.ietf.org; Mon, 17 Jan 2005 14:07:19 -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 OAA04642 for ; Mon, 17 Jan 2005 14:07:18 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqcSm-0004FP-8Y for iptel@ietf.org; Mon, 17 Jan 2005 14:22:56 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 17 Jan 2005 11:11:01 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0HJ6jvl016495; Mon, 17 Jan 2005 11:06:46 -0800 (PST) Received: from [10.86.17.4] (sjc-vpn4-350.cisco.com [10.21.81.94]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVQ49279; Mon, 17 Jan 2005 11:06:43 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 16 Jan 2005 14:42:19 -1000 Subject: Re: [Iptel] Is trunk group a new namespace? From: Cullen Jennings To: "Vijay K. Gurbani" , "iptel@ietf.org" Message-ID: In-Reply-To: <41E6FF04.9060100@lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit 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.4 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit inline comments - not as chair.. Summary - I am very against the new URI type idea. It is not deployable - more inline On 1/13/05 3:06 PM, "Vijay K. Gurbani" wrote: > Folks, > > In order to close the last open issue with trunk-group, I had > a series of email exchanges with the WG chairs, the > results of which now need to go before the WG to decide how to > move forward. > > The last open issue was how to resolve the case where an > incoming call request does not have a calling party's number > available. How do we indicate the originating trunk group? > > We had almost reached a solution in the form of the following > URI: Contact: (the > I-D exhorts originating trunk groups to go in the Contact > header). > I don't like the making up telurifmt as a special SIP user name. However, what the user port of a contact is is a GW local issue and not defined by SIP. The GW could put line1 or ds0-22 or a random number. This problem only comes up in the context of what originating information that is currently in the contact header. > In the email exchange with the WG chairs, Jonathan has > suggested a couple of issues: first, the fact that a trunk > group can exist without a phone number appears to imply that > it is cannot be associated with a tel URI and may, in fact, > indicate that this is a new resource complete with its > own scheme. Something like: > > trgrp:trunk-group-id[:phone-number]@domain The trunk group without a phone number would clearly be useless as a destination. As a GW source information, I'm not keen on it. Were would you put it? In the Contact header? You would have to map it to a sip URI to do this which would result in a SIP uri in the contact that looks almost identical to what everyone has already implemented. This would be a huge amount of work that in the end resulted in protocol on the wire that was semantically identical and differed by at most a few bits in syntax. I am really against the new URI type idea - many SIP elements support tel and the current proposal works in a backwards compatible way with all those devices. If we make a new trgrp URI, no proxy or UA will know about it or be able to do anything with it. There is no migration path from tel to trgrp until they are all replaced. No one will every do it because they are already using tel. > > Second, saving the originating trunk group in the Contact > header is not semantically correct; if the originating trunk > group is to be used for routing, then Contact is not the > semantically correct header to save this information in. > I'm not sure I agree with this. The Contact identifies the resource on the UA. The trunk group is part of the resource name on the GW. Saying you can only route on things in the request URI it totally bogus. I'll point at CPL for example. It is fine to route on many things in the SIP message. The contact header, as used in a registration if pretty fundamental to how requests get routed in SIP. GRU is going to work because some elements are going to look at tag in the contact and route based on them. > Here is my take on these issues. The second one is easier > to tackle, so let me try that first. Jonathan is accurate > in pointing out the semantic use of Contact header. How- > ever, we reached a decision long time ago in the life of > the trunk-group I-D that we would like NOT to have parameters > like ;o-tgrp=xxx;t-tgrp=yyy in the R-URI. Hence we > decided to put the originating trunk group in the Contact > header with the understanding that when it is used for > routing in the reverse side, it will appear in the R-URI > position. But what if it is used in routing on the initiating > side? > > The first issue -- trunk-group being a new resource -- > is an interesting one. It has ramificiations, if we decide > to go that route. Where will it appear? In a new header(s)? > as parameters to the R-URI or the Contact URI? We will need > a short paragraph on how to convert trgrp URIs to sip URIs > or tell URIs, ... > > So, we have some choices to make: > > Regarding putting originating trunk group information: do we > want to leave it in the Contact header or find a new place > for it? I view the originating trunk group as part of the name of the resource on the GW and thus reasonable to put in the contact. > > Regarding representing trunk group information itself: do we > want hash out more abstractly the relationship between the > trunk group and the phone number from a namespace prespective? > > To make matters worse, I will point out that we already have > a few implementations that are following > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-02.txt. > So depending on what we decide, the implementations will be impacted. > > Opinions and comments welcome. If someone can point out the harm that results in trunk group being a parameter of a tel URI that would be fixed by having a separate namespace, I would probably change my opinion. > > Thanks, > > - vijay Part of this discussion was brought up by the example of an IAM with no originating phone number but where the GW still sends an INVITE. In this case SIP does nto say what to put in the From but this is a SIP/tel problem not a trunk group problem. My proposal .... More or less keep what we have and Allow a trgp and phone-context parameter in a tel URI. Also allows these is a SIP uri even if that SIP URI is not mapable to a valid tel URI When this is seen in a contact, it identifies the PSTN associated resource on the GW identified by the contact header When this is seen in a request URI, it specifies the desired trunk group for reaching the PSTN resource identified in the request URI We have been discussing this for a long long time as a WG item. Unless someone has some specific harm or problem caused by the proposed solutions, I'm not keen on totally throwing it out. PS - I'm sick and can't think straight - I lost my crypto token and can't run my VPN so can't do email so have no idea when I will send this or receive responses. I reserve the option to claim my evil twin skip wrote this and I disagree with all of it :-) Someone convince me I'm nuts. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Jan 17 15:47:00 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 PAA13281 for ; Mon, 17 Jan 2005 15:47:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqe1I-0006mq-9E for iptel-web-archive@ietf.org; Mon, 17 Jan 2005 16:02:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqdiB-0007Bf-EK; Mon, 17 Jan 2005 15:42:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqdbO-0004JR-7D for iptel@megatron.ietf.org; Mon, 17 Jan 2005 15:35:54 -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 PAA12369 for ; Mon, 17 Jan 2005 15:35:52 -0500 (EST) Received: from cnr.cs.columbia.edu ([128.59.19.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqdqU-0006Oa-TK for iptel@ietf.org; Mon, 17 Jan 2005 15:51:32 -0500 Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j0HKZqMN032383; Mon, 17 Jan 2005 15:35:52 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j0HKZQ6N032375; Mon, 17 Jan 2005 15:35:26 -0500 (EST) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16876.8590.728956.264487@cnr.cs.columbia.edu> Date: Mon, 17 Jan 2005 15:35:26 -0500 To: =?ISO-8859-1?Q?Administrat=F6r?= Subject: Re: [Iptel] Implementing "language-switch" tag in CPL In-Reply-To: References: <16872.16935.509579.820418@cnr.cs.columbia.edu> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org 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.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable On Monday, January 17 2005, "Administrat=F6r" wrote to "iptel@ietf.org,= Jonathan Lennox" saying: > I don't have any real experience working in the RFC process, in regar= ds > to how and to what extent a RFC can be modified - but here are my > thoughts and opinions about language-switches: The best approach would be to define language-select (or whatever you w= ant to call it) as an extension to CPL. See section 11 of RFC 3880 for det= ails on how CPL extensions work. Since CPL extensions are defined using XML= namespaces, they don't necessarily have to go through the IETF standardization process (though if they're generally useful, I'd encour= age them to be). > - Are regular users actually going supply reasonable. > "accepted-language" values, or will 90% of all phones send some ki= nd > of useless default or supply no values at all =3F - For language-s= witch > to be truly useful, almost all phone must supply correct values fo= r > "accepted-language", for CPL scripts to be able to rely on this > information. This I don't know. If your implementation targets SIP, I'd suggest ask= ing on the SIP-Implementors mailing list. See . --=20 Jonathan Lennox lennox at cs dot columbia dot edu _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Jan 21 07:34:57 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 HAA05468 for ; Fri, 21 Jan 2005 07:34:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CryG2-0001cl-Ud for iptel-web-archive@ietf.org; Fri, 21 Jan 2005 07:51:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrxyF-00026n-Tg; Fri, 21 Jan 2005 07:32:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crxxe-0001xl-OW for iptel@megatron.ietf.org; Fri, 21 Jan 2005 07:32:22 -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 HAA05185 for ; Fri, 21 Jan 2005 07:32:21 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CryDW-0001Y1-V8 for iptel@ietf.org; Fri, 21 Jan 2005 07:48:47 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Jan 2005 05:39:48 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0LCVml2019583; Fri, 21 Jan 2005 04:31:48 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-154.cisco.com [10.86.242.154]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHE57995; Fri, 21 Jan 2005 04:31:46 -0800 (PST) Message-ID: <41F05879.1050106@cisco.com> Date: Thu, 20 Jan 2005 20:18:49 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Iptel] Is trunk group a new namespace? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: 7bit Cc: "iptel@ietf.org" , "Vijay K. Gurbani" 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.7 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: 7bit Also not as chair. I've considered this further, and concluded that here is a case where the pragmatic approach in the current draft is probably a better choice than the more theoretical considerations that led me to consider the idea of a new namespace. As such, I agree with everything cullen suggests, but disagree on one point. Cullen suggests: > Allow a trgp and phone-context parameter in a tel URI. > > Also allows these is a SIP uri even if that SIP URI is not mapable to a > valid tel URI I'd rather not do that. Instead, I'd rather declare this problem (indicating a trunk group without a phone number) as out of scope. This is not a tel URI issue at all - its an ISUP to SIP mapping issue. Our job is to define a way to extend the tel URI to be able to indicate trunk groups, and nothing more. Thanks, Jonathan R. Cullen Jennings wrote: > inline comments - not as chair.. > > Summary - I am very against the new URI type idea. It is not deployable - > more inline > > On 1/13/05 3:06 PM, "Vijay K. Gurbani" wrote: > > >>Folks, >> >>In order to close the last open issue with trunk-group, I had >>a series of email exchanges with the WG chairs, the >>results of which now need to go before the WG to decide how to >>move forward. >> >>The last open issue was how to resolve the case where an >>incoming call request does not have a calling party's number >>available. How do we indicate the originating trunk group? >> >>We had almost reached a solution in the form of the following >>URI: Contact: (the >>I-D exhorts originating trunk groups to go in the Contact >>header). >> > > > I don't like the making up telurifmt as a special SIP user name. However, > what the user port of a contact is is a GW local issue and not defined by > SIP. The GW could put line1 or ds0-22 or a random number. This problem only > comes up in the context of what originating information that is currently in > the contact header. > > >>In the email exchange with the WG chairs, Jonathan has >>suggested a couple of issues: first, the fact that a trunk >>group can exist without a phone number appears to imply that >>it is cannot be associated with a tel URI and may, in fact, >>indicate that this is a new resource complete with its >>own scheme. Something like: >> >> trgrp:trunk-group-id[:phone-number]@domain > > > The trunk group without a phone number would clearly be useless as a > destination. As a GW source information, I'm not keen on it. Were would you > put it? In the Contact header? You would have to map it to a sip URI to do > this which would result in a SIP uri in the contact that looks almost > identical to what everyone has already implemented. This would be a huge > amount of work that in the end resulted in protocol on the wire that was > semantically identical and differed by at most a few bits in syntax. > > I am really against the new URI type idea - many SIP elements support tel > and the current proposal works in a backwards compatible way with all those > devices. If we make a new trgrp URI, no proxy or UA will know about it or be > able to do anything with it. There is no migration path from tel to trgrp > until they are all replaced. No one will every do it because they are > already using tel. > > >>Second, saving the originating trunk group in the Contact >>header is not semantically correct; if the originating trunk >>group is to be used for routing, then Contact is not the >>semantically correct header to save this information in. >> > > > I'm not sure I agree with this. The Contact identifies the resource on the > UA. The trunk group is part of the resource name on the GW. Saying you can > only route on things in the request URI it totally bogus. I'll point at CPL > for example. It is fine to route on many things in the SIP message. The > contact header, as used in a registration if pretty fundamental to how > requests get routed in SIP. GRU is going to work because some elements are > going to look at tag in the contact and route based on them. > > > Here is my take on these issues. The second one is easier > >>to tackle, so let me try that first. Jonathan is accurate >>in pointing out the semantic use of Contact header. How- >>ever, we reached a decision long time ago in the life of >>the trunk-group I-D that we would like NOT to have parameters >>like ;o-tgrp=xxx;t-tgrp=yyy in the R-URI. Hence we >>decided to put the originating trunk group in the Contact >>header with the understanding that when it is used for >>routing in the reverse side, it will appear in the R-URI >>position. But what if it is used in routing on the initiating >>side? >> >>The first issue -- trunk-group being a new resource -- >>is an interesting one. It has ramificiations, if we decide >>to go that route. Where will it appear? In a new header(s)? >>as parameters to the R-URI or the Contact URI? We will need >>a short paragraph on how to convert trgrp URIs to sip URIs >>or tell URIs, ... >> >>So, we have some choices to make: >> >>Regarding putting originating trunk group information: do we >>want to leave it in the Contact header or find a new place >>for it? > > > I view the originating trunk group as part of the name of the resource on > the GW and thus reasonable to put in the contact. > > >>Regarding representing trunk group information itself: do we >>want hash out more abstractly the relationship between the >>trunk group and the phone number from a namespace prespective? >> >>To make matters worse, I will point out that we already have >>a few implementations that are following >>http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-02.txt. >>So depending on what we decide, the implementations will be impacted. >> >>Opinions and comments welcome. > > > If someone can point out the harm that results in trunk group being a > parameter of a tel URI that would be fixed by having a separate namespace, I > would probably change my opinion. > > >>Thanks, >> >>- vijay > > > > Part of this discussion was brought up by the example of an IAM with no > originating phone number but where the GW still sends an INVITE. In this > case SIP does nto say what to put in the From but this is a SIP/tel problem > not a trunk group problem. > > My proposal .... More or less keep what we have and > > Allow a trgp and phone-context parameter in a tel URI. > > Also allows these is a SIP uri even if that SIP URI is not mapable to a > valid tel URI > > When this is seen in a contact, it identifies the PSTN associated resource > on the GW identified by the contact header > > When this is seen in a request URI, it specifies the desired trunk group for > reaching the PSTN resource identified in the request URI > > We have been discussing this for a long long time as a WG item. Unless > someone has some specific harm or problem caused by the proposed solutions, > I'm not keen on totally throwing it out. > > PS - I'm sick and can't think straight - I lost my crypto token and can't > run my VPN so can't do email so have no idea when I will send this or > receive responses. I reserve the option to claim my evil twin skip wrote > this and I disagree with all of it :-) Someone convince me I'm nuts. > > > > > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Jan 21 11:22:24 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 LAA23854 for ; Fri, 21 Jan 2005 11:22:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1oC-0008R6-S6 for iptel-web-archive@ietf.org; Fri, 21 Jan 2005 11:38:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1RQ-0003qk-3P; Fri, 21 Jan 2005 11:15:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1Ge-0001Gy-Hr for iptel@megatron.ietf.org; Fri, 21 Jan 2005 11:04:12 -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 LAA22677 for ; Fri, 21 Jan 2005 11:04:10 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1WY-0007tP-4U for iptel@ietf.org; Fri, 21 Jan 2005 11:20:39 -0500 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 j0LG3ZsQ022137; Fri, 21 Jan 2005 10:03:36 -0600 (CST) 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 j0LG3Yh05935; Fri, 21 Jan 2005 10:03:34 -0600 (CST) Message-ID: <41F127D7.2030002@lucent.com> Date: Fri, 21 Jan 2005 10:03:35 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Iptel] Is trunk group a new namespace? References: <41F05879.1050106@cisco.com> In-Reply-To: <41F05879.1050106@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: Cullen Jennings , "iptel@ietf.org" 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.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Also not as chair. > > I've considered this further, and concluded that here is a case where > the pragmatic approach in the current draft is probably a better choice > than the more theoretical considerations that led me to consider the > idea of a new namespace. Jonathan: OK; pragmatism wins this one. > As such, I agree with everything cullen suggests, but disagree on one > point. Cullen suggests: > > > Allow a trgp and phone-context parameter in a tel URI. > > > > Also allows these is a SIP uri even if that SIP URI is not mapable to a > > valid tel URI > > I'd rather not do that. Instead, I'd rather declare this problem > (indicating a trunk group without a phone number) as out of scope. This > is not a tel URI issue at all - its an ISUP to SIP mapping issue. Our > job is to define a way to extend the tel URI to be able to indicate > trunk groups, and nothing more. As I have so learnt in the past couple of weeks, the calling number is optional in ISUP. So, I would also agree that mapping an absent ISUP parameter to a SIP element is an ISUP to SIP mapping issue and outside the scopr of the trunk-group I-D. I will consider this issue resolved, and will rev up the draft with the WGLC and other discussions shortly. 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 Fri Jan 21 11:45:41 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 LAA25952 for ; Fri, 21 Jan 2005 11:45:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2Ak-0000mJ-R5 for iptel-web-archive@ietf.org; Fri, 21 Jan 2005 12:02:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1lq-0000md-NN; Fri, 21 Jan 2005 11:36:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1cS-0006Qg-CQ for iptel@megatron.ietf.org; Fri, 21 Jan 2005 11: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 LAA24263 for ; Fri, 21 Jan 2005 11:26:42 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cs1sM-00006O-0Q for iptel@ietf.org; Fri, 21 Jan 2005 11:43:11 -0500 Received: (qmail 22183 invoked by uid 1014); 21 Jan 2005 16:25:49 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.033392 secs); 21 Jan 2005 16:25:49 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 21 Jan 2005 16:25:48 -0000 From: "Shan Lu" To: "'Jonathan Rosenberg'" , "'Cullen Jennings'" Subject: RE: [Iptel] Is trunk group a new namespace? Date: Fri, 21 Jan 2005 11:27:23 -0500 Message-ID: <003701c4ffd6$166134d0$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <41F05879.1050106@cisco.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org, "'Vijay K. Gurbani'" 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.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable All, First, I agree with the consensus that trunk group should not be a new namespace. More inline. >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]=20 >On Behalf Of Jonathan Rosenberg >Sent: Thursday, January 20, 2005 8:19 PM >To: Cullen Jennings >Cc: iptel@ietf.org; Vijay K. Gurbani >Subject: Re: [Iptel] Is trunk group a new namespace? > > >I'd rather not do that. Instead, I'd rather declare this problem=20 >(indicating a trunk group without a phone number) as out of=20 >scope.=20 Declaring out of scope does not make the problem go away, does it? I = would further argue that not solving the problem would severely limit the proposal's usability. Think of calls that requested privacy. A solution = that can fail on any given call is not a real solution. But you have a point that the I-D went out of its way to address the problem. The real issue, in my opinion, lies in RFC3966. Had 3966 = allowed tel uri to have empty phone digits (but meaningful parameters), we won't have this discussion at all. As a side note, sip uri allows completely = bogus userinfo/hostport but valid uri parameters. The proposal in the I-D may be ugly and the I-D may even be the wrong = avenue to address the issue. But that's what you get for not doing right at = first try in 3966. Not to mention it does solve a real issue. Regards, Shan Lu _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Jan 21 11:49:59 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 LAA26306 for ; Fri, 21 Jan 2005 11:49:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2Es-0000ux-2v for iptel-web-archive@ietf.org; Fri, 21 Jan 2005 12:06:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1xQ-0004J4-5W; Fri, 21 Jan 2005 11:48:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1mE-0000pC-Pd for iptel@megatron.ietf.org; Fri, 21 Jan 2005 11:36:50 -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 LAA25368 for ; Fri, 21 Jan 2005 11:36:48 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs228-0000UL-IE for iptel@ietf.org; Fri, 21 Jan 2005 11:53:17 -0500 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 j0LGaGSf028958; Fri, 21 Jan 2005 10:36:16 -0600 (CST) 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 j0LGaFh03243; Fri, 21 Jan 2005 10:36:15 -0600 (CST) Message-ID: <41F12F80.5040109@lucent.com> Date: Fri, 21 Jan 2005 10:36:16 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shan Lu Subject: Re: [Iptel] Is trunk group a new namespace? References: <003701c4ffd6$166134d0$eb00000a@SAJAK> In-Reply-To: <003701c4ffd6$166134d0$eb00000a@SAJAK> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, Cullen Jennings 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.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Shan Lu wrote: > Declaring out of scope does not make the problem go away, does it? > I would further argue that not solving the problem would severely > limit the proposal's usability. Think of calls that requested > privacy. A solution that can fail on any given call is not > a real solution. Cullen, in an earlier email, wrote the following which I think is worth bringing up: Now the problem came up when trying to overload where a call came from into the contact header field value. In this case people are trying to specify the trunk group but leave the telephone number unspecified. However, the contact identifies the GW (and the trunk group on GW) - it does not necessarily identify the PSTN endpoint that called the originating GW. The From would identify the originating endpoint on the PSTN. Keep in mind the calling party in the IAM gets mapped to the From not the contact header - it is a far end issue. The trunk group, which is a local to the GW issues, is what makes sense to map into the contact for the GW. A GW could form the user portion of the contact by just saying which DS0 was in use and adding the logical trunk group. The last sentence above provides a decent way out to generate a user portion and add the trunk-group parameters to it without us having to mandate a certain user token. - 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 Fri Jan 21 14:06:53 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 OAA06704 for ; Fri, 21 Jan 2005 14:06:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4NO-0004oC-Vx for iptel-web-archive@ietf.org; Fri, 21 Jan 2005 14:23:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs3xQ-0007jn-JD; Fri, 21 Jan 2005 13:56:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs3vY-00071T-CT for iptel@megatron.ietf.org; Fri, 21 Jan 2005 13:54:36 -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 NAA05760 for ; Fri, 21 Jan 2005 13:54:35 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cs4BU-0004PV-E4 for iptel@ietf.org; Fri, 21 Jan 2005 14:11:04 -0500 Received: (qmail 48117 invoked by uid 1014); 21 Jan 2005 18:54:05 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.034488 secs); 21 Jan 2005 18:54:05 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 21 Jan 2005 18:54:05 -0000 From: "Shan Lu" To: "'Vijay K. Gurbani'" Subject: RE: [Iptel] Is trunk group a new namespace? Date: Fri, 21 Jan 2005 13:55:39 -0500 Message-ID: <004701c4ffea$cd0036f0$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <41F12F80.5040109@lucent.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org, "'Cullen Jennings'" 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.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Vijay, Is it the proposal to use the following: Contact:, where DS0 number is 1 and TG is 2? The why don't you use the same format even when calling number is = available? I have no issue with it, but don't call it tel-uri because it isn't. Regards,=20 Shan Lu >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]=20 >On Behalf Of Vijay K. Gurbani >Sent: Friday, January 21, 2005 11:36 AM >To: Shan Lu >Cc: iptel@ietf.org; Cullen Jennings >Subject: Re: [Iptel] Is trunk group a new namespace? > > >Shan Lu wrote: >> Declaring out of scope does not make the problem go away, does it?=20 >> I would further argue that not solving the problem would severely=20 >> limit the proposal's usability. Think of calls that requested=20 >> privacy. A solution that can fail on any given call is not=20 >> a real solution. > >Cullen, in an earlier email, wrote the following which I think is >worth bringing up: > > Now the problem came up when trying to overload where a call > came from into the contact header field value. In this case > people are trying to specify the trunk group but leave the > telephone number unspecified. However, the contact identifies > the GW (and the trunk group on GW) - it does not necessarily > identify the PSTN endpoint that called the originating GW. > The From would identify the originating endpoint on the PSTN. > Keep in mind the calling party in the IAM gets mapped to the > From not the contact header - it is a far end issue. The > trunk group, which is a local to the GW issues, is what makes > sense to map into the contact for the GW. A GW could form the > user portion of the contact by just saying which DS0 was in > use and adding the logical trunk group. > >The last sentence above provides a decent way out to generate a >user portion and add the trunk-group parameters to it without >us having to mandate a certain user token. > >- vijay >--=20 >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 From iptel-bounces@ietf.org Fri Jan 21 15:33:07 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 PAA16339 for ; Fri, 21 Jan 2005 15:33:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs5is-0007gG-3a for iptel-web-archive@ietf.org; Fri, 21 Jan 2005 15:49:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs5Lt-0007N7-6O; Fri, 21 Jan 2005 15:25:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs5IP-0005Lb-QL for iptel@megatron.ietf.org; Fri, 21 Jan 2005 15:22:17 -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 PAA15130 for ; Fri, 21 Jan 2005 15:22:16 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs5YL-0007Ll-Gz for iptel@ietf.org; Fri, 21 Jan 2005 15:38:47 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j0LKLBV2022283; Fri, 21 Jan 2005 14:21:12 -0600 (CST) 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 j0LKLAh25059; Fri, 21 Jan 2005 14:21:10 -0600 (CST) Message-ID: <41F16437.7070602@lucent.com> Date: Fri, 21 Jan 2005 14:21:11 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shan Lu Subject: Re: [Iptel] Is trunk group a new namespace? References: <004701c4ffea$cd0036f0$eb00000a@SAJAK> In-Reply-To: <004701c4ffea$cd0036f0$eb00000a@SAJAK> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, "'Cullen Jennings'" 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.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Shan Lu wrote: > Vijay, > > Is it the proposal to use the following: > > Contact:, where DS0 number is 1 and TG is 2? Yes, something to that effect. I will flesh it out further in the rev'd I-D. > The why don't you use the same format even when calling number > is available? The I-D, as it currently stands, is focused on where to place the originating trunk group, not what the user part of the Contact SIP URI should be. If an implementation wants to substitute something other than the calling party number (if present), they can do so. On the other hand, if the calling party number is not present, the next rev of the I-D will provide some guidelines on what to populate in the user part. > I have no issue with it, but don't call it tel-uri because it isn't. I like your "no issue with it" part ;-) 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 Sat Jan 22 00:24:24 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 AAA22956 for ; Sat, 22 Jan 2005 00:24:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsE16-0004eI-MP for iptel-web-archive@ietf.org; Sat, 22 Jan 2005 00:41:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsDji-0004yz-22; Sat, 22 Jan 2005 00:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsDgQ-0003B0-9u for iptel@megatron.ietf.org; Sat, 22 Jan 2005 00:19:38 -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 AAA22693 for ; Sat, 22 Jan 2005 00:19:35 -0500 (EST) From: shanlu@sentito.com Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CsDwQ-0004WT-Bp for iptel@ietf.org; Sat, 22 Jan 2005 00:36:11 -0500 Received: (qmail 42830 invoked by uid 1014); 22 Jan 2005 05:19:05 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(127.0.0.1):. Processed in 0.032843 secs); 22 Jan 2005 05:19:05 -0000 Received: from unknown (HELO webmail.sentito.com) (127.0.0.1) by airwolf.sentito.com with SMTP; 22 Jan 2005 05:19:05 -0000 Received: from 4.249.138.117 (SquirrelMail authenticated user shanlu) by webmail.sentito.com with HTTP; Sat, 22 Jan 2005 00:19:05 -0500 (EST) Message-ID: <1657.4.249.138.117.1106371145.squirrel@webmail.sentito.com> In-Reply-To: <004701c4ffea$cd0036f0$eb00000a@SAJAK> References: <41F12F80.5040109@lucent.com> <004701c4ffea$cd0036f0$eb00000a@SAJAK> Date: Sat, 22 Jan 2005 00:19:05 -0500 (EST) Subject: RE: [Iptel] Is trunk group a new namespace? To: iptel@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 1.2 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 8bit Cc: "'Vijay K. Gurbani'" 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: 1.2 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 8bit >From: Vijay K. Gurbani >To: Shan Lu >CC: iptel@ietf.org, Cullen Jennings >Date: Jan 21, 2005 - 3:32pm >Shan Lu wrote: >> Vijay, >> >> Is it the proposal to use the following: >> >> Contact:, where DS0 number is 1 and TG is 2? >Yes, something to that effect. I will flesh it out further >in the rev'd I-D. Wait. Doesn't this take a full circle back to our earlier discussion? I thought we agreed upon the need for a keyword, such as "anonymous" or "teluri", no? Without such a keyword, how do you inform recipient of the above sip uri that "tgrp" stands for "Trunk Group" and not "The Gourmet Roasted Pizza"? Unless you think the DS0 number is sufficient. Regards, Shan Lu _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Sun Jan 23 00:18: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 AAA04992 for ; Sun, 23 Jan 2005 00:18:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsaOq-0006yB-ET for iptel-web-archive@ietf.org; Sun, 23 Jan 2005 00:35:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csa4J-0007ZS-Ko; Sun, 23 Jan 2005 00:13:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csa2T-0006ql-RY for iptel@megatron.ietf.org; Sun, 23 Jan 2005 00:11:54 -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 AAA04742 for ; Sun, 23 Jan 2005 00:11:51 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsaIi-0006pe-8h for iptel@ietf.org; Sun, 23 Jan 2005 00:28:40 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 22 Jan 2005 22:19:37 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0N5BAM8003691; Sat, 22 Jan 2005 21:11:11 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-197.cisco.com [10.86.240.197]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHF32564; Sat, 22 Jan 2005 21:11:09 -0800 (PST) Message-ID: <41F331ED.8050600@cisco.com> Date: Sun, 23 Jan 2005 00:11:09 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: shanlu@sentito.com Subject: Re: [Iptel] Is trunk group a new namespace? References: <41F12F80.5040109@lucent.com> <004701c4ffea$cd0036f0$eb00000a@SAJAK> <1657.4.249.138.117.1106371145.squirrel@webmail.sentito.com> In-Reply-To: <1657.4.249.138.117.1106371145.squirrel@webmail.sentito.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, "'Vijay K. Gurbani'" 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.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Actually, I don't see why its needed to specify any kind of keyword at all. Let us remember that we are talking about the contact header field. As Cullen has pointed out, it doesn't identify the originator but rather a port on a gateway. As such, just because there was no calling number doesn't mean one could not use a tel URI to identify the gateway line. Seems like something of the form: tel:;phone-context="" would suffice, in which case one could add a trunk group to this and then turn it into a sip uri: sip:732766;phone-context=provider.com;tgrp=TG-1@provider.com;user=phone I don't think that we need to say anything about how the tel URI is constructed, merely that any URI that is a reasonable descriptor for the gateway "port" resource itself will suffice. -Jonathan R. shanlu@sentito.com wrote: >>From: Vijay K. Gurbani >>To: Shan Lu >>CC: iptel@ietf.org, Cullen Jennings >>Date: Jan 21, 2005 - 3:32pm > > >>Shan Lu wrote: >> >>>Vijay, >>> >>>Is it the proposal to use the following: >>> >>>Contact:, where DS0 number is 1 and TG is 2? > > >>Yes, something to that effect. I will flesh it out further >>in the rev'd I-D. > > > Wait. Doesn't this take a full circle back to our earlier discussion? I > thought we agreed upon the need for a keyword, such as "anonymous" or > "teluri", no? > > Without such a keyword, how do you inform recipient of the above sip uri > that "tgrp" stands for "Trunk Group" and not "The Gourmet Roasted Pizza"? > Unless you think the DS0 number is sufficient. > > Regards, > > Shan Lu > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Sun Jan 23 09:53:29 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 JAA16971 for ; Sun, 23 Jan 2005 09:53:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsjNf-0003xe-DC for iptel-web-archive@ietf.org; Sun, 23 Jan 2005 10:10:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csj6A-0004DW-NB; Sun, 23 Jan 2005 09:52:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csj5V-00047z-VH for iptel@megatron.ietf.org; Sun, 23 Jan 2005 09:51:37 -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 JAA16886 for ; Sun, 23 Jan 2005 09:51:36 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsjLo-0003uM-Iw for iptel@ietf.org; Sun, 23 Jan 2005 10:08:29 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 23 Jan 2005 06:52:59 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0NEoiRi012943; Sun, 23 Jan 2005 06:51:03 -0800 (PST) Received: e2k4.cisco.com 171.70.93.57 from 10.21.80.13 10.21.80.13 via HTTP with MS-WebStorage 6.5.6944 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 22 Jan 2005 20:15:55 -0800 Subject: Re: [Iptel] Is trunk group a new namespace? From: Cullen Jennings To: "Vijay K. Gurbani" , Jonathan Rosenberg Message-ID: In-Reply-To: <41F127D7.2030002@lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: "iptel@ietf.org" 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.6 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit On 1/21/05 6:03 AM, "Vijay K. Gurbani" wrote: >> I'd rather not do that. Instead, I'd rather declare this problem >> (indicating a trunk group without a phone number) as out of scope. This >> is not a tel URI issue at all - its an ISUP to SIP mapping issue. Our >> job is to define a way to extend the tel URI to be able to indicate >> trunk groups, and nothing more. > > As I have so learnt in the past couple of weeks, the calling number > is optional in ISUP. So, I would also agree that mapping an > absent ISUP parameter to a SIP element is an ISUP to SIP mapping > issue and outside the scopr of the trunk-group I-D. > > I will consider this issue resolved, and will rev up the draft > with the WGLC and other discussions shortly. This sounds like the best path forward to me. I'm happy with this. Cullen - not as chair. Actually as chair, after listening to all the options, I really think this is the only path that has a good chance of closing this issues anytime in next year to two. Given the WG desire to finish this work, I think this is the best path forward with my chair hat on too :-) _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Sun Jan 23 09:55:10 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 JAA17050 for ; Sun, 23 Jan 2005 09:55:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsjPI-0003yu-9N for iptel-web-archive@ietf.org; Sun, 23 Jan 2005 10:12:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csj6A-0004Db-VF; Sun, 23 Jan 2005 09:52:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csj5W-000481-Er for iptel@megatron.ietf.org; Sun, 23 Jan 2005 09:51:38 -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 JAA16889 for ; Sun, 23 Jan 2005 09:51:36 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsjLq-0003uM-3d for iptel@ietf.org; Sun, 23 Jan 2005 10:08:30 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 23 Jan 2005 06:53:01 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0NEoiRk012943; Sun, 23 Jan 2005 06:51:05 -0800 (PST) Received: e2k4.cisco.com 171.70.93.57 from 10.21.80.13 10.21.80.13 via HTTP with MS-WebStorage 6.5.6944 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 23 Jan 2005 06:49:21 -0800 Subject: Re: [Iptel] Is trunk group a new namespace? From: Cullen Jennings To: Shan Lu , Jonathan Rosenberg Message-ID: In-Reply-To: <003701c4ffd6$166134d0$eb00000a@SAJAK> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: "iptel@ietf.org" , "Vijay K. Gurbani" 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.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit On 1/21/05 6:27 AM, "Shan Lu" wrote: > > But you have a point that the I-D went out of its way to address the > problem. The real issue, in my opinion, lies in RFC3966. Had 3966 allowed > tel uri to have empty phone digits (but meaningful parameters), we won't > have this discussion at all. As a side note, sip uri allows completely bogus > userinfo/hostport but valid uri parameters. Not as chair... The issue with a tel URI with no telephone number is that the semantics of what you do with are unclear. Imagine a HTTP URI with no host. What does it mean? My personally view that is unless we explain to the IESG what it means they are likely to tell we are doing the wrong thing and go invent a new URI type - this is a long road. It's true that for some problems, all you need is trunk group information. I think this draft on trunk group attributes on a tel is not attempting to solve that class of problems. Something else can be done to solve them. However, having trunk group information attributes with a tel is useful for some other problems and that is what this is well defined for. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Jan 24 11:54:54 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 LAA29313 for ; Mon, 24 Jan 2005 11:54:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7kw-00031v-4C for iptel-web-archive@ietf.org; Mon, 24 Jan 2005 12:12:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7Kc-0006UJ-Ho; Mon, 24 Jan 2005 11:44:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7Fr-0005SJ-4R for iptel@megatron.ietf.org; Mon, 24 Jan 2005 11:39:55 -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 LAA28257 for ; Mon, 24 Jan 2005 11:39:52 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ct7WM-0002TO-0z for iptel@ietf.org; Mon, 24 Jan 2005 11:57:00 -0500 Received: (qmail 44298 invoked by uid 1014); 24 Jan 2005 16:39:11 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.0366 secs); 24 Jan 2005 16:39:11 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 24 Jan 2005 16:39:10 -0000 From: "Shan Lu" To: "'Jonathan Rosenberg'" Subject: RE: [Iptel] Is trunk group a new namespace? Date: Mon, 24 Jan 2005 11:40:44 -0500 Message-ID: <003f01c50233$72e31700$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <41F331ED.8050600@cisco.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, "'Vijay K. Gurbani'" 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.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Jonathan, While I like the practical side of the proposal, two observations came to mind: 1. It is not at all clear that contact header is limited to gateway "port" resource. RFC3398 does not say so. The rest of the TG draft actually uses contact to mean calling party tel-uri. I would venture to guess that most existing ISUP gateways use contact header to indicate IAM calling party attribute in some shape or form. 2. We now have created one precedence where a tel uri is only a tel uri in syntax that is not intended to represent any real telephone resource. I believe it is important that the TG draft say something on how such tel uri can be formed in contact header. Further it must point out the possibility that tel uri contained in contact header may not be a real tel uri. BTW, I think it is even less likely to have calling exchange's LRN in IAM (if I interpret your example correctly). Regards, Shan Lu >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] >On Behalf Of Jonathan Rosenberg >Sent: Sunday, January 23, 2005 12:11 AM >To: shanlu@sentito.com >Cc: iptel@ietf.org; 'Vijay K. Gurbani' >Subject: Re: [Iptel] Is trunk group a new namespace? > > >Actually, I don't see why its needed to specify any kind of >keyword at all. > >Let us remember that we are talking about the contact header field. As >Cullen has pointed out, it doesn't identify the originator but >rather a >port on a gateway. As such, just because there was no calling number >doesn't mean one could not use a tel URI to identify the gateway line. >Seems like something of the form: > >tel:;phone-context="" > >would suffice, in which case one could add a trunk group to this and >then turn it into a sip uri: > >sip:732766;phone-context=provider.com;tgrp=TG-1@provider.com;user=phone > > >I don't think that we need to say anything about how the tel URI is >constructed, merely that any URI that is a reasonable >descriptor for the >gateway "port" resource itself will suffice. > >-Jonathan R. > > > >shanlu@sentito.com wrote: > >>>From: Vijay K. Gurbani >>>To: Shan Lu >>>CC: iptel@ietf.org, Cullen Jennings >>>Date: Jan 21, 2005 - 3:32pm >> >> >>>Shan Lu wrote: >>> >>>>Vijay, >>>> >>>>Is it the proposal to use the following: >>>> >>>>Contact:, where DS0 number is 1 and TG is 2? >> >> >>>Yes, something to that effect. I will flesh it out further >>>in the rev'd I-D. >> >> >> Wait. Doesn't this take a full circle back to our earlier >discussion? I >> thought we agreed upon the need for a keyword, such as "anonymous" or >> "teluri", no? >> >> Without such a keyword, how do you inform recipient of the >above sip uri >> that "tgrp" stands for "Trunk Group" and not "The Gourmet >Roasted Pizza"? >> Unless you think the DS0 number is sufficient. >> >> Regards, >> >> Shan Lu >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Director, Service Provider VoIP Architecture Parsippany, NJ >07054-2711 >Cisco Systems >jdrosen@cisco.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.cisco.com > >_______________________________________________ >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 Jan 24 12:21: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 MAA03121 for ; Mon, 24 Jan 2005 12:21:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8AN-0004AI-5p for iptel-web-archive@ietf.org; Mon, 24 Jan 2005 12:38:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7bJ-00025w-FX; Mon, 24 Jan 2005 12:02:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7WN-0000x9-NM for iptel@megatron.ietf.org; Mon, 24 Jan 2005 11:56:59 -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 LAA29636 for ; Mon, 24 Jan 2005 11:56:56 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ct7mt-000380-RS for iptel@ietf.org; Mon, 24 Jan 2005 12:14:05 -0500 Received: (qmail 47102 invoked by uid 1014); 24 Jan 2005 16:56:26 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.034022 secs); 24 Jan 2005 16:56:26 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 24 Jan 2005 16:56:26 -0000 From: "Shan Lu" To: "'Cullen Jennings'" , "'Jonathan Rosenberg'" Subject: RE: [Iptel] Is trunk group a new namespace? Date: Mon, 24 Jan 2005 11:58:00 -0500 Message-ID: <004001c50235$dc394470$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org, "'Vijay K. Gurbani'" 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.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cullen, Agreed - I wasn't suggesting the long road. Just wanted to have a tel = uri similar to sip:invalid@invalid.net. For instance, "tel:-;phone-context=3Dinternal" could be useful to indicate attributes = of the resource w/o having to reveal the number. But wasn't suggesting to = modify 3966. Regards, Shan Lu >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]=20 >On Behalf Of Cullen Jennings >Sent: Sunday, January 23, 2005 9:49 AM >To: Shan Lu; Jonathan Rosenberg >Cc: iptel@ietf.org; Vijay K. Gurbani >Subject: Re: [Iptel] Is trunk group a new namespace? > > >On 1/21/05 6:27 AM, "Shan Lu" wrote: > >>=20 >> But you have a point that the I-D went out of its way to address the >> problem. The real issue, in my opinion, lies in RFC3966. Had=20 >3966 allowed >> tel uri to have empty phone digits (but meaningful=20 >parameters), we won't >> have this discussion at all. As a side note, sip uri allows=20 >completely bogus >> userinfo/hostport but valid uri parameters. > >Not as chair... > >The issue with a tel URI with no telephone number is that the=20 >semantics of >what you do with are unclear. Imagine a HTTP URI with no host.=20 >What does it >mean? My personally view that is unless we explain to the IESG=20 >what it means >they are likely to tell we are doing the wrong thing and go=20 >invent a new URI >type - this is a long road. > >It's true that for some problems, all you need is trunk group=20 >information. I >think this draft on trunk group attributes on a tel is not=20 >attempting to >solve that class of problems. Something else can be done to solve them. >However, having trunk group information attributes with a tel=20 >is useful for >some other problems and that is what this is well defined for.=20 > >_______________________________________________ >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