Thanks for your feedback. I agree with you regarding the status-codes. I
would like further clarification on a couple of points:
| HH> I don't quite understand your question. A printer object
| should describe
| HH> the physical device. If the the device does allow
| transparencies to
| HH> be stabled, then the printer object should support it too. If the
| HH> administrator wants to disable this functionality he should do it
| HH> in the printer object somehow.
~~~~~~~
This is my question. How does the administrator disable this functionality
in the printer object? Is this supported through IPP operations, or is a
backdoor method used?
| HH> I can't see any reason to expand the version number. We added the
| HH> 'Validate-job' operation to do what you are looking for.
Validate-job seems like a bulky way to find out if a printer object supports
certain attribute values. If there are numerous private values which a
printer object may be configured to support, does the admin client
application have to perform a validate-job on each of these potential values
before displaying them to the administrator? If IPP had a mechanism to
retrieve all configurable values for an Admin client (similar to
Get-Printer-Attributes of xxx-supported for a Submission client), it would
help to make cleaner and simpler IPP Admin Tools. There are many ways to
accomplish this, one being to make all job template attributes like the
media attribute which includes xxx, xxx-default, xxx-supported, and
xxx-ready.
Thanks!
Mike
| -----Original Message-----
| From: henrik.holst at i-data.com [mailto:henrik.holst at i-data.com]
| Sent: Tuesday, January 04, 2000 3:53 AM
| To: Shepherd, Michael
| Cc: ipp at pwg.org| Subject: Re: IPP> IIG - Administration issues
||| My comments are,
|||||| "Shepherd, Michael" <MShepherd at crt.xerox.com> on 03-01-2000 20:16:16
|| To: "'ipp at pwg.org'" <ipp at pwg.org>
| cc: (bcc: Henrik Holst/INT)
|| Subject: IPP> IIG - Administration issues
||||| I have been working on an additional section to the
| Implementer's Guide
| specifically for guidelines around implementation of an Admin
| client and its
| usage. I've come across a couple of issues that either may
| already have
| easy answers or is something that should be discussed.
|| Issue 1a - Regarding IPP-IIG Section 3.1.2.3.1 (Checking for
| conflicting Job
| Template attribute values), is it allowable for an
| administrator to define
| her own attribute/value conflicts? For instance, a printer object
| implementation ALLOWS transparencies to be stapled, but the
| administrator
| would prefer this to be NOT allowed on her particular printer. An
| additional admin (Set 2) operation or printer attribute
| collection may easy
| provide the functionality for this.
| HH> I don't quite understand your question. A printer object
| should describe
| HH> the physical device. If the the device does allow
| transparencies to
| HH> be stabled, then the printer object should support it too. If the
| HH> administrator wants to disable this functionality he should do it
| HH> in the printer object somehow.
|| Issue 1b - If Issue 1a is allowable, would an admin-defined
| conflict return
| the 'client-error-conflicting-attributes' status code, or does another
| status code need to be created?
| HH> If the administrator has disabled the functionality the
| return code
| HH> should be 'client-error-conflicting-attributes', because
| the printer
| HH> object behave like it does not support it.
|| Issue 2 - If an administrator is defining her own type 3
| attribute values
| according to IPP-MOD Section 6.1, is there a 'private'
| version-number for
| the printer object so that her admin client can know that
| this attribute
| value can be supported? For instance, Xerox creates a
| private job-sheets
| attribute. How does an admin client know that this value can
| be added to
| the 'job-sheets-supported' attribute? Can a third field be
| added to the
| 'version-number' for private versioning, or does each
| organization that
| extends IPP create their own mechanism for this (e.g.. invent a new
| attribute 'Xerox-version-number')?
| HH> I can't see any reason to expand the version number. We added the
| HH> 'Validate-job' operation to do what you are looking for.
|| Issue 3 - If an administrator added her own attributes
| according to IPP-MOD
| Section 6.2, but they require some conflict checking with other IPP
| attributes, how is this accomplished? (Similar to Issue 1a)
| HH> It's just done in the normal way, as it was a normal
| attribute. If a
| HH> conflict occour the 'client-error-conflicting-attributes'
| is returned.
|| Thanks!
|| Mike
| ~~~~~~~~~~~~~~~~~~~~~~~~~
| Michael D. Shepherd
| *8*222-2338 / (716)422-2338
| * Location: 0128-51E
|Michael.Shepherd at crt.xerox.com <mailto:Michael.Shepherd at crt.xerox.com>
| ~~~~~~~~~~~~~~~~~~~~~~~~~
|||||