Answers inline.
> /*Problem*/
> authority = srvr / reg-name
> srvr = [ [ userinfo "@" ] hostport ]
> reg-name = 1*( unreserved / escaped / "$" / ","
> / ";" / ":" / "@" / "&" / "=" / "+" )
>
> Here the problem is with authority.
> I have srvr and reg-name in the same state and I am getting
> reg-name for almost cases from the lexer. I have no way of
> differentiating between srvr and reg-name. So, I can't even put
> them in two different states.
This isn't really a problem, other than with ordering. If it matches the srvr format,
you should use that first. Otherwise, use the more general case of reg-name.
Consider:
username@host
works for both, but is intended to be srvr, whereas:
extension@somewhere@somewhereelse
can only be reg-name.
> 2. Accept Header:
>
> Accept = "Accept" HCOLON
> ( accept-range *(COMMA accept-range) )
> accept-range = media-range *(SEMI accept-param)
> media-range = ( "*/*"
> / ( m-type SLASH "*" )
> / ( m-type SLASH m-subtype )
> ) *( SEMI m-parameter )
> accept-param = ("q" EQUAL qvalue) / generic-param
> qvalue = ( "0" [ "." 0*3DIGIT ] )
> / ( "1" [ "." 0*3("0") ] )
>
> The problem that I have here is that, I can't decide what to parse
> after the SEMI in the accept-range. It could be either a
> m-parameter in the media-range or it could be the accept param
> after the SEMI.
First, (from the Department of the Obvious), figure if you see "q" EQUAL qvalue, it
must be accept-param. :-)
In the cases I think you're really worried about, it could be either. The main thing
is, however, that both m-parameter and generic-param are extensions of the language.
You shouldn't really care about them unless your implementation uses an extension. Of
course, if you saw "q" EQUAL qvalue, you can make the assumption that everything after
that is an accept-param.
Just as a side note, there is a small distinction between generic-param and
m-parameter, in that a generic-param can be simply a token and not just token EQUAL
(something). That may also help.
> 3. Generic Param:
>
> generic-param = token [ EQUAL gen-value ]
> gen-value = token / host / quoted-string
>
> Here the probelm is that token is a superset of the character set
> of host. Now in the lexer, if I define TOKEN first, I am returned
> a TOKEN evertime and no instance of HOST is found.
>
> If I define host first, then in most cases I am getting a HOST and
> TOKEN in only a very few cases where some character that is not in
> HOST is present is present.
So assume host first, if it suits you. Again, generic-param is defined for extending
the language; you don't really need to worry about it unless your implementation has
some extension that uses generic-param.
Hope this helps!
- rob
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors