> -----Original Message-----
> From: Alan D. Cabrera [mailto:adc@toolazydogs.com]
> Sent: Friday, April 02, 2004 9:55 AM
> To: Apache Directory Developers List
> Subject: RE: [snickers] Prefabricated tags?
> 
> 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.

Hey no problem shtuff happens.  BTW that paper by Micheal Sample the
original creator of SNACC does something similar but his mechanism is a tiny
bit different.  He made some good points about why we should stuff (wacky
encode) a tag into an int and I agree with that but a tad differently.  

> 
> -----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
> 
> 
> 
> 
>