Semantic Model Mail Archive: SM> IPP/SM ISSUE 10: Name of Jo

Semantic Model Mail Archive: SM> IPP/SM ISSUE 10: Name of Jo

SM> IPP/SM ISSUE 10: Name of JobMandatoryElements

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Jan 17 2003 - 16:55:24 EST

  • Next message: Hastings, Tom N: "SM> FW: Completed JDF Color extension spec and IPP mapping specs, 17- Jan-2003, available"

    Here is ISSUE 10 to be added to the 9 ISSUE. This one affects both the IPP
    Document object spec and the PWG Semantic Model document.

    Version 0.6 of the IPP Document object specification aligns with the
    attributes of the Semantic Model version 0.18.

    The Semantic Model has the Job Description Element: JobMandatoryElements
    The values are a list of Element names of the Job Processing and Document
    Processing Elements that the submitter wants to be Mandatory, else the
    provider MUST reject the request.

    The IPP Document object spec has the "job-mandatory-attributes" (1setOf
    type2 keyword) operation attribute which the Printer copies to the
    corresponding "job-mandatory-attributes" Job Description attributes. The
    values are a list of the keyword names of the Job Template and Document
    Template attributs that the submitter wants to be Mandatory, else the
    provider MUST reject the request.

    Neither spec allows this same Element/attribute to also be a Document
    Description Element/attribute. This simplification is fine. So whatever
    Job and Document Elements/attributes are declared to be mandatory at the Job
    level must be mandatory at the Document level as well.

    A possible extension in the future might be to allow the submitted to submit
    this Element/Attribute in a Document Creation request. If that ever
    happens, we will regret that its name started with "Job"/"job-", because we
    have to invent a new name with the "Job"/"job-" prefix either removed or
    change to something else, like "Document"/"document-". Since the values are
    already contaiing both job and document attributes, I don't see any problem
    with just dropping the "Job"/"job-" prefix now. But I'm not suggesting that
    the renamed Element/attribute can be submitted at the Document level.

    A further agrument of removing the "Job"/"job-" prefix is that a closely
    relate Element/attribute: ElementFidelity/"ipp-attribute-fidelity" is also
    limited to being a Job level attribute by being a Job Description attribute
    and not a Document Description attribute. However, it too also affects both
    job and document attributes making them all mandatory.

    Comments?

    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Friday, January 17, 2003 02:46
    To: sm@pwg.org
    Subject: SM> Version 0.6 of the IPP Document object specification is
    available

    I've stored version 0.6 of the IPP Document object on the PWG server at:

    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.doc
    which are the same as:
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.doc

    The version with revision marks is available at:
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev
    .pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev
    .doc

    Version 0.6 contains the agreements reached at the last PWG face to face and
    on the SM telecons.
    Version 0.6 also aligns with version 0.18 of the PWG Sementic Model just
    posted.

    The issues will be reviewed during the PWG Semantic Model face to face
    meeting, Thursday, 23.
    Is this specification ready for Last Call?

    Here are 9 ISSUES:
    ISSUE 01: It is the [override] specification the allowed these four
    "compression", "document-format", "document-name", and
    "document-natural-language" operation attributes to be supplied in the
    Create-Job request. There needs to be a way for a client to query to see
    what was submitted. Possible solutions:
    a. OK to have the exception to the no copy down rule for these four which do
    not have any corresponding Job Description attributes to hold them?
    Otherwise, there would be no queriable record of what the client had
    supplied when the client only supplies them in the Create-Job operation.
    b. Or would it be better, simpler, and more consistent to define the four
    corresponding Job Description attributes and have the Printer just copy the
    operation attributes to them, like most other operation attributes?
    c. Or should we forget the [override] extension and go back to the RFC2911
    Create-Job definition (see [RFC2911] section 3.2.4) which does not allow
    these four operation attributes to be submitted in the Create-Job, but
    requires that the client supply them each time in each Send-Document and
    Sent-URI operation, if the client wants to submit them at all. Then the
    Printer just copies them to the corresponding Document Description
    attributes and there is no inheritance problem between the Job and Document
    level for these four attributes.

    ISSUE 02: Should we DEPRECATE the use of the "document-overrides" operation
    attribute in Send-Document and Send-URI when supporting this specification?
    Or forbid?

    ISSUE 03: Should we DEPRECATE the use of the "pages-overrides" operation
    attribute in Send-Document and Send-URI when supporting this specification?
    Or forbid?

    ISSUE 04: Is the definition of "document-format-detail" OK?

    ISSUE 05: Should we call this member attribute "os-type", instead of
    "platform", in order to agree with the PWG Printer Installation Extension
    (see draft-ietf-ipp-install-04.txt)?

    ISSUE 06: The effect of the IPP "page-overrides" Job Template attribute when
    supplied at the job level of a multi-document job depends on the value of
    the "multiple-document-handling" Job Template attribute. For the
    'single-document' and 'single-document-new-sheet' values, the pages are
    numbered as a single set from 1 to n for the job as a whole. For the
    'separate-documents-collated-copies' and
    'separate-document-uncollated-copies' values, the pages are numbered from 1
    to n for each document separately. ISSUE 06: This is a change from
    [override], OK?

    ISSUE 07: The effect of the IPP "page-ranges" Job Template attribute when
    supplied at the job level of a multi-document job depends on the value of
    the "multiple-document-handling" Job Template attribute. For the
    'single-document' and 'single-document-new-sheet' values, the pages are
    numbered as a single set from 1 to n for the job as a whole. For the
    'separate-documents-collated-copies' and
    'separate-document-uncollated-copies' values, the pages are numbered from 1
    to n for each document separately. ISSUE 07: This is a change from
    [override], OK?

     ISSUE 08: Need to add "job-password" to [prod-print2] as a Job Description
    attribute to go along with the Operation attribute with suitable security in
    Get-Job-Attributes response in order to align with the PWG Semantic Model,
    OK?

     ISSUE 09: Need to add "job-password-encryption" to [prod-print2] as a Job
    Description attribute to go along with the Operation attribute with suitable
    security in Get-Job-Attributes response in order to align with the PWG
    Semantic Model, OK?

    Version 0.6, 13 January 2003, agreements from New Orleans October PWG
    meeting and subsequent telecons:
            1. Deleted the Cancel-Current-Document and Validate-Document
    operations.
            2. Deprecated the "input-document-number" operation attribute
    from the Document Creation operations.
            3. Deleted the "document-mandatory-attributes" operation
    attribute to align with the PWG Semantic model. So both specifications have
    only the "job-mandatory-attributes" operation attribute. The client can
    only supply at the Job Level. The Document Level inherits from the Job
    Level.
            4. Increased "document-message" operation attribute length from
    127 to MAX (1023) octets.
            5. Clarified that "ipp-attribute-fidelity" and
    "job-mandatory-attributes" can only be supplied at the Job Level; the
    Document level inherits their values.
            6. Added "ipp-attribute-fidelity" and
    "job-mandatory-attributes" Job Description attributes.
            7. Added the "media-size-name" as a member attribute of
    "media-col" and as a separate Job Template attribute as used by UPnPv1 and
    UPnPv2.
            8. Added the "media-type" as a Job and Document Template
    attribute on its own as used by UPnPv1 and UPnPv2 (as well as leaving it as
    a member attribute of the "media-col" Job and Document Template attributes).
            9. Renamed "document-printer-up-time" Document Description
    attribute to simply "printer-up-time".
            10. Added the following Job Description attributes:
    "ipp-attribute-fidelity", and "job-mandatory-attributes".
            11. Removed the following Document Description attributes:
    "ipp-attribute-fidelity".
            12. Added the following Document Description attributes:
    "document-format-detail", "document-format-detected", "job-id",
    "job-printer-uri", "job-uri", "output-device-assigned".
            13. Defined all of the Document Description attributes, often with
    references to other specifications, so that they appear in the table of
    contents.

    Send comments to the mailing list.

    Thanks,
    Tom

    P.S. I'll not be attending the meeting.



    This archive was generated by hypermail 2b29 : Fri Jan 17 2003 - 16:55:31 EST