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
