Subject: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 26 Apr 2006 21:36:23 +0900

I am the assigned Gen-ART reviewer for 
draft-rosen-iptel-dialstring-03.txt. For background on Gen-ART, please 
see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

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 *"
<X represents call completion> -> <X represents "wait for call completion">

Section 4 para 2, final sentence:
current: <change the URI to specify user=phone.>
proposed: <change the URI parameter value from "user=dialstring" to 
"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
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 26 Apr 2006 08:59:38 -0400

I think your proposed changes are fine, and I will modify the text as you
suggest.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]] 
Sent: Wednesday, April 26, 2006 8:36 AM
To: [email-masked]; [email-masked]; [email-masked]; Peterson, Jon
Subject: Gen-art review of draft-rosen-iptel-dialstring-03.txt

Substantive comments:
=====================

Current text:

New text:

Editorial comments
==================

Tom Taylor

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Apr 2006 11:48:09 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Apr 2006 12:31:17 -0400

Paul

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 26 Apr 2006 12:33:43 -0400

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
[email-masked]

----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Tom-PT Taylor" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Peterson,Jon" 
<[email-masked]>
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?
>
>> 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:
>>
>> 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."
>>
>> 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 latter functions in the definition of dial string in the first place. 
>> I therefore suggest the following changes:
>>
>> General: "user part" and "dial string" (except as a parameter value), not 
>> "userpart" and "dialstring".
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 26 Apr 2006 13:31:11 -0400

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=[email-masked];user=dialstring

is preferable to:
sip:[email-masked];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:[email-masked]] 
Sent: Wednesday, April 26, 2006 12:34 PM
To: Paul Kyzivat; Tom-PT Taylor
Cc: [email-masked]; [email-masked]; Peterson, Jon
Subject: Re: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 27 Apr 2006 06:41:02 +0900

Mine was a parallel review. I had forgotten your intervention and missed 
the point myself.

Paul Kyzivat wrote:
>> 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:
>> =====================
>>
>> "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 an 
>> user part that happens to consist of the same characters."
>>
>>
>> 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:
>>
>> Section 1, para 1, second sentence: "One enters ..." -> "The user 
>> enters ...".
>>
>> 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, note on DTMF following the bullets: suggest this be 
>> indented (empty list item in XML2RFC) to show its informative status.
>>
>> section 1, one would expect the dial string to be 4500X4123 rather 
>> than 4500P4123.
>>
>> References, [RFC3969] repeats citation for [RFC3966] rather than 
>> giving the details for RFC 3969.
>>
>> Tom Taylor
>>
>>
>>
>>
>>
>>