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