This would mean a large change to existing parsers and
formatters. And
also, the "escaping" and "unescaping"
overheads.
Changing the header-value BNF may be more acceptable?
Regards
Satya T
-----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
|
