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

From: "Francois Audet" <[email-masked]>
Date: Tue, 8 Aug 2006 15:12:31 -0500

I agree with Paul, Richard and everybody else on this thread.

I'm not sure why you say this is an open issue. It seems that everybody
agrees but the
author...

It needs to be consistent with Tel URI.

A URI is a URI. It needs to be Unique. The phone-context makes it unique
because it is
in the user part.

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Sunday, July 09, 2006 10:16 AM
> To: 'Paul Kyzivat'; Stastny Richard
> Cc: [email-masked]
> Subject: RE: [Iptel] Re: I-D 
> ACTION:draft-rosen-iptel-dialstring-04.txt
> 
> 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
> 
> 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:
> > 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];u
> ser=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.tx
> > t
> > 
> > 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.
> > 
> > 
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> > _______________________________________________
> > 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: "Brian Rosen" <[email-masked]>
Date: Tue, 8 Aug 2006 16:44:46 -0400

I've already started working on changing the text.
The argument that it should look like a tel uri converted to a sip uri was
compelling, even if we don't actually do that.

Brian

> From: Francois Audet [mailto:[email-masked]]
> Sent: Tuesday, August 08, 2006 4:13 PM
> To: Brian Rosen; Paul Kyzivat; Stastny Richard
> Cc: [email-masked]
> Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-04.txt
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 09:36:45 +0200

Hi,

Currently the draft does not talk about Tel-Uri. Also, since user=phone
is not used, the user part syntax is not even required (as per RFC3261)
to be according to RFC3966. So, from that perspective there is no
requirement to be consistent with Tel-Uri. 

The draft only talks about a Sip-Uri extension/parameter, so in that
case the parameter should of be located after the host part.

HOWEVER, I DO agree with Farncois (and others). We should talk about a
Tel-Uri extension. But, then we also need to define that if
user=dialstrong, the user part shall be parsed as defined in RFC3966
(similar to user=phone).

Regards,

Christer

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: 8. elokuuta 2006 23:13
To: Brian Rosen; Paul Kyzivat; Stastny Richard
Cc: [email-masked]
Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-04.txt

agrees but the author...

A URI is a URI. It needs to be Unique. The phone-context makes it unique
because it is in the user part.

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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 14:49:00 +0200

Hi,

I think the first GOOD is good, but the second GOOD is bad. Why would we
need to define a new phone-context SIP URI parameter? Also, the first
GOOD is "comaptible" with a Tel-Uri.

IF we really need to indicate "dialstring" somewhere I think it should
be a new Tel-Uri parameter.

E.g.

sip:1234;phone-context=atlanta.example.com;xxx=[email-masked]
e.com;user=phone

Regards,

Christer 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 9. elokuuta 2006 15:41
To: Christer Holmberg (JO/LMF); 'Francois Audet'; 'Paul Kyzivat';
'Stastny Richard'
Cc: [email-masked]

In an effort to close this issue, I had a private email exchange with
Paul Kyzivat.  The part of that that swayed me was that he pointed out I
was
advocating:

GOOD: sip:1234;phone-context=[email-masked]
          ;user=phone

BAD:  sip:1234;phone-context=[email-masked]
          ;user=dialstring

GOOD: sip:[email-masked];phone-context=atlanta.example.com
          ;user=dialstring

I looked at that, and pretty quickly decided I was wrong and he was
right.

Brian

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2006 3:37 AM
> To: Francois Audet; Brian Rosen; Paul Kyzivat; Stastny Richard
> Cc: [email-masked]
> Currently the draft does not talk about Tel-Uri. Also, since 
> user=phone is not used, the user part syntax is not even required (as 
> per RFC3261) to be according to RFC3966. So, from that perspective 
> there is no requirement to be consistent with Tel-Uri.
> 

> I'm not sure why you say this is an open issue. It seems that 
> everybody agrees but the author...
> 
> A URI is a URI. It needs to be Unique. The phone-context makes it 
> unique because it is in the user part.
> 
> > >         "FILE
/internet-drafts/draft-rosen-iptel-dialstring-04.txt".

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 15:03:44 +0200

Hi, 

>Please read the draft.
>
>We spent a long time in the evolution of this draft on the question of
whether or not we would extend the tel uri to 
>cover dialstrings, or do what this version (and several previous
versions) do, which is to NOT allow dialstrings in a tel 
>uri, but rather restrict them to a sip uri, with user=dialstring.  It
was a consensus to NOT extend the tel uri, and to 
>restrict dialstrings to sip uris only.  I'd really rather not revisit
that issue.
>
>If a SIP uri contains a dialstring, there has to be something that
tells you it's not a telephone number and is a 
>dialstring, so your suggestion is not acceptable I think.

So, in the first GOOD, what tells you the number is a dial string? To me
it looks like a normal Tel-Uri local number which has been converted
into a SIP-Uri...

Regards,

Christer

> Sent: Wednesday, August 09, 2006 8:49 AM
> To: Brian Rosen; Francois Audet; Paul Kyzivat; Stastny Richard
> Cc: [email-masked]
> I think the first GOOD is good, but the second GOOD is bad. Why would 
> we need to define a new phone-context SIP URI parameter? Also, the 
> first GOOD is "comaptible" with a Tel-Uri.
> 

> Paul Kyzivat.  The part of that that swayed me was that he pointed out

> I was
> > user=phone is not used, the user part syntax is not even required 
> > (as per RFC3261) to be according to RFC3966. So, from that 
> > perspective there is no requirement to be consistent with Tel-Uri.
> >

> > HOWEVER, I DO agree with Farncois (and others). We should talk about

> > a

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

> > > > implementation to automatically retrieve the ASCII version of 
> > > > the Internet-Draft.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > ------------------------------------------------------------------
> > > --
> > > --
> > > > --
> > > >
> > > ------------------------------------------------------------------
> > > --
> > > --
> > > > --
> > > >

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 9 Aug 2006 15:11:21 +0200

Hi Brian,

You finally convinced me with the argument that the
dialstring is an extension to the SIP URI only

Your syntax as proposed in the draft is fine with me now:
sip:[email-masked];user=dialstring;
      phone-context=atlanta.example.com

Richard

> Sent: Wednesday, August 09, 2006 3:00 PM
> To: 'Christer Holmberg (JO/LMF)'; 'Francois Audet'; 'Paul Kyzivat';
> Stastny Richard
> Cc: [email-masked]
> whether or not we would extend the tel uri to cover dialstrings, or do
> what
> this version (and several previous versions) do, which is to NOT allow
> dialstrings in a tel uri, but rather restrict them to a sip uri, with
> user=dialstring.  It was a consensus to NOT extend the tel uri, and to
that
> issue.
tells
> you
> it's not a telephone number and is a dialstring, so your suggestion is
not
> acceptable I think.
> > > user=phone is not used, the user part syntax is not even required
(as
> > > > > Internet-Drafts are also available by anonymous FTP. Login
with
> > > > >         MIME-encoded form by using the "mpack" utility.  To
use
> > this
> > > > >         a MIME-compliant mail reader.  Different
MIME-compliant
> > > > > mail
the
> > > > > Internet-Draft.
--------------------------------------------------------------------
--------------------------------------------------------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Aug 2006 09:25:45 -0400

Aha.  I see where I have confused you.

The first "GOOD" is how a telephone number is expressed in a sip uri.  It is
a correctly formed user=phone, copying the phone-context parameter as
described in the tel uri rfc.  It is NOT a dialstring example, it is a
telephone number example.

The three examples show that if a telephone number with user=phone has a
phone-context before the '@', it looks really wrong to show the same
phone-context parameter after the '@' if user=dialstring.  The user=phone
and user=dialstring parameters should look the same.

Even if you changed the name of the parameter, it still would look 'wrong',
even if the ABNF made it right.

Brian

> From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2006 9:04 AM

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 9 Aug 2006 11:12:05 -0400

Brian,

I am now totally confused as to what your current proposal is.

If dialstring is going to be done in a SIP-URI 'like' a telephone number, 
then I would say the phone-context goes in the user part. This makes sense 
to me because 'user=phone' means the userinfo of the SIP URI contains a 
tel-URI. Granted we don't have a dial-URI, but it also makes sense to me 
that 'user=dialstring' means that the userinfo contains all the information 
about the dialstring, similar to a tel-URI. If that is the case, then 
phone-context belongs in the user part.

On the other hand, if we insist on the context being a SIP-URI parameter, I 
would recommend we choose a different name (e.g. dial-context) so that its 
not confused with the tel-URI phone-context. But that still leaves the 
question of what does a phone-context SIP-URI parameter mean when 
user-dialstring is no present?

In summary, I see two options:

1) <sip:1234;phone-context=[email-masked];user=dialstring>

2) <sip:[email-masked];user=dialstring;dial-context=example.com>

I personally prefer option #1.

cheers,
(-:bob

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

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "'Christer Holmberg (JO/LMF)'" <[email-masked]>; 
"'Francois Audet'" <[email-masked]>; "'Paul Kyzivat'" 
<[email-masked]>; "'Stastny Richard'" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 09, 2006 9:25 AM
Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-04.txt

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Aug 2006 11:22:15 -0400

I am agreeing with option #1

> From: Bob Penfield [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2006 11:12 AM
> To: Brian Rosen; 'Christer Holmberg (JO/LMF)'; 'Francois Audet'; 'Paul
> Kyzivat'; 'Stastny Richard'
> Cc: [email-masked]
> Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-04.txt
> 
> Brian,
> 
> > The first "GOOD" is how a telephone number is expressed in a sip uri.
> It
> > is
> >> > sip:1234;phone-
> context=atlanta.example.com;xxx=[email-masked]
> >> > pl
> >> > e.com;user=phone
> >> >
> >> > Regards,
> >> >
> >> > Christer
> >> >
> >> >

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 17:27:23 +0200

Hi,

Would it be possible to use dial-context also in option #1?

Because, if phone-context as a SIP-URI parameter confuses with Tel-Uri,
doesn't it also confuses with Tel-Uri even more if it's part of the user
part?

Regards,

Christer 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 9. elokuuta 2006 18:22
To: 'Bob Penfield'; Christer Holmberg (JO/LMF); 'Francois Audet'; 'Paul

> If dialstring is going to be done in a SIP-URI 'like' a telephone 
> number, then I would say the phone-context goes in the user part. This

> makes sense to me because 'user=phone' means the userinfo of the SIP 
> URI contains a tel-URI. Granted we don't have a dial-URI, but it also 
> makes sense to me that 'user=dialstring' means that the userinfo 
> contains all the information about the dialstring, similar to a 
> tel-URI. If that is the case, then phone-context belongs in the user 
> part.
> 
> On the other hand, if we insist on the context being a SIP-URI 
> parameter, I would recommend we choose a different name (e.g. 
> dial-context) so that its not confused with the tel-URI phone-context.

> But that still leaves the question of what does a phone-context 
> SIP-URI parameter mean when user-dialstring is no present?
> 
> > a correctly formed user=phone, copying the phone-context parameter 
> > as described in the tel uri rfc.  It is NOT a dialstring example, it

> > is a telephone number example.
> >
> > The three examples show that if a telephone number with user=phone 
> > has a phone-context before the '@', it looks really wrong to show 
> > the same phone-context parameter after the '@' if user=dialstring.  
> > The
> user=phone
> > Even if you changed the name of the parameter, it still would look 
> > 'wrong', even if the ABNF made it right.
> >
> > Brian
> >
> >> >uri, but rather restrict them to a sip uri, with user=dialstring.

> >> So, in the first GOOD, what tells you the number is a dial string? 
> >> To
> me
> >> it looks like a normal Tel-Uri local number which has been 
> >> converted into a SIP-Uri...
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >> > I think the first GOOD is good, but the second GOOD is bad. Why 
> >> > would we need to define a new phone-context SIP URI parameter? 
> >> > Also, the first GOOD is "comaptible" with a Tel-Uri.
> >> >

> >> > In an effort to close this issue, I had a private email exchange 
> >> > with Paul Kyzivat.  The part of that that swayed me was that he 
> >> > pointed
> out
> >>
> >> > I was
> >> > advocating:
> >> >
> >> > GOOD:
sip:1234;phone-context=[email-masked]
> >> > BAD:
sip:1234;phone-context=[email-masked]
> >> > GOOD:
sip:[email-masked];phone-context=atlanta.example.com
> >> >           ;user=dialstring
> >> >
> >> > I looked at that, and pretty quickly decided I was wrong and he 
> >> > was right.
> >> >
> >> > Brian
> >> >
> >> > > user=phone is not used, the user part syntax is not even 
> >> > > required (as per RFC3261) to be according to RFC3966. So, from 
> >> > > that perspective there is no requirement to be consistent with
Tel-Uri.
> >> > > A URI is a URI. It needs to be Unique. The phone-context makes 
> >> > > it unique because it is in the user part.
> >> > >
> >> > > > I agree with Richard. And I brought it up on the -03 (and the

> >> > > > -02 I
> >> > > > > RFC3966 explicitly states that 'tel' URIs may not represent

> >> dial
> >> > > > >    and specifically, if it can represent a dial string.  
> >> > > > > This
> >> memo
> >> > > > > with the

> >> > > > > MIME-compliant mail
> >> > > > > implementation to automatically retrieve the ASCII version 
> >> > > > > of the Internet-Draft.
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > -------------------------------------------------------------
> >> > > > ----
> -
> >> > > > --
> >> > > > --
> >> > > > > --
> >> > > > >
> >> > > > -------------------------------------------------------------
> >> > > > ----
> -
> >> > > > --
> >> > > > --
> >> > > > > --
> >> > > > >

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Aug 2006 11:33:09 -0400

Well, if we have consensus to change the name of the parameter, I don't have
a problem in doing that, although I don't see a real need to do that.  If
you want to ADD the possibility of another parameter that would appear after
the host part, then I would not want to do that.

Brian

> Sent: Wednesday, August 09, 2006 11:27 AM
> To: Brian Rosen; Bob Penfield; Francois Audet; Paul Kyzivat; Stastny
> Richard
> Cc: [email-masked]

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 9 Aug 2006 11:33:41 -0400

I think that using 'dial-context' instead of 'phone-context' is probably a 
good idea to prevent confusion. However, I would still be OK with 
phone-context as long as it was in the user part (option#1) because it 
essentially has the same meaning as it does with a tel-URI.

cheers,
(-:bob

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

----- Original Message ----- 
From: "Christer Holmberg (JO/LMF)" <[email-masked]>
To: "Brian Rosen" <[email-masked]>; "Bob Penfield" 
<[email-masked]>; "Francois Audet" <[email-masked]>; "Paul 
Kyzivat" <[email-masked]>; "Stastny Richard" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 09, 2006 11:27 AM
Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-04.txt

Hi,

Regards,

Christer

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: 9. elokuuta 2006 18:22
To: 'Bob Penfield'; Christer Holmberg (JO/LMF); 'Francois Audet'; 'Paul

Tel-Uri.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Aug 2006 09:00:04 -0400

Please read the draft.

We spent a long time in the evolution of this draft on the question of
whether or not we would extend the tel uri to cover dialstrings, or do what
this version (and several previous versions) do, which is to NOT allow
dialstrings in a tel uri, but rather restrict them to a sip uri, with
user=dialstring.  It was a consensus to NOT extend the tel uri, and to
restrict dialstrings to sip uris only.  I'd really rather not revisit that
issue.

If a SIP uri contains a dialstring, there has to be something that tells you
it's not a telephone number and is a dialstring, so your suggestion is not
acceptable I think.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Aug 2006 08:41:14 -0400

In an effort to close this issue, I had a private email exchange with Paul
Kyzivat.  The part of that that swayed me was that he pointed out I was
advocating:

I looked at that, and pretty quickly decided I was wrong and he was right.

Brian

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 21:49:08 +0200

Hi,

There is still an issue with option #1, I think, from a syntax
perspective.

RFC3261 does not define parameters for the userpart of the SIP-URI.

RFC3261 does say that, if user=phone, the userpart shall be parsed as a
TEL-URI, which may have parameters (phone-context etc).

Now, if user=dialstring, the userpart shall still be parsed as a
SIP-URI, which means it is not possible to put userpart parameters. So,
I think option #1 is not in line with the RFC3261 definition of
userpart.

One option would be to define a DIAL-URI, and say that if
user=dialstring the userpart of the SIP-URI shall be parsed as a
DIAL-URI. No, I know we don't want to do that.

So, from that perspective option #2 would be better.

I think someone said earlier that the userpart must be unique. But, I
don't think that the userpart of a SIP-URI must be unique... A TEL-URI
must be unique, but that's a separate thing.

I still think that defining a new TEL-URI parameter would be the best
option. Brian said, however, that it has been discussed and that the
decission was not to do that, so I will respect that decission.

Regards,

Christer

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]] 
Sent: 9. elokuuta 2006 18:12
To: Brian Rosen; Christer Holmberg (JO/LMF); 'Francois Audet'; 'Paul

Brian,

If dialstring is going to be done in a SIP-URI 'like' a telephone
number, then I would say the phone-context goes in the user part. This
makes sense to me because 'user=phone' means the userinfo of the SIP URI
contains a tel-URI. Granted we don't have a dial-URI, but it also makes
sense to me that 'user=dialstring' means that the userinfo contains all
the information about the dialstring, similar to a tel-URI. If that is
the case, then phone-context belongs in the user part.

On the other hand, if we insist on the context being a SIP-URI
parameter, I would recommend we choose a different name (e.g.
dial-context) so that its not confused with the tel-URI phone-context.
But that still leaves the question of what does a phone-context SIP-URI
parameter mean when user-dialstring is no present?

cheers,
(-:bob

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

----- Original Message -----
From: "Brian Rosen" <[email-masked]>
To: "'Christer Holmberg (JO/LMF)'" <[email-masked]>;

> It is a correctly formed user=phone, copying the phone-context 
> parameter as described in the tel uri rfc.  It is NOT a dialstring 
> example, it is a telephone number example.
>
> The three examples show that if a telephone number with user=phone has

> a phone-context before the '@', it looks really wrong to show the same

> phone-context parameter after the '@' if user=dialstring.  The 
> user=phone and user=dialstring parameters should look the same.
>
>> So, in the first GOOD, what tells you the number is a dial string? To

>> me it looks like a normal Tel-Uri local number which has been 
>> > sip:1234;phone-context=atlanta.example.com;xxx=[email-masked]
>> > xam
>> > pl
>> > e.com;user=phone
>> >
>> > Regards,
>> >
>> > Christer
>> >
>> >
>> > pointed out

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

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 9 Aug 2006 16:14:49 -0400

According to RFC3261, the userinfo can contain:

user             =  1*( unreserved / escaped / user-unreserved )
user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
unreserved       =  alphanum / mark
mark             =  "-" / "_" / "." / "!" / "~" / "*" / "'"
                     / "(" / ")"

All the characters in the dialstring parameters are legal in userinfo. Only 
devices supporting user=dialstring need to understand that everything after 
the ";" are dialstring parameters. To all other devices, its an opaque user 
string.

cheers,
(-:bob

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

----- Original Message ----- 
From: "Christer Holmberg (JO/LMF)" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "Brian Rosen" 
<[email-masked]>; "Francois Audet" <[email-masked]>; "Paul Kyzivat" 
<[email-masked]>; "Stastny Richard" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 09, 2006 3:49 PM
Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-04.txt

Hi,

Regards,

Christer

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: 9. elokuuta 2006 18:12
To: Brian Rosen; Christer Holmberg (JO/LMF); 'Francois Audet'; 'Paul

Brian,

cheers,
(-:bob

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Aug 2006 16:53:31 -0400

Since the tel uri RFC describes how you create a SIP URI that includes the
phone-context in the userpart, we can either copy or reference that text.
The ABNF for the userpart allows the ";" and "=" characters, so there is no
syntax problem.

Brian

> To: Bob Penfield; Brian Rosen; Francois Audet; Paul Kyzivat; Stastny
> Richard
> Cc: [email-masked]

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 22:54:50 +0200

Hi,

The issue is not the actual characters, but the fact that you split the
userpart into parameters. I don't think there ever was an intention to
have parameters in the userpart of the SIP-URI. Again, the only reason
we have them in the user=phone case is because the userpart follows the
TEL-URI syntax.

Regards,

Christer 

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]] 
Sent: 9. elokuuta 2006 23:15
To: Christer Holmberg (JO/LMF); Brian Rosen; Francois Audet; Paul
Kyzivat; Stastny Richard
Cc: [email-masked]

All the characters in the dialstring parameters are legal in userinfo.
Only devices supporting user=dialstring need to understand that
everything after the ";" are dialstring parameters. To all other
devices, its an opaque user string.

cheers,
(-:bob

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

----- Original Message -----
From: "Christer Holmberg (JO/LMF)" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "Brian Rosen" 

Hi,

Regards,

Christer

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: 9. elokuuta 2006 18:12
To: Brian Rosen; Christer Holmberg (JO/LMF); 'Francois Audet'; 'Paul

Brian,

cheers,
(-:bob

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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 22:57:33 +0200

Hi, 

>Since the tel uri RFC describes how you create a SIP URI that includes
the phone-context in the userpart, we can either 
>copy or reference that text.

In that case you are converting a TEL-URI into a SIP-URI, but that is
not what we are doing in the dialstring case.

>The ABNF for the userpart allows the ";" and "=" characters, so there
is no syntax problem.

It's not a syntax problem, as far as the characters are concerned, but I
wonder if it ever was an intention to define userpart parameters for a
SIP-URI. And, we already have SIP-URI parameters, so why not use them?

Regards,

Christer

> RFC3261 does say that, if user=phone, the userpart shall be parsed as 
> a TEL-URI, which may have parameters (phone-context etc).
> 
> SIP-URI, which means it is not possible to put userpart parameters. 
> So, I think option #1 is not in line with the RFC3261 definition of 
> userpart.
> 

part.
> > has

> >> > > required
> >> > > The draft only talks about a Sip-Uri extension/parameter, so in

> >> > > it

> >> > > > > of
> >> > > > ---
> >> > > > ---

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Aug 2006 17:05:33 -0400

I feel really weird defending a proposal I spent a lot of time arguing
against :)  

The tel uri RFC describes how you construct a URI which includes the
phone-context in the userpart.  It doesn't matter WHY you are doing that, it
shows how, in both text and ABNF, you do that.  That's what we would
reference or copy.

Agree that it's adding a new construct to the 3261 syntax, but the tel uri
already did that, we would just be copying the same syntax.

I would be very happy to return to my original plan of making the parameter
appear after the hostpart.  I do see Paul's point though.

Brian

> Sent: Wednesday, August 09, 2006 4:58 PM

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Aug 2006 17:18:54 -0400

> RFC3261 does not define parameters for the userpart of the SIP-URI.

Not explicitly. But the syntax it does define includes all the 
characters needed to include parameters in the user part.

> SIP-URI, which means it is not possible to put userpart parameters.

As far as 3261 is concerned, the URI:

	sip:1234;phone-context=[email-masked];user=dialstring

is valid, but simply has a user part of "1234;phone-context=foo.com" 
with no special structure. The structure of it is (will be) defined by 
Brian's draft.

> So,

Why?

> must be unique, but that's a separate thing.

The user part doesn't need to be unique in the world, but it needs to be 
unique in the domain.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Aug 2006 17:37:40 -0400

> already did that, we would just be copying the same syntax.

I was going to say this (well, not first sentence) but Brian beat me to it.

The "user=dialstring" parameter allows the owning domain to treat the 
user part as a separate namespace from URIs with user=somethingelse. And 
then the draft specifies how to interpret user parts that are dialstrings.

The one thing that you must be careful about is allowing dialstrings to 
be used as AORs for purposes of registration. (Not something I see a lot 
of value in.) Because 3261 says to ignore URI parameters when accessing 
the location service,

	sip:1234;phone-context=[email-masked];user=dialstring
	sip:1234;phone-context=[email-masked];user=phone
	sip:1234;phone-context=[email-masked]

are all equivalent for purposes of registration. And in case you think 
that is bad, the following are also equivalent for purposes of registration:

	sip:[email-masked];dialstring-context=foo.com
	sip:[email-masked]

Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 Aug 2006 09:42:02 +0200

Hi, 

against :)  
>The tel uri RFC describes how you construct a URI which includes the
phone-context in the userpart.

I am not sure I agree. The TEL-URI describes how you define a TEL-URI,
which includes the phone-context parameter. That itself has nothing to
do with the SIP-URI userpart.

We then have a mechanism to map a TEL-URI into a SIP-URI, by adding the
whole TEL-URI (including the parameters) to the SIP-URI userpart, and
add user=phone to indicate that the userpart shall be parsed as a
TEL-URI.

In the dialstring case you are NOT mapping another URI type into a
SIP-URI - you are adding (to use your own words) a new construct to the
SIP-URI.

>It doesn't matter WHY you are doing that, it shows how, in both text
and ABNF, you do that.  That's what we would 
>reference or copy.

In the dialstring case the SIP-URI userpart is still parsed as a
SIP-URI. I agree that all the characters etc are allowed, but the issue
is really that we are adding parameters to the SIP-URI userpart.

>Agree that it's adding a new construct to the 3261 syntax, but the tel
uri already did that, we would just be copying the 
>same syntax.
>
>I would be very happy to return to my original plan of making the
parameter appear after the hostpart.  I do see Paul's 
>point though.

Has this been discussed on the SIP/SIPPING list? I do NOT want to start
a never-ending marathon discussion, but IF we want to add this new
SIP-URI construct I really think people there should have a say about
it...

Regards,

Christer

> It's not a syntax problem, as far as the characters are concerned, but

> I wonder if it ever was an intention to define userpart parameters for

> a SIP-URI. And, we already have SIP-URI parameters, so why not use
them?

> > RFC3261 does say that, if user=phone, the userpart shall be parsed 
> > as a TEL-URI, which may have parameters (phone-context etc).
> >
> > I think someone said earlier that the userpart must be unique. But, 
> > I don't think that the userpart of a SIP-URI must be unique... A 
> > TEL-URI
> 
> > I still think that defining a new TEL-URI parameter would be the 
> > best option. Brian said, however, that it has been discussed and 
> > that the decission was not to do that, so I will respect that
decission.

> > URI contains a tel-URI. Granted we don't have a dial-URI, but it 
> > also makes sense to me that 'user=dialstring' means that the 
> > userinfo contains all the information about the dialstring, similar 
> > to a tel-URI. If that is the case, then phone-context belongs in the

> > user

> > >> > IF we really need to indicate "dialstring" somewhere I think it

> > >> > should
> > >> > sip:1234;phone-context=atlanta.example.com;xxx=dialstring@atlan
> > >> > ta
> > >> > .e
> > >> > xam
> > >> > pl
> > >> > e.com;user=phone
> > >> >
> > >> > Regards,
> > >> >
> > >> > Christer
> > >> >
> > >> >
> > >> > In an effort to close this issue, I had a private email 
> > >> > exchange with Paul Kyzivat.  The part of that that swayed me 
> > >> > was that he pointed out
> > >>
> > >> > I was
> > >> > advocating:
> > >> >
> > >> > GOOD:

> > >> > > > sip:123;phone-context=[email-masked]
> > >> > > > m;
> > >> > > > u
> > >> > > > ser=dialstring
> > >> > > > >
> > >> > > > > NOTE:   The mail server at ietf.org can return the
document
> > in
> > >> > > > >         exhibit different behavior, especially when 
> > >> > > > > dealing
> > with
> > >> > > > > Below is the data which will enable a MIME compliant mail

> > >> > > > > reader
> > >> > > > > I-D-Announce mailing list [email-masked]

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 Aug 2006 09:50:47 +0200

Hi, 

Brian's draft.

I DO agree that there is no problem from a syntax perspective, and an
entity that doesn't support user=dialstring will not treat the whole
userpart as a single string. 

I just wonder whether it's in the "spirit of SIP" to do it like this :)
I am sure there is a reason why the SIP-URI parameters where defined at
the end of the URI.

I don't want to be a showstopper on this, and personally I could live
with the currently proposed solution, but I think we should verify
(unless we have already done that) with the SIP people that doing this
is ok from a "fundamental" perspecitve. Or, do you think that is not
needed?

Regards,

Christer

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 10 Aug 2006 09:16:55 -0400

----- Original Message ----- 
From: "Christer Holmberg (JO/LMF)" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>
Cc: "Bob Penfield" <[email-masked]>; "Brian Rosen" 
<[email-masked]>; "Francois Audet" <[email-masked]>; "Stastny Richard" 
<[email-masked]>; <[email-masked]>
Sent: Thursday, August 10, 2006 3:50 AM
Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-04.txt

>>with no special structure. The structure of it is (will be) defined
>>by Brian's draft.
>
>I just wonder whether it's in the "spirit of SIP" to do it like >this :) I 
>am sure there is a reason why the SIP-URI parameters where
>defined at the end of the URI.

I think you've just hit on the essential point. The proposed "phone-context" 
is a dialstring parameter. It is not a SIP-URI parameter.

I don't think this draft is in conflict with the "spirit of SIP" at all. We 
have the tel-URI precedent for "structure" in the user part defined in 3261. 
It is not that unusual for the user part to have 'structure' that is 
understood by servers that care about it and is an opaque string to those 
that do not. For example, RFC 4240 (Basic Network Media Services with SIP) 
defines a user part format for identifying a conference service:

    sip:conf=[email-masked]

Even though the dialstring is not a URI, I think we are trying to be 
consistent in the usage of the user= URI parameter when it indicates the 
content-type of the user part of the URI, particularly since dialstrings are 
a close cousin of telephone numbers.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Aug 2006 09:20:52 -0400

at end ...

> I am sure there is a reason why the SIP-URI parameters where defined at

The phone-context "parameter" we are defining isn't intended to be a 
"uri-parameter" according to the syntax and/or semantics of 3261. It is 
something entirely new.

It serves a special purpose, and as such I think it can be as we wish.

Whether something is "in the spirit of SIP" is a judgment call. I think 
some sense of the spirit can be inferred from the way user=phone was 
defined - it set the precedent that a deeper syntax for the user part 
could be tied to a value of the "user" parameter. We are just reusing 
that same approach.

Note that it isn't just this "parameter" that has a special 
interpretation. The whole point is that the dial string has a special 
interpretation too. A dial string *could* have the same form as the user 
part of a sip/user=phone URI or the user part of a sip URI with no 
"user" parameter. But all three have different meanings.

> (unless we have already done that) with the SIP people

which "sip people" did you have in mind?

I just now noticed that this is on the iptel list rather than the sip or 
sipping list, so maybe that is what you mean. But I think if you look at 
who is posting, its all the same people on all those lists. Are you 
proposing a formal liason request from the iptel WG to the sip WG?

I guess we could ask Jonathan and Henning to approve. If there are any 
people who qualify as "sip people" I guess it would be them.

But Jonathan is chair of iptel, so I suppose he would already have 
commented if he wanted to. And Henning is author of 3966. I expect he is 
well aware of this discussion as well. So I doubt we need to ask them.

> that doing this

No, I don't think it is needed. Any further concerns would be flushed 
out at WGLC.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 Aug 2006 22:54:44 +0200

Hi,

>>I just wonder whether it's in the "spirit of SIP" to do it like this 
>>:) I am sure there is a reason why the SIP-URI parameters where 
"uri-parameter" according to the syntax and/or 
>semantics of 3261. It is something entirely new.
>
some sense of the spirit can be inferred from the 
>way user=phone was defined - it set the precedent that a deeper syntax
for the user part could be tied to a value of the 
>"user" parameter. We are just reusing that same approach.

We ARE defining a new value for the user parameter, though. According to
RFC3969 that must be documented in an RFC. 

RFC3969 does not say whether that RFC has to be produced by SIP/SIPPING,
though, so maybe any WG (IPTEL in this case) can produce such RFC (and
the SIP WG doesn't have to be informed about it until the RFC is
done)...

>>>Note that it isn't just this "parameter" that has a special
interpretation. The whole point is that the dial string has 
>>>a special interpretation too. A dial string *could* have the same
form as the user part of a sip/user=phone URI or the 
>>>user part of a sip URI with no "user" parameter. But all three have
different meanings.
>I just now noticed that this is on the iptel list rather than the sip
or sipping list, so maybe that is what you mean. 

Yes.

>But I think if you look at who is posting, its all the same people on
all those lists. Are you proposing a formal liason 
>request from the iptel WG to the sip WG?

No, I don't think that is needed. A simple mail on the SIP list would be
enough. However, IF the SIP WG allows for other groups to define new URI
parameter values etc I guess not even that would be needed.

>I guess we could ask Jonathan and Henning to approve. If there are any
people who qualify as "sip people" I guess it 
>would be them.
commented if he wanted to. And Henning is author of 
>3966. I expect he is well aware of this discussion as well. So I doubt
we need to ask them.

Unless there are some "formal rules" saying that the SIP WG must be
involved I can accept that. 

Regards,

Christer