directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <...@toolazydogs.com>
Subject RE: [snickers] Prefabricated tags?
Date Fri, 02 Apr 2004 14:55:18 GMT
Alex,

Sorry about not replying to you sooner.  I had guests visiting me.

I like the idea of having static enums for the tags.  One concern that I have about how much
encoding should go into the tags, I hope that we don't assume a particular encoding.


Regards,
Alan


-----Original Message-----
From:	Alex Karasulu [mailto:aok123@bellsouth.net]
Sent:	Sun 3/28/2004 12:09 AM
To:	'Apache Directory Developers List'
Cc:	
Subject:	RE: [snickers] Prefabricated tags?
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








Mime
View raw message