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 at novell.com Thu Nov 13 16:28:17 1997
> >
> >
> >
> > >>> Robert Herriot <Robert.Herriot at 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>