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

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

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

Hugo Parra HPARRA at novell.com
Tue Nov 7 11:20:44 EST 2000

My vote is for allowing 'D' and 'C'.


>>> "Hastings, Tom N" <hastings at cp10.es.xerox.com> 11/06/00 07:06PM >>>
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:


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).


-----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 
        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 
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

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 
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 
other attributes in this and all other operations?

There are four combinations of status code and Unsupported Attributes 

  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 
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

All four combinations were present at the Bake Off for the Get-Xxxx
operations, with a majority of implementations doing (A), one doing (B), 
some doing (C) or (D).

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 
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)
2. will probably ignore the Unsupported Attribute Group for query 
3. will only look at the Printer or Job Attributes Group returned which 
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 
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 
attributes from which to compare the values of the "requested-attributes"

Therefore, we propose to explain in the Implementer's Guide (which is in 
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 
opportunity to change the current RFCs.

Please indicate on the mailing list whether or not you support this 
by Tuesday November 7, before I update the Implementer's Guide and replace
it in the IESG queue according to the IESG procedures.


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

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
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 at cp10.es.xerox.com> on 10/27/2000 06:36:07 PM

To:   Carl Kugler/Boulder/IBM at IBMUS, ipp at 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 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
> "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

More information about the Ipp mailing list