Re: SIPit21: BNF future-proofing problem?

This is a big change if we do adopt it. It will cause a lot of problem to parsers that handle extenion headers today and is not backwards compatible. Why isn't the extension header as is defined today not sufficient?

 

Hisham

 

On 20/11/2007, Robert Sparks < rjsparksnostrum.com">rjsparksnostrum.com> wrote:

The BNF in 3261 says the following:

extension-header&nbsp; =&nbsp; header-name HCOLON header-value
header-value &nbsp;   ; =&nbsp; *(TEXT-UTF8char / UTF8-CONT / LWS)

This is intended to be the catch-all field for all future extensions
- older parsers working against this BNF shouldn9;t barf
when we introduce a new header field.

Now, we may have new fields in the future that look like:

NewHeader = new-header-name HCOLON quoted-string

And down inside quoted-string, we get:

&nbsp; &nbsp; &nbsp; quoted-string &nbsp;= &nbsp;SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
&nbsp; &nbsp; &nbsp; qdtext ; &nbsp; &nbsp; &nbsp;  = &nbsp;LWS / %x21 / %x23-5B / %x5D-7E
  ; &nbsp; &nbsp; &nbsp; &nbsp;   ; &nbsp; &nbsp; &nbsp; &nbsp;   ;/ UTF8-NONASCII
 &nbsp;   ; quoted-pair&nbsp; =&nbsp; &quot;" (%x00-09 / %x0B-0C
&nbsp; &nbsp;   ; &nbsp; &nbsp; &nbsp; &nbsp;   ; &nbsp; &nbsp;  / %x0E-7F)

So, for instance, we could have inside a quoted string the 2 byte
sequence NULL

This does not parse against header-value above...

Is this a problem? Some of the SIPit21 participants argued that it is.

The projects I've been involved in don't parse unknown headers and
the stacks will just hand up an unparsed bucket of bits (the only rules
used are those necessary to identify the next header-field starting).

Would it be worth the effort to make the BNF reflect that rather than
continuing with the incongruity that we currently specify?

RjS


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu">sip-implementorscs.columbia.edu for questions on current sip
Use sippingietf.org"> sippingietf.org for new developments on the application of sip

I think I did misread Robert';s original email. I thought header values having quoted strings are currently not allowed and Robert wanted to change RFC2822. Now I realise that you can have header field values with quoted string.&nbsp;Therefore I support the correction that Robert is proposing.

 ;

Hisham 

&nbsp;

On 21/11/2007, Hisham Khartabil < hisham.khartabilgmail.com">hisham.khartabilgmail.com> wrote:

This is a big change if we do adopt it. It will cause a lot of problem to parsers that handle extenion headers today and is not backwards compatible. Why isn't the extension header as is defined today not sufficient?

 

Hisham

 

On 20/11/2007, Robert Sparks <nostrum.com" target="_blank">rjsparksnostrum.com > wrote:

The BNF in 3261 says the following:

extension-header&nbsp; =&nbsp; header-name HCOLON header-value
header-value &nbsp;   ; =&nbsp; *(TEXT-UTF8char / UTF8-CONT / LWS)

This is intended to be the catch-all field for all future extensions
- older parsers working against this BNF shouldn9;t barf
when we introduce a new header field.

Now, we may have new fields in the future that look like:

NewHeader = new-header-name HCOLON quoted-string

And down inside quoted-string, we get:

&nbsp; &nbsp; &nbsp; quoted-string &nbsp;= &nbsp;SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
&nbsp; &nbsp; &nbsp; qdtext ; &nbsp; &nbsp; &nbsp;  = &nbsp;LWS / %x21 / %x23-5B / %x5D-7E
 &nbsp;   ; &nbsp; &nbsp; &nbsp; &nbsp;   ; &nbsp; &nbsp; &nbsp; &nbsp;/ UTF8-NONASCII
 &nbsp;   ; quoted-pair&nbsp; =&nbsp; &quot;" (%x00-09 / %x0B-0C
&nbsp; &nbsp;   ; &nbsp; &nbsp; &nbsp; &nbsp;   ; &nbsp; &nbsp;  / %x0E-7F)

So, for instance, we could have inside a quoted string the 2 byte
sequence NULL

This does not parse against header-value above...

Is this a problem? Some of the SIPit21 participants argued that it is.

The projects I've been involved in don't parse unknown headers and
the stacks will just hand up an unparsed bucket of bits (the only rules
used are those necessary to identify the next header-field starting).

Would it be worth the effort to make the BNF reflect that rather than
continuing with the incongruity that we currently specify?

RjS


_______________________________________________
Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use cs.columbia.edu" target="_blank"> sip-implementorscs.columbia.edu for questions on current sip
Use ietf.org" target="_blank">sippingietf.org for new developments on the application of sip