Semantic Model Mail Archive: SM> RE: IPP> Simple Device e

Semantic Model Mail Archive: SM> RE: IPP> Simple Device e

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

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Wed Jul 16 2003 - 15:58:15 EDT

  • Next message: McDonald, Ira: "SM> Is there an SM call in one hour (17 July)??"

    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@manros.com]
    Sent: Wednesday, July 16, 2003 3:29 PM
    To: McDonald, Ira; sm@pwg.org; ipp@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@manros.com
    Web www.manros.com

    > -----Original Message-----
    > From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of McDonald,
    > Ira
    > Sent: Wednesday, July 16, 2003 10:33 AM
    > To: 'sm@pwg.org'; 'ipp@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.
    >



    This archive was generated by hypermail 2b29 : Wed Jul 16 2003 - 15:58:39 EDT