Subject: [SIP] rfc 2543bis-01 SIP syntax

From: Gérard GONNET <[email-masked]>
Date: Mon, 25 Sep 2000 09:23:30 +0200

rfc 2543bis-01 SIP syntax revisited

Some definitions of the SIP syntax can introduce undesirable side effects. For exemple :

the user element is defined as *(unreserved | escaped | "&"| "=" | "+" | "$" | "," | ";" | "?" | "/" ) .
The application of the * operator tell us that a user element is represented as a succession of 0 (the default value) or more chars belonging to the enumerated set.
Giving a 0 value to the low limit of the repetition factor results in an "empty" user element, which is an authorized syntax.
This can introduce some trouble :
1/ what is the meaning of an "empty" user ?
2/ because the given syntax is equivalent to [user] (cf. C part of the draft, page 116), how to ensure the definition of a mandatory user ?

The same remark applies to the password element, defined as
password =  *(unreserved |escaped | "&" | "=" | "+" | "$" | ","), because the notation [":" password] of the user-info element is significant enough to declare password as an optional child element. Furthermore, this syntax could reduce the [":" password] to a lone ":" char only when used with an "empty" password.
 
The same remark applies to the url-parameters element . This mandatory child element of the SIP-URL element can be emptied by the given definition :
url-parameters = * (";" url-parameter).

The same remark applies to the hvalue element defined as :
hvalue = *(hnv-unreserved | unrerserved | escaped) .
Using this definition in the header element 
header = hname "=" hvalue
can reduce the header to a  hname "="  not terminated form. (notice that the hname left element is declared as hname = 1*(hnv-unreserved | unrerserved | escaped) ...

To avoid side effects in the definition of an element, it seems mandatory to apply the following rules :

1/ a mandatory element CANNOT be defined with the *something notation, but MUST use the n*something notation, with n > 0.

2/ an optional element MUST be defined with the ambiguity free [an-optional-element] notation, by opposite to the *may-be-optional form.

3/ an optional element CANNOT be defined with the *may-be-optional notation, to avoid the possible side-effects between the two definitions.

Application of these rules gives :
 
userinfo = (user | telephone-subscriber) [":"password]  (former proposition of modification)
user = 1*(unreserved | escaped | "&"| "=" | "+" | "$" | "," | ";" | "?" | "/" )
password =  1*(unreserved |escaped | "&" | "=" | "+" | "$" | "," )

header = hname "=" hvalue
hname = 1*(hnv-unreserved | unrerserved | escaped)
hvalue = 1*(hnv-unreserved | unrerserved | escaped)
 
SIP-URL = "sip:" [userinfo "@"] hostport url-parameters [headers]
url-parameters = 1*(";" url-parameter).

A remark about the escaped element, declared as :
escaped = "%" hex hex
I cannot find a definition for hex in the ABNF specification. I suppose that a typographic error has occured and hex has to be translated into HEX, which is well defined and seems to be the right element ?

---

From: Sean Olson <[email-masked]>
Date: Mon, 25 Sep 2000 15:44:32 +0200

This may be an issue of trying to express semantics with syntax.
The user, password, url-parameters and headers are not mandatory
elements of the SIP URI.
As an example, the user is always empty in the Request-URI of a REGISTER

request. The ABNF does a good job of expressing syntax, but you need
to augment this with a description of the semantics. Otherwise, the SIP
spec.
would be just one big grammar :) Perhaps I'm missing the point of your
posting.
I do find the possibility of a lone ":" in the password interesting ...
no real harm
done in my opinion, but I'm interested to know how many implementations
handle
this ;)

--
Sean Olson <[email-masked]>

Gérard GONNET wrote:

> rfc 2543bis-01 SIP syntax revisited Some definitions of the SIP syntax
> can introduce undesirable side effects. For exemple : the user element
> is defined as *(unreserved | escaped | "&"| "=" | "+" | "$" | "," |
> ";" | "?" | "/" ) .The application of the * operator tell us that a
> user element is represented as a succession of 0 (the default value)
> or more chars belonging to the enumerated set.Giving a 0 value to the
> low limit of the repetition factor results in an "empty" user element,
> which is an authorized syntax.This can introduce some trouble :1/ what
> is the meaning of an "empty" user ?2/ because the given syntax is
> equivalent to [user] (cf. C part of the draft, page 116), how to
> ensure the definition of a mandatory user ? The same remark applies to
> the password element, defined aspassword =  *(unreserved |escaped |
> "&" | "=" | "+" | "$" | ","), because the notation [":" password] of
> the user-info element is significant enough to declare password as an
> optional child element. Furthermore, this syntax could reduce the [":"
> password] to a lone ":" char only when used with an "empty"
> password. The same remark applies to the url-parameters element . This
> mandatory child element of the SIP-URL element can be emptied by the
> given definition :url-parameters = * (";" url-parameter). The same
> remark applies to the hvalue element defined as :hvalue =
> *(hnv-unreserved | unrerserved | escaped) .Using this definition in
> the header elementheader = hname "=" hvaluecan reduce the header to a
> hname "="  not terminated form. (notice that the hname left element is
> declared as hname = 1*(hnv-unreserved | unrerserved | escaped) ... To
> avoid side effects in the definition of an element, it seems mandatory
> to apply the following rules : 1/ a mandatory element CANNOT be
> defined with the *something notation, but MUST use the n*something
> notation, with n > 0. 2/ an optional element MUST be defined with the
> ambiguity free [an-optional-element] notation, by opposite to the
> *may-be-optional form. 3/ an optional element CANNOT be defined with
> the *may-be-optional notation, to avoid the possible side-effects
> between the two definitions. Application of these rules gives
> : userinfo = (user | telephone-subscriber) [":"password]  (former
> proposition of modification)user = 1*(unreserved | escaped | "&"| "="
> | "+" | "$" | "," | ";" | "?" | "/" )password =  1*(unreserved
> |escaped | "&" | "=" | "+" | "$" | "," ) header = hname "="
> hvaluehname = 1*(hnv-unreserved | unrerserved | escaped)hvalue =
> 1*(hnv-unreserved | unrerserved | escaped) SIP-URL = "sip:" [userinfo
> "@"] hostport url-parameters [headers]url-parameters = 1*(";"
> url-parameter). A remark about the escaped element, declared as
> :escaped = "%" hex hexI cannot find a definition for hex in the ABNF
> specification. I suppose that a typographic error has occured and hex
> has to be translated into HEX, which is well defined and seems to be
> the right element ?

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

---

From: Gethin Liddell <[email-masked]>
Date: Fri, 29 Sep 2000 16:07:53 +0100

> 1/ what is the meaning of an "empty" user ?

what ever you want it to mean.

> 2/ because the given syntax is equivalent to [user] (cf. C part of the draft, page 116), how to ensure the definition of a mandatory user ?

why define a mandatory user?  i do not see why "sip:@example.com" should
be considiered illegal.  perhaps this may mean something to some
server, its all implementation specific.

> password =  *(unreserved |escaped | "&" | "=" | "+" | "$" | ","), because the notation [":" password] of the user-info element is significant enough to declare password as an optional child element…

again there is no reason to make "sip:person:@example.com" illegal.  if
the password does not match then return an unautherized.

> url-parameters = * (";" url-parameter).

mandatory?  there is nothing wrong with a sip url as
"sip:[email-masked]" or even "sip:example.com" and there are no
parameters present.  which parameters do you think are mandatory?

> can reduce the header to a  hname "="  not terminated form. (notice that the hname left element is declared as hname = 1*(hnv-unreserved | unrerserved | escaped) ...

yes, this should probably be:

header = hname [ "=" hvalue ]
where hvalue is defined the same as hname

also please ensure you have the most up to date bis draft - bis02 from
hennings site:

http://www.cs.columbia.edu/~hgs/sip/

> I cannot find a definition for hex in the ABNF specification. I suppose that a typographic error has occured and hex has to be translated into HEX, which is well defined and seems to be the right e…

yep

-- 
Gethin Liddell
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:[email-masked]