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

From: [email-masked] (Robert Herriot)
Date: Wed, 12 Nov 1997 19:39:58 -0800

As I try to figure out what groups should be in an operation, I have
found the following ambiguities not covered by the model.

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.

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. 

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.

---

From: Scott Isaacson <[email-masked]>
Date: Thu, 13 Nov 1997 17:27:20 -0700

>>> Robert Herriot <[email-masked]> 11/12/97 08:39PM >>>
> 

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!?)

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

>   I favor a so that there is always an expected group.

Now your talking.  I favor a too.

Scott Isaacson

---

From: [email-masked] (Robert Herriot)
Date: Fri, 14 Nov 1997 13:33:41 -0800

The issue for #2 is what the model document says in terms of conformance.

If a client sends a job with attribute groups in the wrong order, a Printer
that rejects the job is certainly conforming to the standard. But if a
Printer accepts such a job, I would like to believe that it is still
conforming if the operation semantics are unaffected by the reordering.

I think that the correct statement for the model document around line
598 is that "The client requests and Printer responses SHALL contain
attribute groups in the order specified by the model, and that a
Printer NEED NOT verify that the attribute groups are in the correct
order. That is, a Printer may reject or accept an operation with
attribute groups in the wrong order."  ( line 598 perhaps suggests that
a Printer MUST reject such as operation, but it isn't clear. )

Bob Herriot

> From [email-masked] Fri Nov 14 08:37:32 1997
> 
> 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.
> 
> 
> On Thu, 13 Nov 1997, Robert Herriot wrote:
> 
> > 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
> > > 
> > > 
> > >