IPP> OPS - Xerox comments on Set-Printer-Attributes and Set- Job-Attributes spec

[Hastings, Tom N]

Ron,

>From our IPP WG telecon today, we agreed to drop the term Interpreter and
Interpreter object and just refer to "document-format-varying" attributes.

Based on our discussion today on the telecon, your idea to name the
Set-Printer-Operation attribute with respect to the document-format-varying
attributes seems like a good idea.

So how about changing the name of the Set-Printer-Attributes operation
attribute from:


     "attribute-scope" to "document-format-varying-scope"


Similarly, how about changing the name of the Printer Description attribute
that lists which document-format-varying attributes the Printer supports
from:

     "interpreter-unique-attributes" to "document-format-varying-attributes"

Then the names are parallel and clearly only refer to the
document-format-varying attributes (if the implementation has any).

Tom

-----Original Message-----
From: Ron Bergman [mailto:rbergma at hitachi-hkis.com]
Sent: Tuesday, January 11, 2000 15:00
To: Hastings, Tom N
Subject: Re: IPP> OPS - Xerox comments on Set-Printer-Attributes and
Set-Job-Attributes spec


Tom,

It was my understanding that the "attribute-scope" only applied to
those attributes covered by "interpreter-unique-attributes".  It makes
no sense for this to apply to all attributes.  Why have to enumerate
that there are attributes that don't apply, when they can't apply
under any circumstances.

Maybe a better name would be "interpreter-unique-attribute-scope"

This certainly does not add any additional logic to either the client
or the server, since each must know which are "interpreter-unique"
before the "attribute-scope" can be transmitted.  So, what additional
benefit can be gained from this third keyword?

Alterntively, requiring separate set operations is not all that bad either.
I would not anticipate this operation to occur at a very high frequency.

    Ron

"Hastings, Tom N" wrote:

> Ron,
>
> I agree that removing one of the three keywords choices for
> "attribute-scope" is a good idea if we don't need all three.
>
> However, the need for the third value ('single-interpreter-and-printer')
is
> so that a client can set some interpreter unique attributes for a
particular
> interpreter AND some printer attributes in one Set operation.  Being able
to
> set one interpreter's attributes and some Printer attributes in one Set
> operation avoids an intermediate race condition when the Printer object is
> not set in a consistent state.
>
> Admittedly, a client can't set the unique attributes for two of three
> interpreters in a single Set, so we aren't completely solving the "one Set
> can do all", so maybe having to set each interpreter separately that needs
> to be changed and then set the printer separately is sufficient (when the
> usual case of setting ALL interpreters and the printer in one Set isn't
> sufficient).
>
> Comments?
>
> Tom
>
> -----Original Message-----
> From: Ron Bergman [mailto:rbergma at hitachi-hkis.com]
> Sent: Tuesday, January 11, 2000 09:14
> To: Hastings, Tom N
> Cc: ipp
> Subject: Re: IPP> OPS - Xerox comments on Set-Printer-Attributes and
> Set-Job-Attributes spec
>
> Tom,
>
> This is a  good discussion and looks like a possible solution to what has
> the potential of being a real "rat hole".
>
> I see one minor flaw.  For the attribute "attribute-scope" there are three
> keywords defined.  I propose there only be two;
>     "all-interpreters" which implies it is also a global Printer
>        Description attribute.
>     "single-interpreter" which applies only to the specified
>        'document-format'.
>
> An attribute is either interpreter unique or not.  The third state that
> is defined is not valid.  Even in your examples, there are no unique
> conditions for the third state.
>
>     Ron Bergman
>     Hitachi Koki Imaging Solutions
>
> "Hastings, Tom N" wrote:
>
> > A number of us at Xerox considered the issue 01 in the Set spec and have
> the
> > following suggestions:
> >
> > ISSUE 01 - Is there a better way to model the Printer attributes that
> depend
> > on the interpreter (that is still compatible with IPP/1.1)?  It should
be
> > clear to the operator whether the Set-Printer-Attributes operation is
> > affecting all interpreters or just the one specified by the
> > "document-format" operation attribute (or its default)?  There have been
> > suggestions to have "xxx-exceptions" (collection) Printer Description
> > attributes where "xxx" is the document-format that indicate for each
> > interpreter explicitly which Printer attributes are specialized for it.
> For
> > example:  "application-postscript-exceptions" (collection) and
> > "application-vnd-hp-pcl-exceptions (collection).  Or have a
> > "set-all-interpreters" (boolean) Set-Printer-Attributes operation
> attribute
> > that sets all interpreters.
> >
> > We think that the Interpreter object is a fine way to model those
> > implementations that have some Printer attributes whose values depend on
> the
> > interpreter.  However, we have the following comments about completing
the
> > mechanism.
> >
> > 0. REQUIREMENT:  It must be clear that the concept of the Interpreter
> object
> > is just a way of talking about the semantics at the interface between
the
> > client and the Printer object, i.e., the semantics of the IPP protocol,
> and
> > is not placing any requirement on the internal implementation to have an
> > Interpreter object or not.  So add to the Notes that the introduction of
> the
> > Interpreter object is not specifying internal implementation of an IPP
> > Printer.
> >
> > 1. REQUIREMENT:  It must be clear to the client whether the
> > Set-Printer-Attributes operation is going to affect an attribute for all
> > interpreters or just the target interpreter.
> >
> > 2. REQUIREMENT:  A client must be able to set the attributes for one
> > interpreter or for all interpreters.
> >
> > 3. REQUIREMENT:  If an implementation doesn't support unique attributes
> for
> > different interpreters, then there is no added complexity than in the
> > current Set spec.
> >
> >         4. To meet requirement 1, there needs to be added a Printer
> > Description attribute that contains the names of the Printer attributes
> > whose values returned differ among interpreters or could differ among
> > interpreters.  Such a difference of values includes the case when an
> > attribute is supported by one interpreter and not by another, i.e., when
a
> > value is returned by one interpreter and an attribute is not returned by
> > another interpreter.  Such a Printer attribute returns different values,
> > depending on the Interpreter, and so is said to be an Interpreter object
> > attribute.  Here is the suggested definition for such a Printer
> Description
> > attribute:
> >
> > interpreter-unique-attributes (1setOf type2 keyword)
> >
> > This READ-ONLY attribute indicates which Printer attributes are
> represented
> > as Interpreter object attributes, i.e., potentially return different
> values
> > depending on the value of the "document-format" operation attribute
> supplied
> > by the client in the Get-Printer-Attributes request (see the
> > Get-Printer-Attributes "document-format" operation attribute description
> in
> > [ipp-mod] section 3.2.5.1).  Any Printer attributes not identified by
this
> > attribute MUST be shared by all interpreters, i.e., always return the
same
> > values no matter what "document-format" is supplied in the
> > Get-Printer-Attributes request.  If a Printer attribute is not supported
> by
> > all interpreters, then such an attribute is considered an Interpreter
> object
> > attribute by definition.  For implementations that support the
> > Set-Printer-Attributes operation, the Printer attributes so identified
by
> > this attribute MAY include attributes that are settable as indicated in
> the
> > Printer's "printer-settable-attributes".
> >
> > This attribute MUST be supported by an implementation that supports
> Printer
> > attributes whose values can be returned with different values in a
> > Get-Printer-Attributes request depending on the value of the
> > "document-format" operation attribute supplied by the client.  This
> > attribute, itself, MUST NOT be an Interpreter object attribute, i.e.,
its
> > values MUST be the same for all document formats.
> >
> > Example:  Suppose a Printer supports PostScript, PCL, and text/plain
with
> > the following "xxx-supported" values where "copies" is the shared by all
> > interpreters, "number-up" is supported by all interpreters but has
> different
> > values, and "orientation-requested" is supported only for 'text/plain':
> >
> > PDL         number-up-supported  copies-supported
> > orientation-requested-supported
> > ---         -------------------  ------
> > -------------------------------
> > PostScript  1                    1-10              <not supported>
> > PCL         1                    1-10              <not supported>
> > text/plain  1,2,4                1-10              'portrait',
'landscape'
> >
> > The implementation MUST support the "interpreter-unique-attributes"
> > attribute because several Printer attributes return differing values.
> Such
> > an implementation returns the "interpreter-unique-attributes" attribute
> > values: 'number-up-supported' and 'orientation-requested-supported' (no
> > matter what "document-format" is supplied in the Get-Printer-Attributes
> > request).
> >
> > The following responses are returned for a request that requests all
three
> > attributes:
> >
> > "document-format"        Response
> > -----------------        --------
> > application/postscript   number-up-supported=1, copies-supported=1-10
> > application/vnd.hp-PCL   number-up-supported=1, copies-supported=1-10
> > text/plain               number-up-supported=1,2,4,
copies-supported=1-10,
> >                          orientation-requested-supported='portrait',
> > 'landscape'
> >
> > 5. To meet requirement 2, there needs to be an operation attribute added
> to
> > the Set-Printer-Attributes operation that the client uses to indicate
> > whether the intent is to set (1) all Interpreter objects and the Printer
> > object, (2) a single Interpreter object and the Printer object, or (3)
> just
> > the Interpreter object.  Here is the description of the
> > Set-Printer-Attributes operation attribute:
> >
> > "attribute-scope" (type2 keyword)
> >
> > The client MAY supply this attribute.  The Printer MUST support this
> > attribute if it returns Printer attributes with different values in a
> > Get-Printer-Attributes request depending on the value of the
> > "document-format" operation attribute supplied by the client.  This
value
> of
> > this attribute indicates the client's intention with respect to Printer
> > attributes that are common to all interpreters, i.e., are Printer object
> > attributes, or are specific to an Interpreter, i.e., are Interpreter
> object
> > attributes.
> >
> > Standard keyword values are:
> >
> >     'all-interpreters-and-printer' - all attributes supplied either set
> all
> > Interpreter object attributes that support the attribute or set the
single
> > Printer object attribute
> >
> >     'single-interpreter-and-printer' - all attributes supplied either
set
> > the single interpreter or set the single Printer object attribute.  An
> error
> > is returned if the attribute supplied isn't either the specified
> Interpreter
> > object attribute or a Printer object attribute.
> >
> >     'single-interpreter-only' - all supplied attributes set the single
> > Interpreter object only.  An error is returned if the attributes isn't
the
> > specified Interpreter object attribute doesn't support the supplied
> > attribute or the attribute is a Printer attribute.
> >
> > Example:  Suppose that the "number-up-supported" attribute could be
> settable
> > for the PCL and text/plain interpreters, but not the PostScript
> interpreter,
> > the 'copies-supported' attribute could be settable for all interpreters,
> but
> > the 'orientation-requested-supported' could not be set for any
> interpreters.
> > Then the value of the "printer-settable-attributes" MUST be
> > 'copies-supported' and 'number-up-supported' when the document-format is
> PCL
> > and 'text/plain' and 'copies-supported' when the document-format is
> > 'application/postscript'.  Also, since the value of
"number-up-supported"
> > could be different after being set, the "number-up-supported" MUST be a
> > value in the "interpreter-unique-attributes" attribute (for all
> > document-formats).
> >
> > Pictorially, the Printer object and the Interpreter objects can be drawn
> as
> > follows:
> >
> > Printer object
> > +---------------------------------+
> > |"copies-supported"=1-10(settable)|
> > +---------------------------------+
> >
> > PostScript Interpreter object
> > +-------------------------------------+
> > |"number-up-supported"=1(not-settable)|
> > +-------------------------------------+
> >
> > PCL Interpreter object
> > +---------------------------------+
> > |"number-up-supported"=1(settable)|
> > +---------------------------------+
> >
> > text/plain Interpreter object
> >
+-----------------------------------------------------------------------+
> > |"number-up-supported"=1(settable)
|
> > |"orientation-requested-supported"='portrait',
'landscape'(not-settable)|
> >
+-----------------------------------------------------------------------+
> >
> > Set-Printer-Attributes
> > ----------------------
> > Attempt to set "copies-supported"
> >
> > - "attribute-scope"='all-interpreters-and-printer'
> > Sets the "copies-supported" Printer object attribute for all
> > "document-format" values
> >
> > - "attribute-scope"='single-interpreter-and-printer'
> > Sets the "copies-supported" Printer object attribute for all
> > "document-format" values
> >
> > - "attribute-scope"='single-interpreter-only'
> > Returns an error and does not change the "copies-supported" Printer
object
> > attribute
> >
> > Attempt to set "number-up-supported"
> >
> > - "attribute-scope"='all-interpreters-and-printer'
> > Fails for each "document-format" values because not all Interpreter
> objects
> > have this attribute as settable.
> >
> > - "attribute-scope"='single-interpreter-and-printer'
> > Succeeds for "document-format" = PCL and text/plain, fails for
PostScript
> >
> > - "attribute-scope"='single-interpreter-only'
> > Succeeds for "document-format" = PCL and text/plain, fails for
PostScript
> >
> > Attempt to set "orientation-requested-supported"
> >
> > - "attribute-scope"='all-interpreters-and-printer'
> > Fails for each "document-format" values because all Interpreter objects
> > either have this attribute as not-settable or do not support the
> attribute.
> >
> > - "attribute-scope"='single-interpreter-and-printer'
> > Fails for each "document-format" values because all Interpreter objects
> > either have this attribute as not-settable or do not support the
> attribute.
> >
> > - "attribute-scope"='single-interpreter-only'
> > Fails for each "document-format" values because all Interpreter objects
> > either have this attribute as not-settable or do not support the
> attribute.