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