🚀 go-pugleaf

Sorry, but I made a mistake in my encoding.  The identifier octet should
have been '03'H and not '23'H.  Other than that, the question should be
ok.

Regards,
Steve Case
scase@planet8.sp.unisys.com

In article <1drej9INN8t8@svcase.sp.paramax.com> scase@email.sp.paramax.com (Steve Case) writes:
>I am trying to understand the various ASN.1 encoding and I cannot seem
>to understand how the indefinite form for the length octets can possibly
>work!  To make things simple, let me give you a specific example and
>hopefully someone can clarify the situation for me.
>
>Let's assume we are encoding a bitstring value.  The particular bitstring
>to be encoded is '0900000009'H.  If I use the indefinite length format, 
>wouldn't this be encoded as follows:
>
>   BitString Length Contents
>   23        80     000900000009
>
>   EOC       Length
>   00        00
>
>
>My question, then, is when decoding this octet stream, how do you know
>that the bitstring is '0900000009'H and not '09'H or '090'H or '0900'H
>or '09000'H?  All three of these seem to be possible decodings?
>
 
First of all a correction to your 'correction posting' (second posting that
I did not include) -

No, The Bit String Identifier should be '23' (instead of '03') as mentioned in 
your posting (the first reaction is the correct reaction) :-), as opposed to 
the correction ('03') mentioned in your second posting. 

The reason is, although, 
a Bit string can be encoded in Primitive Form (identifier '03') OR 
Constructor Form (identifier '23'),
you can encode only in Constructor Form using EOC. 

If it is Primitive Form, it will be encoded as

Bit String	Length	Contents
03		06	000900000009

If it is Constructor Form, you can encode it in many ways
Two of the ways are - 

Bit String	Length 	Contents
23  		80	
			Bit String	Length	Contents
			03		06	000900000009
			EOC		Length
			00		00
OR

Bit String	Length 	Contents
23  		80	
			Bit String	Length	Contents
			03		04	00090000
			Bit String	Length	Contents
			03		03	000009
			EOC		Length
			00 		00

I think, you mixed up the encodings of the Primitive Form and Constructor
Form for the Bit String in your example - and hence the confusion.

Hope this helps.

- Ramakrishna			E-mail: rkc@maestro.bellcore.com

In article <1drej9INN8t8@svcase.sp.paramax.com>, scase@email.sp.paramax.com (Steve Case) writes:
|> I am trying to understand the various ASN.1 encoding and I cannot seem
|> to understand how the indefinite form for the length octets can possibly
|> work!  To make things simple, let me give you a specific example and
|> hopefully someone can clarify the situation for me.
|> 
|> Let's assume we are encoding a bitstring value.  The particular bitstring
|> to be encoded is '0900000009'H.  If I use the indefinite length format, 
|> wouldn't this be encoded as follows:
|> 
|>    BitString Length Contents
|>    23        80     000900000009
|> 
|>    EOC       Length
|>    00        00
|> 
|> 
|> My question, then, is when decoding this octet stream, how do you know
|> that the bitstring is '0900000009'H and not '09'H or '090'H or '0900'H
|> or '09000'H?  All three of these seem to be possible decodings?
|> 
Steve,

You cannot use indefinite form for a primitive type, e.g. BIT STRING.
Therefore, the answer is your encoding is invalid.

Tai

|> Thank you for any assistance you might be able to give me.
|> 
|> Regards,
|> Steve Case
|> scase@planet8.sp.paramax.com

-- 
______________________________________________________________________________
Tai Nguyen				Email: ...!bae.bellcore.com!tain
Bell Communication Research 		Phone: (908) 699-7934
444 Hoes Lane Room RRC 1B210
Piscataway NJ, 08854

Steve,

The variable length encoding of the basic encoding rules can only be
used for constructed types.  X.209(88) (== ISO 8825:1987) 6.3.2 reads:

    A sender shall

    a)  use the definite form if the encoding is primitive;

    b)  use either the definite form or the indefinite form, a sender's
        option, if the encoding is constructed and all immediately
        available;

    c)  use the indefinite form if the encoding is contructed and is not
        all immediately available.

Since the constructed encodings ultimately have objectes with primitive
encoding as their constituents, your problem never arises.

In your particular case, you can choose the primitive encoding:

        03 06 00 09 00 00 00 09
        -- -- -- --------------
         |  |  |              |
         |  |  |              +-- contents
         |  |  +----------------- number of residual bits in last octet
         |  +-------------------- definite form, length of content
         +----------------------- universal, primitive, bit string

or constructed:

        23 80 03 06 00 09 00 00 00 09 00 00
        -- -- ----------------------- -----
         |  |                       |     |
         |  |                       |     +-- end of contents marker
         |  |                       +-------- contents of constructed
         |  |                                 encoding (see above!)
         |  +-------------------------------- indefinite form
         +----------------------------------- universal, constructed,
                                              bit string

Hope this helps.

</Erik>
--
Erik Naggum             :  ISO  8879 SGML     :      +47 295 0313
                        :  ISO 10744 HyTime   :
<erik@naggum.no>        :  ISO 10646 UCS      :      Memento, terrigena.
<enag@ifi.uio.no>       :  ISO  9899 C        :      Memento, vita brevis.

In <1drej9INN8t8@svcase.sp.paramax.com> Steve Case writes:
>I am trying to understand the various ASN.1 encoding and I cannot seem
>to understand how the indefinite form for the length octets can possibly
>work!  To make things simple, let me give you a specific example and
>hopefully someone can clarify the situation for me.
>
>Let's assume we are encoding a bitstring value.  The particular bitstring
>to be encoded is '0900000009'H.  If I use the indefinite length format,
>wouldn't this be encoded as follows:
>
>   BitString Length Contents
>   23        80     000900000009
>
>   EOC       Length
>   00        00
>
>My question, then, is when decoding this octet stream, how do you know
>that the bitstring is '0900000009'H and not '09'H or '090'H or '0900'H
>or '09000'H?  All three of these seem to be possible decodings?
>
>Thank you for any assistance you might be able to give me.
>
>Regards,
>Steve Case
>scase@planet8.sp.paramax.com
>
Indefinite length encoding may only be used when the contents are
constructed.  Your example uses the primitive encoding form for
BIT STRING.

Mike Gering
IBM
Dept. E78, Building 673
RTP, NC 27709

In article <1drej9INN8t8@svcase.sp.paramax.com> scase@email.sp.paramax.com (Steve Case) writes:
>I am trying to understand the various ASN.1 encoding and I cannot seem
>to understand how the indefinite form for the length octets can possibly
>work!  To make things simple, let me give you a specific example and
>hopefully someone can clarify the situation for me.
>
>Let's assume we are encoding a bitstring value.  The particular bitstring
>to be encoded is '0900000009'H.  If I use the indefinite length format, 
>wouldn't this be encoded as follows:
>
>   BitString Length Contents
>   23        80     000900000009
>
>   EOC       Length
>   00        00
>
>
>My question, then, is when decoding this octet stream, how do you know
>that the bitstring is '0900000009'H and not '09'H or '090'H or '0900'H
>or '09000'H?  All three of these seem to be possible decodings?

Indefinite encodings are only legal on constructed types.  Primitive
types must always use definite length encoding.  Thus you can always
find the EOC encoding which terminates the innermost indefinite length
encoding that it terminates.  These things can be nested!!!

>Thank you for any assistance you might be able to give me.
>
>Regards,
>Steve Case
>scase@planet8.sp.paramax.com

Art