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

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 a ttribute value? [URGENT email discussion needed]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Mar 17 2000 - 16:57:10 EST

  • Next message: Hastings, Tom N: "RE: IPP> MOD - New attribute metadata proposal"

    The [ipp-pro] contains the following requirement in section 3.7.1:
     

    A Printer MUST treat the reserved delimiter tags differently from reserved
    value tags so that the Printer knows that there is an entire attribute group
    that it doesn't understand as opposed to a single value that it doesn't
    understand.

    So this statement would seem to REQUIRE receivers (clients receiving
    responses and Printer receiving requests) to be able to skip over unknown
    attribute group tags (0x00 to 0x0F) until they get another attribute group
    tag. And since the value tags are defined to be in the range (0x10 to 0xFF
    - see the ABNF section 3.2). Thus [ipp-pro] supports what Michael is saying
    (below).

     

    However, [ipp-pro] section 3.10 Value Length has the following sentence:

     

    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.

     

    This statement is certainly true for the IPP/1.1 out-of-band values define
    in [ipp-mod] and [ipp-pro]. But what about future out-of-band values, such
    as the proposed 'any-value' which takes a value that indicates which
    attribute syntax?

    If we agree to allow the 'any-value' out-of-band value to have a value, then
    we would need to modify this statement in [ipp-pro] to something like the
    following:

    If a value-tag defined in this document 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.
    However, the definition of a future extension out-of-band value MAY have a
    non-zero value when there is a value to be associated with the out of band
    value tag.

     

    So were do we stand on whether or not to allow future out-of-band tags to
    have a non-zero length with a value?

     

    The ABNF in section 3.2 doesn't make any exceptions for out-of-band values.

     

    So far the 'any-value' out-of-band value is proposed to be restricted to the
    Get-Printer-Supported-Values response.

    However, the 'any-value' out-of-band value might make sense in a
    Get-Printer-Attributes response for any "xxx-supported" attribute to
    indicate that the System Administrator is suspending validation of that
    "xxx-supported" attribute and is allowing the client to supply any value of
    the indicated attribute syntax type for the corresponding "xxx" attribute in
    a Job Creation request.

    Then the 'any-value' out-of-band value would be allowed in a
    Set-Printer-Attributes request for a "xxx-supported" attribute.

     

    Comments?

    Tom

     

    -----Original Message-----
    From: Hugo Parra [mailto:HPARRA@novell.com]
    Sent: Wednesday, March 15, 2000 10:25
    To: mike@easysw.com
    Cc: hastings@cp10.es.xerox.com; rbergma@hitachi-hkis.com; ipp@pwg.org
    Subject: Re: IPP> OPS - Ok that the 'any-value' out-of-band value hasan
    attribute value? [URGENT email discussion needed]

    Thank you Michael. I had forgotten about tag ranges. Following the
    established guidelines would certainly address my concerns.
     
    -Hugo
     
    P.S. - I apologize for the HTML format of my messages. I didn't realize
    the tool I'm using is doing it without informing me. I'll look into
    disabling this *feature* in my tool.

    >>> Michael Sweet < mike@easysw.com <mailto:mike@easysw.com> > 03/15/00
    11:12AM >>>
    [Hugo - please don't post HTML messages..]

    Hugo Parra wrote:
    > ...
    > assumes it's a new attribute group. But if we allow the flexibility
    > that I think you're proposing, parsing an IPP packet becomes much
    > more complex and dangerous. When I run into an "unknown tag", am I
    > looking at ..
    > ...

    But the current specs partition the tag space clearly; all tags
    between 0x10 and 0xff are *value* tags, which means they will consist
    of:

        tag
        name-length
        [name]
        value-length
        [value]

    The tag 0x7f is used to introduce a 32-bit value tag.

    For tags below 0x10, the specs show:

        0x01 = operation group
        0x02 = job group
        0x03 = end group
        0x04 = printer group
        0x05 = unsupported group
        0x06 to 0x0f = reserved for future extension groups

    Based on this information a program can easily check for valid
    input.

        1. 0x00 is invalid
        2. 0x01, 0x02, and 0x04 to 0x0f start a group
        3. 0x03 ends the IPP data stream
        4. 0x10 to 0x7e and 0x80 to 0xff start a value
        5. "0x7f aa bb cc dd" starts a value; the actual tag number
           is in the next 4 bytes.

    Anything that doesn't follow this format can be thrown away
    immediately as a bad request/response.

    -- 
    ______________________________________________________________________
    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    <http://www.easysw.com/> 
    



    This archive was generated by hypermail 2b29 : Fri Mar 17 2000 - 17:51:16 EST