[SIPForum-techwg] tag-param and other-param in uri-parameter conflicts in RFC3261 ANBF definition?

[Dale Worley]

On Fri, 2007-07-13 at 11:05 +0800, mike xu wrote:
> When I try to parse the tag in below format (use addr-spec instead of
> name-addr, this means it has no "<" ">" exist)
>   To: sip:2112 at 192.168.100.12;tag=4e10c-f485
> it always failed to get the tag parameter, the tag was dropped.
> And after viewing the ABNF definition in RFC3261, I found that it was
> caused by other-param conflicts with tag-param. In this case, the tag
> parameter would be considered as other-param since the parser don't
> know the end of uri-paramter (so it consider tag-param as
> other-param).
> 
> One workaround solution is to add tag-param definition into url-param,
> then the tag could be parsed smoothly.
> 
> Could anybody here to confirm this problem ? Is it really a bug of
> ABNF definition? If it is, where shall I report it?

The ABNF is ambiguous.  There is a rule that disambiguates it, but it's
hard to find -- the last paragraph of section 20 of RFC 3261.
Basically, any place in SIP where a name-addr can appear, an addr-spec
(URI) can also appear.  Those two productions can both produce strings
like the one you show, but the string has different meanings when parsed
as a name-addr or as an addr-spec.  The disambiguation rule is that in
those cases, the name-addr interpretation prevails.  (That's the
summary, anyway.  I am rushed this morning and may have made a mistake.)

Dale