IPP> OPS - Ok that the 'any-value' out-of-band value has an attribute value?

IPP> OPS - Ok that the 'any-value' out-of-band value has an attribute value?

IPP> OPS - Ok that the 'any-value' out-of-band value has an attribute value?

Hugo Parra HPARRA at novell.com
Thu Mar 9 12:25:05 EST 2000


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 at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/ipp/attachments/20000309/86f9bd55/attachment.html


More information about the Ipp mailing list