IPP Mail Archive: IPP> RE: Dennis's good comments and issues

IPP Mail Archive: IPP> RE: Dennis's good comments and issues

IPP> RE: Dennis's good comments and issues with the Document Object sp ec

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Jun 17 2003 - 22:33:37 EDT

  • Next message: McDonald, Ira: "IPP> RE: Dennis's ISSUE about Job and Printer Description names being the same"


    Thanks for doing such a thorough review job! I agree with all of your
    comments and fixes, except for the few as noted in this mail note. Most of
    the replies are suggested answers to your issues and questions. I've cut
    and pasted your ISSUE along with some surrounding text to make the mail note
    easier to read by itself.

    1. About ISSUE02:

    (DMC ISSUE02: Rule 1 for the table above says MUST, as does the description
    of "document-state-reasons"; OK to change it say MUST here as well?)

    Once a successful response has been sent, the implementation guarantees that
    the Document will eventually end up in the 'canceled' state. Between the
    time of the Cancel-Document operation is accepted and when the document
    enters the 'canceled' document-state (see section 9.1.23), the
    "document-state-reasons" attribute (see section 9.1.25) SHOULD (DMC ISSUE02:
    Rule 1 for the table above says MUST, as does the description of
    "document-state-reasons"; OK to change it say MUST here as well?) contain
    the 'processing-to-stop-point' value which indicates to later queries that
    although the Document might still be 'processing', it will eventually end up
    in the 'canceled' state, not the 'completed' state.

    [rfc2911] Cancel-Job says:
    Rule 1: If the implementation requires some measurable time to cancel the
    job in the 'processing' or 'processing-stopped' job states, the IPP object
    MUST add the 'processing-to-stop-point' value to the job's
    "job-state-reasons" attribute and then transition the job to the 'canceled'
    state when the processing ceases (see section 4.3.8).

    So changing the Cancel-Document operation to MUST would be consistent with
    [rfc2911] Cancel-Job.

    2. About ISSUE 03:

    Note: The queue override level is only available for Printers that support
    the 'guaranteed' value for its "pdl-override-supported" attribute (see
    [ippsave] section 8.1). All other levels are available for all Printers
    independent of the "pdl-override-supported" value. DMC ISSUE03: What about
    a Printer that had an override for "sides", but didn't override the PDL for
    everything else? They would have to report
    "pdl-override-supported"='attempted', right? So I don't think this "Note:"
    is correct.

    The [ippsave] specification says that a Printer MUST have "pdl-override" =
    'guaranteed' and a single value of "xxx-supported" in order to get the Queue
    Override semantics. So I think the note is correct. But if you are
    confused, we need to fix the note.

    3. About ISSUE 04:
    3. Job Level - page override programming - The special " overrides"
    collection Job Template attribute (see [OvrRide]) supplied at the Job Level,
    that is, in a Job Creation operation, that contains the attributes that are
    to have the page override status for the specified ranges of pages in the
    specified Document. This can be supplied by the client when submitting a
    job either in the protocol, or set either by the user or operator after the
    job has been accepted either using the Set-Job-Attributes operation, or by
    the operator using means local to the Printer. Example: " overrides" =
    {"pages" = '1:1'; "document-numbers" = '1:1'; "media" = 'letterhead'} DMC
    ISSUE04: What about "overrides" = {"pages" = '3:3'; "media" = 'letterhead'}
    at the Job level? If I read the overrides spec correctly, this means that
    page 3 of every document is supposed to be on letterhead. So what about a
    "job level" override that doesn't specify a document number, but nonetheless
    overrides the document? Can there be one of these as well as a specific
    document override at the job level?

    This is more of a comment on the Override spec. And the answer is no there
    can't be a collection value for one document and another for all documents,
    since the Override spec requires that there MUST be no overlapping
    collection values. So there can't be one collection value without any
    "document-numbers" attribute meaning applies to all documents in the Job and
    another collection value with "document-numbers" = '1:1' for just document

    4. About DMC Editorial03:
    (DMC Editorial03: Why did you delete the wording here that made a
    distinction between y=>J and y=>D? Either there needs to be wording here
    about that, or the table below needs to have the Js and Ds removed.)

    We agreed on the telecon to restore the =>D to go with the =>J notation to
    indicate the difference between copying to the Job object versus copying to
    the Document object.

    And footnote 24 needs to say 'corresponding "document-format-default"
    attribute' and 'corresponding ", rather than just saying 'corresponding
    attribute', since the names are no longer the same.

    5. About DMC ISSUE05:
    document-uri DMC ISSUE05: Why no =>D in PJ,PU column?

    Answer: Should have one for PU (Print-URI), but NOT PJ (Print-Job). So add
    ->D with a footnote to indicate that the Printer copies the "document-uri"
    to the corresponding Document Description attribute.

    6. About DMC ISSUE06:
    DMC ISSUE06: Why are we not saving the "requesting-user-name"? Is that what
    "original-requesting-user-name" is for? But the latter is part of an
    optional spec. If we don't save "requesting-user-name", how do we
    authenticate for cancel/delete? Am I missing something?

    I agree that we should change the "y" to "y=>J" in both the PJ,PU column and
    the CJ column, so that the "requesting-user-name" attribute is copied to the
    (new) corresponding Job Description attribute.

    7. Table 9, the maximum size of "request-id" and "status-code" is 16 bits,
    not 32-bits. This is the way that [rfc2910] encodes these fixed parameters.
    So don't make the change to integer(1:MAX) and type2 enum, respectively, but
    keep them as integer(1:32767) and integer(0:32767).

    8. About DMC Editorial04:
    DMC Editorial04: Need to sort the table, I believe, since in taking out the
    [job-] prefix, it is no longer sorted. Sections following need to be
    reordered as well (sections 9.1.x). I don't want to just go ahead and do
    this change as it would be very confusing in looking at the revisions.

    I agree, turn off revisions before sorting.

    9. DMC Editorial05: This table has gotten rid of [job-] indication, but
    Table 8 hasn't. Is this what we want?

    I think we want to retain the [job-] prefix in Table 8, since Table 8 is the
    operation attributes in Job and Document Creation operations, so the [job-]
    prefix is needed for Job Creation operations. But Table 11 is only for
    Document objects.

    10. About DMC ISSUE 07:
    DMC ISSUE07: I definitely believe that we need a "Document-equivalent" of
    job-collation-type. It would have different semantics, since the Job level
    semantics include the concept of documents, but I believe that since it is
    useful to know whether a Job is doing collated or uncollated copies, it
    would also be useful to know the same for Documents.

    I disagree. If we did add a Document attribute, it would need to have the
    same value as at the Job Level, since you can't collate some documents and
    not collate other documents in the same job. We don't duplicate on the
    Document object other Job level attributes that apply to the job as a whole,
    such as "job-name", "job-hold", "job-priority", "job-finishing".

    11. About DMC ISSUE 08:
    DMC ISSUE08: Wouldn't we want to make "number-of-documents" a MUST now?

    I agree, its only a SHOULD in [rfc2911] (when supporting multiple document

    12. about DMC ISSUE09:
    9.1.1 attributes-charset (charset)
    This REQUIRED Document Description attribute has the same semantics as the
    corresponding Job Description attribute (see [rfc2911] ?4.3.19) applied to
    the Document object. The Printer sets this Document Description attribute
    from the corresponding Operation attribute supplied by the client in the
    Document Creation operation (see section 4.1). DMC ISSUE09: Section 4.1
    doesn't seem to be the right section, but I'm not quite sure which section
    "the author" wanted to point them to. If this is changed, it must be
    changed in a number of places below as well.

    I think the reference is correct. The reference is to the Document Creation
    operation, Send-Document, in which the client MUST supply the
    "attributes-charset" operation attribute (as in all IPP operations). We
    might want to REQUIRE the client to supply the same value as in the Job
    Creation operation, since a Job in which some of the Document's have one
    charset and other Document's have another charset does seem problematic.

    13. about DMC ISSUE10:
    9.1.1 attributes-charset (charset) and 9.1.2 attributes-natural-language
    DMC ISSUE10: This attribute and the next are the only two (unless I'm
    mistaken) that have the same name as Job Description and as Document
    Description, AND that are copied from Operation attributes. So, for
    Print-Job, does the value get copied to the Job Description or Document
    Description attribute, or both?

    I suggest both, since Print-Job and Print-URI are both Job Creation and
    Document Creation operations. So we probably need to indicate y=>J and y=>D
    in Table 8 and add sentences in section 9.1.1 and 9.1.2 accordingly.

    14. about ISSUE11:
    9.1.21 document-number (integer(1:MAX)) DMC ISSUE11: Table above (and IANA
    section) says (0:MAX)

    Good catch! The table and the IANA sections are incorrect. I generated the
    IANA from the Table.

    15. about Editorial07:
    'completed-successfully' : The Document completed successfully. There were
    no warnings or errors in printing. This value SHOULD be supported.
    [rfc2911] ?4.3.8

    'completed-with-warnings' : The print part of the Document completed with
    warnings (whether or not there were save errors). This value SHOULD be
    supported if the implementation detects warnings. [rfc2911] ?4.3.8 DMC
    Editorial07: What are "save errors"? Why does this reason and the next
    reason use the words "The print part of" when the previous reason doesn't?

    'completed-with-errors' : The print part of the Document completed with
    errors (and possibly warnings too) (whether or not there were save errors).
    This value SHOULD be supported if the implementation detects errors.
    [rfc2911] ?4.3.8

    When saving a job, the Job is really two parts: the print part and the save
    part. With 'completed-successfully' both parts are successful. Sounds like
    this description could be improved. How about adding to
    'completed-successfully' "(or saving)" at the end of the second sentence?

    16. about Editorial08
    DMC Editorial08 for Pete: This attribute's description, as well as the next
    11 or so, have the name of the Job Description attribute added between the
    "[rfc2911]" and the "$x.x". This is not done anywhere else in this
    document, and should be gotten rid of, I believe. If it makes sense here,
    we have to look at everywhere else it might make sense.

    I agree it probably makes sense to remove the name of the attribute and just
    say "This OPTIONAL Document Description attribute ...", since the sentence
    comes right after the heading.

    17. about DMC ISSUE12:
    9.1.40 last-document (boolean)
    This OPTIONAL REQUIRED Document Description attribute indicates whether or
    not this Document is the last Document in the Job. See [rfc2911] ?4.3.12.
    The Printer sets this Document Description attribute from the corresponding
    Operation attribute supplied by the client in the Document Creation
    operation (see ?4). DMC ISSUE12: What about the case where the last
    document is empty with last-document='true'? Does the Printer have to go
    back to the previous document and change its "last-document" Description
    attribute to be 'true', even though the request said 'false'?

    I think that the Printer MUST go back to the last Document Object that it
    created and set its "last-document" Document Description attribute to
    'true', just as if the client has done a Close-Job. Since this sounds
    surprising, we need to add a MUST sentence.

    18. About DMC ISSUE13:
    9.1.41 output-device-assigned (name(127))
    This OPTIONAL Document Description attribute has the same semantics as the
    corresponding Job Description attribute (see [rfc2911] ? applied to
    the Document object. DMC ISSUE13: So even though the user cannot ask for
    different output-device's for different Documents (since
    output-device-requested is only a Job Operation/Description attribute), the
    Printer can print the Documents of the Job on different devices? To me,
    this seems to be a Job Description attribute only. Or we have to allow the
    user to ask for different devices for different Documents. And if we allow
    that, can the user ask for different devices on a page basis in "overrides"?
    Or am I missing something?

    I suppose we should be consistent here. If the Printer can divide a job
    between different output devices, then the client should be able to do so as
    well. On the other hand, the Printer MAY only divide whole jobs between
    output devices when it has multiple copies, rather than breaking up a Job
    copy across a device.

    19. About Editorial09:
    DMC Editorial09: What is this row doing here (and a few just below)?

    These rows are indicating what the member attributes are by referencing the
    list of member attributes, rather than repeating them.

    20. About DMC ISSUE14:
    DMC ISSUE14: I did not have the time nor the expertise to go through the
    above table in as much detail as I did other tables above. However, based
    on the other tables, it is likely that there are some small errors or
    omissions in this table. Someone that understands all the optional
    extensions and all the collection attributes should go through this very
    carefully before last call. BUT Would it make sense to clear out of this
    table any attributes that don't have increased semantics (I would not count
    just a "DT" in the Grp column as increased semantics, but maybe I'm wrong
    about that).

    Looks like the tables do need a through review.
    I think that we want each document attribute listed in the table.

    DMC ISSUE15: If I'm reading it right, the above table would seem to show
    some member attributes of collections as "main" attributes (e.g.
    media-color-supported) and others as member attributes (e.g. xri-uri). This
    should be made consistent, and my vote to make it consistent is to show
    member attributes as member attributes, as they are in all the other tables
    in this specification (smaller font, indented, conformance means IF
    collection attribute supported, and so on).

    I agree that member attributes need to be indented under their main
    attribute consistently and member attributes shouldn't appear as main

    So xri-authentication-supported, xri-security-supported, and
    xri-uri-scheme-supported, should be main level attributes, not indented with
    small type.

    However, for all collection attributes, except "printer-xri-supported", the
    member attributes are the same as the corresponding Job Template attribute,
    so it would be good to avoid repeating all of the member attributes
    indented. Either add one indented line for each collection attribute which
    names the corresponding collection attribute where the member attributes are
    defined, or just make a general statement in front of the table that the
    member attributes aren't listed when they are the same as the corresponding
    Job Template attributes.

    21. About DMC ISSUE16:
    10.1 document-creation-attributes-supported (1setOf type2 keyword)
    This REQUIRED Printer Description attribute lists the keyword names of the
    Document Template and Operation attributes that the Printer will accept in
    the Send-Document and Send-URI Document Creation operations. DMC ISSUE16:
    What about "document-uri"-the Printer MUST accept it in Send-URI and MUST
    NOT in Send-Document. Are there any other Document Template or Operation
    attributes that would vary between Send-Document and Send-URI?

    I agree that we need to add a sentence that indicates that 'document-uri' is
    not included in the value, since it MUST be supported for Send-URI and MUST
    NOT be supported for Send-Document operations, as you point out.

    22. About ISSUE17:
    13.1 server-error-too-many-jobs (0x050B)
    The client has attempted to create a Job using any of the Job Creation
    operations which would exceed the capacity of the Printer and/or the policy
    for this user or type of Job. The client SHOULD NOT try again later. DMC
    ISSUE17: I would have said SHOULD try again later, because resources might
    have been freed up. That is, I would have read "too many jobs" as a
    resource issue and "too many documents" as a policy issue. If we're saying
    not to try again, we should be clear that this error should only be returned
    if the problem is not expected to go away.

    Good ISSUE! It would be good to get Michael Sweet's input on this, since he
    requested these error codes.

    23. about DMC Editorial12:
            U.S. Department of Commerce, "Digital Signature Standard (DDS)",
    Federal Information Processing Standards Publication 186-1 (FIPS PUB 186-1),
    December 15, 1998. DMC Editorial12: We changed this from (DDS) to (DSS)
    above in this spec, so which is it?

    Google says its DSS.

    24. about ISSUE18:
    orientation-requested (type2 enum) [this spec] 8
    DMC ISSUE18: Ira would say the following two shouldn't have the "requested"
    as part of the names. If we change them here, we also have to change them
    in Table 14.
    orientation-requested-default (type2 enum) [this spec] 8
    orientation-requested-supported (1setOf type2 enum)

    But these are already defines as Job Template attributes in [rfc2911], so we
    shouldn't change them for Document Template attributes.

    25. About Editorial14:
    23 Appendix A: Document operations compared to Job operations DMC
    Editorial14: Do you have to say "Normative" or "Informative" in this title?

    Yes, add "(Informative)" to the title.


    -----Original Message-----
    From: Dennis Carney [mailto:dcarney@us.ibm.com]
    Sent: Monday, June 16, 2003 07:46
    To: ipp@pwg.org
    Subject: IPP> Re: SM> JobX Telecon *NEW NUMBER & PASSCODE*


    If I'm not mistaken, in the teleconference yesterday, we pretty much
    accepted Pete's proposal below without change.

    However, I realized something: the "xxx-default" names that we have
    assigned at the Job level (e.g. document-format-default) are the first case
    where a Job level attribute has the same name as a Printer level attribute.
    This would not be a problem except that we discovered the other day that
    IPP notifications have a flat name space of attributes that the client
    requests and that the Printer responds with. This is fine as long as there
    are no Printer attributes that have the same name as Job attributes. We
    are breaking that now: if the client requests the
    "document-charset-default" attribute, for example, the Printer doesn't know
    whether to return the Printer level "document-charset-default" or the Job
    level one, and the client that receives the notification doesn't know which
    is which either.

    Do we need to rethink our decision?

    An idea that I had that I never brought up because I was persuaded by the
    other participants was to create a new suffix for this type of attribute.
    For example, "-docdefault", rather than "-default". I thought this might
    not be a bad idea due to the fact that we were introducing a new concept.

    Dennis Carney
    IBM Printing Systems


                          "Zehler, Peter"

                          <PZehler@crt.xero To: "IPP Discussion
    List (E-mail)" <IPP@pwg.org>
                          x.com> cc: "PWG Semantic Model
    WG (E-mail)" <sm@pwg.org>
                          Sent by: Subject: SM> JobX Telecon



                          06/09/03 01:17 PM




    This Thursday at 1pm EDT is the Semantic Model teleconference. This week's
    teleconference will be dedicated to IPP Jobx. I will post the document
    later today. This review will prepare the document for the Face-to-Face.

    The teleconference is 2 hours long. It will be run using 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. NOTE:
    New Dial in number and passcode

    The agenda for the Semantic Model teleconference is :
    1) Discuss the remaining issue and reach consensus

    The following issue came up during the Review of the JOBX specification on
    June 4, which affects the Job Extension spec, the Document Object spec, and
    the PWG Semantic Model spec.

    For IPP there are the following Operation attributes that a client MAY
    supply in a Print-Job or Print-URI operation for specifying Document
    Attributes that do not have corresponding Description attributes defined
    until the Document Object specification:

    compression (type2 (keyword))
    document-charset (charset)
    document-digital-signature (type2 (keyword))
    document-format (mimeMediaType)
    document-format-details (1setOf (collection))
    document-format-version (text(127))
    document-message (text(MAX))
    document-name (name(MAX))
    document-natural-language (naturalLanguage)

    The preceding attributes are attributes of a Document. Therefore, unless
    the Document object is implemented, it is not possible for a client to
    completely determine what a client had submitted. As a consequence, it is
    also not possible for an application to completely archive a single
    job using the Get-Job-Attributes operation. Furthermore FSG is using these
    attributes at the Job level in its APIs. When implementing the Document
    object, these same attributes can be supplied in the Send-Document and
    Send-URI operation as well. These attribute have slightly different
    semantics at the Job level than they do at the Document level.

    A solution for IPP JOBX (whether or not implementing the Document object)
    would be to define corresponding Job Description attributes for these
    specific operation attributes with the semantics that they are the defaults
    for the all the Document objects in the Job (even single document jobs
    created with Print-Job and Print-URI). These new Job Description
    would be :
    compression-default (type2 (keyword))
    document-charset-default (charset)
    document-digital-signature-default (type2 (keyword))
    document-format-default (mimeMediaType)
    document-format-details-default (1setOf (collection))
    document-format-version-default (text(127))
    document-message-default (text(MAX))
    document-name-default (name(MAX))
    document-natural-language-default (naturalLanguage)
    These new attributes would be populated by the associated operational
    attribute if supplied.

    The file for telecon is the pdf file:
    NOTE: This file does not include the above proposal for the remaining
    However, given the time and my schedule I wanted to get something out. If
    possible I will get an update out later this week. The main issue and
    resolution proposal is explained fairly well above.



    Dial in Info:
    Phone Number:(877) 707-6056
    (Phone Number for Xerox Employees: 8*594-0077)
    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:

    Topic: PWG Semantic Model
    Date: Thursday, June 12, 2003
    Time: 10:00 am, Pacific Daylight Time (GMT -07:00, San Jose)
    Meeting number: 21366675
    Meeting password: pwg_sm1!
    Bob Taylor (HP)


                                                     Peter Zehler
                                                     Xerox Innovation Group
                                                     Voice: (585) 265-8755
                                                     FAX: (585) 422-7961
                                                     US Mail: Peter Zehler
                                                             Xerox Corp.
                                                             800 Phillips Rd.
                                                             M/S 128-25E
                                                             Webster NY,

    This archive was generated by hypermail 2b29 : Tue Jun 17 2003 - 22:33:39 EDT