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