Hi,
I agree with Harry, Carl, Jay, Bill, and others.
'C' is invalid according to the IPP Model (thanks Carl).
'D' is correct and should be the only specified conformant
behavior.
Fix the spec - fix the errant implementations - stop making
special rules for responses to particular operations.
Cheers,
- Ira McDonald
-----Original Message-----
From: Harry Lewis/Boulder/IBM [mailto:harryl@us.ibm.com]
Sent: Wednesday, November 08, 2000 9:27 AM
To: Jay Martin
Cc: ipp@pwg.org
Subject: Re: IPP> Proposed Resolution to BO Issue 4: requesting
unsupported d attributes in query operations
Agree that a single "preferred" choice is best... and recommend D (as
originally intended and specified)
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"Jay Martin" <jmartin@altaworks.com>
Sent by: owner-ipp@pwg.org
11/07/2000 03:59 PM
To: ipp@pwg.org
cc:
Subject: Re: IPP> Proposed Resolution to BO Issue 4:
requesting unsupported d
attributes in query operations
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 : Wed Nov 08 2000 - 14:15:25 EST