Thanks everybody for your comments. It is clear to me now I was not counting for different contexts while working on URIs.
Regards, Brez On Wed, Feb 23, 2011 at 5:20 PM, Worley, Dale R (Dale) <[email protected]>wrote: > > From: sip-implementors On Behalf Of Brez Borland [[email protected]] > > > > sip:alice;[email protected] > > > > The last sample URI above has a user field value of > > "alice;day=tuesday". The escaping rules defined above allow a > > semicolon to appear unescaped in this field. For the purposes of > > this protocol, the field is opaque. The structure of that value is > > only useful to the SIP element responsible for the resource. > > > > ========================== > > > > The last URI example, I would treat "alice" as the hostname, and > > "[email protected]" as a parameter pair. > > As others have pointed out, "@" may not appear in a uri-parameter, and > ";" may appear in 'user' so the user must be "alice;day=tuesday". > > > With the URI like "sip:alice;[email protected]", I would expect > > semicolon to be escaped in the user part, or the address to be enclosed > in > > the angle brackets. > > Be careful interpreting the syntax rules. There are actually *3* > syntax contexts. One context is where the text must be a URI, which > is also named "addr-spec", and never contains <...>. One context is > where the text must be a "name-addr", which is a URI surrounded with > <...>, possibly preceeded by a display name and ofllowed by "field > parameters". The third context may be followed by a comma admits > "addr-spec / name-addr", and can only be disambiguated by the rule at > the end of section 20: > > The Contact, From, and To header fields contain a URI. If the URI > contains a comma, question mark or semicolon, the URI MUST be > enclosed in angle brackets (< and >). Any URI parameters are > contained within these brackets. If the URI is not enclosed in angle > brackets, any semicolon-delimited parameters are header-parameters, > not URI parameters. > > *As you've asked the question*, we are discussing URIs, and so <...> > is not admissible. If this was the third context (e.g., in many SIP > headers), then <...> would be requires to "protect" the semicolon in > the URI. > > Dale > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
