IPP Mail Archive: RE: IPP> DOC - IPP Document Object down-lo

IPP Mail Archive: RE: IPP> DOC - IPP Document Object down-lo

RE: IPP> DOC - IPP Document Object down-loaded, version 0.3

From: Zehler, Peter (PZehler@crt.xerox.com)
Date: Tue Sep 10 2002 - 08:02:40 EDT

  • Next message: Carl: "IPP> 55th IETF WG/BOF Scheduling - Meetings scheduled"

    All,
    Comments on issues below.
    Pete

                                    Peter Zehler
                                    XEROX
                                    Xerox Architecture Center
                                    Email: PZehler@crt.xerox.com
                                    Voice: (716) 265-8755
                                    FAX: (716) 265-8871
                                    US Mail: Peter Zehler
                                                    Xerox Corp.
                                                    800 Phillips Rd.
                                                    M/S 128-30E
                                                    Webster NY, 14580-9701

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Monday, September 09, 2002 7:00 PM
    To: ipp@pwg.org
    Subject: IPP> DOC - IPP Document Object down-loaded, version 0.3

    I've down loaded the next draft of the IPP Document Object, version 0.3:

    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object-rev.pdf - 300Kb
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object-rev.doc - 1.2Mb
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object.pdf - 300Kb
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object.doc - 1.2 Mb

    <snip\>

    ISSUE 1a: Do we need formal definitions of each Operation or is the
    comparison with Job operations in Table 2 sufficient?
    <PZ> I think an encoding section should be added for the operations <\PZ>

    ISSUE 1b: Should Print-Job and Print-URI also be called Document Creation
    operations since they create one Document object? The answer probably
    depends on the answer to the following issue:
    <PZ> Yes they should</PZ>

    ISSUE 1c: We're adding a Document Attribute group (tag) to Send-Document
    and Send-URI so that a client can supply Document Template attributes. OK
    that we don't add this group to Print-Job and Print-URI? The problem with
    adding the Document Template attribute group to Print-Job and Print-URI
    requests is that there becomes two ways for a client to supply many of the
    Job Template attributes that are Document Processing attributes, such as
    "media", "number-up", etc., Those two ways in a Print-Job or Print-URI are
    (1) in the Job Template attribute group or (2) in the Document Template
    attribute group. The PWG Semantic Model is defining each Processing
    attribute to be either a Job Processing attribute or a Document Processing
    attribute, but not both, so that there will only be one way to submit each
    Processing attribute in a PrintJob operation according to whether it is
    defined to be a Job Processing Attribute or a Document Processing Attribute.
    But for backward compatibility, IPP's Job Template attributes are a mixture
    of Job and Document Processing attributes, i.e., "job-priority" and
    "job-hold-until" versus "media" and "number-up" are passed mixed together in
    the Job Template attribute group.
    <PZ> I see no problem with adding the OPTIONAL Document Attribute group to
    Print-Job and Print-URI. Clients and Printers that do not support will not
    emit or gracefully ignore the group. Clients can determine if a Printer
    supports the group by the "operations-supported" attribute or preferably by
    a new minor version number (i.e. IPP 1.2). A Client that send both groups
    to a Printer that supports them will first apply the Job Template attributes
    and then override them with any applicable Document Attributes. The same
    way it would if the job creation and document creation occurred separately.
    </PZ>

    ISSUE 1d: Agree that the Cancel-Current-Document, Delete-Document, and
    Set-Document-Attributes operations are OPTIONAL and that the
    Cancel-Document, Get-Document-Attributes, Get-Documents, and
    Validate-Document operations are REQUIRED as indicated in Table 2 when
    supporting the Document object?
    <PZ>Agree</PZ>

    ISSUE 1e: Currently the returns operation attributes are the same for Job
    Creation and Document Creation responses. Should the "document-number" be
    added as an additional OPTIONAL response attribute to the Document Creation
    responses?
    <PZ>The Printer MUST return and the Client SHOULD support </PZ>

    According to [override], the "document-overrides" (collection) attribute MAY
    be supplied by the client in a Send-Document or Send-URI request as an
    Operation attribute to apply document overrides to this and/or subsequent
    documents in the job. See the "document-overrides" Job Template attribute
    in Table 5 for the listing of the member attributes. However, with the
    introduction of the Document object, the "document-overrides" (collection)
    attribute SHOULD NOT be used (either as a Job Template attribute or an
    Operation attribute). Instead, the client simply supplies the Document
    Template attributes (see Table 5) for each Document Creation request (in a
    new Document Template attribute group) without needing a collection.
    ISSUE 02: What do we want to do with the "document-overrides" collection
    attributes when supporting the Document object, which is no longer needed as
    either a Job Template, Document Template, or operation attribute in Document
    Creation requests? Not completely true, since the "document-copies" member
    attribute of the "document-overrides" attribute allows the client to supply
    different attributes to different copies of a document. Has anyone
    implemented Document Overrides?
    <PZ>Deprecate "document-override". Recommend Printers that support the
    Document object not support "document-override". The tails case of applying
    different attributes to different copies of a document can be easily
    accomplished through submitting, or referencing, the same document more than
    once in the Job.</PZ>

    Similarly, according to [override], the "page-overrides" (collection)
    attribute MAY be supplied by the client in a Send-Document or Send-URI
    request as an Operation attribute to apply page overrides to this and/or
    subsequent documents in the job. See the "page-overrides" Job Template
    attribute in Table 5 for the listing of the member attributes. However,
    with the introduction of the Document object, the "page-overrides"
    (collection) attribute SHOULD be more simply supplied as one of the Document
    Template attributes for the document being created only.
    ISSUE 03: What do we want to do with the "page-overrides" collection
    attributes when supporting the Document object, which is still needed as a
    Job Template and Document Template attribute for overriding attributes in
    specified page ranges, but is not needed as an operation attribute on
    Document Creation requests?
    <PZ>Perhaps in deprecating PWG5100.4 we can add "page-overrides" to this
    document. In any event "page-overrides" should not be passed as operational
    attributes and only as a Job Template or Document Template attribute.</PZ>

    ISSUE 04: Is this query behavior of not appearing to copying down supplied
    Job attributes to the Document object and not bubbling up supplied Document
    attributes to the Job object OK?
    <PZ> Definitely OK </PZ>

    ISSUE 05: Should we sort the attributes ignoring the [job-]? Currently the
    "job-" is used in the sort for attributes.
    <PZ> Sort using the full name. If you plan to use the attribute aliases
    without the [job-] then the two entries should reference each other/<PZ>

    ISSUE 06: How will we register these attributes with IANA, since they will
    be registered for IPP use, with the "job-" prefix. Do we add the ones
    without "job-" as aliases to the IANA registry as is done for charset
    registrations?
    <PZ>Yes</PZ>

    ISSUE 07: Should we sort the attributes values including the [job-]?
    Currently the "job-" is ignored in the sort for attribute values.
    <PZ> Sort using the whole name</PZ>

    ISSUE 08: How will we register these attribute values with IANA, since they
    will be registered for IPP use, with the "job-" prefix. Do we add the ones
    without "job-" as aliases to the IANA registry for as is done for charset
    registrations?
    <PZ>Yes</PZ>

    ISSUE 09: What other Printer Description attributes are needed, if any?
    <PZ>"ipp-versions-supported" should have a new allowed value. When the
    Document Object gets approved the IPP version number should be bumped to
    1.2.</PZ>

    Thanks,
    Tom



    This archive was generated by hypermail 2b29 : Tue Sep 10 2002 - 08:03:22 EDT