home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.protocols.iso
- Path: sparky!uunet!walter!wrench!tain
- From: tain@wrench.bae.bellcore.com (Tai Nguyen)
- Subject: Re: Question on ASN.1 Encodings
- Message-ID: <1992Nov20.165516.17360@walter.bellcore.com>
- Sender: news@walter.bellcore.com
- Nntp-Posting-Host: wrench.bae.bellcore.com
- Organization: Bell Communications Research
- References: <1drej9INN8t8@svcase.sp.paramax.com>
- Date: Fri, 20 Nov 92 16:55:16 GMT
- Lines: 40
-
- 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
-