I see where the example ommits the value name length and name. How does that change the fact that starting with byte 10, a server can reliably determine whether the message contains a valid charset given the message is long enough. The challenge of parsing from byte 10 on is the same whether the first 9 bytes of the packet contain a valid version id, operation id, and request id or not.
-Hugo
>>> "Carl Kugler" <kugler at 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
>papowell at astart.com,
>> I'm going to assume that behind the cheap sarcastic shot there is a valid =
> concern. Here's my reasoning, please validate.
>> 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
>> If the message is 10 bytes or shorter, then the server can safely conclude =
> that it won't be able to obtain an "attribute-charset" attribute from the =
> request. On the other hand, if the server verifies that byte 10 is indeed =
> a charset value tag, then recognizes bytes 11th and 12th as a valid =
> charset value length, and the value that follows is a string identifying a =
> charset the server supports, then it should use it regardless of whether =
> the operation number and request id (and perhaps the versio id) were =
> successfully validated.
>> If the message is not long enough, or the server fails to validate the =
> charset as one it supports, the response should be provided using the =
> server's default charset.
>> -Hugo
>> >>> <papowell at astart.com> 11/09/98 02:14PM >>>
> > From ipp-owner at pwg.org Mon Nov 9 10:47:59 1998
> > Date: Mon, 09 Nov 1998 11:45:14 -0700
> > From: "Hugo Parra" <HPARRA at novell.com>
> > To: <ipp at pwg.org>
> > Subject: Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset not
> >
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *=20
> > 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
> >
> > 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.
> >=20
>>> <WARNING OPTION=3D"sarcasm and irony">
>> I like that phrase, 'next to none-existent' (sic).
>> 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...)
>> Sigh...
>> 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...
>> (Ever see what happens when you FTP a font and it gets transferred
> in ASCII mode?)
>> 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...)
>> The risk of these happening is 'small' as well.
>> Sorry, I could not resist this...
>> </WARNING>
>> >
> > -Hugo
>>>>
-----
See the original message at http://www.egroups.com/list/ipp/?start=4850
--
Free e-mail group hosting at http://www.eGroups.com/