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:christer.holmberg ericsson.com]
> 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:christer.holmbergericsson.com]
> 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:hisham.khartabilgmail.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
>
>
>
>
> _______________________________________________
> 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
>
_______________________________________________
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
|
