IPP>MOD Ambiguity in what groups should be in an

IPP>MOD Ambiguity in what groups should be in an

IPP>MOD Ambiguity in what groups should be in an

Scott Isaacson SISAACSON at novell.com
Thu Nov 13 19:27:20 EST 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
>        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


More information about the Ipp mailing list