-Hugo
>>> "Carl Kugler" <kugler@us.ibm.com> 11/09/98 03:49PM >>>
Hugo-
I think you've unintentionally validated papowell's point with your =
example! You seem to have forgotten about name-length and attribute-name. =
Bytes 11 and 12 really should be the length of the name of the attribute, =
not the length of the attribute value.
Too bad we can't simplify all this somehow. All IPP objects MUST support =
UTF-8. Maybe we could require all clients to accept UTF-8 in error =
responses (they could always ignore text strings in the response if they =
don't really understand UTF-8). The model document already recommends =
that clients pretend to support UTF-8 for other reasons.
-Carl
"The price of reliability is the pursuit of utmost simplicity." --C.A.R. =
Hoare=20
> papowell@astart.com,
>=20
> I'm going to assume that behind the cheap sarcastic shot there is a =
valid =3D
> concern. Here's my reasoning, please validate.
>=20
> Every valid IPP requests has as its first 10 bytes the following:
> 1-2: version id
> 3-4: operation number
> 5-8: request id
> 9: operation attribute tag
> 10: charset value tag
> 11-> : charset value length and actual value
>=20
> If the message is 10 bytes or shorter, then the server can safely =
conclude =3D
> that it won't be able to obtain an "attribute-charset" attribute from =
the =3D
> request. On the other hand, if the server verifies that byte 10 is =
indeed =3D
> a charset value tag, then recognizes bytes 11th and 12th as a valid =3D
> charset value length, and the value that follows is a string identifying =
a =3D
> charset the server supports, then it should use it regardless of whether =
=3D
> the operation number and request id (and perhaps the versio id) were =3D
> successfully validated.
>=20
> If the message is not long enough, or the server fails to validate the =
=3D
> charset as one it supports, the response should be provided using the =
=3D
> server's default charset.
>=20
> -Hugo
>=20
> >>> <papowell@astart.com> 11/09/98 02:14PM >>>
> > From ipp-owner@pwg.org Mon Nov 9 10:47:59 1998
> > Date: Mon, 09 Nov 1998 11:45:14 -0700
> > From: "Hugo Parra" <HPARRA@novell.com>
> > To: <ipp@pwg.org>
> > Subject: Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset not
> >
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *=3D20
> > Carl wrote:
> >
> > >As an implementor, I'd really prefer to be allowed to bail as
> > >soon as a syntax error is detected. It can be dangerous to proceed.
> > >For example, the parser might be expecting the next field to be an
> > >attribute length, but if it's actually a string or something, due
> > >to a syntax error, the parser might end up trying to allocate a
> > >string buffer of a gazillion bytes, crashing the application. Of
> > >course, you can build in protection against this kind of thing,
> > >and scan for patterns to try to resynch to the data stream, etc.
> > >But that all adds complexity.
>=20
> >
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *=3D20
> >
> > Though I agree that it is generally dangerous to proceed parsing
> > a message that has already been determined to be invalid, the risk
> > of parsing up to the "attribute charset" attribute is next to
> > none-existent given that it is always found at the exact same
> > location in the IPP message. If the "attribute-charset" attribute
> > is itself corrupted, the parser must know how to handle it whether
> > a problem has already been detected with the message or not.
> >=3D20
>=20
>=20
> <WARNING OPTION=3D3D"sarcasm and irony">
>=20
> I like that phrase, 'next to none-existent' (sic).
>=20
> Ummm... Do you have a formal analysis to back this up, or have you
> simply used some form of wishful thinking? Perhaps divination
> in a crystal ball? (Personally, I use a coffee cup, but I digress...)
>=20
> Sigh...
>=20
> I suppose that this is the same type of wishful thinking that
> assumed that nobody would ever send a 'bad downloadable font'
> because all of the fonts would be supplied by a manufacturer
> in binary form...
>=20
> (Ever see what happens when you FTP a font and it gets transferred
> in ASCII mode?)
>=20
> Or that believed that nobody would ever put UNICODE characters
> in a text string
> (which resulted in a '0' character being put
> into memory, which resulted in corrupted memory images...)
>=20
> The risk of these happening is 'small' as well.
>=20
> Sorry, I could not resist this...
>=20
> </WARNING>
>=20
> >
> > -Hugo
>=20
>=20
>=20
>=20
-----
See the original message at http://www.egroups.com/list/ipp/?start=3D4850=
=20
-- Free e-mail group hosting at http://www.eGroups.com/