Subject: [Iptel] "*" and "#" signs in the userinfo of SIP URI

From: "Alexeitsev, D" <[email-masked]>
Date: Thu, 1 Mar 2007 13:15:25 +0100

The latest draft draft-rosen-iptel-dialstring-06.txt defines a way of
transporting the "*" and "#" signs using the "E and "F" signs
respectively.

"A new alternative value for the "userinfo" parameter of the 'sip:' or
'sips:' URI schemes is defined, "dialstring". This value may be used in
a 'sip:' or 'sips:' URI when the user part is a dial string. The
dialstring is a sequence of the characters 0-9, A-F, P, X, '*' and "#'.
E represents *, F represents #, P is a pause (short wait, like a comma
in a modem string) and X represents "wait for call completion"

What is the rationale behind this alternative?

There is already a defined way of transporting this signs and bringing
new alternative does support interoperability.

RFC 3261 says:

"The BNF for telephone-subscriber can be found in RFC 2806 [9].
Note, however, that any characters allowed there that are not allowed in
the user part of the SIP URI MUST be escaped."

The 3966 (obsolets 2806) defines the transport of the hex digits and "*"
"#" signs:

local-number-digits = *phonedigit-hex (HEXDIG / "*" /
"#")*phonedigit-hex

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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 1 Mar 2007 14:42:01 +0100

Hi Dennis,
 
In a SIP-URI you can't transport "*" or "#" unescapted - even with
user=phone. It was discussed a while ago, and I proposed that it should
be allowed to send them unescaped in a SIP-URI (I know that some
implementations do it).
 
Whether that is the rationale I don't know, but reading the draft text
you copied I would assume it is...
 
Regards,
 
Christer

________________________________

	From: Alexeitsev, D [mailto:[email-masked]] 
	Sent: 1. maaliskuuta 2007 14:15
	To: [email-masked]
	Subject: [Iptel] "*" and "#" signs in the userinfo of SIP URI 

	The latest draft draft-rosen-iptel-dialstring-06.txt defines a
way of transporting the "*" and "#" signs using the "E and "F" signs
respectively.

	"A new alternative value for the "userinfo" parameter of the
'sip:' or 'sips:' URI schemes is defined, "dialstring". This value may
be used in a 'sip:' or 'sips:' URI when the user part is a dial string.
The dialstring is a sequence of the characters 0-9, A-F, P, X, '*' and
"#'. E represents *, F represents #, P is a pause (short wait, like a
comma in a modem string) and X represents "wait for call completion"

	There is already a defined way of transporting this signs and
bringing new alternative does support interoperability. 

	RFC 3261 says: 

	"The BNF for telephone-subscriber can be found in RFC 2806 [9]. 
	Note, however, that any characters allowed there that are not
allowed in 
	the user part of the SIP URI MUST be escaped." 

	The 3966 (obsolets 2806) defines the transport of the hex digits
and "*" "#" signs: 

	Greetings, 
	Denis Alexeitsev

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Mar 2007 10:10:32 -0500

I never liked the use of E and F for * and #. Its my impression 
(somebody correct me if I am wrong) that of the 16 possible DTMF tones, 
14 are mapped to 0..D, and the other two are mapped to * and #. So there 
is at least a temptation to see this as a hex encoding and call * and # 
E and F.

I'm happy to see * and # supported. I don't mind so much if E and F are 
also supported, though it could present issues during URI comparison. 
But dial strings have other issues in comparison, so this probably is 
not a big deal.

	Paul

Alexeitsev, D wrote:
> transporting the "*" and "#" signs using the "E and "F" signs respectively.
> 
> local-number-digits = *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex
> 
> Greetings,
> Denis Alexeitsev
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 1 Mar 2007 13:28:13 -0500

My problem here is that this effort is a couple of years old, and we are
trying to finish the work.  There is no spec that I know of that couldn't be
improved, this one included.  When do we stop adding good new ideas?  The
codes really are Hex E and F, the pound (square) and star are what the Bell
System engineers decided to mark on the keys.  I defined them that way to
match the P and X and so the string would not need escaping.  You can use #
and *, and you would have to escape in a sip/sips URI.

As I understand it, you want to delete the E and F, and, by the way, leave
the P and X, which are not part of the 3966 syntax.

I want to leave it as is, which means you can have an escaped * or # or you
can have (an unescaped) E or F.  If you don't want to use E and F, don't.

And, Paul, I agree about the comparison problems plural.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, March 01, 2007 10:11 AM
> To: Alexeitsev, D
> Cc: [email-masked]
> Subject: Re: [Iptel] "*" and "#" signs in the userinfo of SIP URI
>

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 2 Mar 2007 08:47:23 +0200

Christer Holmberg \(JO/LMF\) writes:

 > user=phone. 

last time i checked, * was valid char in userpart of sip uri.

 > It was discussed a while ago, and I proposed that it should

yes, some implementation send # unescaped, but it makes NO SENSE to
define yet another way to send #, since it can be sent escaped.

-- juha

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 2 Mar 2007 08:16:12 +0100

Hi, 

user=phone. 
>last time i checked, * was valid char in userpart of sip uri.

That may be true, yes.

>>It was discussed a while ago, and I proposed that it should  be
allowed to send them unescaped in a SIP-URI (I 
>>know that some implementations do it).
> 
define yet another way to send #, since it can be 
>sent escaped.

I agree. We should have one mechanism - whatever that mechanism is.

(I still think it should be allowed to send it unescapted, because I
don't think it can "break" a SIP-URI.)

Regards,

Christer

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 2 Mar 2007 09:21:34 +0200

> don't think it can "break" a SIP-URI.)

that is the only sensible rfc action if any are done.  simply change the
grammar and allow # unescaped.  implementors are already doing it in
wide scale.

-- juha

---

From: <[email-masked]>
Date: Fri, 2 Mar 2007 15:34:51 +0800

I think this is a great idea.

yonghseng

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: 2007年3月2日 15:22
To: Christer Holmberg (JO/LMF)
Cc: [email-masked]
Subject: (瑞星提示-此邮件可能是垃圾邮件)RE: [Iptel] "*" and "#" signs in the
userinfo of SIP URI

-- juha

---

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 2 Mar 2007 12:08:05 +0100

I don't mind transferring # and * escaped or unescaped, it is up to be
ABNF experts to agree on the right encoding.

What I strongly object is the use of "E" and "F" representing the
respective signs.

Greetings,
Denis Alexeitsev

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Mar 2007 08:07:28 -0500

It is my impression that the reason it is this way is so that a sip uri 
is consistent with the generic syntax for URIs. This is important for 
those cases where a sip URI is processed by something that understands 
generic URIs and not specifically sip URIs. That is something we need to 
preserve.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 2 Mar 2007 14:27:00 +0100

Hi, 

>It is my impression that the reason it is this way is so that a sip uri
is consistent with the generic syntax for URIs. 

That is the reason that has been given, yes.

>This is important for those cases where a sip URI is processed by
something that understands generic URIs and not 
>specifically sip URIs. That is something we need to preserve.

We need to consider whether that is a realistic case.

For example, I don't think the "#" would be used in SIP-URIs which you
post on webpages etc, which could be scanned by generic URI parsers. It
will be used between SIP nodes.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Mar 2007 08:55:52 -0500

> will be used between SIP nodes.

While what you say will probably be true in most cases, I don't think it 
justifies making a syntax change. For one thing, there are URL police 
who probably would not approve it. For another, it would then be very 
difficult to specify the conditions under which it could and could not 
be used. If the syntax allowed it in dialstring URLs, it would probably 
also allow it in all sorts of sip URLs. And then you need to tell people 
to make value judgments about when to use it based on where they think 
their URLs will be used. Its just not manageable.

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 3 Mar 2007 04:58:13 +0200

> generic URIs and not specifically sip URIs. That is something we need to 

why?  is it a religious issue?  how it is possible that xmpp uris allow
# unescaped?  why does cisco phones send # unescaped?

looks like protocol people participating this mailing list have lost
sense of real life.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 3 Mar 2007 05:01:10 +0200

Paul Kyzivat writes:

 > who probably would not approve it. 

as i already asked, why didn't this police block # from xmmp uris?

-- juha

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 5 Mar 2007 10:11:01 +0100

Hi, 

>>It is my impression that the reason it is this way is so that a sip
uri is consistent with the generic syntax for 
>>URIs. This is important for those cases where a sip URI is processed
by something that understands generic URIs and 
>>not specifically sip URIs. That is something we need to  > preserve.
> 
>why?  is it a religious issue?  how it is possible that xmpp 
>uris allow # unescaped?  why does cisco phones send # unescaped?
> 
sense of real life.

This reminds me very much of the send-DTMF-using-INFO discussion... :)

Regards,

Christer

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 6 Mar 2007 17:04:12 +0100

Hello altogether

Can the outcome of the discussion be summarised as the encoding of the
"*" and "#": 

- Using "E" and "F" is not recommended.
- Using escaped "*" and "#" is possible according to the current SIP URI
ABNF syntax but is not wanted
- Using unescaped "*" and "#" is currently against the syntax but it is
the wanted solution

What would be then the next steps based on this results?

Greetings,
Denis Alexeitsev

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 6 Mar 2007 12:19:43 -0500

I don't think we agree unescaped * and # is wanted.  It screws up a lot of
other "stuff" for something that looks nice if a human reads it.

I really want to get this done.  By bringing this issue up at this time (a
year after it was proposed), you are asking that we go at least one more
cycle of delay at the IESG to approve this for publication.  I can put in
another version, wait for the hold to be lifted, and then see if we have
consensus before asking the IESG to act.  If we don't have consensus to
leave the text as is, that is what we have to do.

I think the text is okay as written, and I don't want to see this document
propose to change escaping rules for sip URIs.

Brian

> Sent: Tuesday, March 06, 2007 11:04 AM
> To: [email-masked]
> Subject: AW: [Iptel] "*" and "#" signs in the userinfo of SIP URI
> 
> Hello altogether
>

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 6 Mar 2007 20:49:11 +0200

> other "stuff" for something that looks nice if a human reads it.

no-one has ever explained what is screws up.

 > propose to change escaping rules for sip URIs.

and i don't want to see any document that proposed YET ANOTHER way to
carry * and # in sip uri.

there must be an end to adding duplicated features to sip.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Mar 2007 14:12:18 -0500

I agree with Brian.

The proposal would require a revision to the definition of SIP-URI that 
would make it incompatible with RFC 2396. IMO that is a bad thing to do 
for the marginal benefit here. And if attempted it would no doubt take a 
long time.

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 6 Mar 2007 21:26:01 +0200

Paul Kyzivat writes:

 > would make it incompatible with RFC 2396. 

and so what?  compatibility cannot be a religious issue if there are no
technical issues and no-one has not pointed out any.

as i have told, xmpp uris (rfc 3920) allow # in the part as we call
userpart.  xmpp rfc says

   An entity is anything that can be considered a network endpoint
   (i.e., an ID on the network) and that can communicate using XMPP.
   All such entities are uniquely addressable in a form that is
   consistent with RFC 2396 [URI].

but still it isn't and no ietf protocol police has had no trouble with
that, because the rfc has been published.

 > IMO that is a bad thing to do 

a much worse thing would be to define yet another sip feature.

-- juha

---

From: lconroy <[email-masked]>
Date: Wed, 7 Mar 2007 00:26:21 +0000

Hi Brian. folks,
  Amen to that.
This document is the missing piece. It's LONG overdue.

* and # can be escaped when carried in a SIP URI; that works now and  
its legal.
Converting tel URI parameters to be carried in legal SIP URIs is no  
different.

IMHO No change is needed to this document - if some code doesn't do  
escaping
rules properly then it may work, it may not, but that has nothing to  
do with
this document.
I seem to recall a certain SIP phone that didn't enclose display  
names in
quotes even if they have embedded spaces. That caused fun, but not with
all systems. Do you really want to force everyone to re-do their  
regression
testing to fit some implementations?

If you want to re-address valid characters in SIP URIs, then go do it in
SIPPING/SIP. Once that's done, then there will be a stable base on which
to build. Providing ad-hoc "quick hacks" to fit an immediate preference
has not proved successful in the past. The law of unintended  
consequences
still applies (last time I checked, anyway :).

Once a considered change to SIP escaping rules has been standardised  
then
a whole bunch of RFCs could then be re-considered - this is NOT the  
only one.

However, until that point, please let's not delay this even more.
I for one want this yesterday.

all the best,
   Lawrence

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Mar 2007 16:02:34 -0500

> technical issues and no-one has not pointed out any.

This organization is in the standards business. So we at least shouldn't 
be in the business of violating the ones we have set for ourselves. 
Standards are only useful if they are followed.

Specifically, from the beginning sip has asserted that the SIP-URI is a 
URI as defined in RFC 2396. If it isn't, we shouldn't be calling it a 
URI at all.

SIP URIs can be passed around, stored, and manipulated as generic 2396 
URIs by pieces of software that aren't aware of the specifics of SIP 
URIs. Such pieces of software may well look to 2329 as a definition of 
what to expect, and may fail if given a "uri" that doesn't comply.

Unless you can enumerate all possible (current and future) uses of sip 
URIs I don't see how you can say there are no technical issues.

> userpart. 

I don't claim to be an expert regarding that, but I just took a look. I 
don't find any ABNF specifying what is allowed, so its not at all clear 
to me why you think # is allowed.

> xmpp rfc says

The above statement says to me that they are asserting compatibility 
with 2396. And 2396 clearly disallows unescaped # characters.

the xmpp rfc does talk a lot about STRINGPREP and Nodeprep, which seem 
to be involved in canonicalizing international character sets. I'm not 
going to go read that, but the impression I get is that a JID is very 
lenient about the character set it contains, but that it must be 
normalized in order to transform it to a 2396 compatible xmpp URI. I'm 
guessing that the output of that process has no unescaped # characters.

That normalization isn't conceptually different than escaping the 
contents of a dialstring before putting it into a sip URI.

> that, because the rfc has been published.

And it claims to conform to 2396, and doesn't say in any obvious way 
that it violates it.

	Paul

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 7 Mar 2007 10:19:28 +0100

>I for one want this yesterday
 
Amen
Richard

Von: lconroy [mailto:[email-masked]]
Gesendet: Mi 07.03.2007 01:26
An: Brian Rosen
Cc: [email-masked]
Betreff: Re: [Iptel] "*" and "#" signs in the userinfo of SIP URI

Hi Brian. folks,
  Amen to that.

all the best,
   Lawrence

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 7 Mar 2007 10:50:06 +0100

Hi,

I think we should take into consideration that this seems to be
something which relatively widely deployed. And, as said before, the
reason does not seem to be that people have understood the specs wrong,
but that it is required in order to interop. And, I think we also agree
that it doesn't break SIP as such.

Regarding the
we-do-not-know-what-a-SIP-URI-may-be-used-for-in-the-future issue,
please remember that a TEL-URI does NOT seem to be compatible with RFC
2396. So, the problem Paul talks about already exist.

Regards,

Christer

> Sent: 6. maaliskuuta 2007 23:03
> To: Juha Heinanen
> Cc: [email-masked]
> >  > The proposal would require a revision to the definition 
> of SIP-URI 
> > that  > would make it incompatible with RFC 2396.
> > 
> > and so what?  compatibility cannot be a religious issue if 
> there are 
> > no technical issues and no-one has not pointed out any.
> 
> This organization is in the standards business. So we at 
> least shouldn't be in the business of violating the ones we 
> have set for ourselves. 
> Specifically, from the beginning sip has asserted that the 
> SIP-URI is a URI as defined in RFC 2396. If it isn't, we 
> shouldn't be calling it a URI at all.
> 
> SIP URIs can be passed around, stored, and manipulated as 
> generic 2396 URIs by pieces of software that aren't aware of 
> the specifics of SIP URIs. Such pieces of software may well 
> look to 2329 as a definition of what to expect, and may fail 
> if given a "uri" that doesn't comply.
> 
> Unless you can enumerate all possible (current and future) 
> uses of sip URIs I don't see how you can say there are no 
> technical issues.
> 
> I don't claim to be an expert regarding that, but I just took 
> a look. I don't find any ABNF specifying what is allowed, so 
> its not at all clear to me why you think # is allowed.
> 
> > xmpp rfc says
> > 
> The above statement says to me that they are asserting 
> compatibility with 2396. And 2396 clearly disallows unescaped 
> # characters.
> 
> the xmpp rfc does talk a lot about STRINGPREP and Nodeprep, 
> which seem to be involved in canonicalizing international 
> character sets. I'm not going to go read that, but the 
> impression I get is that a JID is very lenient about the 
> character set it contains, but that it must be normalized in 
> order to transform it to a 2396 compatible xmpp URI. I'm 
> That normalization isn't conceptually different than escaping 
> the contents of a dialstring before putting it into a sip URI.
> 
> And it claims to conform to 2396, and doesn't say in any 
> obvious way that it violates it.
> 
> 	Paul
> 
> >  > for the marginal benefit here. And if attempted it would 
> no doubt 
> > take a  > long time.
> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Mar 2007 08:39:57 -0500

I'll note that RFC 2396 has been obsoleted by RFC 3986. It seems to  
give a somewhat clearer explanation of what needs to be escape and  
what doesn't.

"Section 2, on characters, has been rewritten to explain what
    characters are reserved, when they are reserved, and why they are
    reserved, even when they are not used as delimiters by the generic
    syntax."

The basic rule is

If data for a URI component would conflict with a reserved
    character's purpose as a delimiter, then the conflicting data  
must be
    percent-encoded before the URI is formed.

The relevant general rule is

   URI producing applications should percent-encode data octets that
    correspond to characters in the reserved set unless these characters
    are specifically allowed by the URI scheme to represent data in that
    component.  If a reserved character is found in a URI component and
    no delimiting role is known for that character, then it must be
    interpreted as representing the data octet corresponding to that
    character's encoding in US-ASCII.

In my view, this means, roughly, that if a particular URI doesn't  
need one of the delimiters (reserved) characters as delimiters and  
there is no ambiguity, it doesn't have to be %-encoded, although it  
is obviously always safe to do so.

In RFC 3986, # is a gen-delims and * is a sub-delims.

However, in a SIP URI, neither # nor * have any special function.  
Thus, it would, in principle be safe to not escape them. RFC 3261  
seems pretty clear, however, on the fact that telephone-subscriber  
must follow the rules for 'user' components, where neither # or * is  
allowed.

userinfo         =  ( user / telephone-subscriber ) [ ":" password ] "@"
user             =  1*( unreserved / escaped / user-unreserved )
user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"

Thus, I think there are two choices:

- Just escape them. Not as pretty, but most of the time, these URLs  
are not visible to humans, so it doesn't seem to be a big deal.

- The draft would have to update RFC 3261 and explicitly change  
several pieces of the userinfo discussion in RFC 3261, allowing those  
characters in userinfo as additional user-unreserved characters.

In general, the escaping notation of URLs is very confusing, as the  
BNF often shows the pre-escaping character set, at least in some  
older RFCs.

On Mar 6, 2007, at 4:02 PM, Paul Kyzivat wrote:

>
>
> Juha Heinanen wrote:
>> Paul Kyzivat writes:
>>  > The proposal would require a revision to the definition of SIP- 
>> URI that  > would make it incompatible with RFC 2396. and so  
>> what?  compatibility cannot be a religious issue if there are no
> This organization is in the standards business. So we at least  
> shouldn't be in the business of violating the ones we have set for  
> ourselves. Standards are only useful if they are followed.
>
> Specifically, from the beginning sip has asserted that the SIP-URI  
> is a URI as defined in RFC 2396. If it isn't, we shouldn't be  
> calling it a URI at all.
>
> SIP URIs can be passed around, stored, and manipulated as generic  
> 2396 URIs by pieces of software that aren't aware of the specifics  
> of SIP URIs. Such pieces of software may well look to 2329 as a  
> definition of what to expect, and may fail if given a "uri" that  
> doesn't comply.
>
> Unless you can enumerate all possible (current and future) uses of  
> sip URIs I don't see how you can say there are no technical issues.
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 7 Mar 2007 21:28:14 +0100

Hi Henning, 

Comments inline ([CHH])

>I'll note that RFC 2396 has been obsoleted by RFC 3986. It 
>seems to give a somewhat clearer explanation of what needs to 
>be escape and what doesn't.
> 
>If data for a URI component would conflict with a reserved character's
purpose as a delimiter, then the conflicting 
>data must be percent-encoded before the URI is formed.
> 
> 
>are specifically allowed by the URI scheme to represent 
>data in that component. If a reserved character is found in a URI 
>component and no delimiting role is known for that character, then it
must be
>In my view, this means, roughly, that if a particular URI 
>doesn't need one of the delimiters (reserved) characters as 
>delimiters and there is no ambiguity, it doesn't have to be 
>%-encoded, although it is obviously always safe to do so.
> 
>Thus, it would, in principle be safe to not escape them. RFC 
>3261 seems pretty clear, however, on the fact that 
>telephone-subscriber must follow the rules for 'user' 
>components, where neither # or * is allowed.
> 

I think telephone-subscriber allows BOTH # and *.

>From RFC3966 (TEL-URL):

telephone-subscriber = global-number / local-number
local-number         = local-number-digits *par context *par
local-number-digits  = *phonedigit-hex (HEXDIG / "*" /
"#")*phonedigit-hex

>- Just escape them. Not as pretty, but most of the time, 
>these URLs are not visible to humans, so it doesn't seem to 
>be a big deal.
> 
>- The draft would have to update RFC 3261 and explicitly 
>change several pieces of the userinfo discussion in RFC 3261, 
>allowing those characters in userinfo as additional 
>user-unreserved characters.

The fix could be done using bugzilla, or something...

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 8 Mar 2007 13:32:08 -0600

You do realize that you can do exactly the same thing with
RFC 3966 and the phone-context, by defining a
phone-context=mydiaplan.example.net, right?

> From: lconroy [mailto:[email-masked]] 
> Sent: Tuesday, March 06, 2007 16:26
> To: Brian Rosen
> Cc: [email-masked]
> * and # can be escaped when carried in a SIP URI; that works 
> now and its legal.
> Converting tel URI parameters to be carried in legal SIP URIs 
> is no different.
> 
> IMHO No change is needed to this document - if some code 
> doesn't do escaping rules properly then it may work, it may 
> not, but that has nothing to do with this document.
> I seem to recall a certain SIP phone that didn't enclose 
> display names in quotes even if they have embedded spaces. 
> That caused fun, but not with all systems. Do you really want 
> to force everyone to re-do their regression testing to fit 
> some implementations?
> 
> If you want to re-address valid characters in SIP URIs, then 
> go do it in SIPPING/SIP. Once that's done, then there will be 
> a stable base on which to build. Providing ad-hoc "quick 
> hacks" to fit an immediate preference has not proved 
> successful in the past. The law of unintended consequences 
> Once a considered change to SIP escaping rules has been 
> standardised then a whole bunch of RFCs could then be 
> re-considered - this is NOT the only one.
> 
> > I don't think we agree unescaped * and # is wanted.  It screws up a 
> > lot of other "stuff" for something that looks nice if a human reads 
> > it.
> >
> > I really want to get this done.  By bringing this issue up at this 
> > time (a year after it was proposed), you are asking that we go at 
> > least one more cycle of delay at the IESG to approve this for 
> > publication.  I can put in another version, wait for the hold to be 
> > lifted, and then see if we have consensus before asking the IESG to 
> > act.  If we don't have consensus to leave the text as is, 
> that is what 
> > we have to do.
> >
> > I think the text is okay as written, and I don't want to see this 
> > document propose to change escaping rules for sip URIs.
> >
> > Brian
> >
> >> Can the outcome of the discussion be summarised as the encoding of 
> >> the "*" and "#":
> >>
> >> - Using escaped "*" and "#" is possible according to the 
> current SIP 
> >> URI ABNF syntax but is not wanted
> >> - Using unescaped "*" and "#" is currently against the 
> syntax but it 
> >> is the wanted solution
> >>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 8 Mar 2007 17:55:29 -0500

iptel is not meeting at IETF68, so I can't get up and ask for a hum there.

I really want to get this done now.  We two aspects on this that we need to
resolve:

1. Is it required that I drop E and F as a way to encode * and #?

2. Is it required to modify the syntax of the uri to allow * and #
un-escaped?

We have a lot of people who are saying "no" to both of these.  Would the
people who demand changes please state:
a) If I have captured the issue correctly
b) If they demand one or both of the items

I'd appreciate email from anyone who demands something change.  "Demand"
here means you would hum against recommending the IESG approve the current
text if we asked the question in Prague.

We'll have to come up with a way to determine rough consensus without this
being a work group item.

Brian

> From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2007 3:28 PM
> To: Henning Schulzrinne; Paul Kyzivat
> Cc: [email-masked]; Juha Heinanen
> Subject: RE: [Iptel] "*" and "#" signs in the userinfo of SIP URI
> 
> 
> Hi Henning,
> 
> Comments inline ([CHH])
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 9 Mar 2007 11:06:02 +0100

Hi,

>iptel is not meeting at IETF68, so I can't get up and ask for 

I think this would be a valid case for BLISS to discuss, wouldn't it?
Because, it is not only related to your draft, but to SIP in general.
 
>I really want to get this done now.  We two aspects on this 
>that we need to resolve:
> 
>2. Is it required to modify the syntax of the uri to allow * 
>and # un-escaped?

* can alady be sent un-escapted.

>We have a lot of people who are saying "no" to both of these. 
>Would the people who demand changes please state:

Yes.

>b) If they demand one or both of the items

Both.

>here means you would hum against recommending the IESG approve the
current text if we asked the question in Prague.

Is question 2) really a show-stopper for your draft? I assume it is
based on the SIP-URI syntax, and that is what need to be changed if we
want to allow un-escapted #.

Regards,

Christer

> We'll have to come up with a way to determine rough consensus 
> without this being a work group item.
> 
> Brian
> 
> seems to 
> > >character's
> data in that 
> > >component. If a reserved character is found in a URI 
> component and no 
> > >delimiting role is known for that character, then it
> > must be
> these URLs

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 9 Mar 2007 07:34:57 -0500

> want to allow un-escapted #.
Well, I am opposed to changing SIP-URI syntax without an extensive
discussion in sip to make sure we understand the consequences.  I think they
are significant, but I don't know.

I think this discussion is misplaced, because it doesn't matter a whit how
you encode * and #; it's not a user visible string.  That you can do it is
all you need.  That makes E and F not such a strong argument, and if this 
was not two revisions passed the point where we (unofficially) last called
the draft, I'd take it out.  As it is ready for the IESG to approve, I'd
prefer we just leave it alone and put our attention on things that 
actually matter.

Brian

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 9 Mar 2007 13:48:02 +0100

Hi, 

>>based on the SIP-URI syntax, and that is what need to be 
>>changed if we want to allow un-escapted #.
>Well, I am opposed to changing SIP-URI syntax without an 
>extensive discussion in sip to make sure we understand the 
>consequences.  I think they are significant, but I don't know.

You should not change any syntax in your draft in any case - because the
issue is generic.

Regards,

Christer

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 9 Mar 2007 08:54:06 -0500

Okay, I understand, but then are you opposed to recommending the IESG
approve the draft as is?

Brian

> Sent: Friday, March 09, 2007 7:48 AM
> To: Brian Rosen; Henning Schulzrinne; Paul Kyzivat

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 9 Mar 2007 15:01:37 +0100

Hi, 

approve the draft as is?

I think that we shall only have one mechanism of representing # and *.

But, from what I understood you are proposing to remove the E and F
part, right, and use # and * instead?

I don't think your draft needs to talk about what has to be escapted
etc, because that is handled by 3261.

Regards,

Christer

> > >discussion in sip to make sure we understand the consequences.  I 
> > >think they are significant, but I don't know.
> > 
> > You should not change any syntax in your draft in any case 
> - because 
> > the issue is generic.
> > 
> > Regards,
> > 
> > Christer
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 9 Mar 2007 09:06:52 -0500

> etc, because that is handled by 3261.

I think a reasonable mechanism is to focus on the "input" character  
set and encoding, before URL encoding. The latter is largely a  
mechanical process that's invisible to the user, except when writing  
URLs on napkins. If we later (3261bis) change our minds and say that  
# does not need to be escaped, "old" (escaped) URLs will still work  
and have the same meaning.

Personally, I think using E and F is a hack that will likely lead to  
mistakes and confusion since nobody will be able to remember whether  
E represents # or * (or that they are at all connected).

My suggestion: Briefly describe the issues surrounding # and say that  
it needs to be %-encoded. Done. (There doesn't seem to be a need to  
encode *.)

Henning

---

From: David R Oran <[email-masked]>
Date: Fri, 9 Mar 2007 10:39:44 -0500

On Mar 9, 2007, at 9:06 AM, Henning Schulzrinne wrote:

> mechanical process that's invisible to the user, except when  
> writing URLs on napkins. If we later (3261bis) change our minds and  
> say that # does not need to be escaped, "old" (escaped) URLs will  
> still work and have the same meaning.
>
> Personally, I think using E and F is a hack that will likely lead  
> to mistakes and confusion since nobody will be able to remember  
> whether E represents # or * (or that they are at all connected).
>
> My suggestion: Briefly describe the issues surrounding # and say  
> that it needs to be %-encoded. Done. (There doesn't seem to be a  
> need to encode *.)
>
> Henning
>
>
I agree with Henning.
DaveO.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 9 Mar 2007 10:47:13 -0500

Meaning you insist I rev the draft again, and wait another IESG cycle?

Brian

> From: David R Oran [mailto:[email-masked]]
> Sent: Friday, March 09, 2007 10:40 AM
> To: Henning Schulzrinne
> Cc: [email-masked]; Juha Heinanen; Christer Holmberg (JO/LMF)

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 9 Mar 2007 10:50:34 -0500

I suspect compared to the time it will take from here to RFC  
publication, an IESG cycle is likely less than 10% of the total. I  
wish it were different, but this seems like the wrong optimization  
point.

---

From: David R Oran <[email-masked]>
Date: Fri, 9 Mar 2007 10:55:15 -0500

> Meaning you insist I rev the draft again, and wait another IESG cycle?
Not necessarily. Changes of this magnitude are often made without  
another last call.

---

From: "Alexeitsev, D" <[email-masked]>
Date: Mon, 12 Mar 2007 17:21:52 +0100

Yes

Yes, it would be the clearest and intuitive solution.

BTW, I have not yet seen such a lot of people answering "no" to both of
the questions

There is a session in Prague where the issue with unescaped # could be
brought up:

Session 1: Tuesday March 20, 2007 1740-1840 Grand Ballroom

Robert Sparks Process for Revising 3261
Mechanism for Publication 
Prioritization of Issues 
Which current drafts are bugfixes?    20 

Greetings
Denis Alexeitsev

---

From: lconroy <[email-masked]>
Date: Mon, 12 Mar 2007 17:37:28 +0000

Hi Folks,
  I hadn't realised this was a vote (it being the IETF and all ;).
My "vote" was and is for the second of these questions to be deemed
out of scope for this draft. The first one I don't care either way.

If folk insist on any change at all -way- after this went through
last call, and that change is to remove E & F as encodings for *
and #, then...

The quick fix is to strip these from the draft and leave it as is.
[with a possible added caveat that * and/or # may need to be escaped
in the context of the URI]

IMHO, That is the only reasonable (and quick) solution.
I'm not sure that change warrants another WGLC/IETF LC.
I believe that the draft (with or without E&F) can ship.

----
That is quite independent of any other windmill-tilting people
want to do. As a separate task, not specific to this draft, I
wonder:
   Do all the people stating that the URI syntax needs to change
   seriously believe that this will happen quickly in the IETF?

I don't care whether it's a more elegant approach for this problem.
I do care about what is possible to standardise in reasonable time.
I would guess that this is a SIPPING/SIP task, not an IPTEL task.

I will watch with interest, but would object if it is cobbled onto
this draft. That would be more than normally stupid, as it has a
general impact rather than being tied only to this one.

all the best,
   Lawrence

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 12 Mar 2007 14:52:44 -0400

In message <[email-masked]>
"Alexeitsev, D" writes:
> BTW, I have not yet seen such a lot of people answering "no" to both
> of the questions

I suggest the following.

  MUST NOT send E or F.

  MAY accept E and F (some might send it, but unlikely).

  SHOULD (or MUST?) send * and # escaped.

  SHOULD NOT send * and # un-escaped.

  MUST accept * and # escaped.

  SHOULD accept * and # un-escaped (some might send it).

Changing MUST, SHOULD, and MAY generally will not require a full IESG
cycle so might as well make it clear.

There was some question about whether both * and # escaped.  Its
probably best to send both escaped, therefore the SHOULD.

Curtis

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2007 15:09:03 -0400

> 1. Is it required that I drop E and F as a way to encode * and #?

I don't care much about this. I would have preferred that E/F not be 
included, but I have no interest in holding things up for this change. 
If it is going to be held up anyway then I would be in favor of removing 
this.

> Yes, it would be the clearest and intuitive solution.

Can somebody explain why it matters that the # be unescaped?

- Are you worried about people having to type in dialstring URIs with 
the escape? (Who would want to do so?)

- Or are you worried about people being confused when looking at them? 
(Who will see them?

- Or are you worried about the burden on the recipient that has to 
process the escape? (Escapes must be processed in any case.)

> BTW, I have not yet seen such a lot of people answering "no" to both of

I don't think we should be changing 3261 at this time for so petty a reason.

> There is a session in Prague where the issue with unescaped # could be

Do we have the time to spare for this? Maybe in the evening, over beer.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 13 Mar 2007 09:00:45 +0100

Hi, 

>Can somebody explain why it matters that the # be unescaped?

It seems like it is rather widely deployed. And, eventhough we generally
should not change our specifications just because someone has
implemented them wrong, I think this is a case where it could be done.
Because, it doesn't break the protocol, and there is no good
justification to mandate the escaping ("general parsers" would fail when
parsing TEL-URLs anyway).

>- Are you worried about people having to type in dialstring 
>URIs with the escape? (Who would want to do so?)
> 
>- Or are you worried about the burden on the recipient that 
>has to process the escape? (Escapes must be processed in any case.)

Maybe those who are implemeting it should answer...

>Do we have the time to spare for this? Maybe in the evening, over beer.

As I said earlier, wouldn't this be something for BLISS to discuss?

Regards,

Christer

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 13 Mar 2007 11:46:18 +0100

Comments inline

>the escape? (Who would want to do so?)#

No

>- Or are you worried about people being confused when looking at them? 

Yes, conformance testing would be much simpler if you could understand
it clear text. At the end it was one of the main arguments pro SIP that
it can be understood without expensive protocol decoders. 

>process the escape? (Escapes must be processed in any case.)

No

I am worried about the endless rounds of discussions with the CPE
implementers about how to encode the "#" sign and why should it be
escaped when the "*" is not escaped. Especially the IAD vendors that
would normally have to encode only digits, would have to implements the
escaped syntax just for one sign. 

I'm also worried about the terminals sending the strings like
sip:[email-masked] where there is no possibility to understand if
it is a dial string or just a weird alias some one picked up. You can
neither differentiate at the user interface whether it is a dial string,
or alias to attach the user=dialstring parameter, nor at the proxy.

Greetings,
Denis Alexeitsev

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2007 08:48:51 -0400

> parsing TEL-URLs anyway).

Oh, so your argument for this is that you see it being used in unescaped 
form today.

Are you really seeing URIs with user=dialstring today??? Or are you 
talking about user=phone, or plain ordinary SIP URIs?

If the real problem is that there is widespread use of unescaped # in 
SIP URIs, independent of user=dialstring, then I don't think we should 
solve that problem in this draft. Instead this draft should just accept 
the standard rules for sip URIs, and if they are eventually changed it 
can apply here as well.

	Paul

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2007 09:08:04 -0400

> it can be understood without expensive protocol decoders. 

Then should we also eliminate the requirement to escape characters when 
headers are embedded in URIs? Escaping is a fact of life. If 
implementors can't understand it they should get a different job.

> escaped syntax just for one sign. 

My heart bleeds for them. :-)

> or alias to attach the user=dialstring parameter, nor at the proxy.

If E and F are only URI encodings for the dialing of the characters * 
and #, then there should be no problem at the user interface. Just don't 
allow the use of E and F for this purpose in the user interface. And any 
UI that is collecting a dialstring and passing it directly as a URI 
(without expansion to E.164) should always use user=dialstring to 
distinguish it from a real sip username.

If you are concerned with figuring this out after the fact - after the 
dialstring has been encoded as a SIP URI with no user=dialstring - then 
you should also be concerned with the characters A-D. E.g.

	SIP:[email-masked]
   vs	SIP:[email-masked];user=dialstring

Note: I think it would be *better* to remove E and F, but only to 
prevent there from being two ways to encode the same thing, not for the 
above reasons. And I don't think it is important enough to delay this if 
there is no other reason to delay it.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 13 Mar 2007 16:25:22 +0100

Hi, 

>>It seems like it is rather widely deployed. And, eventhough we 
>>generally should not change our specifications just because someone 
>>has implemented them wrong, I think this is a case where it 
>>could be done.
>>justification to mandate the escaping ("general parsers" would fail 
>>when parsing TEL-URLs anyway).
> 
>Oh, so your argument for this is that you see it being used 
>in unescaped form today.

That's my main argument, but I also share Dennis' view that it's stupid
having to escape it without any good reason.

>Are you really seeing URIs with user=dialstring today??? Or 
>are you talking about user=phone, or plain ordinary SIP URIs?

I haven't seen it with user=dialstring, but I've seen it at least in
user=phone (maybe also in ordinary SIP URIs).

>If the real problem is that there is widespread use of 
>unescaped # in SIP URIs, independent of user=dialstring, then 
>I don't think we should solve that problem in this draft. 
>Instead this draft should just accept the standard rules for 
>sip URIs, and if they are eventually changed it can apply 
>here as well.

That's what I have said.

I do NOT propose that this draft should change the SIP-URI ABNF. That
should be done elsewhere.

This draft should simply remove E and F, and use # (escapted, until we
have changed the SIP-URI ABNF) and * instead.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 13 Mar 2007 17:08:44 +0100

Hi,

If we remove E and F (which I think nobody has really objected to) there
is no reason why the draft should be delayed.

The escape issue will be dealt with elsewhere ("3261bis").

Regards,

Christer 

> Sent: 13. maaliskuuta 2007 15:08
> To: Alexeitsev, D
> Cc: [email-masked]; Liess, Laura; Beck01,Wolfgang
> Subject: Re: AW: AW: [Iptel] "*" and "#" signs in the 
> userinfo of SIP URI
> 
> 
> 
> Alexeitsev, D wrote:
> > Comments inline
> > 
> > it clear text. At the end it was one of the main arguments pro SIP 
> > that it can be understood without expensive protocol decoders.
> 
> Then should we also eliminate the requirement to escape 
> characters when headers are embedded in URIs? Escaping is a 
> fact of life. If implementors can't understand it they should 
> get a different job.
> 
> > would normally have to encode only digits, would have to implements 
> > the escaped syntax just for one sign.
> 
> > sip:[email-masked] where there is no possibility to 
> understand 
> > if it is a dial string or just a weird alias some one 
> picked up. You 
> > can neither differentiate at the user interface whether it 
> is a dial 
> > string, or alias to attach the user=dialstring parameter, 
> nor at the proxy.
> 
> If E and F are only URI encodings for the dialing of the 
> characters * and #, then there should be no problem at the 
> user interface. Just don't allow the use of E and F for this 
> purpose in the user interface. And any UI that is collecting 
> a dialstring and passing it directly as a URI (without 
> expansion to E.164) should always use user=dialstring to 
> If you are concerned with figuring this out after the fact - 
> after the dialstring has been encoded as a SIP URI with no 
> user=dialstring - then you should also be concerned with the 
> characters A-D. E.g.
> 
> 	SIP:[email-masked]
> Note: I think it would be *better* to remove E and F, but 
> only to prevent there from being two ways to encode the same 
> thing, not for the above reasons. And I don't think it is 
> important enough to delay this if there is no other reason to 
> delay it.
> 
> 	Paul
>

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 13 Mar 2007 23:22:56 +0200

> there is no other reason to delay it.

i don't like at all the idea that proxy implementers need add another
uri user parser to their software.  please use sip wg bandwidth for
something new and useful rather than specifying many ways to do the same
thing.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2007 18:26:49 -0400

> something new and useful rather than specifying many ways to do the same

Your average proxy doesn't need to parse the user part of a dialstring. 
Dialstrings *ought* to be the business of the UA.

If a proxy is assuming the responsibility for translating dialstrings 
into E.164 numbers, then it will need a bunch of special logic to do so.

What bothers me the most is systems where *nobody* translates the 
dialstring into something context-free like an E.164 number - just 
assuming that everybody will understand the dialstring the same way.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 14 Mar 2007 12:01:03 -0500

Isn't it obvious that Paul is right?

This group does not have the mandate to change the definition
of what a URI is and allow non-allowable un-escaped caracters. 

I don't see that a vote on the second item is useful at all.

> Sent: Tuesday, March 13, 2007 06:08
> To: Alexeitsev, D
> Cc: [email-masked]; Liess, Laura; Beck01, Wolfgang