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.
RjS
On Nov 21, 2007, at 1:08 AM, Christer Holmberg wrote:
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
