IPP Mail Archive: Re: IPP> OPS - Ok that the 'any-value' out

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

From: Hugo Parra (HPARRA@novell.com)
Date: Thu Mar 09 2000 - 12:25:05 EST

  • Next message: Ron Bergman: "Re: IPP> OPS - Ok that the 'any-value' out-of-band value hasan attribute value?"

    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 - 12:31:25 EST