Agree that a single "preferred" choice is best... and recommend D (as
originally intended and specified)
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"Jay Martin" <jmartin at altaworks.com>
Sent by: owner-ipp at pwg.org
11/07/2000 03:59 PM
To: ipp at 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 at cp10.es.xerox.com]
> Sent: Monday, November 06, 2000 9:07 PM
> To: ipp at 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 at us.ibm.com]
> Sent: Thursday, November 02, 2000 13:25
> To: Hastings, Tom N
> Cc: ipp at 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 at cp10.es.xerox.com>
> Sent by: owner-ipp at pwg.org> 11/01/2000 08:16 PM
>>> To: ipp at 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 at us.ibm.com]
> Sent: Monday, October 30, 2000 09:47
> To: Carl Kugler/Boulder/IBM
> Cc: hastings at cp10.es.xerox.com; ipp at 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 at IBMUS> Sent by: owner-ipp at pwg.org> 10/30/2000 09:44 AM
>> To: "Hastings, Tom N" <hastings at cp10.es.xerox.com>
> cc: ipp at 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 at cp10.es.xerox.com> on 10/27/2000 06:36:07 PM
>> To: Carl Kugler/Boulder/IBM at IBMUS, ipp at 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 at us.ibm.com]
> Sent: Friday, October 27, 2000 13:44
> To: ipp at pwg.org> Subject: Re: IPP> IPP Bake-Off 3 issue 4
>> "Zehler, Peter" <Peter.Zehler at 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
> >
> >