Semantic Model Mail Archive: Re: SM> 4 significant proposed

Semantic Model Mail Archive: Re: SM> 4 significant proposed

Re: SM> 4 significant proposed increases in conformance requirements for the IPP Document object spec

From: Dennis Carney (dcarney@us.ibm.com)
Date: Fri Apr 18 2003 - 16:45:20 EDT

  • Next message: Hastings, Tom N: "SM> 2 more significant proposed increases in conformance requirements for the IPP Document object spec"

    My comments below marked by <dmc> </dmc>.

    A couple overall comments:
    1) It seems like the Document object spec is becoming a grab-bag for all
    the ideas we come up with, whether they make sense as part of the Document
    object or not--the spec risks becoming a "Here's a bunch of things that we
    thought of that would make IPP cooler" spec.

    2) I don't like the argument that we should not have OPTIONAL things in the
    Document object spec. Here are some reasons:
    - Even if we did what was proposed below, there would still be many, many
    OPTIONALs in the spec. If we really believe in our argument, those should
    all be REQUIRED, right? No? Why not? Oh, so there *is* a line between
    what should be OPTIONAL and what should be REQUIRED? Well, if there *is* a
    line, that sort of invalidates our argument that there shouldn't be any
    OPTIONALs.
    - The Document object spec has become more than just an extension. I think
    it is seriously rivaling RFC2911 in term of complexity (not in pages, but
    in complexity, with all those tables for example). This is NOT a
    criticism--having a Document object is a good idea and this spec is a very
    good one. But once a spec gets as complex as this one, it is unreasonable
    to consider it as just an extension that can have the "luxury" of not
    having any OPTIONALs.

    Dennis Carney
    IBM Printing Systems

    --------------------------------------------------
    1. Change the Send-URI operation and the corresponding
    "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description
    attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed
    that a conforming implementation MAY have an empty list for the
    "reference-uri-schemes-supported" Printer Description attribute.

    Reason: PSI requires this operation (and has no OPTIONAL attributes).
    Optional operations are much less likely to get support by clients. It is
    best practice for an OPTIONAL extension specification (such as this spec)
    to
    have no OPTIONAL operations, so that user clients will receive the same
    level of service from all Printer implementations that support this
    extension.
    <dmc>
    PSI and IPP are different. Look at the PSI "Use Cases" from the Developers
    Guide--there are no "Joe is at his desk and wants to print to the printer
    down the hall" use cases. That's not the point of PSI. PSI is very
    web-oriented, and as such, it makes sense to print by reference. With IPP,
    printing by reference is really not mainline, so it should be optional.

    And what does Send-URI have to do with the document object? Ok, it is a
    way to send a document, but the Document object spec should describe the
    Document object, NOT try to redefine the way IPP works, imho.
    </dmc>

    2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED
    for a Printer to support.

    Reason: This is the Document object spec and users should be able to modify
    a Document object after the job is submitted. Optional operations are much
    less likely to get support by users clients. It is best practice for an
    OPTIONAL extension specification (such as this spec) to have no OPTIONAL
    operations, so that user clients will receive the same level of service
    from
    all Printer implementations that support this extension.
    <dmc>
    It seems to have been a long-standing tradition in IPP that the ability to
    do "Set"s is optional. I don't see why this should change now. What is so
    special about Set-Document-Attributes? Why aren't we mandating the other
    "Set" operations as well while we're at it?
    </dmc>

    3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for
    a Printer to support.

    Reason: To go along with the change in the conformance requirements for the
    Set-Document-Attributes operation. However, don't REQUIRE
    Set-Job-Attributes, since most of the interesting attributes are document
    attributes, not job attributes.
    <dmc>
    I have less problem here since we aren't going to REQUIRED, but my last
    comment is valid here as well.
    </dmc>

    4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the
    "pdl-overrides-supported" Printer Description attribute (REQUIRED in
    [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted'
    values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf
    type2 keyword) Printer Description attribute. The values indicate those
    Job
    Template and Document Template attributes for which the Printer guarrantees
    success in overriding the corresponding instruction in the PDL data. The
    values of this attribute returned in the Get-Printer-Attributes response
    MAY
    be colored by the "document-format" operation attribute supplied by the
    client in the request, if the Printer's guarrantee depends on the document
    format. A conforming Printer MAY return 'none' as the value.

    Reason: The IPPFAX needs the ability for the Printer to indicate which Job
    Template and Document Template attributes the Printer is able to guarantee
    success in overriding the PDL. Waiting for the Production Printing Set2
    [ippsave] to be updated does meet the schedule for IPPFAX which is also
    trying to go out to last call. Also this extension is analoguous to our
    addition of "job-mandatory-attributes" to give a finer granularity to
    "ipp-attribute-fidelity" (boolean) operation attribute.
    <dmc>
    The 'guaranteed' value: So you are only listing this value that already
    exists in another spec in the interest of trying to get the value to be
    "official" as quick as possible? I guess I can't argue with that, but it
    does seem a bit strange to me. I guess [ippsave] is going to be updated to
    refer to the Document object spec rather than define this new value?

    The "pdl-override-attributes-guaranteed" attribute: I agree that this was a
    shortcoming of IPP--the printer had no ability to say which attributes it
    could override and which it couldn't. I wonder about its applicability to
    the Document object, but...
    </dmc>



    This archive was generated by hypermail 2b29 : Fri Apr 18 2003 - 16:45:43 EDT