True that enums are SIGNED-INTEGER 4 bytes, but so are the enums that we
assign for "operations-supported" whose values have to fit into two bytes in
the request headers, just like status codes have to fit into bytes the
response. We just require that the two high order bytes always be zero when
we assign the values.
Tom
-----Original Message-----
From: Carl Kugler/Boulder/IBM [mailto:kugler@us.ibm.com]
Sent: Wednesday, October 18, 2000 17:28
To: Hugo Parra; ipp@pwg.org
Subject: Re: IPP> NOT> "notify-status-code" is undefined
I'm all for enums, however, enum attributes are still SIGNED-INTEGER, 4
bytes.
-Carl
"Hugo Parra" <HPARRA@novell.com> on 10/16/2000 09:08:19 PM
To: Carl Kugler/Boulder/IBM@IBMUS
cc:
Subject: Re: IPP> NOT> "notify-status-code" is undefined
Their value range would suggest that "notify-status-code"s are in the same
space as the other regular IPP "status-codes". For that reason I'd suggest
that they be encoded the same way as "status-codes" i.e., with two bytes.
I'm currently using ENUM to encode them. What do others think?
-Hugo
>>> "Carl Kugler/Boulder/IBM" <kugler@us.ibm.com> 10/10/00 03:56PM >>>
ipp-not-spec-000830 fails to specify the attribute syntax for
"notify-status-code" (returned in the Subscription Attributes Groups of
responses).
It's not really obvious how to encode it, either. The operation attribute
group's "status-code" is a SIGNED-SHORT in a special location. There is no
attribute tag for a SIGNED-SHORT. "Integer" and "enum" are SIGNED-INTEGER.
I'm guessing it should be (integer(0x00000001:0x00000415))?
-Carl
This archive was generated by hypermail 2b29 : Fri Oct 20 2000 - 07:31:27 EDT