IPP Mail Archive: RE: IPP> IPP Bake-Off 3 issue 4

IPP Mail Archive: RE: IPP> IPP Bake-Off 3 issue 4

RE: IPP> IPP Bake-Off 3 issue 4

From: Harry Lewis/Boulder/IBM (harryl@us.ibm.com)
Date: Mon Oct 30 2000 - 12:46:41 EST

  • Next message: Atsushi Uchino: "Re: IPP> IPP Bake Off 3 Issue 2"

    I agree with Carl. I don't think the goal (or result) of interop testing
    should be to loosen the spec because of diverse findings. This does not
    yield interoperability! Diverse interpretations are a sign of an area (of
    the spec) that may have been unclear, unnecessarily complex or simply not

    This is a case of mismatched redundant information. I think either ....
    a. Forcing the information to match
    b. Removing the redundancy
    ... would be helpful... but not just throwing our hands up and allowing
    any combination to be considered valid.
    Harry Lewis
    IBM Printing Systems

    Carl Kugler/Boulder/IBM@IBMUS
    Sent by: owner-ipp@pwg.org
    10/30/2000 09:44 AM

            To: "Hastings, Tom N" <hastings@cp10.es.xerox.com>
            cc: ipp@pwg.org
            Subject: RE: IPP> IPP Bake-Off 3 issue 4

    To be really anal ytical, the spec still only allows D:

    3.1.7 Unsupported Attributes
    A Printer object MUST include an Unsupported Attributes group in a
    if the status code is one of the following:
    'client-error-attributes-or-values-not-supported' or

    My opinion is that specifying four or more ways to accomplish the same
    thing just complicates matters and makes implementation more confusing.
    Back at bakeoff 1, the spec only allowed D. I admit that I was one of
    those who implemented it wrong for bakeoff 1. But when the spec was
    loosened up, I still got it wrong and ended up in camp A. IBM is
    shipping three different implementations of "requested-attributes". I
    don't consider this a good thing.


    "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 10/27/2000 06:36:07 PM

    To: Carl Kugler/Boulder/IBM@IBMUS, ipp@pwg.org
    Subject: RE: IPP> IPP Bake-Off 3 issue 4

    I agree with Carl that the current standard only allows C and D. But
    so many implementations did A and since the client gets back the supported
    attributes anyway, whether or not the unsupported requested attributes are
    returned or not seems less important to the client.

    However, I disagree with Carl that we should tighten up the standard to
    allow only D. That is the way the standard was written for the first Bake
    Off and we agreed to allow C.

    So the current standards allows C and D. Since requesting unsupported
    attributes isn't really going to cause the client to get unexpected
    (since the client will be looking at the supported returned attributes
    anyway), I favor adding A as allowed. And we may as well allow B as well.
    No matter which of the 4 ways the Printer is written, the client doesn't
    have any extra work to work with all 4 ways:

    Until we add OPTIONAL operation attributes or OPTIONAL operation attribute
    values to the Get-Printer-Attributes operation, there is not much need for
    the client to look at the Unsupported Attribute group returned by the
    Printer at all. (Currently the only other attribute that a Printer could
    return in the Unsupported Attributes Group is "document-format" with an
    unsupported document format that the client requested).

    So the client merely treats success (0) and
    Successful-attribute-or-value-ignored (1) status codes the same and then
    looks at the Printer Attributes Group returned.

    Lets here from others...


    -----Original Message-----
    From: Carl Kugler/Boulder/IBM [mailto:kugler@us.ibm.com]
    Sent: Friday, October 27, 2000 13:44
    To: ipp@pwg.org
    Subject: Re: IPP> IPP Bake-Off 3 issue 4

    "Zehler, Peter" <Peter.Zehler@u...> wrote:
    > All,
    > BO3-4: For get-printer-attributes operation submitted with an
    > "requested-attributes" value what is the return code and should an
    > unsupported attributes group be returned containing the
    > attribute and the unsupported value. There are four possibilities of
    > code and unsupported attribute:
    > A) successful-ok/no attributes
    > B) successful-ok/unsupported requested-attributes returned
    > C) Successful-attribute-or-value-ignored/ no attributes
    > D) Successful-attribute-or-value-ignored/ unsupported
    > requested-attributes returned
    > The standard currently allows A, C, D. Should the standard
    > be relaxed to include C.
    I'm not sure I follow you here!

    Looks to me like the spec currently allows only C or D:
    <<<<< client-error-attributes-or-values-not-supported (0x040B)
    For any operation where a client requests attributes (such as a Get-Jobs,
    Get-Printer-Attributes, or Get-Job-Attributes operation), if the IPP
    does not support one or more of the requested attributes, the IPP object
    simply ignores the unsupported requested attributes and processes the
    request as if they had not been supplied, rather than returning this
    code. In this case, the IPP object MUST return the
    'successful-ok-ignored-or-substituted-attributes' status code and MAY
    return the unsupported attributes as values of the "requested-attributes"
    in the Unsupported Attributes Group (see section
    Choice D would simplify the spec, since there wouldn't need to be any
    special exception for "requested-attributes"; it would be treated the
    as any other attribute. However, "requested-attributes" seems to be
    confusing to implement, since I have seen implementations all over the map
    on this. I have even seen some imaginative responses that don't fall into
    any of the above possibilities (but not at the bakeoff). Maybe we should
    settle on D, the simplest one to specify, then put a big chapter in the
    Implementer's Guide explaining the details.


    > The implementations at the Bake-Off supported were
    > A-11, B-1, C-3, D-0
    > Proposed Resolution: Allow all combinations

    This archive was generated by hypermail 2b29 : Mon Oct 30 2000 - 12:56:31 EST