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

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Mar 2006 16:29:06 -0500

Stastny Richard wrote:
> Paul,
> 
> I see your problem
>  
> What about leaving phone-context with RFC 3966?
>  
> sip:123;phone-context=[email-masked];user=dialstring

That is what I proposed. Brian didn't like it.

	Paul

> Richard
> 
> ________________________________
> 
> Von: Paul Kyzivat [mailto:[email-masked]]
> Gesendet: Mi 08.03.2006 21:44
> An: [email-masked]
> Cc: [email-masked]; Stastny Richard
> Betreff: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt
> 
> 
> 
> 
> 
> Brian Rosen wrote:
> 
>>I think what you propose for the phone number parameters are too ugly, and
>>unnecessary.  What I did with the current language is define a new parameter
>>as defined in 3966.  This makes the user parameter and the phone-context
>>parameter the same type of parameter.  The user= doesn't go before the "@",
>>and neither should the phone-context.
> 
> 
> It was my feeling that this is pretty similar to user=phone, so I was
> expecting the representation to be similar as well. I find it pretty
> surprising to reuse the phone-context parameter but in an entirely
> different namespace. Even more so if the values for the parameter have a
> differing meaning. (If that is to be done it might be better to change
> the name.)
> 
> Are you proposing that a phone-context *URI parameter* be valid for
> user=phone as well?
> 
> I would prefer this to deviate as little as possible from the sip form
> of the tel uri.
> 
> 
>>I do think fixing 3261's ABNF is a good idea.  Having a formal ABNF in this
>>draft for the dialstring is a good idea.
>>
>>I can add the escaped * and #. 
> 
> 
> Only # *needs* to be escaped if it is used.
> 
>         Paul
> 
> 
>>And Richard, of course you are correct; sloppy editing on my part, and I'll
>>fix the examples.
>>
>>Brian
>>-----Original Message-----
>>From: Paul Kyzivat [mailto:[email-masked]]
>>Sent: Wednesday, March 08, 2006 11:26 AM
>>To: [email-masked]
>>Cc: Stastny Richard
>>Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt
>>
>>I agree with Richard that I support the concept of this draft, but have
>>a few nits. I have a different spin on the one Richard pointed out:
>>
>>All the parameters defined in 3966 are part of the phone number. When
>>the definitions in 3966 are applied to sip with the user=phone uri
>>parameter, the parameters defined in 3966 all go before the "@" sign.
>>The user=dialstring is just a variant on this, so I expect the
>>phone-context parameter ought to go before the "@" sign in that case
>>too. For example:
>>
>>; what a SIP Phone might emit when a user dials extension 123
>>sip:123;phone-context=[email-masked];user=dialstrin
>>g
>>
>>Next, this draft permits the dialled digits A-F, but it doesn't permit *
>>and #. 3966 does permit * and # as well as E and F - apparently they are
>>synonymous. (When used in conjunction with sip uris, the # has to be
>>escaped as %23.)
>>
>>We are slightly in limbo here, because 3261 references 2805 rather than
>>3966. Need to deal with that somehow. I think it would be helpful to
>>introduce in this draft a formal syntax for the user part. The following
>>is a suggested start at a syntax. This could just be for
>>user=dialstring, but this might be a convenient place to revise 3261 so
>>it references 3966 for user=phone as well. The following is a start at
>>the changes. I've included some stuff from 3261 and 3966 for reference
>>that probably don't need to be included in the draft.
>>
>>;;; UNCHANGED RULES FROM 3261:
>>;SIP-URI          =  "sip:" [ userinfo ] hostport
>>;                    uri-parameters [ headers ]
>>;SIPS-URI         =  "sips:" [ userinfo ] hostport
>>;                    uri-parameters [ headers ]
>>;user             =  1*( unreserved / escaped / user-unreserved )
>>;user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
>>;
>>;uri-parameters    =  *( ";" uri-parameter)
>>;
>>;uri-parameter     =  transport-param / user-param / method-param
>>;                     / ttl-param / maddr-param / lr-param
>>
>>;                     / other-param
>>
>>;;; UNCHANGED RULES FROM 3966
>>;   local-number         = local-number-digits *par context *par
>>;   local-number-digits  =
>>;      *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex
>>;   phonedigit-hex       = HEXDIG / "*" / "#" / [ visual-separator ]
>>;   visual-separator     = "-" / "." / "(" / ")"
>>
>>
>>;;; REVISED RULES FROM 3261
>>userinfo         =  ( user / telephone-subscriber / dial-string )
>>                     [ ":" password ] "@"
>>user-param        =  "user="
>>                         ( "phone" / "ip" / "dialstring" / other-user)
>>
>>    The BNF for 'telephone-subscriber', 'par', and 'context' can be
>>    found in RFC 3966 [?].  Note, however, that any characters allowed
>>    there that are not allowed in the 'user' part of the SIP URI MUST
>>    be escaped.
>>
>>
>>
>>;;; NEW RULES
>>dial-string = dial-string-number *par context *par
>>dial-string-number = 1* ( [ "X" ] 1*dial-string-segment )
>>dial-string-segment = ( * "P" ) dial-string-digit
>>dial-string-digit = HEXDIG / "*" / "#"
>>
>>
>>This needs to be accompanied by text explaining that the dial-string
>>syntax applies when the user=dialstring parameter is present.
>>
>>      Thanks,
>>      Paul
>>
>>Stastny Richard wrote:
>>
>>
>>>Brian,
>>>
>>>in principle I support and welcome this draft
>>>
>>>A minor comment to the phone-context examples:
>>>
>>>"When the "user=dialstring" is used, a context parameter as defined in
>>>  [RFC3966] MUST be specified."
>>>
>>>Ok
>>>
>>>but in your examples you use
>>>(Examples of dialstring use include)
>>>  ; what a SIP Phone might emit when a user dials extension 123
>>>  sip:[email-masked];user=dialstring;
>>>     phone-context='AtlantaDialPlan'
>>>
>>>but phone-context is defined in RFC3966 as:
>>>context = ";phone-context=" descriptor
>>>descriptor = domainname / global-number-digits
>>>
>>>this is because the phone-context must globally unique
>>>
>>>so you should use in your examples either
>>>
>>>phone-context=altlanta.example.com
>>>
>>>or
>>>
>>>phone-context=+1234
>>>
>>>(without "")
>>>
>>>regards
>>>
>>>Richard
>>>
>>>
>>>________________________________
>>>
>>>Von: [email-masked] [mailto:[email-masked]]
>>>Gesendet: Di 07.03.2006 21:50
>>>An: [email-masked]
>>>Betreff: I-D ACTION:draft-rosen-iptel-dialstring-03.txt
>>>
>>>
>>>
>>>A New Internet-Draft is available from the on-line Internet-Drafts
>>
>>directories.
>>
>>
>>>       Title           : Dialstring parameter for the Session Initiation
>>
>>Protocol URI
>>
>>
>>>       Author(s)       : B. Rosen
>>>       Filename        : draft-rosen-iptel-dialstring-03.txt
>>>       Pages           : 8
>>>       Date            : 2006-3-7
>>>     
>>>RFC3966 explicitly states that TEL URIs may not represent a dial
>>>string.  That leaves no way specify a dialstring 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 dialstring as a SIP or SIPS
>>>URI.
>>>
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-03.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-03.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-03.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.
>>>
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>I-D-Announce mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/i-d-announce
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>Iptel mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/iptel
>>
>>
>>_______________________________________________
>>Iptel mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/iptel
>>
> 
> 

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

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 8 Mar 2006 22:12:20 +0100

Paul,

I see your problem

 
Richard

        Paul

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 9 Mar 2006 11:20:05 -0500

> That is what I proposed. Brian didn't like it.

I'm actually surprised that the draft didn't completely follow rfc3966 and
relax the phone-context rule.  Or totally disregard rfc3966 (including the
phone-context type requirements) and allow the receiver to determine the
context.

If I understand correctly, the draft currently disregards rfc3966 but still
requires a context to be sent.  

I agree that indicating context can be helpful; but why put the same rfc3966
phone-context requirement on the dialstring draft?  

Relaxing the rule is helpful for interactions between device and outbound
proxy so they don't have to uselessly configure and pass such a context when
not needed.

If the group thinks a context is really needed for dialstring, would
something like "phone-context=outbound.invalid." or
"phone-context=unknown.invalid." be acceptable as a default context?  Thus
outbound devices which allow it can use it; and others can handle it as they
would when the phone-context is unknown.

I would suggest such a default context for rfc3966 usage (within "tel:" and
when user=phone); however I'm sure some would consider it a violation of the
rfc3966 phone-context rule.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Mar 2006 11:46:33 -0500

Brett,

The problem with omitting the context from the URI is that it makes the 
URI itself dependent on the context in which it is used. That means it 
must be detected and translated into some context independent form while 
the original context is still known.

Of course it is tempting to say "oh the edge proxy will fix everything 
up". But its pretty easy for something to slip past. It isn't just the 
R-URI that might need translating. Some examples where that is not the case:

- the Refer-To uri in a REFER message
- perhaps the address of a colleague referenced in a presence document
- an XCAP message containing forwarding address URL.

So if a URI that depends on implicit context slips by the element that 
understands that context, and gets used in some other context, then at 
best it will fail, and at worst it will succeed by assuming the wrong 
context and reach the wrong party.

If the context is explicit in the URI, at worst it may fail if handed to 
someone that doesn't understand the context. At best it will be routed 
to an element that does understand the context and can do the needed 
translation.
	
	Paul