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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/ipp/attachments/20000315/213fcc92/attachment-0001.html