Subject: Re: IPP>MOD Ambiguity in what groups should be in an operation

From: [email-masked] (Robert Herriot)
Date: Thu, 13 Nov 1997 16:46:43 -0800

The reason that I favor b for 2 below is that it decreases server
complexity.  If a server decodes and validates in one step, then it is
hard to process them out of order and the server should reject the
operation, but if a server first decodes and then validates, it may be
more of a burden for the server to check for order than to ignore it
and the server should be free to accept such an operation.   I agree
that the client must follow the order, but the question is whether a
server MUST reject an operation that is out of order.

The reason that I favor b for 1 is so that a server will not reject
operations that have unknown extensions, such as extra groups.  This
is another fidelity issue. If a user doesn't care about fidelity, then
as long as the server can somewhat understand the operation, it should
be free to try its best.
 
> From [email-masked] Thu Nov 13 16:28:17 1997
> 
> 
> 
> >>> Robert Herriot <[email-masked]> 11/12/97 08:39PM >>>
> > 
> > 1)  What should a printer do if an operation contains an unexpected
> >     group, e.g. a printer-attributes-tag.
> >      a) reject the operation always.
> >      b) reject a create job operation if ipp-attribute-fidelity is 
> >         true and ignore the group for other operations and for 
> >         ipp-attribute-fidelity is false. Return a new attribute
> >         'unsupported-groups' with the tag values that were ignored.
> >
> >    I favor b because it is similar to unrecognized operation attributes.
> 
> I favor a.  It is a BUG if this happens.  The implementers on the client
> side did not  read the spec correctly and they are not conforming.  The
> server code has to be much more complex to handle them in any order.  We
> keep burdening the poor server implementations ( I thought we were expecting
> that this might be embedded in network attached printers!?)

> 
> > 2)  What should a Printer do if the correct groups are present but
> >    in the wrong order, e.g. Job Template attributes precede the
> >    operation attributes.
> >       a) reject the job
> >       b) allow an implementation to accept or reject an operation
> >
> >    I favor b. Client should be required to follow the order, but
> >    servers/printers need not enforce the order. 
> 
> Again, I favor a.   It is a bug.  The implementer that sends them in the
> wrong order is not compliant.  If we would allow option b we would be
> enabling poor software not interoperability.  Why have a spec if everything
> is optional
> or can come in reverse order or weird stuff can come in any order, ....
> 
> > 3)  If Get-Attributes is returning no job/printer attributes, does it
> return
> >        a) a Job/Printer group which is empty or 
> >       b) no Job/Printer group
> >
> >   I favor a so that there is always an expected group.
> 
> Now your talking.  I favor a too.
> 
> Scott Isaacson
> 
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>    
>

---

From: Ron Bergman <[email-masked]>
Date: Fri, 14 Nov 1997 08:35:30 -0800 (Pacific Standard Time)

I support Bob's position on number 1.  This will allow new groups to be
added to the protocol and servers that support older versions of the
protocol will still be useable, as long as fidelity is false.  This does
not obsolete old equipment.  As Bob stated this situation is "similar to
unrecognized operation attributes."  I would go further and say it is
almost identical!

I support Scott's position on number 2.  If the order is specified, it
must be followed and must be enforced by the server.  For the case in
Bob's examnple where the server "decodes and validates in one step" the
order must be enforced.  For clients to operate with this type of server
they have no choice but to provide the proper order.  I see no problem
with someone designing a server to accept any order, but the specification
should not recommend this approach.

	Ron Bergman
	Dataproducts Corp.