IPP> 'any' out-of-band value

IPP> 'any' out-of-band value

IPP> 'any' out-of-band value

kugler at us.ibm.com kugler at us.ibm.com
Wed Jun 28 15:51:46 EDT 2000



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





More information about the Ipp mailing list