Carl,
I'm interpreting your comments as WG Last Call comments on the IPP Set
Operations document.
I have several questions about the requirements for your proposal:
1. Are you looking for a way to represent that any "document-format" value
will be acceptable in a Job Creation operation for ONLY that attribute? In
other words, only the "document-formats-supported" Printer Description
attribute needs a way to indicate that any value will be acceptable.
2. For the "document-format-supported" Printer attribute, then there would
only be a single "special" value that indicates any and that no other values
would be included as well, correct?
3. Why wouldn't the Job Repository application that you indicate need the
same mechanism for any "xxx-supported" attribute?
4. Would any other "xxx-supported" attributes only need a SINGLE value and
would not need any other values as well?
So we could either take your suggestion for using 'unknown' or define a new
'any' out-of-band value, but restrict it to be the ONLY value of an
"xxx-supported" Printer attribute. The advantage of 'unknown' is that
current clients should know what that out of band value means. Because the
out-of-band value would NOT be used in combination with other values in any
"xxx-supported" attribute returned by Get-Printer-Attributes to an existing
client, there is not an interoperability problem.
The next issue that comes up is how does the Set-Printer-Attributes
operation know whether or not to accept a 'unknown' out-of-band value as a
value to be set?
The simplest solution would be for the Set spec to say that the
Set-Printer-Attributes operation MUST always accept the 'unknown' value for
an "xxx-supported" attribute, as long as it is the only value being set for
that attribute. Then the Get-Printer-Supported-Values operation would not
be affected and would NOT return 'unknown' as one of the values that can be
set.
A more complicated alternative would be to require that the 'unknown' (or
'any') value be ONE OF the values among others returned by the (new)
Get-Printer-Supported-Values operation. Then it would be clear whether a
Set-Printer-Attributes operation could set the 'unknown' value or not.
I favor the simpler alternative. I also favor overloading the 'unknown'
value as you suggest, rather than introducing a new 'any' out-of-band value
that old clients wouldn't recognize.
Comments?
Tom
-----Original Message-----
From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
Sent: Wednesday, June 28, 2000 12:52
To: ipp at pwg.org
Subject: Re: IPP> 'any' out-of-band value
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