In today's telecon, nobody liked my proposal for an 'any' out-of-band
value. I have an alternative solution, using the existing 'unknown' OOB
value. We could amend the IIG to specify that if the Printer's
"document-format-supported" is 'unknown', this indicates that all
document-formats are acceptable.
This checking, from section 3.2.1.5, Validate the values of the REQUIRED
Operation attributes, would have to be modified:
document-format (mimeMediaType)
IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
'client-error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "document-format-supported" attribute,
REJECT/RETURN 'client-error-document-format-not-supported'
IF NOT supplied by the client, the IPP object assumes the value of the
Printer object's "document-format-default" attribute.
to :
document-format (mimeMediaType)
IF NOT a single non-empty 'mimeMediaType' value, or 'unknown',
REJECT/RETURN 'client-error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "document-format-supported" attribute,
REJECT/RETURN 'client-error-document-format-not-supported',
unless "document-format-supported:" is 'unknown'.
IF NOT supplied by the client, the IPP object assumes the value of the
Printer object's "document-format-default" attribute.
Since this proposal only changes implementation guidance, not the spec
itself, I don't think it should break any existing implementations.
-Carl
--- In ipp at egroups.com, kugler at u... wrote:
>>> At one time, I believe the Set 2 Ops proposal included an 'any'
out-of-band
> value. But I don't see it in the spec anymore. 'Anyway', I'd like to
> raise this issue again, since we have run into this problem again in
> product development.
>> The key place where we need the 'any' out-of-band value is in
> "document-format-supported". Some IPP Printers are actually proxy
gateways
> to downstream print services of some kind. It's not always possible to
> know what document-formats are supported downstream. One example comes
> from the IPP model document itself: a Printer can represent a logical
> device such as "a gateway into an online document archive or repository".
> The archive or repository may "support" any document format. But there
is
> no way to indicate this in IPP.
>> Lacking an 'any' value, the best solution (hack) we have come up with is
to
> respond with "document-format-supported" (if applicable) containing
> 'application/octet-stream' plus whatever "document-format" the client
might
> have supplied in the request. But this could be confusing to some
clients,
> and is in direct violation of the spec: "The values of all other Printer
> object attributes (including "document-format-supported") remain
invariant
> with respect to the client supplied document format..."
>> Could you discuss this in San Fran? I will try to make at least part of
> the telecon tomorrow.
>> -Carl