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:hisham.khartabil gmail.com]
> 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
<hisham.khartabilgmail.com>
> 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 <rjsparksnostrum.com > 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://ww
w1.ietf.org/mailman/listinfo/sip
> <https:
//www1.ietf.org/mailman/listinfo/sip>
> This list is for NEW development of the core SIP
> Protocol
> Use sip-implementorscs.columbia.edu for
> questions on current sip
> Use sippingietf.org for new developments on the
> application of sip
>
>
>
>
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
