[snickers] Prefabricated tags?

[Alex Karasulu <ao...@bellsouth.net>]

Alan,

MessageTypeEnum values are not prefabricated tag octets!

For some time now I thought those constant values in the MessageTypeEnum
represented the prefabricated tag for the LDAP message type CHOICE.  I don't
remember how but I got them from SNACC4J for some reason. After our IM
conversation I looked at it more in depth and realized that they in fact are
not.  If you look at the values we have:

    /** Bind request protocol message type value */
    public static final int BINDREQUEST_VAL = 0x40000000 ;
    /** Bind response protocol message type value */
    public static final int BINDRESPONSE_VAL = 0x40000001 ;
    /** Unbind request protocol message type value */
    public static final int UNBINDREQUEST_VAL = 0x40000002 ;
    /** Search request protocol message type value */
    public static final int SEARCHREQUEST_VAL = 0x40000003 ;

and so on.

The byte values for the actual tags would be 0x60, 0x61, 0x62, and 0x63
respectively.  All these types are of the APPLICATION type class and are
constructed TLVs so the first three bits would always be 011.  So the
correct tags are not used in that enum but perhaps they should be.  WDYT?

Alex

RE: [snickers] Prefabricated tags?

[Alex Karasulu <ao...@bellsouth.net>]

Alan,

I've been doing some research into this by reading the original SNACC paper
by Sample and Neufeld and here is an interesting section on how to deal with
tags efficiently:


------------ from paper ------------
4.2 Tags

Snacc's tag representation was motivated by several things.

1. the tags must be easy to compare for equality in if and switch statements
to make tag-based decisions cheap.
2. a tag must be cheap to decode.
3. a tag must be cheap to encode.

The first requirement meant that tags had to be integer types (for the
switch statement). The representation of the tag within the integer was set
by the second requirement. The best way to decode cheaply is minimize the
transformation between the encoded and decoded (internal) format. So the
four (can be set-up for two) bytes of the long integer are used to hold the
encoded tag, starting with the first octet of the tag in the most
significant byte of the integer and the rest (if any) following. Any unused
(always trailing) bytes in the integer are zero. This limits the
representable tag code to less than 2^21 but for reasonable ASN.1
specifications this should not be a problem.
------------ from paper ------------

Well that's really interesting because in the tuple I have left tag id
representation limited to 21 bits since I use an int for the id field.

Now this does not shed light on the way Snacc4J uses these values below.
Because according to this the values should be:

     /** Bind request protocol message type value */
     public static final int BINDREQUEST_VAL = 0x60000000 ;
     /** Bind response protocol message type value */
     public static final int BINDRESPONSE_VAL = 0x61000000 ;
     /** Unbind request protocol message type value */
     public static final int UNBINDREQUEST_VAL = 0x62000000 ;
     /** Search request protocol message type value */
     public static final int SEARCHREQUEST_VAL = 0x63000000 ;

The first 3 bits of all tags will have 011 for APPLICATION (01) and
constructed (1) bits.  Then the other 5 bits in the first octet are
the id up to 30 or all 1's for the long form of the tag.  In this case the
tag would be a single octet but you see how it goes.

So for example a tag of 97 which uses two octets would have the following
integer value:

0x6F610000

And a tag of 300 would use three octets and would have the following integer
value:

0x6F812C00

I'm thinking we follow this standard set by Sample and Neufeld because it
works well in any language dealing with binary and switches to perform fast
operations to encode, decode and match for tags.

Furthermore these prefabricated tag values kept as primitive ints should be
used as the values of valued type safe enumerations generated for the tags
of an ASN.1 module.  Subsets of these enum values are then used to build
CHOICE type safe enumerations which chose between explicit and implicitly
tagged options.  

Alex

> -----Original Message-----
> From: Alex Karasulu [mailto:aok123@bellsouth.net]
> Sent: Saturday, March 27, 2004 11:02 PM
> To: 'Apache Directory Developers List'
> Subject: [snickers] Prefabricated tags?
> 
> Alan,
> 
> MessageTypeEnum values are not prefabricated tag octets!
> 
> For some time now I thought those constant values in the MessageTypeEnum
> represented the prefabricated tag for the LDAP message type CHOICE.  I
> don't
> remember how but I got them from SNACC4J for some reason. After our IM
> conversation I looked at it more in depth and realized that they in fact
> are
> not.  If you look at the values we have:
> 
>     /** Bind request protocol message type value */
>     public static final int BINDREQUEST_VAL = 0x40000000 ;
>     /** Bind response protocol message type value */
>     public static final int BINDRESPONSE_VAL = 0x40000001 ;
>     /** Unbind request protocol message type value */
>     public static final int UNBINDREQUEST_VAL = 0x40000002 ;
>     /** Search request protocol message type value */
>     public static final int SEARCHREQUEST_VAL = 0x40000003 ;
> 
> and so on.
> 
> The byte values for the actual tags would be 0x60, 0x61, 0x62, and 0x63
> respectively.  All these types are of the APPLICATION type class and are
> constructed TLVs so the first three bits would always be 011.  So the
> correct tags are not used in that enum but perhaps they should be.  WDYT?
> 
> Alex