RE: FW: RFC2279 to Standard

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Paf writes:

> The current suggestion is that we say we have only talked 
> about values up to 10ffff, but implementations should be
> prepared on higher values.
> 
> This in the security consideration section.
> 
But Ned wrote:

>   Actually, I think it is preferable to treat them as
>   protocol errors, due to the need for UTF-16 compatibility.
>

So, is that in conflict then?

Bert
> 
> On lördag, jan 11, 2003, at 00:25 Europe/Stockholm, Wijnen, 
> Bert (Bert) 
> wrote:
> 
> > Form Randy Presuhn (I think he is the best skilled from
> > the SNMP community w.r.t. UTF-8 and related topics)
> >
> > So the possible concern would/might be:
> >
> >   It DOES however mean that some older SNMP entities will
> >   accept (and play back) values that would legitimately
> >   be rejected by newer ones.
> >
> > So the statement by Ned that we should return an error:
> >   Actually, I think it is preferable to treat them as
> >   protocol errors, due to the need for UTF-16 compatibility.
> >
> > Does that mean that values above 10ffff should be rejected?
> > So if my older agents don't do that, is that a problem or
> > a non-compliance?
> >
> > Bert
> > -----Original Message-----
> > From: Presuhn, Randy [mailto:Randy_Presuhn@bmc.com]
> > Sent: vrijdag 10 januari 2003 19:42
> > To: 'Wijnen, Bert (Bert)'
> > Subject: RE: RFC2279 to Standard
> >
> >
> > Hi -
> >
> > I'm not sure why they're talking about UTF-16.  It's bogus,
> > and the surrogates it uses are not used in the UTF-8 transform.
> >
> > ISO 10646 and Unicode agreed to go from the full 31-bit range
> > down to the 0..10ffff range.  I think I raised the question
> > (along with selecting one of the normalization forms) on the
> > mailing list.  As I recall, there was only one response, and
> > the respondant didn't want to open that can of worms.
> >
> > RFC 3411 says:
> >        Since additional code points are added by
> >        amendments to the 10646 standard from time
> >        to time, implementations must be prepared to
> >        encounter any code point from 0x00000000 to
> >        0x7fffffff.  Byte sequences that do not
> >        correspond to the valid UTF-8 encoding of a
> >        code point or are outside this range are
> >        prohibited.
> >
> > The agreements on Unicode/ISO 10646 just say that those code
> > points in the 110000..7fffffff range will never be added.  If
> > the definition of "valid UTF-8 encoding" has been changed to
> > encompass a smaller range, I believe the the statement "Byte
> > sequences that do not correspond to the valid UTF-8 encoding
> > of a code point or are outside this range are prohibited"
> > remains correct, and gives an implementation grounds to reject
> > code points outside the 0..10ffff range.  It DOES however mean
> > that some older agents will accept (and play back) values that
> > would legitimately be rejected by newer ones.
> >
> >  ------------------------------------------------------
> >  Randy Presuhn          BMC Software, Inc.  1-3141
> >  randy_presuhn@bmc.com  2141 North First Street
> >  Tel: +1 408 546-1006   San José, California 95131  USA
> >  ------------------------------------------------------
> >  My opinions and BMC's are independent variables.
> >  ------------------------------------------------------
> >
>