Subject: [SIP] (no subject)

From: Mark Eastman <[email-masked]>
Date: Thu, 6 Jul 2000 10:33:46 -0400 (EDT)

Hello,

I saw part of a thread of your discussion on TEL URLs shown below.  I was
wondering what the initial question was.  Does this discussion involve 
tel: URLs being transformed to sip: URLs or handling tel: separately?
(i.e. tel:5555555 = sip:[email-masked];user=phone).

Thanks,
Mark

---------------------------------------------------
Simple solution: any @ should be reserved (and thus needs to be escaped)
since it is syntactically significant in SIP URLs. (@ has no syntactic
significance in RFC 2806 and thus this transformation is harmless.)
Translating tel: URL delimiters into something else is really, really
ugly and just cascades the problem.

"Fairlie-Cuninghame, Robert" wrote:
> 
> Gethin,
> >
> > @ is not allowed in parameters.  Therefore it would be possible to
> > delimit the userinfo first by looking for @ and then parsing the host
> > afterwards so in the case above (assuming the ; and ? hasve been added
> > to the user bnf), this can only be resolved as
> >
> > user = ABCD;dog=cat
> > host = fish.com
> >
> 
> 
> I think you misinterpreted my example (the parameter cat=dog originated
as a
> tel: prameter not a sip one; however it may be interpreted as a SIP
> parameter dog=[email-masked] - that's the ambiguity).
> 
> sip:ABCD;dog=[email-masked];user=phone
> 
> >From RFC2543bis (July 2000) the @ is a valid SIP parameter value (see
> below). So if the parser doesn't understand the user=phone parameter (or
is
> not very careful in handling the tel:) then it WILL be misinterpreted!!!
See
> what I mean about this making the SIP URL parsing complicated and
> conditional on the understanding of a parameter value !!!
> 
> other-param = pname - pname "=" pvalue (Henning, I assume that is
supposed
> to be a '|' not a hyphen in the document, right ?).
> pname = 1 * paramchar
> pvalue = 1 * paramchar
> paramchar = param-unreserved | unreserved | escaped
> param-unreserved = [ | ] | / | : | @ | & | + | $
> 
> > > If the parser determines the end of the user@host:port by
> > searching for a
> > > semicolon then the same thing will occur. This is a valid
> > (as far as I can
> > > see) and simple way for parser to pull out the base URL (until now).
> >
> > do you mean searching for a question mark here?  If you do
> > then i agree
> > this is a problem.  Slightly modifying your example (whether
> > there is a
> > user parameter or not does not matter):
> >
> 
> No. I am simply anticipating how some parsers might currently work.
> 
> sip:user@host:port;option1=optionval;etc=etcval
> 
> An easy way to retrieve the user@host:port section is to search for the
> first semicolon (or end of string or closing angle bracket '>'). Placing
a
> semicolon in the user part will confuse them.
> 
> >
> > > Slightly kludgier but at least syntactically workable would be to
> > > differently quote the meta characters in the tel:.
> >
> > or remove @ from the list of characters in headers and make it have to
> > be escaped.
> >
> So we hack/simplify things by removing the @ character from headers so
that
> we can place the ; in the user part?? Doesn't sound like a good trade
off to
> me.
> 
> > But it is not backwards compatible at all  If an old parser sees %%3b
> > then it will not correctly parse it anyway.  I don't really
> > like adding
> > and removing characters from the BNF but I think it is preferable to
> > adding a new escaping mechanism that will make things fuzzier and more
> > complicated.
> 
> Ok ok ... I knew I should have suggested an alternate quoting mechanism
from
> the outset.
> The translation may make conversion of the telephone-subscriber ever so
> slightly more complicated but at least the complication and changes are
> localized to just this area (and not pushed to complicating the whole
SIP
> URL parsing).
> 
> One of the simplest methods would be to translate the tel: reserved
> characters ';' & '?' to two other URI reserved characters (RFC2396) that
are
> unreserved characters in the SIP user part.
> 
> '&', '$' and '/' fulfill these conditions.
> 
> So simply translate ; to & and ? to $.
> 
> 
> Something a little more idiot proof is to translate them to something
> longer, eg:
> ; to /%3b/
> ? to /%3f/
> 
> See any problems ? Got any objections or preference ?
> 
> Robert.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: James Undery <[email-masked]>
Date: Thu, 6 Jul 2000 16:29:11 +0000 (GMT)

Hi,

	I've noticed in the July version of the bis draft section 1.4.2
says

"... If there is no port number in the URI, the default port, 5060, is
used."

step 4 of the algorithm following that says,

"The Request-URI is examined. If it contains an explicit port number other
than 5060, the next two steps are skipped."

the next two steps are SRV lookups.

My question is why if the default port is explicitly specified would you
want to do SRV record lookups? If there is a sensible answer to that why
doesn't it apply to all other explicit ports?

James Undery

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Jul 2000 13:38:36 -0400

> doesn't it apply to all other explicit ports?

This has been discussed extensively on the list, I believe. Has to do
with comparisons of URLs, where having
foo:5060 and foo being different is strange. The advantages of bypassing
SRV, whatever they might be, didn't seem to outweigh the confusion of
having the default port and its absence be different. I seem to remember
Igor Slepchin bringing this up last time around. 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs