[IPP] Conflict between RFC 8010 and RFC 8011 for unsupported / out-of-band encodings?

[IPP] Conflict between RFC 8010 and RFC 8011 for unsupported / out-of-band encodings?

Michael Sweet msweet at msweet.org
Fri Nov 1 01:02:37 UTC 2024


Chris,

> On Oct 31, 2024, at 6:20 PM, Rizzo, Christopher via ipp <ipp at pwg.org> 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



More information about the ipp mailing list