Subject: Re: [SIP] new torture tests

From: "Keith Robinson" <[email-masked]>
Date: Fri, 17 Nov 2000 12:41:10 +0000

I have a problem regarding the parsing of the contact line in 12C :

Contact: sip:[email-masked];user=phone

The accompanying text says that the 'user' parameter should be interpreted as
being a contact-param and not a url-parameter; I believe the opposite is true if
the BNF followed; here is why:

The first line of the contact rule is:

Contact = ("Contact" | "m") ":"
                    ("*"|(1#((name-addr|addr-spec)*((";"contact-params))))

having decoded the keyword Contact, the rule is now looking for name-addr or
addr-spec; as there is no display name or angled brackets then addr-spec is the
next rule to decode.

The rule for addr-spec is

addr-spec = SIP-URL|URI

which is matched perfectly by

sip:[email-masked];user=phone

I do not see any reason why the decoding of the SIP-URL rule should stop before
the parameters if they satisfy the url-parameter spec  so therefore user=phone
would belong to url-parameters and not contact-parameters which is probably
intended.

Now to the particular problem I see. Consider the following line

Contact: sip:[email-masked];action=proxy

Using the above logic , paramter action=proxy would satisfy the other-param spec
in SIP-URL which is probably not what is intended.

I think the safest approach is to use the name-addr format in all cases and then
parameters which belong to url-parameters are placed inside the angled brackets
and parameters which belong to contact-params are placed otside the brackets,
thus

Contact: <sip:[email-masked];user=phone>;action=proxy

will always give desired behaviour.

The above also applies to other headers such as To and From.

Regards,
K. Robinson.

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

---

From: "Hisham Khartabil" <[email-masked]>
Date: Fri, 17 Nov 2000 15:39:58 +0200

Section 6.5 in the Bis:

"
   The Contact, From and To header fields contain a URL. If the URL
   contains a comma, question mark or semicolon, the URL MUST be
   enclosed in angle brackets (< and >). Any URL parameters are
   contained within these brackets. If the URL is not enclosed in angle
   brackets, any semicolon-delimited parameters are header-parameters,
   not URL parameters.

"

I think this should answer your query.

Regards,
Hisham Khartabil
Hotsip Finland
www.hotsip.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Keith Robinson
Sent: Friday, 17 November 2000 2:41 PM
To: Anders Kristensen
Cc: Neil Deason; Sip List
Subject: Re: [SIP] new torture tests

The accompanying text says that the 'user' parameter should be interpreted
as
being a contact-param and not a url-parameter; I believe the opposite is
true if
the BNF followed; here is why:

having decoded the keyword Contact, the rule is now looking for name-addr or
addr-spec; as there is no display name or angled brackets then addr-spec is
the
next rule to decode.

addr-spec = SIP-URL|URI

I do not see any reason why the decoding of the SIP-URL rule should stop
before
the parameters if they satisfy the url-parameter spec  so therefore
user=phone
would belong to url-parameters and not contact-parameters which is probably
intended.

Using the above logic , paramter action=proxy would satisfy the other-param
spec
in SIP-URL which is probably not what is intended.

I think the safest approach is to use the name-addr format in all cases and
then
parameters which belong to url-parameters are placed inside the angled
brackets
and parameters which belong to contact-params are placed otside the
brackets,
thus

Regards,
K. Robinson.

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 17 Nov 2000 14:39:33 +0100

> the BNF followed; here is why:

This goes back to that paragraph I was quoting... (bis-02 section 6.14):

   Even if the "display-name" is empty, the "name-addr" form
   MUST be used if the "addr-spec" contains a comma, semicolon,
   or question mark.

Since the name-addr form is NOT used it follows that the addr-spec part
does NOT contain a comma, semicolon, or question mark. Hence the
parameter cannot belong to the SIP URL and so must belong to the
Contact.  The correct parsing is not captured in the grammar which is
what makes this case tricky.

> in SIP-URL which is probably not what is intended.

The above logic is wrong. This example is OK.

> and parameters which belong to contact-params are placed otside the brackets,

Absolutely. No discussion at all. The point of the torture tests,
though, is to test those rarely used constructs and try to stress
implementations. It's not a BCP. It would probably have been better if
the grammer hadn't allowed the addr-spec form to begin with.

--
Anders Kristensen