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 rbergma@dpc.com 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 SISAACSON@novell.com Thu Nov 13 16:28:17 1997
> > >
> > >
> > >
> > > >>> Robert Herriot <Robert.Herriot@Eng.Sun.COM> 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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>