IPP Mail Archive: IPP> RE: SM> 1 more significant propose

IPP Mail Archive: IPP> RE: SM> 1 more significant propose

IPP> RE: SM> 1 more significant proposed conformance change to the IPP Document object spec [last-document]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Apr 23 2003 - 03:04:20 EDT

  • Next message: Hastings, Tom N: "RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec [why PDL-override]"

    Dennis wrote:

    > I'm a bit confused: I had the (apparently flawed) impression that the plan
    > was to deprecate, for a client, using the "last-document" operation
    > attribute entirely--that is, say the "correct" way to say a job was done
    > was to do Close-Job.

    I could have gotten the notes wrong here, but I had scribbled the comment
    under the Send-URI where it discussed the empty Send-Document operation to
    close a job.

    I see no objection to a client saving a trip and closing the job on the
    Send-Document or Send-URI operation when sending actual data with the
    "last-document" = 'true'.

    So I think we should keep "last-document" operation for all of the following
    reasons:

    1. We need a "last-document" Document Description attribute for the Document
    object anyway for querying, so that the client knows when its gotten to the
    last Document.

    2. Being able to submit data and "last-document" = 'true" saves a round trip
    when creating a multiple document job.

    3. The current [rfc2911] REQUIRED behaviour is the client MUST always supply
    the "last-document" with a 'false' or a 'true' value in Send-Document and
    Send-URI; the client MUST NOT omit the "last-document', so we'd be
    deprecating something that we REQUIRE the client to supply.

    4. The current [RFC2911] requirement for the Printer is:
    "If the Printer supports this [Send-Document] operation but does not support
    multiple documents per job, the Printer MUST reject subsequent Send-Document
    operations supplied with data and return the
    'server-error-multiple-document-jobs-not-supported'. However, the Printer
    MUST accept the first document with a 'true' or 'false' value for the
    "last-document" operation attribute (see below), so that clients MAY always
    submit one document jobs with a 'false' value for "last-document" in the
    first Send-Document and a 'true' for "last-document" in the second
    Send-Document (with no data)."

    5. If the client fails to close the job one way or another without the
    timeout period, the Printer MUST perform an action to abort, hold, or
    process the job, depending on policy. So Jobs aren't always cleanly closed
    by the client anyway (using a separate Close-Job operation).

    6. The client supplying "last-document" as an Operation attirbute which the
    Printer copies to the "last-document" Document Description attribute aligns
    better with the PWG Semantic Model where LastDocument is a Document
    Description Element, since in the PWG SM the client is able to supply _any_
    Document Description attribute which the Printer copies to the Document
    object.

    7. In summary, the current [RFC2911] "last-document" operation attributes
    semantics isn't broken (just unethetic to some), so lets not fix it.

    Tom

    P.S. I'm only replying to the IPP DL as requested by some members.

    -----Original Message-----
    From: Dennis Carney [mailto:dcarney@us.ibm.com]
    Sent: Monday, April 21, 2003 16:14
    To: sm@pwg.org; ps@pwg.org; ipp@pwg.org
    Subject: Re: SM> 1 more significant proposed conformance change to the
    IPP Documen t object spec

    I'm a bit confused: I had the (apparently flawed) impression that the plan
    was to deprecate, for a client, using the "last-document" operation
    attribute entirely--that is, say the "correct" way to say a job was done
    was to do Close-Job. If we do that, we will by definition deprecate the
    special case you're discussing below, right? Am I thinking of PSI or maybe
    SM?

    Since deprecation is only a suggestion, might it make sense to deprecate
    "last-document" entirely? (The Printer will still have to support it, but
    we're encouraging clients to move to Close-Job.) Do we want to make such a
    stand?

    Dennis

     

                          "Hastings, Tom N"

                          <hastings@cp10.es To: sm@pwg.org

                          .xerox.com> cc: ps@pwg.org,
    ipp@pwg.org

                          Sent by: Subject: SM> 1 more
    significant proposed conformance change to the IPP Documen t object spec

                          owner-sm@pwg.org

     

     

                          04/21/03 10:08 AM

     

     

    In going over my notes I discovered one more significant conformance
    changes
    proposed change for the IPP Document object from Thursday's April 17,
    telecon. This proposal will also go through the two-week comment period.

    1. DEPRECATE the way a client can close a Job by supplying an empty
    Send-Document operation supplying the "last-document" = 'true' operation
    attribute for a Job created with Create-Job and any of (1)
    Create-Document/Send-Data, (2) Send-Document, and/or (3) Send-URI. When
    the
    Printer accepts this no-data Send-Document operation with "last-document"
    =
    'true' the Printer MUST set the still REQUIRED "last-document" Document
    Description attribute. Instead, the client SHOULD use the new Close-Job
    operation (which also sets the "last-document" Document Description
    attribute).

    The Printer MUST continue to support this method of closing a job with an
    empty Send-Document request for backward compatibility with existing
    clients.

    As with the other two mail messages on significant conformance requirements
    changes, I will not edit this comment into the spec until we reach
    consensus
    on Friday, May 1.

    Please send comments.

    Tom



    This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 03:05:08 EDT