IPP Mail Archive: IPP> 25 additional agreements to IPP Docum

IPP Mail Archive: IPP> 25 additional agreements to IPP Docum

IPP> 25 additional agreements to IPP Document object spec during Thurs day's April 17, telecon

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Apr 22 2003 - 01:21:57 EDT

  • Next message: Zehler, Peter: "IPP> Extended PWG Semantic Model(Document Object) Teleconference"

    Three previous notes listed 4 significant, 2 significant, and 1 additional
    conformance requirements to the IPP Document Object spec and called for
    comments on them during the next two weeks, due Friday May 1.

    As just announced, we're continuing the review of the IPP Document Object
    spec, only on the ipp@pwg.org DL, and discontinuing cross-posting on the
    sm@pwg.org and ps@pwg.org, so that people only receive one email message.

    This mail note describes the other agreements we reached when reviewing the
    IPP Document Object spec and its 9 issues at Thursday's April 17 telecon.
    These are not significant enough to make a special call for comment.
    However, if you do have comments on these agreements, please send any
    comments on these agreements as well to the ipp@pwg.org DL. However, the
    review next week Thursday, April 24, will be to continue the original spec
    from Table 7, page 41, not a spec updated with these changes.

    1. Abstract: Remove the REQUIRED and OPTIONAL from the Abstract

    2. Abstract and Introduction: Move Get-Documents to the Job operations row.

    3. Introduction: Mention the -actuals Document Description attributes.

    4. Footnote 5 ISSUE: The corresponding PSI operation to Create-Document is

    5. Page 13, Table 2: Remove the use of the term "Hint". These
    Operation/Document Description attributes are not hints, since the Printer
    MUST use them if supported.

    6. Page 18, Create-Document, Clarify that the Notification Subscriptions
    MUST be supplied only in Job Creation operations as specified in [ippntfy],
    not in Document Creation operations.

    7. Page 25, Move Get-Documents from the Document operations to the Job
    operations section.

    8. Page 35, Print-Job: add that Print-Job creates a single Document object.
    Also clarify that the results of these two operations will be
    indistinguishable from a Job created by a Create-Job where the client
    supplied Job Template attributes, a Send-Document with no Document Template
    attributes, and a Close-Job. In other words, a new client performing a
    Get-Job-Attributes and a Get-Documents will see the same results from the
    Job created with Print-Job as with a Job created with Create-Job,
    Send-Document, and Close-Job provided that the Send-Document doesn't supply
    any Document Temlate attributes. Also an old client performing just a
    Get-Job-Attributes will see the same results from (1) an old Printer that
    accepted the Print-Job, (2) a new Printer that accepted the Print-Job, and
    (3) a new Printer that accepted the Create-Job, Send-Document, Close-Job.
    However, if a new client supplies Document Temlate attributes on the
    Send-Document, instead of the same attributes as Job Template attributes on
    the Create-Job, then an old client will not see any of the Documenet
    Template attributes when it performs the Get-Job-Attributes operation (since
    the Printer does not "copy up" Document Template attributes to the Job Level
    on a Get-Job-Attributes on a one document job). ISSUE: OK that the old
    client doesn't see the Template attributes?

    9. Page 35, Add the same discussion for Print-URI being indistinguishable
    from a job created by Create-Job, Send-URI with no Document Template
    attributes, and a Close-Job.

    10. Page 36, Close-Job, change the MAY to SHOULD for the client to use,
    instead of setting "last-document" boolean.

    11. Page 36, Close-Job, add that request is rejected if the operation is
    already closed with the 'client-error-not-possible' status code.

    12. Pages 37-38, Move the Administrative operations (Purge-Jobs,
    Cancel-Current-Job, Suspend-Current-Job, and Delete-Document), to a new
    Administrative operations section.

    13. Page 42, Table 7, Change from Landscape to Portrait, so that it can be
    read on a 640 x 480 pixel screen. Remove the remaining four columns to make
    it fit.

    14. Page 42, Table 7, make a new column for Print-Job and Print-URI, rather
    than using the "p" notation.

    Resolutions of ISSUES:

    15. 7.1.1 document-charset (charset)
    ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it
    CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document
    formats? AGREED: Yes.

    16. 7.1.1 document-digital-signature (type2 keyword)
    If the Printer supports this attribute and the value supplied by the client,
    the Printer MAY 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 (and MAY indicate on the printed output some
    how) or (2) put the job on hold and wait for human intervention, or (3)
    abort the job depending on implementation and/or site configuration? Need a
    new "job-state-reasons" and "document-state-reasons", 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 or
    (3) abort the job depending on implementation and/or site configuration?
    AGREED: Add the (3) choice to abort the job. Also need a new
    "job-state-reasons" and "document-state-reasons":

    17. 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'? Printer MUST support the technology and MUST
    verify the signature during the processing of the document. AGREED:
    Printer MUST abort the job. The client can resubmit without
    "job-mandatory-attributes" if client wants to get the signature ignored.

    18. ISSUE 05 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.
    Agreed to add: Note: 1st four attributes are intended more for a document
    transformation service which MAY be part of a Printer.

    19. document-creator-application-name (name(MAX)) and
    document-creator-application-version (text(127))
    AGREED: To change the name to document-source-application-name (name(MAX))
    and document-source-application-version (text(127))

    20. ISSUE 06: Should document-source-application-version be for program
    consumption, not human? Such a change would agree with the CIP4 JDF review
    comments for the corresponding attribute. AGREED: OK The above description
    would be changed as suggested.

    21. 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? AGREED: The Printer doesn't bang on the list, but
    the client might. How about CIP4 host the flat file? Or the PWG finds a
    commercial enterprise to host it on a commercial web site. Put schemas
    there too?

    22. ISSUE 07: Clarify that Document Template attributes share the same
    "xxx-default", "xxx-supported", and "xxx-ready" Printer attributes with the
    corresponding Job Template attributes and so have the same supported,
    default, and ready values. AGREED.

    23. ISSUE 08: OK to add mention of the corresponding "xxx-actual" Document
    Description attributes that a Printer MAY support and add a reference to the
    [ippact] specification? AGREED.

    24. ISSUE 09: Ok that the -actual concept is not applied to any
    Operation/Document Description attributes, such as the new
    "document-charset", "document-digital-signature", "document-format-details"
    (it has "document-format-details-detected"), "document-format-version", and
    "document-natural-language"? AGREED.

    25. Add a 'guaranteed" value for "pdf-override-supported" and
    "pdl-override-attributes-guaranteed" Printer Description here for IPPFAX.

    Send any comments to the IPP DL only.


    This archive was generated by hypermail 2b29 : Tue Apr 22 2003 - 01:22:47 EDT