IPP Mail Archive: Re: IPP> Proposed Resolution to BO Issue 4

IPP Mail Archive: Re: IPP> Proposed Resolution to BO Issue 4

Re: IPP> Proposed Resolution to BO Issue 4: requesting unsupported d attributes in query operations

From: Jay Martin (jmartin@altaworks.com)
Date: Tue Nov 07 2000 - 17:59:37 EST

  • Next message: Hastings, Tom N: "IPP> DRV - Client Print Support Files Internet-Draft down-loaded"

    I tend to agree with Bill Wagner on this one. Despite the
    many (confusing) choices, a single *preferred* choice would
    be the best way to cultivate broad compatible support.

            ...jay

    "Wagner,William" wrote:
    >
    > I would agree with allowing C or D, but I would still like a definite single
    > recommendation. In addition, note that C is confusing since it is an
    > exception to an absolute, unqualified requirement made earlier in the RFC.
    >
    > Bill Wagner
    >
    > -----Original Message-----
    > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    > Sent: Monday, November 06, 2000 9:07 PM
    > To: ipp@pwg.org
    > Subject: RE: IPP> Proposed Resolution to BO Issue 4: requesting
    > unsupporte d attributes in query operations
    >
    > Reminder to indicate your preferences by Tuesday, November 7.
    >
    > Harry's suggestion seems to be the most reasonable, given that the current
    > replies are in disagreement with each other:
    >
    > Namely:
    >
    > 1. don't change the standard which allows C or D
    >
    > 2. indicate in the Implementer's Guide a warning to client implementers that
    > Bake Off 3 found a number of implementations that also did A (which is not
    > in conformance with the standard).
    >
    > Tom
    >
    > -----Original Message-----
    > From: Harry Lewis/Boulder/IBM [mailto:harryl@us.ibm.com]
    > Sent: Thursday, November 02, 2000 13:25
    > To: Hastings, Tom N
    > Cc: ipp@pwg.org
    > Subject: Re: IPP> Proposed Resolution to BO Issue 4: requesting
    > unsupported attribu tes in query operations
    >
    > I do not support the proposal.
    >
    > The Model document specifies
    >
    > D) successful-ok-attribute-or-value-ignored (0x0001)/ unsupported
    >
    > We made the exception following BO-1 to also allow
    >
    > C) successful-ok-attribute-or-value-ignored (0x0001)/ no attributes
    >
    > I don't think we should loosen the specification further. I do think the
    > Implementer's guide should warn Clients of the current BO findings.
    >
    > ----------------------------------------------
    > Harry Lewis
    > IBM Printing Systems
    > ----------------------------------------------
    >
    > "Hastings, Tom N" <hastings@cp10.es.xerox.com>
    > Sent by: owner-ipp@pwg.org
    > 11/01/2000 08:16 PM
    >
    >
    > To: ipp@pwg.org
    > cc:
    > Subject: IPP> Proposed Resolution to BO Issue 4: requesting
    > unsupported attribu tes
    > in query operations
    >
    > Please indicate on the mailing list whether or not you support this
    > proposed
    > resolution to Issue 4 by Tuesday November 7. Then I will update the
    > Implementer's Guide and replace it in the IESG queue according to the IESG
    > procedures.
    >
    > At the telecon today we discussed Bake Off Issue 4:
    >
    > ISSUE BO3-4: Which status code does the Printer return for the
    > Get-Printer-Attributes, Get-Job-Attributes, and Get-Jobs operations, when
    > a
    > client submits an unsupported "requested-attributes" value? Also does the
    > Printer return the "requested-attributes" attribute with (just) the
    > unsupported values in the Unsupported Attributes Group like it MUST for
    > all
    > other attributes in this and all other operations?
    >
    > There are four combinations of status code and Unsupported Attributes
    > Group:
    >
    > A) successful-ok (0x0000)/no attributes
    > B) successful-ok (0x0000)/unsupported requested-attributes returned
    > C) successful-ok-attribute-or-value-ignored (0x0001)/ no attributes
    > D) successful-ok-attribute-or-value-ignored (0x0001)/ unsupported
    > "requested-attributes" returned
    >
    > The standard requires (C) or (D) for the Get-Xxx operations if all
    > sections
    > of the standard are read. The standard requires (D) for all other
    > attributes for the Get-Xxxx operation and for all attributes for all other
    > operations.
    >
    > All four combinations were present at the Bake Off for the Get-Xxxx
    > operations, with a majority of implementations doing (A), one doing (B),
    > and
    > some doing (C) or (D).
    >
    > Discussion:
    > We agreed that the purpose of a Bake Off isn't to change the standard to
    > agree with implementations. We also agreed that having alternatives for
    > Printers usually makes it harder for clients. We also agreed that we did
    > not want to invalidate currently conforming Printer implementations, i.e.,
    > ones that did (C) or (D).
    >
    > However, for this issue and because these are query operations, rather
    > than
    > operations that change the state of the Printer, we felt that allowing all
    > four alternatives does not make it harder for clients and does not impact
    > interoperability, because we think that most clients will:
    >
    > 1. treat the two success status codes the same for query (Get-xxx)
    > operations
    > 2. will probably ignore the Unsupported Attribute Group for query
    > operations
    > 3. will only look at the Printer or Job Attributes Group returned which
    > will
    > only contain requested attributes that are supported for query operations
    >
    > We could not even agree on which alternative to recommend for future
    > implementations and hence could not even agree on deprecating any.
    > Alternative (A) is simple, but some implementations want to handle ALL
    > attributes and operations consistently and not make an exception for the
    > Get
    > operations with the "requested-attributes" operation attribute, i.e., such
    > implementations want to do (D). At Bake Off 1, several implementations
    > found alternative (D) difficult, since they didn't have a list of
    > supported
    > attributes from which to compare the values of the "requested-attributes"
    > operation.
    >
    > Therefore, we propose to explain in the Implementer's Guide (which is in
    > the
    > IESG queue, but is not yet approved by them), that a client should handle
    > all four alternatives (which is easy as described above) and that Printers
    > may do any one of the four alternatives.
    >
    > In the future, when an updated Model and Semantics document is produced,
    > these same alternatives will be explained. However, at present there is
    > no
    > opportunity to change the current RFCs.
    >
    > Please indicate on the mailing list whether or not you support this
    > proposal
    > by Tuesday November 7, before I update the Implementer's Guide and replace
    > it in the IESG queue according to the IESG procedures.
    >
    > Thanks,
    > Tom
    >
    > P.S. the entire mail thread is attached.
    >
    > -----Original Message-----
    > From: Harry Lewis/Boulder/IBM [mailto:harryl@us.ibm.com]
    > Sent: Monday, October 30, 2000 09:47
    > To: Carl Kugler/Boulder/IBM
    > Cc: hastings@cp10.es.xerox.com; ipp@pwg.org
    > Subject: RE: IPP> IPP Bake-Off 3 issue 4
    >
    > 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
    > needed.
    >
    > 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
    > response
    > if the status code is one of the following:
    > 'successful-ok-ignored-or-substituted-attributes',
    > 'successful-ok-conflicting-attributes',
    > 'client-error-attributes-or-values-not-supported' or
    > 'client-error-conflicting-attributes'.
    > >>>>>>>>>>>>
    >
    > 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
    > currently
    > shipping three different implementations of "requested-attributes". I
    > don't consider this a good thing.
    >
    > -Carl
    >
    > "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
    > cc:
    > Subject: RE: IPP> IPP Bake-Off 3 issue 4
    >
    > I agree with Carl that the current standard only allows C and D. But
    > since
    > 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
    > results
    > (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...
    >
    > Tom
    >
    > -----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
    > unsupported
    > > "requested-attributes" value what is the return code and should an
    > > unsupported attributes group be returned containing the
    > requested-attributes
    > > attribute and the unsupported value. There are four possibilities of
    > status
    > > 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:
    > <<<<<
    > 13.1.4.12 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
    > object
    > 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
    > status
    > 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 13.1.2.2).
    > >>>>>
    > Choice D would simplify the spec, since there wouldn't need to be any
    > special exception for "requested-attributes"; it would be treated the
    > same
    > 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.
    >
    > -Carl
    >
    > > 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 : Tue Nov 07 2000 - 18:07:38 EST