Hi Robert, I am not really sure what you are proposing, but if we would mandate parsers not to parse unknown headers something is REALLY wrong with the BNF...
Regards, Christer > -----Original Message----- > From: Robert Sparks [mailto:[EMAIL PROTECTED] > Sent: 19. marraskuuta 2007 23:35 > To: sip List > Subject: [Sip] SIPit21: BNF future-proofing problem? > > 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 > _______________________________________________ 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
