> From ipp-owner at pwg.org Mon Nov 9 16:19:12 1998
> Date: Mon, 09 Nov 1998 17:16:22 -0700
> From: "Hugo Parra" <HPARRA at novell.com>
> To: <ipp at pwg.org>, <kugler at us.ibm.com>
> Subject: Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset
>>> Is a message that specifies an operation that the server doesn't
> support a malformed request?
>> -Hugo
>>
This is a VERY good question, and deserves a serious answer.
I have spent a few minutes thinking about this, and here are
some of my thoughts.
I think we need to distinguish between 'syntax' and ('semantics' or 'information
content').
In programming languages, protocols, etc., 'syntax' refers to the framework
or datastructures that are used to convey the information, while 'semantics'
refers to the information or information encoded in the structure.
<ASIDE>
Now, before you all CS and Math types start to jump down my throat,
I know that I have simplified this, I have left out all sorts of
stuff that the linguists/computational theory/information theory types
etc etc are wincing at. I will simply note that I have taught these
theory courses as well, and I know when to throw away theory and
use a big hammer. This is BIG hammer time, guys. It's called
'implementation', a dirty word to the theory types, I know.
</ASIDE>
The IPP protocol and format has tried hard to specify a set of
'data types' and a set of 'encodings' for these data types to be
used to transfer information. The IPP protcol really tries hard
to specify a syntax for 'data type specifier', a set of primitive
types that can be used as ancestors (in the inheritance sense) for these
data types, and a set of encodings for the specifiers and values
of the primitive data types.
Now, you usually specify an operation by sending a message with
'specifiers' of various data types. If the 'value' of this
specifier is 'not recognized' by the destination, or the value
'encoded' into the primitive type is out of the range
of allowable values for the data type, this is effectively
the same as an 'out of range' situation so beloved by protocol
designers and programming lanaguage types.
Given the above line of thought, I hope that we can now divide
the problem as follows:
- determining if the 'syntax values',
when decoded, specify a 'meaningful' 'specifier' for a data and
a primitive value,
- the specifiers are in the set recognized by the printer
- the value(s) of the primitive data type is in the range
of the data type
- the value(s) of the primitive data type is 'available for use'
In summary, I think the parsing algorithm for IPP can be stated as:
while there is transactions on an input connection
while there is a request
get the next major syntactical unit;
if( syntactical error ){
whoop cookies, return error status;
abort reception on the current input stream;
}
decode and determine the semantics of the request;
if( semantic error ){
save semantic error information for later error message
}
endwhile
if( saved semantic errors ){
return nicely formatted error indication
} else {
based on current transfer operations
take whatever action is appropriate
}
endwhile
HORRORIBLE THOUGHT 1.
If you EVER get a syntax error on a data channel, you
need to close the channel, and give up.
HORRIBLE SIDE EFFECT: The Looping Job from Hell
Unfortunately, some implementations may/will not be able
to handle a syntax error. For example, they will start to
send their job; the server ... I mean printer... will detect
a syntax error. The server closes the 'incoming' connection,
and writes an error message on the 'outgoing' connection.
The client, though, thinks that the 'closing' of its 'outgoing'
connection is due to a network problem, and so does not try to
read from the input side. Thus, it misses the error message.
Sooo... of course it will retry the job... again and again...
Sigh...
Patrick Powell Astart Technologies,
papowell at astart.com 9475 Chesapeake Drive, Suite D,
Network and System San Diego, CA 92123
Consulting 619-874-6543 FAX 619-279-8424
LPRng - Print Spooler (http://www.astart.com)