Tom,
I agree in principle with the name changes, I just don't like long
names. But I cannot think of anything better, so let's go with
your proposal.
Ron
"Hastings, Tom N" wrote:
> 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.