SM> RE: IPP> Simple Device extension to Semantic Model

SM> RE: IPP> Simple Device extension to Semantic Model

SM> RE: IPP> Simple Device extension to Semantic Model

McDonald, Ira imcdonald at sharplabs.com
Wed Jul 16 15:58:15 EDT 2003


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




More information about the Sm mailing list