Semantic Model Mail Archive: FW: SM> This week's SM teleconf

Semantic Model Mail Archive: FW: SM> This week's SM teleconf

FW: SM> This week's SM teleconference agenda and information

From: Hastings, Tom N (
Date: Tue Dec 03 2002 - 16:04:09 EST

  • Next message: Hastings, Tom N: "SM> PWG Review of the IPP Color and Imaging Attributes version 0.1, T hur, 12/5/02, 1-2 PM EST"

    Rick and Ted (and other CIP4 Digital Printing WG members, PODi Job Ticketing
    WG members, and FSG Job Ticket API members),

    There is a one hour PWG (Printer Working Group) Semantic Model telecon this
    Thursday, 10-11 AM PST (1-2 EST), to review two IPP documents:
    IPP Document Object
    IPP Color and Imaging Attributes
    (See below how to obtain the documents)
    See below for dial-in numbers and webex connections.

    The attributes in the IPP Color and Imaging Attributes spec are the ones
    just added to the CIP4/PODi/FSG IPP to JDF/1.1, CUPS, FSG JTAPI, PODi
    mapping table.

    If you want to send comments ahead of the meeting (much appreciated) join
    the Semantic Model mailing list (which is needed in order to send email to
    the list because of spam), subscribe using the usual Majordomo:

    Send to
    with the following in the body of the message:

       subscribe sm

    But you don't need to subscribe to join the teleconference (and your company
    doesn't need to join the PWG either, though we welcome your company to do

    I'll send out a proposal from Michael Sweet for two additional attributes:
    "adjust-hue" (integer(-180:180))
    "image-subsample" (type2 keyword)
    and a "resample-method" (type2 keyword) counter proposal for the latter in a
    separate mail message.


    -----Original Message-----
    From: Zehler, Peter []
    Sent: Monday, December 02, 2002 11:35
    To: PWG Semantic Model WG (E-mail)
    Subject: SM> This week's SM teleconference agenda and information


    This Thursday at 1pm EDT is the Semantic Model teleconference. The
    teleconference is one hour long. It will be run using both phone and Webex.
    Anyone that does not yet have Webex installed should do that before
    Thursday. Information for the phone and Webex are included below.

    The agenda for the Semantic Model teleconference is

    1) Status on Semantic Model and associated schema
    2) Discuss outstanding issues in the Document Object Specification
       The 4 outstanding issues are included below in an excerpt from a mail
    note from Tom Hastings
        (The document has not been updated since our last conversation. The 6
    included issues have been resolved.)
       Note that this conversation is IPP specific.
    3) Discuss "The Printer Working Group Standard for the Internet Printing
    Protocol (IPP):
        Color and Imaging Attributes"
         Note that this conversation is IPP specific.
    4) Next steps

                                    Peter Zehler
                                    Xerox Architecture Center
                                    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

    PS to Bob Taylor: Let me know if there is any problem with Webex for this

    Dial in Info:
    Phone Number: (877) 776-6306
    (Phone Number for Xerox Employees: 8*594-0576)
    webex info:
    We will also use an on line tool called webex,
    if you have not used this before, setup up by
    following the First Time Users instructions.
    Do this in advance of the meeting.

    For fully interactive meetings, including the ability
    to present your documents and applications, a one-time
    setup takes less than 10 minutes. Click this URL to set up now:

    Then click New User.

    On Thursday use:

    Then click join unlisted meeting.
    Use the info below:
    Name: PWG Semantic Model
    Date: 12/5/2002
    Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time)
             10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time)
    Meeting Number: 21366675
    Meeting Password: pwg_sm
    Bob Taylor (HP)

    Document Object Issues:

    I sent the original note to the SM DL on November 21. Here is the revised
    note dropping the suggestion to make Send-Document OPTIONAL. Send-Document
    should remain REQUIRED in the Document object spec for two reasons:

    1. OPTIONAL operations aren't supported by clients.
    2. If the client supplies "ipp-attribute-fidelity" = 'false' or omits it,
    the client may as well use Send-Document since the Printer MUST accept it,
    rather than the two operations: Create-Document and Send-Data.

    Here is the original mail note with edits:

    Peter has relayed some concerns raised at the Semantic Model WG meeting in
    Orleans about low end (non-spooling) Printer support for the Document
    object. Those concerns included:

    A. Create-Document and Send-Data operations being REQUIRED for a Printer to

    B. A client can create "holes" in the document numbering space and send
    documents in any order using the "document-number" operation attribute for
    Create-Document, Send-Document, and Send-URI. The suggestion was to remove
    the "document-number" operation attribute from the specification for all
    operations. Then there can't be holes in the document numbers. Make the
    client create the documents in the order wanted in the output, so that the
    Printer will number them as the client wants. (Also need to deprecate the
    "document-number" operation attribute for use with the Send-Document and
    Send-URI operations in the PWG Document Overrides specification - IEEE-ISTO

    Here is a rather long note that proposes to:
    1. eliminate the REQUIRED Validate-Document operation altogether.
    2. keep Create-Document and Send-Data REQUIRED (see reasoning below).
    3. Remove the "document-number" operation attribute because it isn't needed
    since Create-Document would always be available (see reasoning below).
    4. Consider deleting the Cancel-Current-Document, since its pretty funky if
    "copies" is > 1.

    I've discussed this mail note with Gail Songer before sending it. She was
    one of the people at the meeting who was concerned about low end Printers
    that wanted to support the Document object. She could not find any flaws in
    the reasoning in this email note.

    Goals and Requirements for the Document object spec:

    Goal 1. In order to improve interoperability, we need to eliminate
    operations and operation attributes that are OPTIONAL for a Printer to
    support. In fact, if an operation or operation attribute is OPTIONAL for a
    Printer to support, it is highly unlikely that clients will bother to
    support the feature. Also we want to define as small a number of different
    ways to submit a multi-document job as possible, as long as they cover the
    important use cases.

    Goal 2: The Document object should be supportable by a non-spooling low end
    printer as well as a higher end spooling printer.

    The non-spooling low end printer can't support making copies (except for
    really short documents), except for "sheet-collate" = 'uncollated'. Such a
    Printer starts to mark document data as it is received. So such a Printer
    cannot support "multiple-document-handling" =

    In principle, the spooling printer can support all values of "sheet-collate"
    and "multiple-document-handling".

    However, the non-spooling Printer MUST keep the Document object (but not the
    data) for the lifetime of the Job. The Printer cannot throw away the
    Document object as soon as the Document has been printed, but MUST keep it
    until the Job is completed. This requirement means that there is no extra
    burden on a non-spooling Printer to have to accept multiple Create-Document
    requests for a given job before getting any data. It has to keep all of the
    Document objects for the life of the job anyway.

    Goal 3. There are two client use cases that the spec needs to support:

    Use Case A. A client should be able to validate all the documents in a
    multi-document job, before sending the data for any of them. If the Printer
    can't support a document or can't support it when combined with other
    documents in the same job, the client can avoid sending any data, or decide
    with the user which documents to actually submit in the Document Creation

    Usage Case B. A client should be able to validate a document and send the
    data, validate the next document and send its data, etc.

    Given the above, here are my suggestions for the spec with my reasons:

    1. Validate-Document should be removed from the spec (even though Printer's
    are REQUIRED to support it in the current version).

    If the client performs a Create-Document with "ipp-attribute-fidelity" =
    'true', then it is practically the same as Validate-Document. If any of the
    supplied attributes or values are unsupported, the Printer rejects the
    operation and its the same a Validate-Document. Only if the Create-Document
    succeeds, does the Printer actually create the Document object which is
    probably what the client would want anyway (Use Case B). (In the unlikely
    case that the client didn't want to create the Document object, the client
    can do a Cancel-Document operation).

    For the Validate-Document case when not supplying the "job-id", the client
    can obtain the same functionality by using Validate-Job with each Document
    separately, before sending any data (Use Case A).

    Another reason to get rid of Validate-Document is because it doesn't
    completely allow validation of all documents before sending any data (Use
    Case A). For example, if a Printer object represents a one-sided color
    printer and a two-sided black and white printer, Validate-Document will not
    correctly validate a two-document job consisting of a two-sided black and
    white document and a one-sided color job. This is because one of the
    Document objects has to be created in order to validate the other Document
    in combination. Secondly, if we REQUIRE Create-Document, there is no need
    for Validate-Document, since Create-Document creates the Document object and
    validates it in the context of the job (without the client sending any

    Also eliminating Validate-Document removes another REQUIRED operation
    attribute for the Printer to support in Validate-Document, namely, the
    "job-id". So the Printer doesn't have to have two validate paths, one for a
    document in the context of a job and the other for the document by itself,
    thereby simplifying Printer implementation and eliminating another set of
    cases to be tested.

    I know that the PSI also has Validate-Document, so we'll need to try to
    convince them to drop Validate-Document as well.

    2. Remove the "document-number" OPTIONAL operation attribute from the spec
    for Create-Document, Send-Document, and Send-URI (Goal 1 above). The
    "document-number" operation attribute was added to the Document Override
    spec per request from Carl Kugler to support sending multiple document data
    in parallel (on separate channels) for high end applications. The client
    can force the Printer to number the documents by ordering the
    Create-Document operations in the desired order and then send the data in
    parallel for the documents. In order to meet the requirements of a
    non-spooling printer, the client MUST issue the Send-Data request for each
    document in order. If the Printer gets a Send-Data out of order (and can't
    spool), then the Printer rejects the Send-Data with an error code:
    "client-error-documents-not-in-order". If the client had a race between
    different threads, then each thread will back off an try again when it gets
    this error. If the client is single threaded, then the error indicates a
    bug in the client.

    3. Keep Create-Document and Send-Data as REQUIRED for the Printer to
    support. Then these two operations are the preferred way for a client to
    submit a multi-document job. Keeping them REQUIRED means that clients will
    bother to support them. If they are OPTIONAL, most clients won't bother
    supporting them. Finally, keeping them REQUIRED means that we can remove
    the "document-number" operation attribute all together (as in point number 2
    above), since Clients that want to submit data in parallel can do so using
    multiple Create-Document calls in serial followed by multiple Send-Data
    operations in parallel (on separate channels).

    Having two operations, one to create the Document object and the other to
    send the data, does REQUIRE the Printer to deal with the time-out problem.
    But multi-document jobs already have to deal with the time-out problem,
    after a Create-Job operation anyway, so timing out a Send-Data the didn't
    happen soon enough after a Create-Document shouldn't be much of an extra
    burden on the Printer.

    After we did IPP/1.1, we wished that we had made Create-Job and
    Send-Document REQUIRED, instead of Print-Job. After operational experience,
    even Paul Moore regretted that Microsoft had demanded that the IPP WG make
    Print-Job be REQUIRED and Create-Job/Send-Document be OPTIONAL. The problem
    with Print-Job (and Send-Document) is that the client has to wait to get
    back a failure status code in a Print-Job response until after the client
    has wasted its time sending all of the data. Lets learn from our
    experience with IPP/1.1 on the Job object and not repeat the same mistakes
    on the Document object.

    However, when the client supplies the "ipp-attribute-fidelity" = 'false' or
    omits it, the client can be more efficient by using Send-Document, instead
    of Create-Document and Send-Data, since the Printer MUST accept such a
    request no matter what attributes and values are supplied. So keep
    Send-Document REQUIRED as well.

    Here is the list of operations:

    Operation Name Printer Printer
                               support support
                               V0.1 proposed

    Create-Document REQUIRED REQUIRED
    Send-Document * REQUIRED REQUIRED
    Validate-Document REQUIRED delete
    Get-Document-Attributes REQUIRED REQUIRED
    Set-Document-Attributes OPTIONAL OPTIONAL
    Cancel-Document REQUIRED REQUIRED
    Cancel-Current-Document OPTIONAL delete **?
    Delete-Document OPTIONAL OPTIONAL
    * The existing IPP/1.1 operations defined in [RFC2911] with an extension so
    the client can supply Document Template attributes in a new attribute Group
    in the request.
    ** Cancel-Current-Job is fine, but Cancel-Current-Document is pretty funky
    if the job has multiple documents and "copies" is greater than 1.



    This archive was generated by hypermail 2b29 : Tue Dec 03 2002 - 16:05:09 EST