Hi, >This would mean a large change to existing parsers and formatters. And also, the "escaping" and "unescaping" overheads.
Existing parsers would not reject the message due to unsupported characters, because you would only use characters already allowed. Of course, parser would need to be able to unescapte those characters. But, again, I wonder whether the characters we are talking about are really needed in the first place... >Changing the header-value BNF may be more acceptable? Extending the definition is for sure going to have impacts on many existing parsers. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 21, 2007 11:13 PM > To: Christer Holmberg; Robert Sparks > Cc: sip List > Subject: RE: [Sip] SIPit21: BNF future-proofing problem? > > Hi, > > Another alternative would be to define an escaping mechanism > for quoted-strings in SIP messages, and require all > characters not allowed by the header-value ABNF to be escaped. > > Regards, > > Christer > > ________________________________ > > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Wed 21/11/2007 15:33 > To: Robert Sparks > Cc: sip List > Subject: RE: [Sip] SIPit21: BNF future-proofing problem? > > > > > Hi, > > >So to restate the problem that was reported: > > > >Right now, extension-header does not allow a new header that > contains a > > >quoted-string. > > > >We have defined extensions (and are likely to define new > >ones) that use quoted-string (anything that uses name-addr for > >instance). > > > >This inconsistency has caused interoperability problems in real > >implementations. > > > >My original note was to suggest that we change extension-header to > >actually allow the headers we're going to define. > > > >Christer's response could be read as a proposal to change > >quoted- string to achieve the same goal. > > Yes. > > Unless someone can show a use-case where the x00-x20 > characters would be needed, for backward compability reasons > I think it's better to restrict quoted-string than to extend > extension-header. > > Regards, > > Christer > > > > > > > Hi, > > > > > > I am still a little unclear what Robert is proposing, but > is there > > > really a need to be able to use characters between x00 and > > x20 in SIP > > > messages? Characters between x21 and x7F, and between x80 > > and xBF, are > > > ok since they are covered by TEXT-UTF8char and UTF8-CONT. > > > > > > Regards, > > > > > > Christer > > > > > > > > > ________________________________ > > > > > > From: Hisham Khartabil [mailto:[EMAIL PROTECTED] > > > Sent: 21. marraskuuta 2007 7:30 > > > To: Robert Sparks > > > Cc: sip List > > > Subject: Re: [Sip] SIPit21: BNF future-proofing problem? > > > > > > > > > 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. Therefore I support the > correction that > > > Robert is proposing. > > > > > > Hisham > > > > > > > > > On 21/11/2007, Hisham Khartabil <[EMAIL PROTECTED]> > > > 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 <[EMAIL PROTECTED] > wrote: > > > > > > 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 > > > <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 > > > > > _______________________________________________ > 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
