I think you are suggesting a syntax that looks ahead for the ? and then
decides the preceding ;s introduce uri parameters. That seems obscene to
me. :-)
If writing an ad hoc parser I would simply consider the ; to end the
addr-spec. If writing a formal parser I think I would alter the grammar
more or less as somebody else suggested yesterday. Since you are
altering it, you can take your best guess how to do that - should you
include ? parameters but not ; parameters? I think I would just conclude
that it may not have parameters at all.
Paul
P.S. You are in Spain, right? I guess you don't sleep much.
Iñaki Baz Castillo wrote:
> El Viernes, 18 de Abril de 2008, Paul Kyzivat escribió:
>
>> IMO the way one must interpret the instruction to treat the parameters
>> as header parameters is to assume that the ";" indicates the completion
>> of the URI and the beginning of the header parameters. Thus everything
>> forward from there must be parsed according to the syntax for what
>> follows the addr-spec.
>>
>> Then the ? becomes a syntax error.
>>
>> I don't see any other reasonable way to deal with it.
>
> Hi, let me insist a bit, since this change has broken all my parser and
> forces
> me to do several changes making it ugly:
>
> I think that what you say is correct because RFC 3261 says:
> "If no "<" and ">" are present, all parameters after the URI
> are header parameters, not URI parameters."
>
> But from the point of view of the ABNF, what I meant in my original mail is
> correct:
>
> From = ( "From" / "f" ) HCOLON from-spec
> from-spec = ( name-addr / addr-spec ) *( SEMI from-param )
>
> addr-spec can contain URI headers with no URI params so we would have:
>
> addr-spec = sip:[EMAIL PROTECTED]
>
> Also it could contain URI params and URI headers:
>
> addr-spec = sip:[EMAIL PROTECTED];p1=qqq?header1=XXX
>
> And after the addr-spec there can be *( SEMI from-param ), so:
>
> addr-spec = sip:[EMAIL PROTECTED];p1=qqq?header1=XXX;hp1=HHH
>
>
> So, in conclusion, the above is IMHO a perfectly valid value according to the
> SIP ABNF but it violates a rule appearing in RFC 3261.
> It's not cool at all :(
>
> So I can do a perfect parser respecting all the ABNF grammar (that is
> complex)
> but it's not enought since there are "extra" rules described in the RFC .
> That's a pain.
>
>
> Thanks and best regards.
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
