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 at us.ibm.com]
Sent: Wednesday, October 18, 2000 17:28
To: Hugo Parra; ipp at 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 at novell.com> on 10/16/2000 09:08:19 PM
To: Carl Kugler/Boulder/IBM at 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 at 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