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 - 13:04:40 EST