Semantic Model Mail Archive: RE: SM> Summary of additions to

Semantic Model Mail Archive: RE: SM> Summary of additions to

RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Mar 18 2003 - 14:58:14 EST

  • Next message: Hastings, Tom N: "SM> JDF FileSpec/@FileFormatVersion and IPP "document-format-version" for PDF/X and TIFF/IT"

    Here is the definition of the "document-format-device-id" proposed in the
    Document object spec:

    This OPTIONAL Document Description attribute identifies the type of device
    for which the document was formatted, including manufacturer and model.
    This attribute is intended to identify document formats that are not
    portable, e.g., PDLs that are device dependent. The value of this variable
    MUST exactly match the IEEE 1284-2000 Device ID string (see [IEEE1284]
    clause 6), except the length field MUST not be specified. See the Microsoft
    Universal Plug and Play [upnp] section 2.2.6 DeviceId parameter for details
    and examples. Here is an example showing only the required fields for a
    PostScript document:
        MANUFACTURER:ACME Co.;COMMAND SET:PS;MODEL:LaserBeam 9;

    And here is the definition of the UPnP DeviceId attribute from the UPnP v1
    Printer Template. Note: in UPnP this is a Printer attribute, not an
    attribute that the submitter includes with his job submission:

    2.6.6 DeviceId

    The value of this variable MUST exactly match the IEEE 1284-2000 Device ID
    string, except the length field MUST not be specified.. The value is
    assigned by the Printer vendor and MUST NOT be localized by the Print
    Service.
    The IEEE 1284-2000 Device ID is a length field followed by a case-sensitive
    string of ASCII characters defining peripheral characteristics and/or
    capabilities. For the purposes of this specification, the length bytes MUST
    NOT be included. The Device ID sequence is composed of a series of keys and
    values of the form:

       key: value {,value} repeated for each key

    As indicated, each key will have one value, and MAY have more than one
    value. The minimum necessary keys (case-sensitive) are MANUFACTURER,
    COMMAND SET, and MODEL. (These keys MAY be abbreviated as MFG, CMD, and MDL
    respectively.) Each implementation MUST supply these three keys and possibly
    additional ones as well. Each key (and each value) is a string of
    characters. Any characters except colon (:), comma (,), and semi-colon (;)
    MAY be included as part of the key (or value) string. Any leading or
    trailing white space (SPACE[x'20'], TAB[x'09'], VTAB[x'0B'], CR[x'0D'],
    NL[x'0A'], or FF[x'0C']) in the string is ignored by the parsing program
    (but is still counted as part of the overall length of the sequence).

    An example ID String, showing optional comment and active command set keys
    and their associated values (the text is actually all on one line):

    MANUFACTURER:ACME Manufacturing;
    COMMAND SET:PCL,PJL,PS,XHTML-Print+xml;
    MODEL:LaserBeam 9;
    COMMENT:Anything you like;
    ACTIVE COMMAND SET:PCL;
    (See IEEE 1284-2000 clause 7.6)

    Note: One of the purposes of the DeviceId variable is to select a printer
    driver for those UCPs that need a printer driver. The values of the COMMAND
    SET key are interpreted by the printer driver provided by the vendor and so
    are vendor-defined, rather than being standardized.

    TH Observations:
    1. The Note is part of the definition of the UPnP DeviceId Printer attribute
    showing the intent to relate to the driver needed.

    2. Because the keyword fields also have shorter forms, the string:
    MFG:ACME Manufacturing;CMD:PCL,PJL,PS,XHTML-Print+xml;MDL:LaserBeam 9;
    is also conforming for the UPnP DeviceId Printer Attribute.

    3. This alternate form for the keyword fields means that the Printer will
    either have to include both forms in its
    "document-format-device-id-supported" Printer attribute (if we decide to
    have one) or have a more sophisticated matching algorithm.

    4. The UPnP DeviceId attribute is a Printer Attribute that describes the
    Printer's capabilities. Unlike the IPP "document-format-device-id", the
    UPnP DeviceId attribute is not submitted by the clent to tell the printer
    what the document format is that the client is submitting.

    5. For our use as an attribute that the client submits as a value of
    "document-format-device-id", presumably there would only be one value of the
    COMMAND SET, e.g.,: MFG:ACME Manufacturing;CMD:PS;MDL:LaserBeam 9;

    Right?

    Tom

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Tuesday, March 18, 2003 07:53
    To: 'Zehler, Peter'; 'HALL,DAVID (HP-Vancouver,ex1)'; Hastings, Tom N
    Cc: sm@pwg.org
    Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document
    obj ect for document format versions

    Hi Pete,

    Agreed - specifically, Bob Taylor (HP strong voice for document details)
    has urged the use of DeviceID as the unambiguous identifier.

    Admittedly that's no help to actually find the driver install for human
    beings, but that's a separate problem, I think.

    Cheers,
    - Ira McDonald

    -----Original Message-----
    From: Zehler, Peter [mailto:PZehler@crt.xerox.com]
    Sent: Tuesday, March 18, 2003 9:31 AM
    To: 'HALL,DAVID (HP-Vancouver,ex1)'; Hastings, Tom N
    Cc: sm@pwg.org
    Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document
    obj ect for document format versions

    Dave,

    I was under the impression that the reason for defining DeviceId was to
    establish an unambiguous mapping of a Printer and its associated driver.
    IPP v1.0 and 1.1 used PrinterMakeAndModel. UPnP felt that that mapping was
    not sufficiently defined and ambiguous. The IEEE P1284 device registry was
    utilized with the definition of DeviceId.

    I believe that the DeviceId provides a more direct and convenient mapping to
    printer's device driver. It also includes the make and model in a well
    defined format. I recommend that we do not include PrinterMakeAndModel in
    the list below.

    Pete

                                    Peter Zehler
                                    XEROX
                                    Xerox Architecture Center
                                    Email: PZehler@crt.xerox.com
                                    Voice: (585) 265-8755
                                    FAX: (585) 265-8871
                                    US Mail: Peter Zehler
                                                    Xerox Corp.
                                                    800 Phillips Rd.
                                                    M/S 128-30E
                                                    Webster NY, 14580-9701

    -----Original Message-----
    From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com]
    Sent: Monday, March 17, 2003 1:55 PM
    To: 'Hastings, Tom N'
    Cc: sm@pwg.org
    Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document
    obj ect for document format versions

    Having just implemented an initial PSI TargetDeviceSupportInterface, another
    IPP attribute appears to be very important:

    PrinterMakeAndModel

    While the DeviceID can be utilized to indirectly determine the appropriate
    device data format, it is much more convient to utilize the printer make and
    model, if it corresponds to the Printer Driver Name.

    I would like to recommend that we consider this attribute for inclusion in
    the below list..

    Dave

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Friday, March 14, 2003 6:00 PM
    To: CIP4 Capabilities WG [capabilities@cip4.org]
    Cc: sm@pwg.org
    Subject: SM> Summary of additions to JDF/FileSpec and IPP Document
    object for document format versions

    We've had a long thread of discussion about the need to indicate the version
    of a document format in a job submission along with its MIME type in JDF and
    IPP. In JDF this infomation is represented as attributes in the FileSpec
    resource. In IPP, the PWG Semantic Model (SM) and the Print Service
    Interface (PSI), the document format and versions are represented as
    Document Description attributes. In IPP the client submits these as
    operation attributes which the Printer copies to the corresponding Document
    Description attributes.

    Here is a quick summary to see if we are in agreement:

    1. Don't add stuff to the IPP Document object that hasn't been asked for,
    even though its being added to JDF FileSpec resource. So IPP will remain a
    subset of JDF. So while adding TransferEncoding (per Israel Viente's
    request), DocumentClass (to help distinguish fonts from other files), and
    some attribute for use with fonts to designate which organization they are
    coming from (which need work) so we don't need MIME types for fonts.

    2. The following list show the relationship between IPP Document object and
    the JDF FileSpec. In JDF, only ContainerSummary, IEEE1284DeviceID and
    FileFormatVersion are new. All of the IPP Document attributes are new
    except for document-format and document-natural-language:

    document-container-summary (collection) ContainerSummary
      which can contain:
      document-creator-application-name (name(MAX))
      document-creator-application-version (name(MAX))
      document-creator-os-name (name(MAX))
      document-creator-os-version (name(MAX))
      document-format (mimeMediaType)
      document-format-device-id (text(127))
      document-format-version (text(127)
      document-natural-language (naturalLanguage)
    document-creator-application-name (name(MAX)) Application
    document-creator-application-version (name(MAX)) AppVersion
    document-creator-os-name (name(40)) AppOS
    document-creator-os-version (name(40)) OSVersion
    document-format (mimeMediaType) MimeType
    document-format-detected (mimeMediaType) N/A
    document-format-device-id (text(127)) IEEE1284DeviceId
    document-format-version (text(127) FileFormatVersion
    document-natural-language (naturalLanguage)

    I'll have an updated spec for IPP Document object out by Monday AM and a
    corresponding FileSpec on Monday.

    I won't be addressing additional MIME types in these documents. That is
    separate.

    Tom



    This archive was generated by hypermail 2b29 : Tue Mar 18 2003 - 14:58:35 EST