Here is what IPP/1.0 and IPP/1.1 [ipp-pro] documents up until the March 1,
2000 version have said:
If a value-tag contains an "out-of-band" value, such as "unsupported", the
value-length MUST be 0 and the value empty - the value has no meaning when
the value-tag has an "out-of-band" value.
Here is the new paragraph in the March 1, 2000 [ipp-pro] version:
If a value-tag contains an "out-of-band" value defined in this document,
such as "unsupported", the value-length MUST be 0 and the value empty; the
value has no meaning when the value-tag has one of these "out-of-band"
values. However, the definitions of additional "out-of-band" values in
future documents are able to explicitly use the value field and have a
value-length that is non-zero, if there is a need for additional information
to be associated with the out-of-band value. Unless the definition of an
"out-of-band" value explicitly allows for a value, the value-length MUST be
0 and the value empty.
The intent of this March 1, 2000 clarification was to limit the restriction
to existing defined out-of-band values in [ipp-pro], namely, 'unsupported',
'no-value', and 'unknown', and to allow future definitions of NEW
out-of-band values to have a value if the definition needed such a value.
So the three out-of-band values defined so far in [ipp-pro] are defined to
REQUIRE 0 length, but the clarification allows us in the future, if we want
(and if it doesn't break existing clients accepting responses, or existing
servers accepting requests) to define NEW out-of-band values which do use
the length field (such as the 'any-value'). However, if this is going to
break existing clients and existing servers, then we shouldn't define new
out-of-band values with non-zero length. However, lets be clear,
implementers aren't free to add values to out-of-band values, unless the
definition of that out-of-band value allows a non-zero value field.
We have the following new out-of-band values in IPP extension documents:
'none', 'not-settable', 'delete-attribute', and 'any-value'
and [ipp-pro] reserves the 'default' out-of-band value for future
definition. O Of all these values, only the 'any-value' is proposed to have
a non-zero value field (which contains the attribute syntax code that the
'any-value' goes with). None of the other proposed out-of-band values have
a non-zero length.
If having a non-zero length for 'any-value' is a real compatibility problem
(see questions to Hugo below), then a possibility would be to define
'any-value' with a zero-length and say that the definition of the attribute
indicates what attribute syntax the 'any-value' goes with. This could be
done by changing the "Job and Printer Set Operations" document only. The
[ipp-pro] could still leave us the possibility in the future as in the March
1, 2000 text.
Comments?
Hugo,
What does your server code do if it gets an out-of-band value with a
non-zero length?
a. Reject the request with client-error-bad-request or some such code?
b. Change the length to 0 and throw away the value data?
c. return the attribute in the Unsupported Attributes Group?
What does your client code do if it gets an out-of-band value with a
non-zero length?
a. simply skip over the value field as with any other value
b. ignore the length, assume that it meant to be 0, and try to interpret
the value field as the next length field (and get terribly confused)?
c. bother the user with a message about the server returning incorrect
syntax?
NOTE: that the 'any-value' out-of-band value with a non-zero length field is
only defined so far for the new Get-Printer-Supported-Values operation.
Does limiting it to this purpose help with the backwards compatibility
problem?
However, it could be used in any "xxx-supported" attributes to indicate that
validation is not performed on that attribute (something Carl Kugler
mentioned a need for certain servers that just want to store away or forward
jobs without validating them). When used for this purpose, it might then be
used in a Set-Printer-Attributes operation to configure an "xxx-supported",
so it could go in the client to server direction. But again the
Set-Printer-Attributes is a new operation. The only problem with existing
client or server code would be a client that did a Get-Printer-Attributes
requesting "xxx-supported" where it might get back the 'any-value'
out-of-band value. But what would such a client (like yours) do?
Hopefully, not crash. If the client quietly skips over the value field as
with any other attribute value, then there shouldn't be any problem, even
with this use of 'any-value'.
But in any case, we need to be very careful not to define things that will
break existing implementations, hence this mail thread.
Comments?
Thanks,
Tom
-----Original Message-----
From: Ron Bergman [mailto:rbergma@hitachi-hkis.com]
Sent: Thursday, March 09, 2000 10:08
To: Hugo Parra
Cc: hastings@cp10.es.xerox.com; ipp@pwg.org
Subject: Re: IPP> OPS - Ok that the 'any-value' out-of-band value hasan
attribute value?
All,
In the IPP 1.1 Protocol document, the paragraph cited
by Hugo goes on to read...
"However, the definitions of additional "out-of-band"
values in future documents are able to explicitly use the value field
and have a value-length that is non-zero, if there is a need for
additional information to be associated with the out-of-band value.
Unless the definition of an "out-of-band" value explicitly allows for a
value, the value-length MUST be 0 and the value empty."
So a 1.1 implemetation must not break, but a 1.0 might.
Ron Bergman
Hitachi Koki Imaging Solutions
Hugo Parra wrote:
> All, Our current client implementation (Novell's IPP Gateway) checks
> that all "out of band" attributes have value lengths of zero. This
> code hasn't yet been officially released, so it's still possible to
> change it, if needs be. But make no mistake, allowing non-zero values
> for "out-of-band" values does break the current IPP rules. Section
> 3.10 of the "IPP/1.0: Encoding and Transport" document reads: "If a
> value-tag contains an "out-of-band" value, such as "unsupported", the
> value-length MUST be 0 and the value empty — the value has no
> meaning when the value-tag has an "out-of-band" value." -Hugo
>
> >>> "Hastings, Tom N" <hastings@cp10.es.xerox.com> 03/08/00 05:29PM
> >>>
> At the IPP telecon today we agreed to remove the final issue from the
> "Job
> and Printer Set operation" document, because we didn't see any
> problems.
> However, we also agreed that I should ask for comments regarding the
> issue
> on the DL. We assume that Printer parsers aren't checking for
> out-of-band
> values to have a zero length and rejecting requests if its is
> non-zero, at
> least for the three out-of-band values defined in IPP/1.1 [ipp-mod and
>
> ipp-pro] which are 'unknown', 'unsupported', and 'no-value'. We are
> also
> assuming that clients won't crash if they get an out-of-band value
> with a
> non-zero length in a response. Please send any objections. Silence
> will be
> assumed to be agreement.
>
> In the [ipp-pro] document, the statement that an out-of-band value
> MUST have
> a zero length, has been qualified to say for the out-of-band values
> "defined
> in this [ipp-pro] document".
>
> Therefore, we are free to define an attribute value for use with a new
>
> out-of-band value, if that provides some useful capabilities. We have
> found
> a need for being able to indicate in an "xxx-supported" attribute in a
>
> Get-Printer-Supported-Valued response, for the 'any-value' out-of band
> value
> to indicate which attribute syntax it is to apply. This 'any-value'
> could
> also be used in "xxx-supported" with Get-Printer-Attributes to
> indicate that
> the Printer will accept any value for attribute syntaxes that don't
> have a
> way to indicate any, such as 'name', 'mimeMediaType', 'uriScheme'.
>
> Here is the definition of the 'any-value' out-of-band value as it
> appears in
> the "Job and Printer Set operation" document:
>
> 8.3 'any-value' out-of-band attribute value
> The 'any-value' out-of-band attribute value MAY be used in combination
> with
> an attribute syntax to represent "any" attribute value of that
> attribute
> syntax.
> See section 4.3 in this document for an example definition of the
> usage of
> the 'any-value' out-of-band attribute value with the 'name' attribute
> syntax
> in any "xxx-supported" attribute returned in a
> Get-Printer-Supported-Values
> response.
>
> 8.3.1 Encoding of the 'any-value' out-of-band attribute value
> The encoding of the 'any-value' out-of-band attribute value is 0x17
> (see
> [ipp-pro]). This out-of-band value REQUIRES a non-zero length and an
> attribute value which identifies an attribute syntax type. The
> attribute
> value is either (1) a one-octet attribute syntax tag as defined in
> [ipp-pro]
> (value length = 1) or (2) a 0x7F code followed by a 4-octets of an
> extended
> attribute syntax type code as allocated in [ipp-pro] (value length =
> 5).
> ISSUE 01 - Ok to define the 'any-value' out-of-band value to have an
> actual
> value, consisting of the attribute syntax code?
>
This archive was generated by hypermail 2b29 : Thu Mar 09 2000 - 14:08:37 EST