> I have 2 questions about ASN.1/BER:
>
> -What's the exact meaning of the P/C bit? I mean, what would be the correct
> reaction to data tagged as UNIVERSAL 16 primitive (instead of complex)?
> Doesn't the type number imply primitive or complex?
Dear Mr. Sidler:
It is not as simple as saying that we can already discern whether a type
is simple or complex by the type itself, namely, that SET and SEQUENCE are
by definition complex while the other types are by definition simple.
The problem is that not all tags are UNIVERSAL. Indeed, in actual
real-world examples, most tags are context-specific, so you can't tell
just by looking at the tag which type is being represented. By way of
example, for the case
Z ::= SEQUENCE {
a [0] IMPLICIT FirstType,
b [1] IMPLICIT SecondType,
c [2] IMPLICIT ThirdType
}
which would encode as 3009800105810107820109, I can tell that the
[UNIVERSAL 16] would have the C (constructed) bit turned on since I'm
certain it is a SEQUENCE, but what about FirstType? Since it's an IMPLICIT
tag, I don't know what type it is. That is, I cannot discern the type only
by analyzing the BER; I could, of course, refer to the ASN.1 syntax to
figure it out.
And now to the original question: What's the exact meaning of the P/C bit.
When the bit is on (C) it says that the length is to be followed by
a tag and not a value field. That is, instead of TLV, it would be TLT...
For instance, we could have
Y ::= SEQUENCE {
i INTEGER,
j INTEGER,
k INTEGER }
encoded as 3009020105020107020109 (TL TLV TLV TLV), where the TLVs for
i, j, and k together form the V following the TL for Y.
Similarly
X ::= [0] INTEGER
taking the value 5 would be encoded A003020105 (TL TLV) even though an
INTEGER is but a simple type. In the above case, there are two tags, the
default [UNIVERSAL 2] and the context-specific [0]. Note how, when
encoded, the second is embedded within the first. Note how the P/C bit is
1 for the A0 tag, but 0 for the 02 tag.
> -Are there some efforts in creating rules for handling untagged data, such
> as pcap?
I don't know about pcap, but there are rules (Packed Encoding Rules) which
have no tags. I assume that until now you were referring to BER (Basic
Encoding Rules).
> Obviously, it is hard or impossible to create such rules unspeci-
> fically to the actual data.
No, it isn't. ASN.1 is not meant to be retrofitted to existing protocols.
It is meant for designing and implementing protocols. The A in ASN.1
stands for Abstract, which means that the designer creates his design
abstractly, not paying attention to how the actual data will look.
Sometimes existing designs can be retrofitted to use ASN.1. Sometimes they
can't. There is a feature of ASN.1 called ECN which was created quite a
few years ago to make it easier to retrofit non-ASN.1 standards to use
ASN.1. It is also useful when the designer wishes to tweak the existing
ASN.1 encoding rules to do things his own way. Unfortunately it is seldom
used.
Tagging is a subject which is both complex and simple. In its complexity
it can seem almost overwhelming to the beginner, but if we use PER, there
are no encoded tags at all. Even in BER, where tags must be used, it is
common nowadays to use AUTOMATIC TAGS, where the ASN.1 Compiler takes care
of the tagging for you.
If you are designing a new protocol, there is no good reason to worry
about tagging. If you are working with an ASN.1-based protocol standard,
you need to learn enough to support it. If you are trying to retrofit a
non-ASN.1 protocol to work with ASN.1, you would do well to see if it's
possible with PER rather than BER.
Let me know what you're trying to do and I'll see if I can help.
_______________________________________________
Asn1 mailing list
[email protected]
http://lists.asn1.org/mailman/listinfo/asn1
