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 16:04:28 -0800 (PST)

> From ipp-owner@pwg.org Mon Nov 9 14:24:48 1998
> Date: Mon, 09 Nov 1998 15:21:19 -0700
> From: "Hugo Parra" <HPARRA@novell.com>
> To: <ipp@pwg.org>
> Subject: Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset not
>
> papowell@astart.com,
>
> I'm going to assume that behind the cheap sarcastic shot there is a valid concern. Here's my reasoning, please validate.

Hey! It was NOT cheap. I editted the sarcasm at least twice... :0)

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

No argument on this part, it is very clear.

HOWEVER: it is the other parts of the posting, where there is
an implication that if OTHER parts of the protocol message
have syntax errors, then you MUST/SHOULD storm bravely on,
trying to determine the cause of errors.

Trying to do 'syntax diagnostics' is extremely difficult...

Patrick ("Gee... I wonder how they would respond to irony...
you know, steel bar to the side of the terminal...") Powell

> -Hugo