IPP> IIG - Administration issues

IPP> IIG - Administration issues

henrik.holst at i-data.com henrik.holst at i-data.com
Tue Jan 4 03:53:29 EST 2000


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>
~~~~~~~~~~~~~~~~~~~~~~~~~








More information about the Ipp mailing list