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 at novell.com]
Sent: Wednesday, March 15, 2000 10:25
To: mike at easysw.com
Cc: hastings at cp10.es.xerox.com; rbergma at hitachi-hkis.com; ipp at 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 at easysw.com <mailto:mike at 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 at easysw.com
Printing Software for UNIX http://www.easysw.com
<http://www.easysw.com/>