Semantic Model Mail Archive: RE: SM> Summary of 9 recent ISS

RE: SM> Summary of 9 recent ISSUES/fixes for the IPP Document obj ect tele con, Thur, 4/3/03, 12-3 EST (9-12 PST)

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Apr 02 2003 - 21:23:31 EST

  • Next message: Hastings, Tom N: "SM> Minutes of the IPP Document object spec call"

    And a 10th issue for the Document Object spec:

    10. At today's IPPFAX telecon, we discussed the following IPPFAX Printer
    Description attribute:

    digital-signatures-supported (1setOf type2 keyword)
    This attribute identifies which digital signatures technologies are
    supported by the Receiver. A Receiver MUST support this Printer Description
    attribute.
    TODO: Get list of keywords; can be found in "IPP driver install" spec

    We agreed that it should go in the IPP Document object spec, and that it
    should have a "digital-signature" (type2 keyword) operation/Document
    Description attribute that the client submits in a Document Creation
    operation as well. And therefore, the spelling of the corresponding
    "digital-signature-supported" (1setOf type2 keyword) Printer Description
    attribute should be without the "s".

    The description from the "IPP Driver Install" (IPP Printer Installation
    Extension) spec is:

    "digital-signature"
    One REQUIRED LOWER-CASE 'keyword' string identifying the mechanism used to
    ensure the integrity and authenticity of this set of Client Print Support
    Files. Standard values are: 'smime', 'pgp', 'dss', and 'xmldsig' which are
    defined in [RFC2634], [RFC1991], [dss], and [xmldsig], respectively. In
    addition, the special keyword value: 'none' is valid.

    The 'none' value MUST be supported if this attribute is supported.

    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Tuesday, April 01, 2003 18:46
    To: sm@pwg.org
    Cc: ps@pwg.org
    Subject: SM> Summary of 9 recent ISSUES/fixes for the IPP Document
    object tele con, Thur, 4/3/03, 12-3 EST (9-12 PST)

    The 2nd and 3rd hours will be reviewing the IPP Document Object spec (sent
    out March 25:
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip
    (1,225 KB)
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip
    (294 KB)
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip
    (649 KB)
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip
    (309 KB)

    This note summarizes the suggestions that have been and issues raised since
    the document was sent out, including discussions in CIP4 about the
    JDF/FileSpec resource and the SM telecon March 27.

    The first part of this mail note is a summary of the issues and point to
    earlier mail messages that are appended for more detail and rationale.

    1. Close-Job operation needs the same timeout Printer requirements as RFC
    2911 has for Send-Document.

    2. Remove "document-id-uri" Document Description attribute. PSI agreed last
    week that they can use the IPP "document-number" (integer(1:MAX)) Document
    Description attribute to identify documents within a job.

    3. Add a "document-format-version" (text(127)) operation/Document
    Description attribute with self-identifing values, such as 'PS/3.0',
    'PCL/5e', 'PDF/1.4', 'PDF/X-1a:2001' (See ISSUES 01 and 02 below for more
    details). The prefix is from the Printer MIB langTC values used in the
    prtInterpretedLangFamily object and the version after the "/" can be used in
    the Printer MIB prtInterpreterLangLevel object.

    4. Add a "document-format-version-default" (text(127)) and
    "document-format-version-supported" (1setOf text(127)) Printer Description
    attributes to describe the default and supported values. (See ISSUES 03
    below for more details).
    So "document-format-version" and "document-format" would have parallel
    semantics, including also being member attributes of
    "document-format-details" (1setOf collection).

    5. ISSUE 04 (repeat of below): Is "document-format-version" a Best Effort
    (hint) unless "ipp-attribute-fidelity" = 'true" or
    "job-mandatory-attributes" = 'document-format-version' or do we make
    "document-format-version" be like "document-format" in that the Printer MUST
    reject the job if the Printer doesn't support the version?

    6. Put the version strings into a flat text file that implementers and
    implementations can access on the PWG FTP site. Adding new values is simply
    done whenever they are registered or standardized with some recognized body,
    such as IANA, CIP4, ISO, etc.

    ISSUE 05: We need to convince CIP4 to use the same flat file for their
    FileSpec/@MimeOrFileTypeVersion attribute and/or have each of them shadow
    the other.

    7. Add a "document-natural-language" (naturalLanguage) operation/Document
    Description attribute and a "document-natural-language-supported" (1setOf
    naturalLanguage) Printer Description attribute. The
    "document-natural-language" operation attribute is already defined in RFC
    2911 for use with Print-Job, Send-Document, and Send-URI, so we are just
    continuing this RFC 2911 attribute for the Create-Document operation and
    making it a Document Description attribute as well, so that it can be
    queried. Also keep "document-natural-language" (naturalLanguage) as a
    member attribute of "document-format-details" for describing packages.

    The "document-natural-language" is needed in order to know how to display
    characters that depend on language.

    ISSUE 06: What about multiple languages in a single document for the top
    level attribute?
    ISSUE 06a: What about for the member attribute of "document-format-details"?

    8. Add a "document-charset" (charset) operation/Document Description
    attribute and a "docuemnt-charset-supported" (1setOf charset) Printer
    Descrition attribute. This attribute is needed for the many plain text and
    markup languages in which the charset is not embedded in the data. For
    example, PCL often doesn't have the charset escape sequence in the data.
    Also many files use the various 8-bit ISO 8859 charsets in which the lower
    half is US-ASCII and the upper half is various Latin sets (about 8 or 9),
    Greek, Cyrllic, Hebrew, and Arabic. Shift JIS is another example where the
    left half is US-ASCII, but the right half can be one of a number of things.
    But if the data doesn't contain the charset escape sequences, this attribute
    can help the Printer know what the charset is in the Document.

    9. There is one issue embedded in the Document Object spec:

    6.1.2.2 document-creator-application-version (text(127))

    This OPTIONAL member Operation attribute identifies the version number of
    the application that created the document. The intent of this attribute is
    for display to a human being, rather than being parsed by the Printer for
    purpose of affecting the interpreting by the Printer and so may also include
    the name of the application, as well as build or service pack numbers.
    Examples:
    "WinzipÒ 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "MicrosoftÒ Word 2000
    (9.0.4119 SR-1)"

    ISSUE: OK that the purpose is human consumption, instead of program
    consumption and that it be the same as the application shows in its help
    message?
    The two other version attribute: "document-format-version" and
    "document-format-os-version" are intended for program consumption, not human
    consumption. Its possible that CIP4 will want to have both types of
    versions for: applications, operating systems, and documet-formats.

    Tom

    Here is last week's thread with more details:

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Wednesday, March 26, 2003 15:05
    To: sm@pwg.org; ps@pwg.org
    Cc: CIP4 System Behaviour and Interoperability WG
    [system_behaviour@cip4.org]; CIP4 Capabilities WG
    [capabilities@cip4.org]
    Subject: SM> More improvements to the IPP "document-format-version" and
    JDF Mi meOrFileTypeVersion attributes [4 ISSUES]

    Ira and I had even further thoughts about the IPP "document-format-version"
    (wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes
    since it is a top level attribute in the FileSpec resource):

    The proposal from yesterday is to make the values of IPP
    "docuent-format-version" and JDF MimeOrFileTypeVersion attributes be
    self-identifying, because they start with a prefix that identifies the
    format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc.

    ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP
    "docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make
    the values self identifying indendent of the correspoding IPP
    "document-format" and JDF MimeType attributes?

    Today's further thought is that we can now promote the IPP
    "document-format-version" member Operation attribute back to being a top
    level Document object attribute to accompany the existing "document-format"
    Operation attribute. This is because "document-format-version-supported"
    attribute now makes sense as a Printer Descrition attribute on its own,
    since the values would be things like:

    "PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998",
    "DCS/2.0", "MSWORD/2000" and don't need to be paired up with the
    correspoding "document-format-supported" Printer attribute values:
    "applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and
    "application/msword" MIME type values.

    ISSUE 02: OK to add a "document-format-version" operation and Document
    Description attribute to the IPP Document object spec?

    Just like the "document-format" Operation attribute which is also a member
    attribute of the "document-format-details" (1setOf collection)
    Operation/Document Description attribute, we'd keep
    "document-format-version" as a member attribute as well with the same
    prefixed values.

    This now means that "document-format" and "document-format-version" have all
    parallel construction:

    a. They are both operation attributes.
    b. They both have correspoding Document Description attributes that the
    Printer copies to.
    c. They both have "xxx-supported" Printer attributes.
    d. There is a "document-format-default" which now can have a corresponding
    "document-format-version-default" Printer attribute.
    ISSUE 03: OK to add "document-format-default" printer attribute?
    e. The Printer MUST reject the request if the "document-format" isn't
    supported.
     
    ISSUE 04: Do we want to make the same rule for the
    "document-format-version" or keep it as a Best Effort, unless the client
    supplies "ipp-attribute-fidelity"='true' or
    "job-mandatory-attributes"='document-format-version'?

    Comments?

    Thanks,
    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Tuesday, March 25, 2003 14:32
    To: sm@pwg.org; ps@pwg.org
    Cc: CIP4 System Behaviour and Interoperability WG
    [system_behaviour@cip4.org]; CIP4 Capabilities WG
    [capabilities@cip4.org]
    Subject: SM> Improvements of the IPP "document-format-version" and JDF
    MimeOfF ileTypeVersion attributes

    Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion
    the current IPP "document-format-version" attribute in the IPP Document
    Object spec Working Draft, dated March 24, 2003 and the JDF
    MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March
    21, 2003.

    This mail note has two specific proposals:

    1. Put the version strings into a flat file that can be updated and used by
    implementers. The respective specs can have an initial sets of strings for
    the flat file.

    2. Make the verson strings self-identifying.

    Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic
    Model WG and CIP4 System Behaviour and Interoperability WG).

    The current text for the IPP "document-format-version" attribute is:

    6.1.2.7 document-format-version (text(127))
    This REQUIRED member Operation attribute contains the level or version of
    the document format identified by the "document-format" member attribute.
    The client MAY supply and the Printer MUST support this member attribute.
    Possible values are the same as the Printer MIB [rfc1759]
    prtInterpreterLangLevel (not prtInterpreterLangVersion), such as:
                    '3': For Postscript level 3 [rfc1759].
                    '5e': For PCL 5e [rfc1759].

    Other example values are for those document formats that have well-defined
    version identification, either in the specification or as an actual field in
    the document content, such as::
                    'PDF/X-1:2001': For PDF/X-1 [iso15930]. "?
                    'PDF/X-1.2001': For PDF/X-1a [iso15930]
                    'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page -
    baseline.
                    'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone
    picture data - baseline
                    'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page -
    profile 1
                    'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone
    picture data - profile 1

    The current text for the JDF MimeOfFileTypeVersion attribute is:

    The level or version of the file format identified by MimeType or, FileType.
    Some example values are the same as the Printer MIB [rfc1759]
    prtInterpreterLangLevel, such as:
    "1", "2", "3" for MimeType = "application/postscript"
    "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL"
    Other example values are for those document formats that have well-defined
    version identification, either in the specification or as an actual field in
    the document content, such as:
    "5.0", "6.0", "2000", "XP" for MimeType = "application/msword"
    "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType =
    "application/pdf"
    "2.0" for FileType = "DCS"
    "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC
    Profiles?
    "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType =
    "TIFF/IT"
    See Appendix A.1 "FileSpec Resource examples for MimeType, FileType,
    MimeOrFileTypeVersion attributes" for additional examples in common use by
    JDF applications.

    The two suggestions for improvement is:

    1. Put the version strings into a flat file so that implementers can get
    them, so that new values can be added to easily, after appropriate review,
    without having to republish either the IPP Document Object spec or the CIP4
    JDF spec.

    ISSUE: Whether both the PWG and CIP4 would have their own flat files that
    they would co-ordinate is an issue to be discussed.

    2. The version string should be self identifying, e.g., PDF/1.3, not just
    1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the
    Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the
    Language Family and the Language Level attributes for the version. The
    Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF.

    In the Printer MIB there are two attributes (MIBs call them "objects"):

    prtInterpreterLangFamily OBJECT-TYPE
        -- NOTE: In RFC 1759, the enumeration values were implicitly
        -- defined by this object.
        SYNTAX PrtInterpreterLangFamilyTC
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The family name of a Page Description Language (PDL) or
            control language which this interpreter in the printer can
            interpret or emulate.

            NOTE: The above description has been modified from RFC 1759
            for clarification."

    prtInterpreterLangLevel OBJECT-TYPE
        SYNTAX OCTET STRING (SIZE(0..31))
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The level of the language which this interpreter is
            interpreting or emulating. This might contain a value like
            '5e'for an interpreter which is emulating level 5e of the PCL
            language. It might contain '2' for an interpreter which is
            emulating level 2 of the PostScript language. Similarly it
            might contain '2' for an interpreter which is emulating level 2
            of the HPGL language."

    The prtInterpreterLangFamily has a Textual Convention for the assignment of
    about 62 printer languages. The symbolic names are of the form: langXxxx

    For example there are the following:
            langPCL(3), -- PCL. Starting with PCL version 5,
                                 -- HP-GL/2 is included as part of the
                                 -- PCL language.
                                 -- PCL and HP-GL/2 are registered
                                 -- trademarks of Hewlett-Packard
                                 -- Company.
            langHPGL(4), -- Hewlett-Packard Graphics Language.
                                 -- HP-GL is a registered trademark of
                                 -- Hewlett-Packard Company.
            langPJL(5), -- Peripheral Job Language. Appears in
                                 -- the data stream between data intended
                                 -- for a page description language.
                                 -- Hewlett-Packard Co.
            langPS(6), -- PostScript (tm) Language
                                 -- Postscript - a trademark of Adobe
                                 -- Systems Incorporated which may be
                                 -- registered in certain jurisdictions
            langIPDS(7), -- Intelligent Printer Data Stream
                                 -- Bi-directional print data stream for
                                 -- documents consisting of data objects
                                 -- (text, image, graphics, bar codes),
                                 -- resources (fonts, overlays) and page,
                                 -- form and finishing instructions.
                                 -- Facilitates system level device
                                 -- control, document tracking and error
                                 -- recovery throughout the print
                                 -- process.
                                 -- IBM Corporation.

    ...<middle section deleted>

            langPDF(54), -- Not in RFC 1759
                                 -- Adobe Portable Document Format
                                 -- Adobe Systems, Inc.
            langRPDL(55), -- Not in RFC 1759
                                 -- Ricoh Page Description Language for
                                 -- printers.
                                 -- Technical manual "RPDL command
                                 -- reference" No.307029
                                 -- RICOH, Co. LTD
            langIntermecIPL(56), -- Not in RFC 1759
                                 -- Intermec Printer Language for label
                                 -- printers.
                                 -- Technical Manual: "IPL Programmers
                                 -- Reference Manual"
                                 -- Intermec Corporation
            langUBIFingerprint(57), -- Not in RFC 1759
                                 -- An intelligent basic-like programming
                                 -- language for label printers.
                                 -- Reference Manual: "UBI Fingerprint
                                 -- 7.1", No. 1-960434-00
                                 -- United Barcode Industries
            langUBIDirectProtocol(58), -- Not in RFC 1759
                                 -- An intelligent control language for
                                 -- label printers.
                                 -- Programmers guide: " UBI Direct
                                 -- Protocol", No. 1-960419-00
                                 -- United Barcode Industries
            langFujitsu(59), -- Not in RFC 1759
                                 -- Fujitsu Printer Language
                                 -- Reference Manual:
                                 -- "FM Printer Sequence" No. 80HP-0770
                                 -- FUJITSU LIMITED
            langCGM(60), -- Not in RFC 1759
                                 -- Computer Graphics Metafile
                                 -- MIME type 'image/cgm'
            langJPEG(61), -- Not in RFC 1759
                                 -- Joint Photographic Experts Group
                                 -- MIME type 'image/jpeg'
            langCALS1(62), -- Not in RFC 1759
                                 -- US DOD CALS1 (see MIL-STD-1840)
                                 -- MIME type 'application/cals-1840'
            langCALS2(63), -- Not in RFC 1759
                                 -- US DOD CALS2 (see MIL-STD-1840)
                                 -- MIME type 'application/cals-1840'
            langNIRS(64), -- Not in RFC 1759
                                 -- US DOD NIRS (see MIL-STD-1840)
                                 -- MIME type 'application/cals-1840'
            langC4(65) -- Not in RFC 1759
                                 -- US DOD C4 (see MIL-STD-1840)
                                 -- MIME type 'application/cals-1840'

    So take the prtInterpreterLangFamily textual convention after the "lang",
    follow it with a "/" and then have the prtInterpreterLangLevel.

    So the updated IPP "document-format-version" member attribute would become:

    6.1.2.7 document-format-version (text(127))
    This REQUIRED member Operation attribute contains the level or version of
    the document format identified by the "document-format" member attribute.
    The client MAY supply and the Printer MUST support this member attribute.
    Possible values are the same as the Printer MIB [rfc1759]
    prtInterpreterLangFamily textual convention (minus the "lang" prefix) and
    prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/",
    such as:
                    'PS/3': For Postscript level 3 [rfc1759].
                    'PCL/5e': For PCL 5e [rfc1759].

    Other example values are for those document formats that have well-defined
    version identification, either in the specification or as an actual field in
    the document content, such a:
                    'PDF/X-1:2001': For PDF/X-1 [iso15930]. "?
                    'PDF/X-1.2001': For PDF/X-1a [iso15930]
                    'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page -
    baseline.
                    'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone
    picture data - baseline
                    'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page -
    profile 1
                    'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone
    picture data - profile 1

    See PWG www.pwg.org [need URL] for a flat file list of the version strings
    currently recognized for use in the PWG Semantic Model and derivative
    protocols, such as IPP and PSI.

    and the updated JDF MimeOrFileTypeVersion attribute would become:

    The level or version of the file format identified by MimeType or, FileType.
    Some example values are the same as the Printer MIB [rfc1759]
    prtInterpreterLangFamily textual convention (minus the "lang" prefix) and
    prtInterpreterLangLevel, such as:
    "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript"
    "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL"
    Other example values are for those document formats that have well-defined
    version identification, either in the specification or as an actual field in
    the document content, such as:
    "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType =
    "application/msword"
    "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType =
    "application/pdf"
    "DCS/2.0" for FileType = "DCS"
    "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC
    Profiles?
    "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType =
    "TIFF/IT"
    See CIP4 www.cip4.org [need URL] for the flat text file that contains the
    version strings currently recognized for the "FileSpec Resource attributes:
    MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications.

    Comments?

    Tom



    This archive was generated by hypermail 2b29 : Wed Apr 02 2003 - 21:23:46 EST