IPP> MOD> Issue 1.19 [REVISITED - charset

IPP> MOD> Issue 1.19 [REVISITED - charset

IPP> MOD> Issue 1.19 [REVISITED - charset

papowell at astart.com papowell at astart.com
Tue Nov 10 20:04:24 EST 1998

> 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

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.


 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.


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
  if( saved semantic errors ){
     return nicely formatted error indication
  } else {
     based on current transfer operations
       take whatever action is appropriate


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


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)

More information about the Ipp mailing list