From 7d609a59278e639ef2ea6fc621b6e40aa89a4f25 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn=20Gustavsson?= Date: Thu, 27 Mar 2014 11:58:52 +0100 Subject: Bring information about tags up to date Since 1994 when the AUTOMATIC TAGS was introduced, ASN.1 users no long need to worry about tagging, and the following sentence no longer makes any sense: It is essential for all users of ASN.1 to understand all the details about tags. Therefore, remove the entire existing section of tags, and replace it with a shorter section explaining why we no longer need to know about tags. Remove all tags from the examples. --- lib/asn1/doc/src/asn1_ug.xml | 164 +++++++++++++++---------------------------- 1 file changed, 57 insertions(+), 107 deletions(-) (limited to 'lib/asn1/doc') diff --git a/lib/asn1/doc/src/asn1_ug.xml b/lib/asn1/doc/src/asn1_ug.xml index dd08eb1817..ce8da39e6d 100644 --- a/lib/asn1/doc/src/asn1_ug.xml +++ b/lib/asn1/doc/src/asn1_ug.xml @@ -391,6 +391,40 @@ File3.asn

+
+ A quick note about tags + +

Tags used to be important for all users of ASN.1, because it + was necessary to manually add tags to certain constructs in order + for the ASN.1 specification to be valid. Here is an example of + an old-style specification:

+ + 
+Tags DEFINITIONS ::=
+BEGIN
+  Afters ::= CHOICE { cheese [0] IA5String,
+                      dessert [1] IA5String }
+END
+ +

Without the tags (the numbers in square brackets) the ASN.1 + compiler would refuse to compile the file.

+ +

In 1994 the global tagging mode AUTOMATIC TAGS was introduced. + By putting AUTOMATIC TAGS in the module header, the ASN.1 compiler + will automatically add tags when needed. Here is the same + specification in AUTOMATIC TAGS mode:

+ + 
+Tags DEFINITIONS AUTOMATIC TAGS ::=
+BEGIN
+  Afters ::= CHOICE { cheese IA5String,
+                      dessert IA5String }
+END
+
+ +

Tags will not be mentioned any more in this manual.

+
+
The ASN.1 Types @@ -983,47 +1017,24 @@ SExt ::= SEQUENCE { CHOICE

The CHOICE type is a space saver and is similar to the concept of a - 'union' in the C-language. As with the previous SET-type, the - tags of all components of a CHOICE need to be distinct. If - AUTOMATIC TAGS are defined for the module (which is - preferable) the tags can be omitted completely in the ASN.1 - specification of a CHOICE. -

+ 'union' in the C language.

Assume:

+SomeModuleName DEFINITIONS AUTOMATIC TAGS ::=
+BEGIN
 T ::= CHOICE {
-        x [0] REAL,
-        y [1] INTEGER,
-        z [2] OBJECT IDENTIFIER }
-
+ x REAL, + y INTEGER, + z OBJECT IDENTIFIER } +END

It is then possible to assign values:

 TVal1 = {y,17},
 TVal2 = {z,{0,1,2}},
-

A CHOICE value is always represented as the tuple +

A CHOICE value is always represented as the tuple {ChoiceAlternative, Val} where ChoiceAlternative - is an atom denoting the selected choice - alternative. -

-

It is also allowed to have a CHOICE type tagged as follow:

-

- 
-C ::= [PRIVATE 111] CHOICE {
-        C1,
-        C2 }
-
-C1 ::= CHOICE { 
-         a [0] INTEGER,
-         b [1] BOOLEAN }
-
-C2 ::= CHOICE {
-         c [2] INTEGER,
-         d [3] OCTET STRING }
-

In this case, the top type C appears to have no tags at all in - its components, however, both C1 and C2 are also defined as - CHOICE types and they have distinct tags among themselves. - Hence, the above type C is both legal and allowed. + is an atom denoting the selected choice alternative.

@@ -1104,20 +1115,23 @@ Arr2Val = ["abc",[14,34,54],"Octets"], Where Value may be a value of yet another type T2.

For example:

+EmbeddedExample DEFINITIONS AUTOMATIC TAGS ::=
+BEGIN
 B ::= SEQUENCE {
         a Arr1,
-        b [0] T }
+        b T }
 
 Arr1 ::= SET SIZE (5) OF INTEGER (4..9) 
 
 T ::= CHOICE {
-        x [0] REAL,
-        y [1] INTEGER,
-        z [2] OBJECT IDENTIFIER }
-

The above example can be assigned like this in Erlang:

+ x REAL, + y INTEGER, + z OBJECT IDENTIFIER } + END +

The SEQUENCE b can be encoded like this in Erlang:

-V2 = #'B'{a=[4,5,6,7,8], b={x,7.77}}.
-
+1> 'EmbeddedExample':encode('B', {'B',[4,5,6,7,8],{x,"7.77"}}). +{ok,<<5,56,0,8,3,55,55,55,46,69,45,50>>}
@@ -1139,8 +1153,8 @@ V2 = #'B'{a=[4,5,6,7,8], b={x,7.77}}. Emb ::= SEQUENCE { a SEQUENCE OF OCTET STRING, b SET { - a [0] INTEGER, - b [1] INTEGER DEFAULT 66}, + a INTEGER, + b INTEGER DEFAULT 66}, c CHOICE { a INTEGER, b FooType } } @@ -1211,7 +1225,7 @@ PType{T} ::= SEQUENCE{

Types may refer to themselves. Suppose:

 Rec ::= CHOICE {
-     nothing [0] NULL,
+     nothing NULL,
      something SEQUENCE {
           a INTEGER,
           b OCTET STRING,
@@ -1243,7 +1257,7 @@ tt TT ::= {a 77,b {"kalle","kula"}}
Firstly, it could be used as the value in some DEFAULT component:

 SS ::= SET {
-    s [0] OBJECT IDENTIFIER,
+    s OBJECT IDENTIFIER,
     val TT DEFAULT tt }

It could also be used from inside an Erlang program. If the above ASN.1 code was defined in ASN.1 module Values, then the ASN.1 value @@ -1402,70 +1416,6 @@ T2 ::= General{BIT STRING}

-
- Tags -

Every built-in ASN.1 type, except CHOICE and ANY have a universal tag. - This is a unique number that clearly identifies the type.

- - It is essential for all users of ASN.1 to - understand all the details about tags.

-

Tags are implicitly encoded in the BER encoding as shown below, but - are hardly not accounted for in the PER encoding. In PER tags are - used for instance to sort the components of a SET.

-

There are four different types of tags.

- - universal - -

For types whose meaning is the same in all - applications. Such as integers, sequences and so on; that is, all the built in - types.

- - application - -

For application specific types for example, the types in - X.400 Message handling service have this sort of tag.

- - private - -

For your own private types.

- - context - -

This is used to distinguish otherwise indistinguishable - types in a specific context. For example, if we have two - components of a - CHOICE type that are both INTEGER values, there is no - way for the decoder to - decipher which component was actually chosen, since both - components will be - tagged as INTEGER. When this or similar situations occur, - one or both of the components should be given a context specific - to resolve the ambiguity.

- - -

The tag in the case of the 'Apdu' type [PRIVATE 1] is encoded to a - sequence of bytes making it possible for a - decoder to look at the (initial) bytes that arrive and determine - whether the rest of the bytes must be of the type associated - with that particular sequence of bytes. This means that each - tag must be uniquely associated with only one ASN.1 - type. -

-

Immediately following the tag is a sequence of bytes - informing the decoder of the length of the instance. This is - sometimes referred to as TLV (Tag length value) encoding. - Hence, the structure of a BER encoded series of bytes is as shown in the table below.

-

- - - Tag - Len - Value - - Structure of a BER encoded series of bytes -
-
-
Encoding Rules

When the first recommendation on ASN.1 was released 1988 it was -- cgit v1.2.3