As it's an OPTIONAL extension attribute, obviously if the
IPP Printer Description attribute "printer-role" is NOT
present, then the IPP Printer MUST behave (as in RFC 2911)
as a 'logical' Printer (a service, not a device) - which
is perfectly backwards compatible.
Further, a client that doesn't understand "printer-role"
will never ignore it erroneously in an IPP 'physical'
Printer (a device), because that URL is NOT advertised -
it's only constructed from the associated IPP 'logical'
Printer's URL, as I proposed.
- Ira McDonald
High North Inc
From: Carl [mailto:email@example.com]
Sent: Wednesday, July 16, 2003 3:29 PM
To: McDonald, Ira; firstname.lastname@example.org; email@example.com
Subject: RE: IPP> Simple Device extension to Semantic Model
Unless you suggest this to be an mandatory element, what is the default
assumption if it is not present?
700 Carnegie Street #3724
Henderson, NV 89052, USA
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com]On Behalf Of McDonald,
> Sent: Wednesday, July 16, 2003 10:33 AM
> To: 'firstname.lastname@example.org'; 'email@example.com'
> Subject: IPP> Simple Device extension to Semantic Model
> Hi folks, Wednesday (16 July 2003)
> Proposal for a simple Device extension to the PWG Semantic Model:
> (1) Add a "PrinterRole" element to the Printer object, with legal values
> 'logical' (PSI Print Service, IPP Printer, etc.), 'physical' (PSI
> Target Device, SNMP Device, etc.), or 'logical-and-physical' (for
> consistency with ISO 10175 DPA's "printer-realization" attribute
> and a number of shipping vendor implementations of DPA).
> (2) Any 'logical' Printer object MAY support (e.g., via PSI's
> GetTargetDeviceElements) returning its 'best effort knowledge'
> of the elements of local surrogate 'physical' Printers (Devices).
> The URI of each local surrogate 'physical' Printer is formed by
> (a) Any URI value of the "PrinterUriSupported" element (e.g., a
> 'pwg-psips:' value), and
> (b) a single dot '.', and
> (c) any value of the "OuputDeviceSupported" element.
> (3) A 'physical' Printer supports all standard Printer elements and MAY
> also support the "PrtXXX" elements extracted from the IESG-approved
> final draft of Printer MIB v2 (for the WBMM effort).
> - Ira McDonald
> High North Inc
> PS - Mapping this PWG Semantic Model extension back to IPP is trivial.
> The latest IPP Job Extensions spec defines "output-device" (a client
> supplied Job Creation operation attribute) and "output-device-supported"
> (a Printer attribute that bounds the values of "output-device" and the
> existing "output-device-assigned", a Job Description attribute).
> An 'ipp:' value of "printer-uri-supported" on an IPP 'logical' Printer
> MAY be suffixed with a dot and a value of "output-device-supported" to
> form the URI of an IPP 'physical' Printer with "prt-xxx" attributes.
> Existing Get-Printer-Attributes and Set-Printer-Attributes operations
> MAY be used to manage and configure an IPP 'physical' Printer. No new
> IPP operations are required to add Device support to IPP.
This archive was generated by hypermail 2b29 : Wed Jul 16 2003 - 15:58:39 EDT