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

Re: IPP> OPS - Ok that the 'any-value' out-of-band value hasan attribute value? [URGENT email discussion needed]

From: Hugo Parra (HPARRA@novell.com)
Date: Wed Mar 15 2000 - 13:25:03 EST

  • Next message: Manros, Carl-Uno B: "FW: IPP> I-D ACTION:draft-ietf-ipp-ldap-printer-schema-00.txt"

    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> 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
    



    This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 13:31:42 EST