Subject: [SIP] Sip Grammer: Multiple entries

From: Vivek Rao <[email-masked]>
Date: Tue, 9 May 2000 03:21:41 -0700 (PDT)

Hi
   The grammer for contact specified in RFC2543bis is
as follows

Contact   = ("Contact"|"m")":"
                 ("*"|(1#((name_addr|addr_spec)
{*(";"contact-params)])))
name_addr = [display-name]"<"addr_spec">"
addr_spec  = SIP-URL|URI

In the example below 
Contact:<sip:[email-masked]>;action=proxy,gaya<sip:[email-masked]>

Since the grammar for URI field accepts a ';' , '=' &
',' , ";action=proxy,gaya" will be identified as a
URI. Hence its required to scan through this to
retrieve the Contact-Param. All this can be avoided if
we allow a minimum of one space on either side of
comma. 
Similar situation occurs for Via, Route &
Record-Route.

A similar situation occurs if a colon(:) is
immediately followed by a display name as in From or
To fields (e.g. From:Jerry). 

Please clarify on this.
Thanks
Vivek

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

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

---

From: "Rick Workman" <[email-masked]>
Date: Tue, 09 May 2000 10:17:25 -0400

> we allow a minimum of one space on either side of

My interpretation is the URI (or in this case SIP-URL) completes when the
">" is encountered so the "action=proxy" is parsed as a legal
contact-param. So I don't understand the problem.

> To fields (e.g. From:Jerry).

This one's a bit more problematical because "Jerry" is a valid URI (a
relativeURI), but then again almost anything is. It can't be a display name
because it's not followed by a "<" addr-spec ">". However, I don't think
inserting a space helps, does it? (Inserting white space is always allowed
in headers, but only mandatory when header elements need to be separated,
i.e., between two tokens.)

> Vivek

Rick Workman
Nortel Networks
Ottawa

---

From: "Albee Vimal" <[email-masked]>
Date: Tue, 9 May 2000 21:13:42 +0530

Thanks for responding to our doubts.
 Since the URI/addr-spec grammar accepts alpha-numeric, ";" ,  "," , "="
etc. We find that during the lexical analysis the rule/token that matches
the maximum number of input is returned  hence ";action=proxy,gaya" is
returned  as a single URI token, instead of being returned as contact-param
,a comma token (comma token refers to ',') and display-name token (refers
the 'gaya'). Earlier we were trying to convey that if a space is introduced
we can avoid this situation and make token retrieval more easy.

Sorry, for giving an incomplete example it should have been
                  From:Jerry<sip:any@doubt>
Here since there is no space between the ':' and 'Jerry',  even though we
specify rule to return From as a separate token and ':' as another. The
lexical analyzer goes for the maximum pattern match and returns "From:Jerry"
as the URI/addr-spec token.  The grammar works fine in identifying
<sip:any@doubt> as URI/addr-spec token. Had there been a space between ':'
and display-name "From:Jerry" would not be returned as a addr-spec token.
Yes, this can be overcome by having some special condition checks and doing
rescan. What we thought was this could be avoided if a space is mandated in
both the cases.
Thanks
Albee Vimal
 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Rick Workman
Sent: Tuesday, May 09, 2000 7:47 PM
To: Vivek Rao
Cc: [email-masked]
Subject: Re: [SIP] Sip Grammer: Multiple entries

  Vivek Rao wrote:

    Hi

    In the example below

  My interpretation is the URI (or in this case SIP-URL) completes when the
">" is encountered so the "action=proxy" is parsed as a legal contact-param.
So I don't understand the problem.

    Please clarify on this.
    Thanks
    Vivek

  Rick Workman
  Nortel Networks
  Ottawa

---

From: "Rick Workman" <[email-masked]>
Date: Tue, 09 May 2000 14:03:11 -0400

It sounds like you're trying to apply a URI lexical analysis to SIP
headers which isn't going to work too well for the reasons you've
discovered. If you want to take this approach, I think you have to
provide a more granular tokenizer and glue things back together, if
necessary. I suspect most implementations perform context sensitive
parsing, rather than try to do a context insensitive tokenization as a
first step.

Putting in additional spaces will force your tokenizer to work, but
isn't at all backwards compatible with spec or existing implementations.

Rick

Albee Vimal wrote:

>  Thanks for responding to our doubts.  Since the URI/addr-spec grammar
> accepts alpha-numeric, ";" ,  "," , "=" etc. We find that during the
> lexical analysis the rule/token that matches the maximum number of
> input is returned  hence ";action=proxy,gaya" is returned  as a single
> URI token, instead of being returned as contact-param ,a comma token
> (comma token refers to ',') and display-name token (refers the
> 'gaya'). Earlier we were trying to convey that if a space is
> introduced we can avoid this situation and make token retrieval more
> easy.Sorry, for giving an incomplete example it should have
> been                   From:Jerry<sip:any@doubt>Here since there is no
> space between the ':' and 'Jerry', even though we specify rule to
> return From as a separate token and ':' as another. The lexical
> analyzer goes for the maximum pattern match and returns "From:Jerry"
> <sip:any@doubt> as URI/addr-spec token. Had there been a space between
> ':' and display-name "From:Jerry" would not be returned as a addr-spec
> token. Yes, this can be overcome by having some special condition
> checks and doing rescan. What we thought was this could be avoided if
> a space is mandated in both the cases. ThanksAlbee Vimal-----Original
> Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Rick Workman
>     > ontact:<sip:[email-masked]>;action=proxy,gaya<sip:[email-masked]>
>     >
>      My interpretation is the URI (or in this case SIP-URL)
>      completes when the ">" is encountered so the "action=proxy"
>      is parsed as a legal contact-param. So I don't understand
>      the problem.
>
>     >
>      This one's a bit more problematical because "Jerry" is a
>      valid URI (a relativeURI), but then again almost anything
>      is. It can't be a display name because it's not followed by
>      a "<" addr-spec ">". However, I don't think inserting a
>      space helps, does it? (Inserting white space is always
>      allowed in headers, but only mandatory when header elements
>      need to be separated, i.e., between two tokens.)
>
>     >
>     > Please clarify on this.
>     > Thanks
>     > Vivek
>     >

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 9 May 2000 15:20:45 -0400 (EDT)

> we can avoid this situation and make token retrieval more easy.

The simplest solution to this is to drop ',' from the set of characters
which is allowed to appear unescaped in a SIP URI, as Igor suggested a few
days ago.  I don't think this will cause much in the way of compatibility
problems (though you SHOULD handle an unescaped comma in a URI correctly if
it's between angle brackets, in a Request-URI, or whatever).

> rescan. What we thought was this could be avoided if a space is mandated in

This one, however, I don't think is a problem.  Tracing down the grammar for
the generic message-header syntax in 2543, we find:

        message-header  =  field-name ":" [ field-value ] CRLF
        field-name      =  token

        token       =  1*< any CHAR  except CTL's  or separators>
        separators  =  "(" | ")" | "<" | ">" | "@" |
                       "," | ";" | ":" | "\" | <"> |
                       "/" | "[" | "]" | "?" | "=" |
                       "{" | "}" | SP | HT

Thus, ":" isn't allowed in a field-name, so the grammar is unambiguous.

It looks like what you're trying to do is to have a separate tokenizer and
parser (the usual lex/yacc split)?   I don't think the SIP grammar will
support that, unfortunately; it's too irregular at a low level.

-- 
Jonathan Lennox
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 May 2000 18:01:57 -0400

> it's between angle brackets, in a Request-URI, or whatever).

I still don't get how your analyzer figured that ;action=proxy,gaya is a
URI. Was sip:[email-masked] picked up as a URI? If so, the grammar
clearly requires a comma between these two.

In any case, I really don't want to mandate white space between tokens
and separators, particularly in random select places like this. The rule
for white space is generic and applies everywhere. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com