From iptel-bounces@ietf.org Sat Apr 08 11:40:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSFXt-00017B-Tx; Sat, 08 Apr 2006 11:40:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSFXs-000173-DS; Sat, 08 Apr 2006 11:40:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSFXr-0008Mh-59; Sat, 08 Apr 2006 11:40:16 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k38FeE0e026183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Apr 2006 15:40:14 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FSFXq-0002dj-L4; Sat, 08 Apr 2006 11:40:14 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Sat, 08 Apr 2006 11:40:14 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: iptel@ietf.org Subject: [Iptel] Last Call: 'Number Portability Parameters for the "tel" URI' to Proposed Standard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org The IESG has received a request from the IP Telephony WG to consider the following document: - 'Number Portability Parameters for the "tel" URI ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-np-09.txt _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Apr 18 08:08:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp0P-0003aA-Ou; Tue, 18 Apr 2006 08:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp0O-0003ZR-ET for iptel@ietf.org; Tue, 18 Apr 2006 08:08:28 -0400 Received: from smtp12.clb.oleane.net ([213.56.31.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVp0N-00026E-1n for iptel@ietf.org; Tue, 18 Apr 2006 08:08:28 -0400 Received: from Pavillonquatre ([194.3.133.88]) by smtp12.clb.oleane.net with ESMTP id k3IC8P4D018770 for ; Tue, 18 Apr 2006 14:08:25 +0200 Message-Id: <200604181208.k3IC8P4D018770@smtp12.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 18 Apr 2006 14:07:22 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZi4KXwkKMknOqRQcyGDMzjv9lD5g== X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [Iptel] Mobile TV World Congress 2007 - Paris - France X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0725129814==" Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0725129814== Content-Type: multipart/alternative; boundary="----=_NextPart_000_05B0_01C662F1.69F28660" This is a multi-part message in MIME format. ------=_NextPart_000_05B0_01C662F1.69F28660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The Mobile TV World Congress, will be held in Paris January 23 to 26, together with the worldwide leader event TVoDSL 2007. Carriers, content providers and equipment vendors will address technical issues, describe the standardization process and discuss business and content delivery models. A call for proposals is online at: http://www.upperside.fr/mobiletv2007/mobiletv2007intro.htm ------=_NextPart_000_05B0_01C662F1.69F28660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Mobile TV World = Congress, will be held in Paris January 23 to 26, together with the worldwide leader event = TVoDSL = 2007.

Carriers, content providers and equipment = vendors will address technical issues, describe the standardization process and = discuss business and content delivery models.

 

A call for proposals is online = at:

http://www.upperside.fr/mobiletv2007/mobiletv2007intro.htm

 

------=_NextPart_000_05B0_01C662F1.69F28660-- --===============0725129814== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0725129814==-- From iptel-bounces@ietf.org Wed Apr 26 08:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYjGF-0006GY-LQ; Wed, 26 Apr 2006 08:36:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYjGE-0006GQ-Fc; Wed, 26 Apr 2006 08:36:50 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYjGB-0001wk-SB; Wed, 26 Apr 2006 08:36:50 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3QCajM06871; Wed, 26 Apr 2006 08:36:45 -0400 (EDT) Received: from [127.0.0.1] ([47.153.168.80] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 08:36:44 -0400 Message-ID: <444F6947.7060608@nortel.com> Date: Wed, 26 Apr 2006 21:36:23 +0900 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: gen-art@ietf.org, iptel@ietf.org, br@brianrosen.net, "Peterson, Jon" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2006 12:36:44.0587 (UTC) FILETIME=[13A8A7B0:01C6692E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Subject: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org I am the assigned Gen-ART reviewer for draft-rosen-iptel-dialstring-03.txt. For background on Gen-ART, please see the FAQ at . This draft is basically acceptable, but needs a few fixes. I have also identified a number of editorial issues. I suppose I'm going to get hell for not reviewing this draft in the two years it has been around, but better late than never. Substantive comments: ===================== 1. I believe the problem is mis-stated in the second paragraph of section 1. Ignoring the matter of RFC 2806-based implementations, the user part of a SIP URI with the "user=phone" parameter is, without ambiguity, a phone number. The real problem is that before the transformation occurs (and the "user=phone" parameter is added if applicable), entities beyond the originating point cannot distinguish between a dial string and an user part that happens to consist of the characters that can be present in a dial string. I suggest that the second paragraph be replaced by the following: "There is a problem here. The intermediary can apply its transformation only if it recognizes that the user part of the SIP URI is a dial string. However, there is currently no way to distinguish an user part consisting of a dial string from an user part that happens to be composed of characters that would appear in a dial string." It is also necessary to change the second-last requirement in section 3 as follows: Current text: " It MUST be possible to distinguish between a dialstring and a phone number." New text: " It MUST be possible to distinguish between a dialstring and an user part that happens to consist of the same characters." 2. The requirement in section 3 that a context be present is unmotivated. I suggest adding the following sentence at the end of the first paragraph of section 1: " The intermediary is able to perform this transform provided that it knows the context (i.e., dialling plan) within which the number was dialled." 3. In section 3, a dial string is defined to consist of a certain set of characters, but then the requirement to convey pause and "wait for call completion" is added. It would be cleaner to include the characters for the latter functions in the definition of dial string in the first place. I therefore suggest the following changes: -- move the requirement to represent pause and "wait for call completion" from its present position near the end of the section to follow the first sentence/requirement of the section. -- add the following bullet point to the list of characters in a dial string: <* Characters to express "pause" and "wait for call completion".> Editorial comments ================== General: "user part" and "dial string" (except as a parameter value), not "userpart" and "dialstring". Section 1, para 1, second sentence: "One enters ..." -> "The user enters ...". Section 1, para 1, third sentence: "The entered sequence, called a "dialstring", may ..." ^ ^^^ Section 1, para 3, first sentence: "post dial" -> "after the initial number has been dialled". Section 1, para 3, second sentence: "functions" -> "function". Section 1, para 3, end of third sentence: "as DTMF" -> "as a series of DTMF digits". Section 1, para 3: add this sentence at the end to make the point of the paragraph: "This is another case where the ability to indicate that a dialstring is being presented would be useful." Section 3, dial string character list, third bullet: "* The MF digits A-D" -> "* The DTMF digits A-D" Section 3, note on DTMF following the bullets: suggest this be indented (empty list item in XML2RFC) to show its informative status. Section 4 para 1, final sentence: "E represent *" -> "E represents *" -> Section 4 para 2, final sentence: current: proposed: Section 4, voicemail example: to be consistent with the motivation in section 1, one would expect the dial string to be 4500X4123 rather than 4500P4123. Section 5, second para, second sentence: "This RFC would" -> "This RFC must". Section 5, third para, end: "[RFC3969]" -> "[RFC3966]" References, [RFC3969] repeats citation for [RFC3966] rather than giving the details for RFC 3969. Tom Taylor _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Apr 26 09:00:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYjcQ-0005mj-UE; Wed, 26 Apr 2006 08:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYjcP-0005mb-2d; Wed, 26 Apr 2006 08:59:45 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYjcN-0002mN-MS; Wed, 26 Apr 2006 08:59:45 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FYjcI-0005QZ-73; Wed, 26 Apr 2006 07:59:38 -0500 From: "Brian Rosen" To: "'Tom-PT Taylor'" , , , "Peterson, Jon" Date: Wed, 26 Apr 2006 08:59:38 -0400 Message-ID: <06ec01c66931$48f55730$6901a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <444F6947.7060608@nortel.com> Thread-Index: AcZpLhbiGXLiG+VWS3uNFJensOACewAAvzBA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: Subject: [Iptel] RE: Gen-art review of draft-rosen-iptel-dialstring-03.txt X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org I think your proposed changes are fine, and I will modify the text as you suggest. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortel.com] Sent: Wednesday, April 26, 2006 8:36 AM To: gen-art@ietf.org; iptel@ietf.org; br@brianrosen.net; Peterson, Jon Subject: Gen-art review of draft-rosen-iptel-dialstring-03.txt I am the assigned Gen-ART reviewer for draft-rosen-iptel-dialstring-03.txt. For background on Gen-ART, please see the FAQ at . This draft is basically acceptable, but needs a few fixes. I have also identified a number of editorial issues. I suppose I'm going to get hell for not reviewing this draft in the two years it has been around, but better late than never. Substantive comments: ===================== 1. I believe the problem is mis-stated in the second paragraph of section 1. Ignoring the matter of RFC 2806-based implementations, the user part of a SIP URI with the "user=phone" parameter is, without ambiguity, a phone number. The real problem is that before the transformation occurs (and the "user=phone" parameter is added if applicable), entities beyond the originating point cannot distinguish between a dial string and an user part that happens to consist of the characters that can be present in a dial string. I suggest that the second paragraph be replaced by the following: "There is a problem here. The intermediary can apply its transformation only if it recognizes that the user part of the SIP URI is a dial string. However, there is currently no way to distinguish an user part consisting of a dial string from an user part that happens to be composed of characters that would appear in a dial string." It is also necessary to change the second-last requirement in section 3 as follows: Current text: " It MUST be possible to distinguish between a dialstring and a phone number." New text: " It MUST be possible to distinguish between a dialstring and an user part that happens to consist of the same characters." 2. The requirement in section 3 that a context be present is unmotivated. I suggest adding the following sentence at the end of the first paragraph of section 1: " The intermediary is able to perform this transform provided that it knows the context (i.e., dialling plan) within which the number was dialled." 3. In section 3, a dial string is defined to consist of a certain set of characters, but then the requirement to convey pause and "wait for call completion" is added. It would be cleaner to include the characters for the latter functions in the definition of dial string in the first place. I therefore suggest the following changes: -- move the requirement to represent pause and "wait for call completion" from its present position near the end of the section to follow the first sentence/requirement of the section. -- add the following bullet point to the list of characters in a dial string: <* Characters to express "pause" and "wait for call completion".> Editorial comments ================== General: "user part" and "dial string" (except as a parameter value), not "userpart" and "dialstring". Section 1, para 1, second sentence: "One enters ..." -> "The user enters ...". Section 1, para 1, third sentence: "The entered sequence, called a "dialstring", may ..." ^ ^^^ Section 1, para 3, first sentence: "post dial" -> "after the initial number has been dialled". Section 1, para 3, second sentence: "functions" -> "function". Section 1, para 3, end of third sentence: "as DTMF" -> "as a series of DTMF digits". Section 1, para 3: add this sentence at the end to make the point of the paragraph: "This is another case where the ability to indicate that a dialstring is being presented would be useful." Section 3, dial string character list, third bullet: "* The MF digits A-D" -> "* The DTMF digits A-D" Section 3, note on DTMF following the bullets: suggest this be indented (empty list item in XML2RFC) to show its informative status. Section 4 para 1, final sentence: "E represent *" -> "E represents *" -> Section 4 para 2, final sentence: current: proposed: Section 4, voicemail example: to be consistent with the motivation in section 1, one would expect the dial string to be 4500X4123 rather than 4500P4123. Section 5, second para, second sentence: "This RFC would" -> "This RFC must". Section 5, third para, end: "[RFC3969]" -> "[RFC3966]" References, [RFC3969] repeats citation for [RFC3966] rather than giving the details for RFC 3969. Tom Taylor _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Apr 26 11:48:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmFS-0008Gq-Sy; Wed, 26 Apr 2006 11:48:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmFR-0008Gh-CV; Wed, 26 Apr 2006 11:48:13 -0400 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYmFP-0003sv-P3; Wed, 26 Apr 2006 11:48:13 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-3.cisco.com with ESMTP; 26 Apr 2006 08:48:11 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3QFm8w9001458; Wed, 26 Apr 2006 08:48:10 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Apr 2006 11:48:10 -0400 Received: from [161.44.79.144] ([161.44.79.144]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Apr 2006 11:48:09 -0400 Message-ID: <444F9639.4070407@cisco.com> Date: Wed, 26 Apr 2006 11:48:09 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt References: <444F6947.7060608@nortel.com> In-Reply-To: <444F6947.7060608@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2006 15:48:09.0855 (UTC) FILETIME=[D16978F0:01C66948] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: iptel@ietf.org, gen-art@ietf.org, "Peterson, Jon" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org There was other discussion of this back in March that, AFAIK, did not come to a conclusion. Are that discussion and the Gen-ART review running in parallel, or has the earlier discussion been forgotten? I had brought up two issues: - I propose that the phone-context parameter, reused from 3966, should be used the way other parameters from 3966 are used with a sip uri - in the user part. (If a phone-context parameter is to be used as a sip URI parameter, then the syntax of the sip URI will need to be updated to reflect this. But I don't think that is the right thing to do.) - allowing use of # and * in dial strings. (Brian did agree to this.) Paul Tom-PT Taylor wrote: > I am the assigned Gen-ART reviewer for > draft-rosen-iptel-dialstring-03.txt. For background on Gen-ART, please > see the FAQ at > . > > This draft is basically acceptable, but needs a few fixes. I have also > identified a number of editorial issues. I suppose I'm going to get hell > for not reviewing this draft in the two years it has been around, but > better late than never. > > Substantive comments: > ===================== > > 1. I believe the problem is mis-stated in the second paragraph of > section 1. Ignoring the matter of RFC 2806-based implementations, the > user part of a SIP URI with the "user=phone" parameter is, without > ambiguity, a phone number. The real problem is that before the > transformation occurs (and the "user=phone" parameter is added if > applicable), entities beyond the originating point cannot distinguish > between a dial string and an user part that happens to consist of the > characters that can be present in a dial string. I suggest that the > second paragraph be replaced by the following: > > "There is a problem here. The intermediary can apply its transformation > only if it recognizes that the user part of the SIP URI is a dial > string. However, there is currently no way to distinguish an user part > consisting of a dial string from an user part that happens to be > composed of characters that would appear in a dial string." > > It is also necessary to change the second-last requirement in section 3 > as follows: > > Current text: > " It MUST be possible to distinguish between a dialstring and a phone > number." > > New text: > " It MUST be possible to distinguish between a dialstring and an user > part that happens to consist of the same characters." > > > 2. The requirement in section 3 that a context be present is > unmotivated. I suggest adding the following sentence at the end of the > first paragraph of section 1: > > " The intermediary is able to perform this transform provided that it > knows the context (i.e., dialling plan) within which the number was > dialled." > > 3. In section 3, a dial string is defined to consist of a certain set of > characters, but then the requirement to convey pause and "wait for call > completion" is added. It would be cleaner to include the characters for > the latter functions in the definition of dial string in the first > place. I therefore suggest the following changes: > > -- move the requirement to represent pause and "wait for call > completion" from its present position near the end of the section to > follow the first sentence/requirement of the section. > > -- add the following bullet point to the list of characters in a dial > string: > > <* Characters to express "pause" and "wait for call completion".> > > Editorial comments > ================== > > General: "user part" and "dial string" (except as a parameter value), > not "userpart" and "dialstring". > > Section 1, para 1, second sentence: "One enters ..." -> "The user enters > ...". > > Section 1, para 1, third sentence: > "The entered sequence, called a "dialstring", may ..." > ^ ^^^ > > Section 1, para 3, first sentence: "post dial" -> "after the initial > number has been dialled". > > Section 1, para 3, second sentence: "functions" -> "function". > > Section 1, para 3, end of third sentence: "as DTMF" -> "as a series of > DTMF digits". > > Section 1, para 3: add this sentence at the end to make the point of the > paragraph: > > "This is another case where the ability to indicate that a dialstring is > being presented would be useful." > > Section 3, dial string character list, third bullet: > "* The MF digits A-D" -> "* The DTMF digits A-D" > > Section 3, note on DTMF following the bullets: suggest this be indented > (empty list item in XML2RFC) to show its informative status. > > Section 4 para 1, final sentence: > "E represent *" -> "E represents *" > -> > > Section 4 para 2, final sentence: > current: > proposed: "user=phone".> > > Section 4, voicemail example: to be consistent with the motivation in > section 1, one would expect the dial string to be 4500X4123 rather than > 4500P4123. > > Section 5, second para, second sentence: "This RFC would" -> "This RFC > must". > > Section 5, third para, end: "[RFC3969]" -> "[RFC3966]" > > References, [RFC3969] repeats citation for [RFC3966] rather than giving > the details for RFC 3969. > > Tom Taylor > > > > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Apr 26 12:31:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmvF-0001q6-Cw; Wed, 26 Apr 2006 12:31:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmvE-0001q1-Bi for iptel@ietf.org; Wed, 26 Apr 2006 12:31:24 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYmv9-0006I2-KB for iptel@ietf.org; Wed, 26 Apr 2006 12:31:24 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 26 Apr 2006 09:31:19 -0700 X-IronPort-AV: i="4.04,158,1144047600"; d="scan'208"; a="1798865013:sNHT36475898" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3QGVIYi002504; Wed, 26 Apr 2006 09:31:18 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Apr 2006 12:31:17 -0400 Received: from [161.44.79.144] ([161.44.79.144]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Apr 2006 12:31:17 -0400 Message-ID: <444FA055.1000708@cisco.com> Date: Wed, 26 Apr 2006 12:31:17 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt References: <444F6947.7060608@nortel.com> In-Reply-To: <444F6947.7060608@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2006 16:31:17.0761 (UTC) FILETIME=[D7EC9710:01C6694E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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: , Errors-To: iptel-bounces@ietf.org There was other discussion of this back in March that, AFAIK, did not come to a conclusion. Are that discussion and the Gen-ART review running in parallel, or has the earlier discussion been forgotten? I had brought up two issues: - I propose that the phone-context parameter, reused from 3966, should be used the way other parameters from 3966 are used with a sip uri - in the user part. (If a phone-context parameter is to be used as a sip URI parameter, then the syntax of the sip URI will need to be updated to reflect this. But I don't think that is the right thing to do.) - allowing use of # and * in dial strings. (Brian did agree to this.) Paul Tom-PT Taylor wrote: > I am the assigned Gen-ART reviewer for > draft-rosen-iptel-dialstring-03.txt. For background on Gen-ART, please > see the FAQ at > . > > This draft is basically acceptable, but needs a few fixes. I have also > identified a number of editorial issues. I suppose I'm going to get hell > for not reviewing this draft in the two years it has been around, but > better late than never. > > Substantive comments: > ===================== > > 1. I believe the problem is mis-stated in the second paragraph of > section 1. Ignoring the matter of RFC 2806-based implementations, the > user part of a SIP URI with the "user=phone" parameter is, without > ambiguity, a phone number. The real problem is that before the > transformation occurs (and the "user=phone" parameter is added if > applicable), entities beyond the originating point cannot distinguish > between a dial string and an user part that happens to consist of the > characters that can be present in a dial string. I suggest that the > second paragraph be replaced by the following: > > "There is a problem here. The intermediary can apply its transformation > only if it recognizes that the user part of the SIP URI is a dial > string. However, there is currently no way to distinguish an user part > consisting of a dial string from an user part that happens to be > composed of characters that would appear in a dial string." > > It is also necessary to change the second-last requirement in section 3 > as follows: > > Current text: > " It MUST be possible to distinguish between a dialstring and a phone > number." > > New text: > " It MUST be possible to distinguish between a dialstring and an user > part that happens to consist of the same characters." > > > 2. The requirement in section 3 that a context be present is > unmotivated. I suggest adding the following sentence at the end of the > first paragraph of section 1: > > " The intermediary is able to perform this transform provided that it > knows the context (i.e., dialling plan) within which the number was > dialled." > > 3. In section 3, a dial string is defined to consist of a certain set of > characters, but then the requirement to convey pause and "wait for call > completion" is added. It would be cleaner to include the characters for > the latter functions in the definition of dial string in the first > place. I therefore suggest the following changes: > > -- move the requirement to represent pause and "wait for call > completion" from its present position near the end of the section to > follow the first sentence/requirement of the section. > > -- add the following bullet point to the list of characters in a dial > string: > > <* Characters to express "pause" and "wait for call completion".> > > Editorial comments > ================== > > General: "user part" and "dial string" (except as a parameter value), > not "userpart" and "dialstring". > > Section 1, para 1, second sentence: "One enters ..." -> "The user enters > ...". > > Section 1, para 1, third sentence: > "The entered sequence, called a "dialstring", may ..." > ^ ^^^ > > Section 1, para 3, first sentence: "post dial" -> "after the initial > number has been dialled". > > Section 1, para 3, second sentence: "functions" -> "function". > > Section 1, para 3, end of third sentence: "as DTMF" -> "as a series of > DTMF digits". > > Section 1, para 3: add this sentence at the end to make the point of the > paragraph: > > "This is another case where the ability to indicate that a dialstring is > being presented would be useful." > > Section 3, dial string character list, third bullet: > "* The MF digits A-D" -> "* The DTMF digits A-D" > > Section 3, note on DTMF following the bullets: suggest this be indented > (empty list item in XML2RFC) to show its informative status. > > Section 4 para 1, final sentence: > "E represent *" -> "E represents *" > -> > > Section 4 para 2, final sentence: > current: > proposed: "user=phone".> > > Section 4, voicemail example: to be consistent with the motivation in > section 1, one would expect the dial string to be 4500X4123 rather than > 4500P4123. > > Section 5, second para, second sentence: "This RFC would" -> "This RFC > must". > > Section 5, third para, end: "[RFC3969]" -> "[RFC3966]" > > References, [RFC3969] repeats citation for [RFC3966] rather than giving > the details for RFC 3969. > > Tom Taylor > > > > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Apr 26 12:34:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmxq-0002hs-3B; Wed, 26 Apr 2006 12:34:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmxo-0002hk-D8; Wed, 26 Apr 2006 12:34:04 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYmxo-0006Rd-00; Wed, 26 Apr 2006 12:34:04 -0400 Received: from BPenfield [10.0.200.6] by acmepacket.com with ESMTP (SMTPD-9.03) id A0E80420; Wed, 26 Apr 2006 12:33:44 -0400 Message-ID: <002601c6694f$2ed9b3f0$800101df@acmepacket.com> From: "Bob Penfield" To: "Paul Kyzivat" , "Tom-PT Taylor" References: <444F6947.7060608@nortel.com> <444F9639.4070407@cisco.com> Subject: Re: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt Date: Wed, 26 Apr 2006 12:33:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.6 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: iptel@ietf.org, gen-art@ietf.org, "Peterson, Jon" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org I agree with Paul on the phone-context point. Just as user=phone hints/indicates that the userinfo is a phone number including its phone-context, dialstring should mean the same sort of construct. The phone-context is an attribute of the userinfo part of the URI. What would a phone-context SIP-URI parameter mean when there was no user parameter? or with a user=phone URI parameter? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Paul Kyzivat" To: "Tom-PT Taylor" Cc: ; ; "Peterson,Jon" Sent: Wednesday, April 26, 2006 11:48 AM Subject: Re: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt > There was other discussion of this back in March that, AFAIK, did not come > to a conclusion. Are that discussion and the Gen-ART review running in > parallel, or has the earlier discussion been forgotten? > > I had brought up two issues: > > - I propose that the phone-context parameter, reused from 3966, > should be used the way other parameters from 3966 are used > with a sip uri - in the user part. (If a phone-context parameter > is to be used as a sip URI parameter, then the syntax of the > sip URI will need to be updated to reflect this. But I don't > think that is the right thing to do.) > > - allowing use of # and * in dial strings. (Brian did agree to this.) > > Paul > > Tom-PT Taylor wrote: >> I am the assigned Gen-ART reviewer for >> draft-rosen-iptel-dialstring-03.txt. For background on Gen-ART, please >> see the FAQ at >> . >> >> This draft is basically acceptable, but needs a few fixes. I have also >> identified a number of editorial issues. I suppose I'm going to get hell >> for not reviewing this draft in the two years it has been around, but >> better late than never. >> >> Substantive comments: >> ===================== >> >> 1. I believe the problem is mis-stated in the second paragraph of section >> 1. Ignoring the matter of RFC 2806-based implementations, the user part >> of a SIP URI with the "user=phone" parameter is, without ambiguity, a >> phone number. The real problem is that before the transformation occurs >> (and the "user=phone" parameter is added if applicable), entities beyond >> the originating point cannot distinguish between a dial string and an >> user part that happens to consist of the characters that can be present >> in a dial string. I suggest that the second paragraph be replaced by the >> following: >> >> "There is a problem here. The intermediary can apply its transformation >> only if it recognizes that the user part of the SIP URI is a dial string. >> However, there is currently no way to distinguish an user part consisting >> of a dial string from an user part that happens to be composed of >> characters that would appear in a dial string." >> >> It is also necessary to change the second-last requirement in section 3 >> as follows: >> >> Current text: >> " It MUST be possible to distinguish between a dialstring and a phone >> number." >> >> New text: >> " It MUST be possible to distinguish between a dialstring and an user >> part that happens to consist of the same characters." >> >> >> 2. The requirement in section 3 that a context be present is unmotivated. >> I suggest adding the following sentence at the end of the first paragraph >> of section 1: >> >> " The intermediary is able to perform this transform provided that it >> knows the context (i.e., dialling plan) within which the number was >> dialled." >> >> 3. In section 3, a dial string is defined to consist of a certain set of >> characters, but then the requirement to convey pause and "wait for call >> completion" is added. It would be cleaner to include the characters for >> the latter functions in the definition of dial string in the first place. >> I therefore suggest the following changes: >> >> -- move the requirement to represent pause and "wait for call >> completion" from its present position near the end of the section to >> follow the first sentence/requirement of the section. >> >> -- add the following bullet point to the list of characters in a dial >> string: >> >> <* Characters to express "pause" and "wait for call completion".> >> >> Editorial comments >> ================== >> >> General: "user part" and "dial string" (except as a parameter value), not >> "userpart" and "dialstring". >> >> Section 1, para 1, second sentence: "One enters ..." -> "The user enters >> ...". >> >> Section 1, para 1, third sentence: >> "The entered sequence, called a "dialstring", may ..." >> ^ ^^^ >> >> Section 1, para 3, first sentence: "post dial" -> "after the initial >> number has been dialled". >> >> Section 1, para 3, second sentence: "functions" -> "function". >> >> Section 1, para 3, end of third sentence: "as DTMF" -> "as a series of >> DTMF digits". >> >> Section 1, para 3: add this sentence at the end to make the point of the >> paragraph: >> >> "This is another case where the ability to indicate that a dialstring is >> being presented would be useful." >> >> Section 3, dial string character list, third bullet: >> "* The MF digits A-D" -> "* The DTMF digits A-D" >> >> Section 3, note on DTMF following the bullets: suggest this be indented >> (empty list item in XML2RFC) to show its informative status. >> >> Section 4 para 1, final sentence: >> "E represent *" -> "E represents *" >> -> > completion"> >> >> Section 4 para 2, final sentence: >> current: >> proposed: > "user=phone".> >> >> Section 4, voicemail example: to be consistent with the motivation in >> section 1, one would expect the dial string to be 4500X4123 rather than >> 4500P4123. >> >> Section 5, second para, second sentence: "This RFC would" -> "This RFC >> must". >> >> Section 5, third para, end: "[RFC3969]" -> "[RFC3966]" >> >> References, [RFC3969] repeats citation for [RFC3966] rather than giving >> the details for RFC 3969. >> >> Tom Taylor >> >> >> >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Apr 26 13:31:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYnrG-0003KJ-OX; Wed, 26 Apr 2006 13:31:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYnrF-0003Jn-7X; Wed, 26 Apr 2006 13:31:21 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYnrC-0000jN-O1; Wed, 26 Apr 2006 13:31:21 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FYnr3-000840-7t; Wed, 26 Apr 2006 12:31:10 -0500 From: "Brian Rosen" To: "'Bob Penfield'" , "'Paul Kyzivat'" , "'Tom-PT Taylor'" Subject: RE: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt Date: Wed, 26 Apr 2006 13:31:11 -0400 Message-ID: <073a01c66957$385cb9b0$6901a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <002601c6694f$2ed9b3f0$800101df@acmepacket.com> Thread-Index: AcZpTzsCizM4L+XRRu+KA39JTxPkSwAB29ug X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: iptel@ietf.org, gen-art@ietf.org, "Peterson, Jon" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org I have not forgotten this. I have been asking around for other opinions. I still find it hard to believe that: sip:123;phone-context=dial.example.com@example.com;user=dialstring is preferable to: sip:123@example.com;user=dialstring;phone-context=dial.example.com but if that is the way most people want it, it's not a big deal to change the text to reflect that. Brian -----Original Message----- From: Bob Penfield [mailto:BPenfield@acmepacket.com] Sent: Wednesday, April 26, 2006 12:34 PM To: Paul Kyzivat; Tom-PT Taylor Cc: iptel@ietf.org; gen-art@ietf.org; Peterson, Jon Subject: Re: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt I agree with Paul on the phone-context point. Just as user=phone hints/indicates that the userinfo is a phone number including its phone-context, dialstring should mean the same sort of construct. The phone-context is an attribute of the userinfo part of the URI. What would a phone-context SIP-URI parameter mean when there was no user parameter? or with a user=phone URI parameter? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Paul Kyzivat" To: "Tom-PT Taylor" Cc: ; ; "Peterson,Jon" Sent: Wednesday, April 26, 2006 11:48 AM Subject: Re: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt > There was other discussion of this back in March that, AFAIK, did not come > to a conclusion. Are that discussion and the Gen-ART review running in > parallel, or has the earlier discussion been forgotten? > > I had brought up two issues: > > - I propose that the phone-context parameter, reused from 3966, > should be used the way other parameters from 3966 are used > with a sip uri - in the user part. (If a phone-context parameter > is to be used as a sip URI parameter, then the syntax of the > sip URI will need to be updated to reflect this. But I don't > think that is the right thing to do.) > > - allowing use of # and * in dial strings. (Brian did agree to this.) > > Paul > > Tom-PT Taylor wrote: >> I am the assigned Gen-ART reviewer for >> draft-rosen-iptel-dialstring-03.txt. For background on Gen-ART, please >> see the FAQ at >> . >> >> This draft is basically acceptable, but needs a few fixes. I have also >> identified a number of editorial issues. I suppose I'm going to get hell >> for not reviewing this draft in the two years it has been around, but >> better late than never. >> >> Substantive comments: >> ===================== >> >> 1. I believe the problem is mis-stated in the second paragraph of section >> 1. Ignoring the matter of RFC 2806-based implementations, the user part >> of a SIP URI with the "user=phone" parameter is, without ambiguity, a >> phone number. The real problem is that before the transformation occurs >> (and the "user=phone" parameter is added if applicable), entities beyond >> the originating point cannot distinguish between a dial string and an >> user part that happens to consist of the characters that can be present >> in a dial string. I suggest that the second paragraph be replaced by the >> following: >> >> "There is a problem here. The intermediary can apply its transformation >> only if it recognizes that the user part of the SIP URI is a dial string. >> However, there is currently no way to distinguish an user part consisting >> of a dial string from an user part that happens to be composed of >> characters that would appear in a dial string." >> >> It is also necessary to change the second-last requirement in section 3 >> as follows: >> >> Current text: >> " It MUST be possible to distinguish between a dialstring and a phone >> number." >> >> New text: >> " It MUST be possible to distinguish between a dialstring and an user >> part that happens to consist of the same characters." >> >> >> 2. The requirement in section 3 that a context be present is unmotivated. >> I suggest adding the following sentence at the end of the first paragraph >> of section 1: >> >> " The intermediary is able to perform this transform provided that it >> knows the context (i.e., dialling plan) within which the number was >> dialled." >> >> 3. In section 3, a dial string is defined to consist of a certain set of >> characters, but then the requirement to convey pause and "wait for call >> completion" is added. It would be cleaner to include the characters for >> the latter functions in the definition of dial string in the first place. >> I therefore suggest the following changes: >> >> -- move the requirement to represent pause and "wait for call >> completion" from its present position near the end of the section to >> follow the first sentence/requirement of the section. >> >> -- add the following bullet point to the list of characters in a dial >> string: >> >> <* Characters to express "pause" and "wait for call completion".> >> >> Editorial comments >> ================== >> >> General: "user part" and "dial string" (except as a parameter value), not >> "userpart" and "dialstring". >> >> Section 1, para 1, second sentence: "One enters ..." -> "The user enters >> ...". >> >> Section 1, para 1, third sentence: >> "The entered sequence, called a "dialstring", may ..." >> ^ ^^^ >> >> Section 1, para 3, first sentence: "post dial" -> "after the initial >> number has been dialled". >> >> Section 1, para 3, second sentence: "functions" -> "function". >> >> Section 1, para 3, end of third sentence: "as DTMF" -> "as a series of >> DTMF digits". >> >> Section 1, para 3: add this sentence at the end to make the point of the >> paragraph: >> >> "This is another case where the ability to indicate that a dialstring is >> being presented would be useful." >> >> Section 3, dial string character list, third bullet: >> "* The MF digits A-D" -> "* The DTMF digits A-D" >> >> Section 3, note on DTMF following the bullets: suggest this be indented >> (empty list item in XML2RFC) to show its informative status. >> >> Section 4 para 1, final sentence: >> "E represent *" -> "E represents *" >> -> > completion"> >> >> Section 4 para 2, final sentence: >> current: >> proposed: > "user=phone".> >> >> Section 4, voicemail example: to be consistent with the motivation in >> section 1, one would expect the dial string to be 4500X4123 rather than >> 4500P4123. >> >> Section 5, second para, second sentence: "This RFC would" -> "This RFC >> must". >> >> Section 5, third para, end: "[RFC3969]" -> "[RFC3966]" >> >> References, [RFC3969] repeats citation for [RFC3966] rather than giving >> the details for RFC 3969. >> >> Tom Taylor >> >> >> >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Apr 26 17:41:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrlM-0000mW-P0; Wed, 26 Apr 2006 17:41:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrlL-0000bM-BY for iptel@ietf.org; Wed, 26 Apr 2006 17:41:31 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYrlJ-0007n1-Pl for iptel@ietf.org; Wed, 26 Apr 2006 17:41:31 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k3QLaaE19807; Wed, 26 Apr 2006 17:36:36 -0400 (EDT) Received: from [127.0.0.1] ([47.153.168.4] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 17:41:21 -0400 Message-ID: <444FE8EE.20508@nortel.com> Date: Thu, 27 Apr 2006 06:41:02 +0900 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt References: <444F6947.7060608@nortel.com> <444F9639.4070407@cisco.com> In-Reply-To: <444F9639.4070407@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2006 21:41:21.0793 (UTC) FILETIME=[28CA9710:01C6697A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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: , Errors-To: iptel-bounces@ietf.org Mine was a parallel review. I had forgotten your intervention and missed the point myself. Paul Kyzivat wrote: > There was other discussion of this back in March that, AFAIK, did not > come to a conclusion. Are that discussion and the Gen-ART review running > in parallel, or has the earlier discussion been forgotten? > > I had brought up two issues: > > - I propose that the phone-context parameter, reused from 3966, > should be used the way other parameters from 3966 are used > with a sip uri - in the user part. (If a phone-context parameter > is to be used as a sip URI parameter, then the syntax of the > sip URI will need to be updated to reflect this. But I don't > think that is the right thing to do.) > > - allowing use of # and * in dial strings. (Brian did agree to this.) > > Paul > > Tom-PT Taylor wrote: >> I am the assigned Gen-ART reviewer for >> draft-rosen-iptel-dialstring-03.txt. For background on Gen-ART, please >> see the FAQ at >> . >> >> This draft is basically acceptable, but needs a few fixes. I have also >> identified a number of editorial issues. I suppose I'm going to get >> hell for not reviewing this draft in the two years it has been around, >> but better late than never. >> >> Substantive comments: >> ===================== >> >> 1. I believe the problem is mis-stated in the second paragraph of >> section 1. Ignoring the matter of RFC 2806-based implementations, the >> user part of a SIP URI with the "user=phone" parameter is, without >> ambiguity, a phone number. The real problem is that before the >> transformation occurs (and the "user=phone" parameter is added if >> applicable), entities beyond the originating point cannot distinguish >> between a dial string and an user part that happens to consist of the >> characters that can be present in a dial string. I suggest that the >> second paragraph be replaced by the following: >> >> "There is a problem here. The intermediary can apply its >> transformation only if it recognizes that the user part of the SIP URI >> is a dial string. However, there is currently no way to distinguish an >> user part consisting of a dial string from an user part that happens >> to be composed of characters that would appear in a dial string." >> >> It is also necessary to change the second-last requirement in section >> 3 as follows: >> >> Current text: >> " It MUST be possible to distinguish between a dialstring and a phone >> number." >> >> New text: >> " It MUST be possible to distinguish between a dialstring and an >> user part that happens to consist of the same characters." >> >> >> 2. The requirement in section 3 that a context be present is >> unmotivated. I suggest adding the following sentence at the end of the >> first paragraph of section 1: >> >> " The intermediary is able to perform this transform provided that it >> knows the context (i.e., dialling plan) within which the number was >> dialled." >> >> 3. In section 3, a dial string is defined to consist of a certain set >> of characters, but then the requirement to convey pause and "wait for >> call completion" is added. It would be cleaner to include the >> characters for the latter functions in the definition of dial string >> in the first place. I therefore suggest the following changes: >> >> -- move the requirement to represent pause and "wait for call >> completion" from its present position near the end of the section to >> follow the first sentence/requirement of the section. >> >> -- add the following bullet point to the list of characters in a dial >> string: >> >> <* Characters to express "pause" and "wait for call completion".> >> >> Editorial comments >> ================== >> >> General: "user part" and "dial string" (except as a parameter value), >> not "userpart" and "dialstring". >> >> Section 1, para 1, second sentence: "One enters ..." -> "The user >> enters ...". >> >> Section 1, para 1, third sentence: >> "The entered sequence, called a "dialstring", may ..." >> ^ ^^^ >> >> Section 1, para 3, first sentence: "post dial" -> "after the initial >> number has been dialled". >> >> Section 1, para 3, second sentence: "functions" -> "function". >> >> Section 1, para 3, end of third sentence: "as DTMF" -> "as a series of >> DTMF digits". >> >> Section 1, para 3: add this sentence at the end to make the point of >> the paragraph: >> >> "This is another case where the ability to indicate that a dialstring >> is being presented would be useful." >> >> Section 3, dial string character list, third bullet: >> "* The MF digits A-D" -> "* The DTMF digits A-D" >> >> Section 3, note on DTMF following the bullets: suggest this be >> indented (empty list item in XML2RFC) to show its informative status. >> >> Section 4 para 1, final sentence: >> "E represent *" -> "E represents *" >> -> > completion"> >> >> Section 4 para 2, final sentence: >> current: >> proposed: > "user=phone".> >> >> Section 4, voicemail example: to be consistent with the motivation in >> section 1, one would expect the dial string to be 4500X4123 rather >> than 4500P4123. >> >> Section 5, second para, second sentence: "This RFC would" -> "This RFC >> must". >> >> Section 5, third para, end: "[RFC3969]" -> "[RFC3966]" >> >> References, [RFC3969] repeats citation for [RFC3966] rather than >> giving the details for RFC 3969. >> >> Tom Taylor >> >> >> >> >> >> >> _______________________________________________ >> 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 Thu Apr 27 10:48:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7n7-0007zH-48; Thu, 27 Apr 2006 10:48:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7n5-0007yq-GI for iptel@ietf.org; Thu, 27 Apr 2006 10:48:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ7n5-0000zM-En for iptel@ietf.org; Thu, 27 Apr 2006 10:48:23 -0400 Received: from smtp3.clb.oleane.net ([213.56.31.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZ7jT-0005Ff-OW for iptel@ietf.org; Thu, 27 Apr 2006 10:44:45 -0400 Received: from Pavillonquatre ([194.3.133.88]) by smtp3.clb.oleane.net with ESMTP id k3REiVKf028957 for ; Thu, 27 Apr 2006 16:44:38 +0200 Message-Id: <200604271444.k3REiVKf028957@smtp3.clb.oleane.net> From: "Chantal Ladouce" To: Date: Thu, 27 Apr 2006 16:43:29 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZqCPLQE0sF9N7KS1yEP2MoBnKA/g== X-Spam-Score: 0.6 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Subject: [Iptel] TVoDSL International Conference 2007 - Paris - France X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0329938882==" Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0329938882== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01C66A19.B6996270" This is a multi-part message in MIME format. ------=_NextPart_000_00B9_01C66A19.B6996270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The fourth edition of the TVoDSL International Conference and the Triple Play Showcase will stand in Paris next January 23 to 26, 2007. With the opening of a second exhibition floor and the launch of the Mobile TV World Congress, TVoDSL will confirm his rank of very first worldwide rendez-vous in the IPTV realm. A call for proposals has been launched for the TVoDSL conference. All details at: http://www.upperside.fr/tvodsl2007/tvodsl2007intro.htm ------=_NextPart_000_00B9_01C66A19.B6996270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The fourth edition of the TVoDSL International = Conference and the Triple Play Showcase will stand in Paris next January 23 to 26, = 2007.

With the opening of a second exhibition floor = and the launch of the Mobile TV World Congress, TVoDSL will = confirm his rank of very first worldwide rendez-vous in the = IPTV realm.

 

A call for = proposals has been launched for the TVoDSL conference.

=

 

All details = at:

=

http://www.upperside.fr/tvodsl2007/tvodsl2007intro.htm

=

 

------=_NextPart_000_00B9_01C66A19.B6996270-- --===============0329938882== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0329938882==--