Hi Carl-Uno,
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.
OK?
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: Carl [mailto:carl at manros.com]
Sent: Wednesday, July 16, 2003 3:29 PM
To: McDonald, Ira; sm at pwg.org; ipp at pwg.org
Subject: RE: IPP> Simple Device extension to Semantic Model
Ira,
Unless you suggest this to be an mandatory element, what is the default
assumption if it is not present?
Carl-Uno
Carl-Uno Manros
700 Carnegie Street #3724
Henderson, NV 89052, USA
Tel +1-702-617-9414
Fax +1-702-617-9417
Mob +1-702-525-0727
Email carl at manros.com
Web www.manros.com
> -----Original Message-----
> From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of McDonald,
> Ira
> Sent: Wednesday, July 16, 2003 10:33 AM
> To: 'sm at pwg.org'; 'ipp at pwg.org'
> 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
> concatenating:
>> (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).
>> Comments?
>> Cheers,
> - 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.
>