Subject: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-04.txt

From: "Stastny Richard" <[email-masked]>
Date: Wed, 5 Jul 2006 10:46:56 +0200

Hi Brian,
 
IMHO the examples are wrong:
 
e.g.:
   sip:[email-masked];user=dialstring;
      phone-context=atlanta.example.com

should read:
sip:123;phone-context=[email-masked];user=dialstring
 
Phone-context is part of the tel: URI and not from the sip URI
 
-sta

________________________________

Von: [email-masked] [mailto:[email-masked]]
Gesendet: Mi 28.06.2006 00:50
An: [email-masked]
Betreff: I-D ACTION:draft-rosen-iptel-dialstring-04.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Dialstring parameter for the Session
                          Initiation Protocol Uniform Resource
                          Identifier
        Author(s)       : B. Rosen
        Filename        : draft-rosen-iptel-dialstring-04.txt
        Pages           : 8
        Date            : 2006-6-27
       
RFC3966 explicitly states that 'tel' URIs may not represent a dial
   string.  That leaves no way specify a dial string in a standardized
   way.  Great confusion exists with the SIP URI parameter "user=phone",
   and specifically, if it can represent a dial string.  This memo
   creates a new value for the user parameter "dialstring", so that one
   may specify "user=dialstring" to encode a dial string as a 'sip:' or
   'sips:' URI.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-04.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-rosen-iptel-dialstring-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-rosen-iptel-dialstring-04.txt".
       
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Jul 2006 17:20:10 -0400

I agree with Richard. And I brought it up on the -03 (and the -02 I 
think) versions as well. There is also the issue of * & #. I'm attaching 
an old message that covers most of that.

	Paul

Stastny Richard wrote:
> ------------------------------------------------------------------------
> 
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 
> 
> ------------------------------------------------------------------------
> 

Subject: Re: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt
From: "Bob Penfield" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>, "Tom-PT Taylor" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Peterson,Jon" <[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?
>
> 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
>> <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
>>
>>
>>
>>
>>
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 9 Jul 2006 13:15:33 -0400

The form of the parameter is an open issue; I don't agree that it should be
a URI parameter.  

The * & # is an oversight, and I'll get it fixed one way or another.

Brian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, July 05, 2006 5:20 PM
To: Stastny Richard
Cc: [email-masked]; Rosen, Brian
Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-04.txt

	Paul