Re: Conflict between RFC 8010 and RFC 8011 for unsupported / out-of-band encodings?

Chris,

> On Oct 31, 2024, at 6:20 PM, Rizzo, Christopher via ipp <[email protected]> wrote:
> 
>  RFC 8010 section 3.8: “For “out-of-band” values for the value-tag field defined in this document, such as ‘unsupported’, the “value-length” MUST be 0 and the “value” empty…”
>  RFC 8011 section 4.1.7: “In the case of an unsupported attribute name, the Printer returns the Client-supplied attribute with a substituted value of ‘unsupported’. “
>  So for example, if the attribute ‘job-account-id’ is not supported then should the encoding in unsupported attribute list be:
>  Per RFC 8010:
> value-tag = 0x10 (unsupported)
> name-length = length(‘job-account-id’) = 14
> name = ‘job-account-id’
> value-length = 0

Correct.

The two possibilities with current IPP operations are to return unsupported Client-supplied attributes with the 'unsupported' tag (value length 0) *or* unsupported Client-supplied values with their corresponding tags/lengths.

For example, if a Client submitted a Print-Job request with the "finishings" attribute set to the 'staple' and 'fold' enum values but the Printer only supports stapling, the Printer would respond with the "finishings" attribute in the unsupported attributes group with the 'fold' enum value.  However, if the Printer did not support the "finishings" attribute at all it would return the "finishings" attribute with the 'unsupported' out-of-band value tag instead.


________________________
Michael Sweet

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp