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.