Semantic Model Mail Archive: SM> My responses to existing is

Semantic Model Mail Archive: SM> My responses to existing is

SM> My responses to existing issues and a reminder to be ready for Th ursday

From: Zehler, Peter (PZehler@crt.xerox.com)
Date: Tue Apr 15 2003 - 10:41:30 EDT

  • Next message: Dennis Carney: "SM> Integrate "-actual" attributes into the document object spec"

    All,

    I hope you all are reading the Document Object specification and preparing
    for Thursday's teleconference. The Document Object specification we will
    use for review is still:
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB

    Please forward any new issues or comments to the list. Below are my
    opinions
    on the 5 outstanding issues.

    Pete
    __________________________________________________________________________

    ISSUE 1:
    Since we agreed that this attribute isn't a hint, OK to make it
    CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document
    formats?
    <PZ>Yes</>

    ISSUE 2:
    If the Printer supports this "document-digital-signature" Operation
    attribute and the value supplied by the client, the Printer MUST verify the
    signature according to the rule for that signature format. If the signature
    does not verify, then the Printer MUST either (1) ignore the signature or
    (2) put the job on hold and wait for human intervention, depending on
    implementation. The Printer gives no additional indication to the client.
    ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the
    correct behavior for the Printer if the digital signature doesn't verify?
    <PZ>It should also be valid to abort the job. In any event the JobState
    and JobStateReasons should give an indication to the client. I think we
    will
    need a new JobStateReason such as InvalidSignature. How does this apply to
    documents within a job? Do we (1) ignore the signature and print the
    document and job, (2) Put the job on hold and wait for human intervention
    (and
    what about partially printed jobs?) (3) abort the document and continue
    printing the job (4) abort the document and job (once again what about
    partially printed jobs. This would be cleaned up if we mandated that
    document-signatures are evaluated at submission time. This may not be
    practical given the latency involved in contacting the certificate
    authority<PZ>

    ISSUE 3:
    This Printer behavior is backwards compatible with a Printer that doesn't
    support the "digital-signature" attribute. However, if the Printer supports
    the "job-mandatory-attributes" attribute (see section 8.1.2) and the client
    supplies the "job-mandatory-attribute" Operation attribute with the
    'digital-signature' keyword value, then the Printer MUST reject the job if
    the "digital-signature" attribute is supplied with a value that isn't
    supported by the Printer (or the Printer doesn't support the
    "digital-signature" attribute at all). Thus the client can force the
    Printer to reject a signed document for a signature technology that the
    Printer does not support. ISSUE 03: What if the digital signature is
    supported, but the signature fails verification by the Printer when
    "job-mandatory-attributes" identifies 'document-digital-signature'?
    <PZ>The digital-signature should be treated as any other mandatory value
    with an invalid value. The job should be rejected, Document-signature
    and its value should be returned. This assumes the signature is evaluated
    at submission time.<PZ>

    ISSUE 4:
    The values of the "document-format" and their corresponding
    "document-format-version" values will be kept in a flat text file on the PWG
    server for use by the PWG and CIP4. Implementers and implementations will
    be able to access this file at any time (at CD writing time, install time,
    vendor update time, and/or at power-up time, etc.). New values will be
    added to the flat file by its Maintainer after sending to the PWG list for a
    two week review whenever they are registered with or standardized by some
    recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4
    buy-in to use the same flat file (which will require an additional field for
    the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for
    the file. The URL is:
                    ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should
    the URL be for the flat file? What is the formatting conventions for the
    flat file. Is it a PWG Schema of sorts?
    <PZ>I never thought that schemas would be retrieved real time from printers
    and print clients. I assumed that the namespace would indicate the schema
    used. Clearly Printers would not need to access the schema since it already
    knows what it has implemented and the instance document would be valid for
    the schema. Print clients do not need to know all the possible semantic
    elements and values. It only needs the elements and values for the target
    Printer. The client would have built in support for the PWG schema to
    validate a Printer's instance document against. That leaves a general
    purpose web service client that will somehow be able to derive and present
    the semantic meaning behind the PWG schema in a user friendly way. (yeah
    there are a lot of those out there)<PZ>

    ISSUE 5:
    from Dennis Carney:
    - I brought this up on the call, but I'll mention it again, since I'm not
    sure whether it was resolved. You sell a printer. You happen to have
    found out that some specific thing goes wrong when a user uses Powerpoint
    2000 on Windows NT 4.0, such that your printer always messes up the
    printout. How do you specify this in document-format-details-implemented?
    And a much simpler issue on these same lines: why would *anyone*, ever,
    return any values for the document-creator-application-name-implemented or
    document-creator-application-version-implemented member attributes--why
    would anyone want to try to list all applications they support? Similarly
    for the two "os" member attributes--I might know I don't provide special
    drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a
    PDF file, *can* print to me from Macintosh. Even if there *were* some OSes
    I wanted to say I don't support (which seems doubtful), I have to do this
    by listing all *other* OSes? I guess in summary: I can see the use for the
    5th-8th member attributes of document-format-details-implemented, but not
    for the 1st-4th.
    <PZ>These seem most useful for transformation services such as a PSI Server.
    Printers would probably try and describe the document formats they support
    in the most generic way. A transformation service may want to be very
    explicit about the source document formats it is able to transform into
    printer ready formats.<PZ>

    Tom

                                    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



    This archive was generated by hypermail 2b29 : Tue Apr 15 2003 - 10:41:38 EDT