IPP> OPS - Notes and Agreements on IPP Admin Ops from IPP WG meeting,

IPP> OPS - Notes and Agreements on IPP Admin Ops from IPP WG meeting,

IPP> OPS - Notes and Agreements on IPP Admin Ops from IPP WG meeting,

kugler at us.ibm.com kugler at us.ibm.com
Thu Jul 15 11:26:33 EDT 1999

 <918c79ab552bd211a2bd00805f15ce850182df3- at x-crt-es-ms1.cp10.es.xerox.c
om> wrote: 
original article:http://www.egroups.com/group/ipp/?start=5979
> 11.  Set-Printer-Attributes operation:  The "document-format"
>   attribute does have issues that were left unresolved.  Issue of how
>   to resolve with attributes that do and don't vary with regard to
>   format. For example if I set n-up and media for a format of
>   PostScript and then Get-Printer-Attributes with a document format of
>   text, have I changed the values of n-up and media, or just n-up
>   because its value depends on the format but not media which doesn't.
>   The document format is a limited version of constraints.  ISSUE:  Do
>   we continue the error with Get-Printer-Attributes by adding
>   "document-format" to Set-Printer-Attributes or do we acknowledge
>   an attribute holds all values, but some may be constrained by
>   constraints which are another attribute to set.

I think this issue could be resolved by clarifying some of the wording
in the Model doc in some future revision.  This issue arises from a
flaw in the IPP data model.  

In the OO methodologies I'm familiar with, one strives to get the data
model to at least Second Normal Form.  It's against the rules to have
some Printer attributes identified by a (Printer identifier,
document-format) tuple, while other Printer attributes depend only on
the Printer identifier.  Failing to correct this leads to the kind of
problems we see now with document-format.

We could correct this problem by acknowledging that there is really
another object class hidden in the IPP model:  the Interpreter.  A
Printer contains one or more Interpreters.  When appropriate, the
"document-format" operation attribute is really part of the operation
target:  it selects the Interpreter which the current operation is to
be applied.  Some of those attributes currently called Printer
attributes -- the ones that vary with "document-format" -- should
rightly be called Interpreter attributes.  

Simply explaining this in the wording might be enough to avert
confusion without any changes to the actual protocol.  

BTW, I've been complaining about this issue for over a year now.  See 


More information about the Ipp mailing list