The BNF in 3261 says the following:
extension-header = header-name HCOLON header-value
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
This is intended to be the catch-all field for all future extensions
- older parsers working against this BNF shouldn'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:
quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
qdtext = LWS / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
quoted-pair = "\" (%x00-09 / %x0B-0C
/ %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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
