IPP Mail Archive: Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset not

Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset not

papowell@astart.com
Mon, 9 Nov 1998 13:14:46 -0800 (PST)

> 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
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> 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.

>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> 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.
>

<WARNING OPTION="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