Merge branch 'bjorn/asn1/documentation'

* bjorn/asn1/documentation:
  Consistenly use ASN.1 instead of asn1
  Correct some spelling, grammar and punctation issues
  Correct description of the undec_rest option
  Correct description of the REAL type
  Replace "extend-ability" with "extensibility"
  Remove the section about encoding rules
  Bring information about tags up to date
  Don't waste words describing the SET type
  Correct and modernize the examples for DEFAULT
  Correct the UTF8String description and example
  Correct the PrimStrings example
  Remove all uses of the deprecated asn1{ct,rt}:{en,de}code/2 functions
  Correct and modernize the "A First Example" section
  Shorten the Introduction section, keeping only the essential details
  Fix an ampersand
  Document the asn1_OPENTYPE wrapper

2 files changed, 313 insertions, 492 deletions

diff --git a/lib/asn1/doc/src/asn1_ug.xml b/lib/asn1/doc/src/asn1_ug.xml
index ee54fdffd7..020e58c615 100644
--- a/lib/asn1/doc/src/asn1_ug.xml
+++ b/lib/asn1/doc/src/asn1_ug.xml
@@ -34,23 +34,25 @@
 
     <section>
       <title>Features</title>
-      <p>The Asn1 application provides:
-        </p>
+      <p>The Asn1 application provides:</p>
       <list type="bulleted">
         <item>An ASN.1 compiler for Erlang, which generates encode and
          decode functions to be used by Erlang programs sending and
          receiving ASN.1 specified data.</item>
         <item>Run-time functions used by the generated code.</item>
-        <item>The supported encoding rules are: 
+        <item>Support for the following encoding rules:
 	<list>
 	  <item>
 	    Basic Encoding Rules (<em>BER</em>)
 	  </item>
 	  <item>
-	    Distinguished Encoding Rules (<em>DER</em>), a specialized form of BER that is used in security-conscious applications.
+	    Distinguished Encoding Rules (<em>DER</em>), a specialized
+	    form of BER that is used in security-conscious
+	    applications.
 	  </item>
 	  <item>
-	    Packed Encoding Rules (<em>PER</em>) both the aligned and unaligned variant.
+	    Packed Encoding Rules (<em>PER</em>); both the aligned and
+	    unaligned variant.
 	  </item>
 	  </list>
 	</item>
@@ -59,71 +61,41 @@
 
     <section>
       <title>Overview</title>
-      <p>ASN.1 (Abstract Syntax Notation 1) is a formal language for describing data structures to be exchanged between distributed computer systems.
-        The purpose of ASN.1 is to have
-        a platform and programming language independent notation to express 
-	types   using a
-        standardized set of rules  for the transformation of values of
-        a defined type, into a stream of bytes. This stream of bytes
-        can then be sent on a communication channel set  up by the
-        lower layers in the stack of communication protocols e.g.
-        TCP/IP or encapsulated within UDP packets. This way, two
-        different applications written in two completely different
-        programming languages running on different computers with
-        different internal representation of data can exchange
-        instances of structured data types  (instead of exchanging
-        bytes or bits). This makes programming faster and easier since no code
-        has to be written to process  the transport format of the
-        data. 
-        </p>
-      <p>To write a network application which processes ASN.1 encoded
-        messages, it is prudent and sometimes essential to have a set
-        of off-line development tools such as an ASN.1 compiler which
-        can generate the encode and decode logic for the specific ASN.1
-        data types. It is also necessary to combine this with some
-        general language-specific runtime support for ASN.1 encoding and
-        decoding. 
-        </p>
-      <p>The ASN.1 compiler must be directed towards a target language
-        or a set  of closely related languages. This manual describes a
-        compiler which is directed towards the functional language
-        Erlang. In order to use this  compiler, familiarity with the
-        language Erlang is essential. Therefore, the runtime support for ASN.1 is
-        also closely related to the language Erlang and
-        consist of a number of functions, which the
-        compiler uses. The types in ASN.1 and how to represent
-        values of those types in Erlang are described in this manual.
-        </p>
-      <p>The following document is structured so that the first part describes 
-        how to use ASN.1 compiler, and then there are descriptions of all
-        the primitive and constructed ASN.1 types and their representation
-        in Erlang,
-        </p>
+      <p>ASN.1 (Abstract Syntax Notation One) is a formal language for
+      describing data structures to be exchanged between distributed
+      computer systems. The purpose of ASN.1 is to have a platform
+      and programming language independent notation to express types
+      using a standardized set of rules for the transformation of
+      values of a defined type into a stream of bytes. This stream of
+      bytes can then be sent on any type of communication
+      channel. This way, two applications written in different
+      programming languages running on different computers with
+      different internal representation of data can exchange instances
+      of structured data types.</p>
     </section>
 
     <section>
       <title>Prerequisites</title>
-      <p>It is assumed that the reader is familiar with the ASN.1 notation
-        as documented in the standard definition [<cite id="X.680"></cite>] which is
-        the primary text. It may also be helpful, but not necessary,
-        to read the standard definitions 
-        [<cite id="X.681"></cite>] [<cite id="X.682"></cite>]  [<cite id="X.683"></cite>]
-        [<cite id="X.690"></cite>] [<cite id="X.691"></cite>]. </p>
-      <p>A very good book explaining those reference texts is 
-        [<cite id="DUBUISSON"></cite>], free to download at 
-        <url href="http://www.oss.com/asn1/dubuisson.html">http://www.oss.com/asn1/dubuisson.html </url>.
+      <p>It is assumed that the reader is familiar with the ASN.1
+      notation as documented in the standard definition [<cite
+      id="X.680"></cite>] which is the primary text. It may also be
+      helpful, but not necessary, to read the standard definitions
+      [<cite id="X.681"></cite>] [<cite id="X.682"></cite>] [<cite
+      id="X.683"></cite>] [<cite id="X.690"></cite>] [<cite
+      id="X.691"></cite>]. </p>
+      <p>A good book explaining those reference texts is
+        [<cite id="DUBUISSON"></cite>], which is free to download at
+        <url href="http://www.oss.com/asn1/dubuisson.html">http://www.oss.com/asn1/dubuisson.html</url>.
         </p>
     </section>
 
     <section>
-      <title>Capability</title>
+      <title>Capabilities</title>
       <p>This application covers all features of ASN.1 up to the 1997
-      edition of the specification. In the 2002 edition of ASN.1 a number of
-      new features where introduced of which some are supported while
-      others are not. For example the
-      ECN (Encoding Control Notation) and XML notation are still
-      unsupported. Though, the other features of the 2002 edition are
-      fully or partly supported as shown below:</p>
+      edition of the specification. In the 2002 edition of ASN.1 a
+      number of new features were introduced.  The following features
+      of the 2002 edition are fully or partly supported as shown
+      below:</p>
       <list type="bulleted">
 	<item>
 	  <p>Decimal notation (e.g., "1.5e3") for REAL values. The
@@ -131,7 +103,7 @@
 	  supported.</p>
 	</item>
 	<item>
-	  <p>The RELATIVE-OID type for relative object identifiers are
+	  <p>The RELATIVE-OID type for relative object identifiers is
 	  fully supported.</p>
 	</item>
 	<item>
@@ -141,16 +113,16 @@
 	  constraint is not a PER-visible constraint.</p>
 	</item>
 	<item>
-	  <p>The subtype constraint by regular expressions (PATTERN) for character string types is parsed when compiling, but no further action is taken. This constraint is not a PER-visible constraint.</p>
+	  <p>The subtype constraint by regular expressions (PATTERN)
+	  for character string types is parsed when compiling, but no
+	  further action is taken. This constraint is not a
+	  PER-visible constraint.</p>
 	</item>
 	<item>
 	  <p>Multiple-line comments as in C, <c>/* ... */</c>, are
 	  supported.</p>
 	</item>
       </list>
-      <p>It should also be added here that the encoding formats
-      supported are <em>BER</em>, <em>DER</em>, <em>PER aligned
-      basic</em> variant and <em>PER unaligned basic</em> variant.</p>
     </section>
 
   </section>
@@ -162,19 +134,17 @@
       <title>A First Example</title>
       <p>The following example demonstrates the basic functionality used to run 
         the Erlang ASN.1 compiler.</p>
-      <p>First, create a file called <c>People.asn</c> containing the following:</p>
+      <p>Create a file called <c>People.asn</c> containing the following:</p>
       <pre>
-People DEFINITIONS IMPLICIT TAGS ::=
-
+People DEFINITIONS AUTOMATIC TAGS ::=
 BEGIN
-EXPORTS Person;
-
-Person ::= [PRIVATE 19] SEQUENCE {
-        name PrintableString,
-        location INTEGER {home(0),field(1),roving(2)},
-        age INTEGER OPTIONAL }
+  Person ::= SEQUENCE {
+    name PrintableString,
+    location INTEGER {home(0),field(1),roving(2)},
+    age INTEGER OPTIONAL
+  }
 END      </pre>
-      <p>This file (<c>people.asn</c>) must be compiled before it can  be 
+      <p>This file (<c>People.asn</c>) must be compiled before it can be
         used. 
         The ASN.1 compiler checks that the syntax is correct and that the 
         text represents proper ASN.1 code before generating an abstract
@@ -186,14 +156,14 @@ END      </pre>
         The following shows how the compiler
         can be called from the  Erlang shell:</p>
       <pre>
-1><input>asn1ct:compile("People", [ber]).</input>
+1><input> asn1ct:compile("People", [ber]).</input>
 ok
 2>      </pre>
 
       <p>The <c>verbose</c> option can be given to have information
       about the generated files printed:</p>
       <pre>
-2><input>asn1ct:compile("People", [ber,verbose]).</input>
+2><input> asn1ct:compile("People", [ber,verbose]).</input>
 Erlang ASN.1 compiling "People.asn" 
 --{generated,"People.asn1db"}--
 --{generated,"People.hrl"}--
@@ -201,17 +171,17 @@ Erlang ASN.1 compiling "People.asn"
 ok
 3>      </pre>
 
-      <p>The ASN.1 module People is now accepted and the abstract syntax tree
-        is saved in the <c>People.asn1db</c> file, the
-        generated Erlang code is compiled using the Erlang compiler and
-        loaded into  the Erlang runtime system. Now there is a user interface
-        for <c>encode/2</c> and <c>decode/2</c> in the module People,
-	which is invoked by:
-                <br></br>
-<c><![CDATA['People':encode(<Type name>,<Value>),]]></c>        <br></br>
-
+      <p>The ASN.1 module <c>People</c> is now accepted and the
+      abstract syntax tree is saved in the <c>People.asn1db</c> file;
+      the generated Erlang code is compiled using the Erlang compiler
+      and loaded into the Erlang run-time system. Now there is an API
+      for <c>encode/2</c> and <c>decode/2</c> in the module
+      <c>People</c>, which is invoked by: <br></br>
+      <c><![CDATA['People':encode(<Type name>, <Value>)]]></c>
+      <br></br>
         or        <br></br>
-<c><![CDATA['People':decode(<Type name>,<Value>),]]></c></p>
+<c><![CDATA['People':decode(<Type name>, <Value>)]]></c></p>
+
       <p>Assume there is a network
         application which receives instances of the  ASN.1 defined
         type Person,  modifies and sends them back again:</p>
@@ -234,8 +204,7 @@ receive
         constructed  and encoded using
         <c>'People':encode('Person',Answer)</c> which takes an
         instance of a defined ASN.1 type and transforms it to a
-        binary according to the BER or PER
-        encoding-rules. 
+        binary according to the BER or PER encoding rules.
                 <br></br>
 The encoder and the decoder can also be run from
         the shell.</p>
@@ -252,13 +221,13 @@ The encoder and the decoder can also be run from
 
     <section>
       <title>Module dependencies</title>
-      <p>It is common that asn1 modules import defined types, values and
-        other entities from another asn1 module.</p>
-      <p>Earlier versions of the asn1 compiler required that modules that
+      <p>It is common that ASN.1 modules import defined types, values and
+        other entities from another ASN.1 module.</p>
+      <p>Earlier versions of the ASN.1 compiler required that modules that
         were imported from had to be compiled before the module that
-        imported. This caused problems when asn1 modules had circular
+        imported. This caused problems when ASN.1 modules had circular
         dependencies.</p>
-      <p>Now are referenced modules parsed when the compiler finds an
+      <p>Referenced modules are now parsed when the compiler finds an
         entity that is imported. There will not be any code generated for
         the referenced module. However, the compiled module rely on
         that the referenced modules also will be compiled.</p>
@@ -310,7 +279,7 @@ erlc -o ../asnfiles -I ../asnfiles -I /usr/local/standards/asn1 Person.asn
         </item>
         <tag><c>-I IncludeDir</c></tag>
         <item>
-          <p>Where to search for <c>.asn1db</c> files and asn1
+          <p>Where to search for <c>.asn1db</c> files and ASN.1
             source specs in order to resolve references to other
             modules. This option can be repeated many times if there
             are several places to search in.  The compiler will always
@@ -322,26 +291,26 @@ erlc -o ../asnfiles -I ../asnfiles -I /usr/local/standards/asn1 Person.asn
         </item>
         <tag><c>+asn1config</c></tag>
         <item>
-          <p>This functionality works together with the flags
-            <c>ber</c>. It enables the
+          <p>This functionality works together with the
+            <c>ber</c> option. It enables the
             specialized decodes, see the <seealso marker="asn1_spec">Specialized Decode</seealso> chapter.
             </p>
         </item>
         <tag><c>+undec_rest</c></tag>
         <item>
-          <p>A buffer that holds a message, being decoded may
-            also have some following bytes. Now it is possible to get
-            those following bytes returned together with the decoded
-            value. If an asn1 spec is compiled with this option a tuple
-            <c>{ok,Value,Rest}</c> is returned. <c>Rest</c> may be a
-            list or a binary. Earlier versions of the compiler ignored
-            those following bytes.</p>
+          <p>A buffer that holds a message being decoded may also have
+          trailing bytes. If those trailing bytes are important they
+          can be returned along with the decoded value by compiling
+          the ASN.1 specification with the <c>+undec_rest</c> option.
+          The return value from the decoder will be
+          <c>{ok,Value,Rest}</c> where <c>Rest</c> is a binary
+          containing the trailing bytes.</p>
         </item>
         <tag><c>+'Any Erlc Option'</c></tag>
         <item>
           <p>You may add any option to the Erlang compiler when
             compiling the generated Erlang files. Any option
-            unrecognised by the asn1 compiler will be passed to the
+            unrecognized by the ASN.1 compiler will be passed to the
             Erlang compiler.</p>
         </item>
       </taglist>
@@ -366,10 +335,6 @@ asn1ct:compile("H323-MESSAGES.asn1",[ber]).      </pre>
 asn1ct:compile("H323-MESSAGES.asn1",[per]).      </pre>
       <p>The generic encode and decode functions can be invoked like this:</p>
       <pre>
-asn1ct:encode('H323-MESSAGES','SomeChoiceType',{call,"octetstring"}).
-asn1ct:decode('H323-MESSAGES','SomeChoiceType',Bytes).      </pre>
-      <p>Or, preferable like:</p>
-      <pre>
 'H323-MESSAGES':encode('SomeChoiceType',{call,"octetstring"}).
 'H323-MESSAGES':decode('SomeChoiceType',Bytes).      </pre>
     </section>
@@ -389,7 +354,7 @@ asn1ct:decode('H323-MESSAGES','SomeChoiceType',Bytes).      </pre>
         compile time appear on the screen together with
         a line number indicating where in the source file the error 
         was detected. If no errors are found, an Erlang ASN.1 module will
-        be created as default.</p>
+        be created.</p>
       <p>The run-time encoders and decoders execute within a catch and
       returns <c>{ok, Data}</c> or
         <c>{error, {asn1, Description}}</c> where
@@ -400,18 +365,18 @@ asn1ct:decode('H323-MESSAGES','SomeChoiceType',Bytes).      </pre>
 
   <section>
     <marker id="inlineExamples"></marker>
-    <title>Multi File Compilation</title>
-    <p>There are various reasons for using a multi file compilation:</p>
+    <title>Multi-file Compilation</title>
+    <p>There are various reasons for using multi-file compilation:</p>
     <list type="bulleted">
-      <item>You want to choose name for the generated module by
-       any reason. Maybe you need to compile the same specs for
-       different encoding/decoding standards.</item>
+      <item>You want to choose the name for the generated module,
+      perhaps because you need to compile the same specs for
+      different encoding rules.</item>
       <item>You want only one resulting module.</item>
     </list>
-    <p>You need to specify which asn1 specs you will
+    <p>You need to specify which ASN.1 specs you will
       compile in a module that must have the extension
       <c>.set.asn</c>. You chose name of the module and provide the
-      names of the asn1 specs. For instance, if you have the specs
+      names of the ASN.1 specs. For instance, if you have the specs
       <c>File1.asn</c>, <c>File2.asn</c> and <c>File3.asn</c> your
       module <c>MyModule.set.asn</c> will look like:</p>
     <pre>
@@ -422,11 +387,45 @@ File3.asn    </pre>
     <code type="none">
 ~> erlc MyModule.set.asn    </code>
     <p>the result will be one merged module <c>MyModule.erl</c> with
-      the generated code from the three asn1 specs.
+      the generated code from the three ASN.1 specs.
       </p>
   </section>
 
   <section>
+    <title>A quick note about tags</title>
+
+    <p>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:</p>
+
+    <pre>
+Tags DEFINITIONS ::=
+BEGIN
+  Afters ::= CHOICE { cheese [0] IA5String,
+                      dessert [1] IA5String }
+END </pre>
+
+    <p>Without the tags (the numbers in square brackets) the ASN.1
+    compiler would refuse to compile the file.</p>
+
+    <p>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:</p>
+
+    <pre>
+Tags DEFINITIONS AUTOMATIC TAGS ::=
+BEGIN
+  Afters ::= CHOICE { cheese IA5String,
+                      dessert IA5String }
+END
+</pre>
+
+    <p>Tags will not be mentioned any more in this manual.</p>
+  </section>
+
+  <section>
     <marker id="ASN1Types"></marker>
     <title>The ASN.1 Types</title>
     <p>This section describes the ASN.1 types including their
@@ -497,7 +496,7 @@ Operational ::= BOOLEAN --ASN.1 definition    </pre>
     <p>In Erlang code it may look like:</p>
     <pre>
 Val = true,
-{ok,Bytes}=asn1rt:encode(MyModule,'Operational',Val),    </pre>
+{ok,Bytes} = MyModule:encode('Operational', Val),    </pre>
     <p>Below follows a description of how
       values of each type can be represented in Erlang. 
       </p>
@@ -563,20 +562,18 @@ T6value3 = white
     <section>
       <marker id="REAL"></marker>
       <title>REAL</title>
-      <p>In this version reals are not implemented. When they are, 
-        the following
-        ASN.1 type is used:</p>
+      <p>The following ASN.1 type is used for real numbers:</p>
       <pre>
 R1 ::= REAL
       </pre>
-      <p>Can be assigned a value in Erlang as:</p>
+      <p>It can be assigned a value in Erlang as:</p>
       <pre>
-R1value1 = 2.14,
+R1value1 = "2.14",
 R1value2 = {256,10,-2},
       </pre>
       <p>In the last line note that the tuple {256,10,-2} is the real number
         2.56 in a special notation, which will encode faster than simply 
-        stating the number as 2.56. The arity three tuple is 
+        stating the number as <c>"2.56"</c>. The arity three tuple is
         <c>{Mantissa,Base,Exponent}</c> i.e. Mantissa * Base^Exponent.</p>
     </section>
 
@@ -736,13 +733,11 @@ O2Val = &lt;&lt;"must be exactly 28 chars...."&gt;&gt;,</pre>
         specified for a type are especially important for PER, where
         they affect the encoding.
         </p>
-      <p>Please note that <em>all</em> the Character strings are 
-        supported and it is possible to use the following ASN.1 type 
-        definitions:</p>
+      <p>Here are some examples:</p>
       <pre>
 Digs ::= NumericString (SIZE(1..3))
 TextFile ::= IA5String (SIZE(0..64000))      </pre>
-      <p>and the following Erlang assignments:</p>
+      <p>with corresponding Erlang assignments:</p>
       <pre>
 DigsVal1 = "456",
 DigsVal2 = "123",
@@ -755,70 +750,86 @@ TextFileVal2 = [88,76,55,44,99,121 .......... a lot of characters here ....]
         characters are all represented by quadruples beginning with
         three zeros like {0,0,0,65} for the 'A' character. When
         decoding a value for these strings the result is a list of
-        quadruples, or integers when the value is an ASCII character.
-        The following example shows how it works:</p>
-      <p>In a file <c>PrimStrings.asn1</c> the type <c>BMP</c> is defined as
-                <br></br>
-<c>BMP ::= BMPString</c> then using BER encoding (<c>ber</c>
-        option)the input/output format will be:</p>
+        quadruples, or integers when the value is an ASCII character.</p>
+
+        <p>The following example shows how it works. We have the following
+	specification in the file <c>PrimStrings.asn1</c>.</p>
+       <pre>
+PrimStrings DEFINITIONS AUTOMATIC TAGS ::=
+BEGIN
+   BMP ::= BMPString
+END
+       </pre>
+
+       <p>Encoding and decoding some strings:</p>
+
       <pre>
-1> <input>{ok,Bytes1} = asn1rt:encode('PrimStrings','BMP',[{0,0,53,53},{0,0,45,56}]).</input>
-{ok,[30,4,"55-8"]}
-2> <input>asn1rt:decode('PrimStrings','BMP',list_to_binary(Bytes1)).</input>
+1> <input>asn1ct:compile('PrimStrings', [ber]).</input>
+ok
+2> <input>{ok,Bytes1} = 'PrimStrings':encode('BMP', [{0,0,53,53},{0,0,45,56}]).</input>
+{ok,&lt;&lt;30,4,53,54,45,56>>}
+3> <input>'PrimStrings':decode('BMP', Bytes1).</input>
 {ok,[{0,0,53,53},{0,0,45,56}]}
-3> <input>{ok,Bytes2} = asn1rt:encode('PrimStrings','BMP',[{0,0,53,53},{0,0,0,65}]).</input>
-{ok,[30,4,[53,53,0,65]]}
-4> <input>asn1rt:decode('PrimStrings','BMP',list_to_binary(Bytes2)).</input>
+4> <input>{ok,Bytes2} = 'PrimStrings':encode('BMP', [{0,0,53,53},{0,0,0,65}]).</input>
+{ok,&lt;&lt;30,4,53,53,0,65>>}
+5> <input>'PrimStrings':decode('BMP', Bytes2).</input>
 {ok,[{0,0,53,53},65]}
-5> <input>{ok,Bytes3} = asn1rt:encode('PrimStrings','BMP',"BMP string").</input>
-{ok,[30,20,[0,66,0,77,0,80,0,32,0,115,0,116,0,114,0,105,0,110,0,103]]}
-6> <input>asn1rt:decode('PrimStrings','BMP',list_to_binary(Bytes3)).</input>
+6> <input>{ok,Bytes3} = 'PrimStrings':encode('BMP', "BMP string").</input>
+{ok,&lt;&lt;30,20,0,66,0,77,0,80,0,32,0,115,0,116,0,114,0,105,0,110,0,103>>}
+7> <input>'PrimStrings':decode('BMP', Bytes3).</input>
 {ok,"BMP string"}      </pre>
-      <p>The UTF8String is represented in Erlang as a list of integers,
-        where each integer represents the unicode value of one
-        character. When a value shall be encoded one first has to
-        transform it to a UTF8 encoded binary, then it can be encoded by
-        asn1. When decoding the result is a UTF8 encoded binary, which
-        may be transformed to an integer list. The transformation
-        functions, <c>utf8_binary_to_list</c> and
-        <c>utf8_list_to_binary</c>, are in the <c>asn1rt</c> module. In
-        the example below we assume an asn1 definition <c>UTF ::= UTF8String</c> in a module <c>UTF.asn</c>:</p>
+
+      <p>The UTF8String type is represented as a UTF-8 encoded binary in
+      Erlang. Such binaries can be created directly using the binary syntax
+      or by converting from a list of Unicode code points using the
+      <c>unicode:characters_to_binary/1</c> function.</p>
+
+      <p>Here are some examples showing how UTF-8 encoded binaries can
+      be created and manipulated:</p>
+
+      <pre>
+1> <input>Gs = "Мой маленький Гном".</input>
+[1052,1086,1081,32,1084,1072,1083,1077,1085,1100,1082,1080,
+ 1081,32,1043,1085,1086,1084]
+2> <input>Gbin = unicode:characters_to_binary(Gs).</input>
+&lt;&lt;208,156,208,190,208,185,32,208,188,208,176,208,187,208,
+  181,208,189,209,140,208,186,208,184,208,185,32,208,147,
+  208,...>>
+3> <input>Gbin = &lt;&lt;"Мой маленький Гном"/utf8>>.</input>
+&lt;&lt;208,156,208,190,208,185,32,208,188,208,176,208,187,208,
+  181,208,189,209,140,208,186,208,184,208,185,32,208,147,
+  208,...>>
+4> <input>Gs = unicode:characters_to_list(Gbin).</input>
+[1052,1086,1081,32,1084,1072,1083,1077,1085,1100,1082,1080,
+ 1081,32,1043,1085,1086,1084]
+      </pre>
+
+      <p>See the <seealso marker="stdlib:unicode">unicode</seealso> module
+      for more details.</p>
+
+      <p>In the following example we will use this ASN.1 specification:</p>
       <pre>
-1> <input>asn1ct:compile('UTF',[ber]).</input>
-Erlang ASN.1 version "1.4.3.3" compiling "UTF.asn" 
-Compiler Options: [ber]
---{generated,"UTF.asn1db"}--
---{generated,"UTF.erl"}--
+UTF DEFINITIONS AUTOMATIC TAGS ::=
+BEGIN
+   UTF ::= UTF8String
+END
+      </pre>
+
+      <p>Encoding and decoding a string with Unicode characters:</p>
+
+      <pre>
+5> <input>asn1ct:compile('UTF', [ber]).</input>
+ok
+6> <input>{ok,Bytes1} = 'UTF':encode('UTF', &lt;&lt;"Гном"/utf8>>).</input>
+{ok,&lt;&lt;12,8,208,147,208,189,208,190,208,188>>}
+7> <input>{ok,Bin1} = 'UTF':decode('UTF', Bytes1).</input>
+{ok,&lt;&lt;208,147,208,189,208,190,208,188>>}
+8> <input>io:format("~ts\n", [Bin1]).</input>
+Гном
 ok
-2> <input>UTF8Val1 = "hello".</input>
-"hello"
-3> <input>{ok,UTF8bin1} = asn1rt:utf8_list_to_binary(UTF8Val1).</input>
-{ok,&lt;&lt;104,101,108,108,111&gt;&gt;}
-4> <input>{ok,B}='UTF':encode('UTF',UTF8bin1).</input>
-{ok,[12,
-     5,
-     &lt;&lt;104,101,108,108,111&gt;&gt;]}
-5> <input>Bin = list_to_binary(B).</input>
-&lt;&lt;12,5,104,101,108,108,111&gt;&gt;
-6> <input>{ok,UTF8bin1}='UTF':decode('UTF',Bin).</input>
-{ok,&lt;&lt;104,101,108,108,111&gt;&gt;}
-7> <input>asn1rt:utf8_binary_to_list(UTF8bin1).</input>
-{ok,"hello"}           
-8> <input>UTF8Val2 = [16#00,16#100,16#ffff,16#ffffff].</input>
-[0,256,65535,16777215]
-9> <input>{ok,UTF8bin2} = asn1rt:utf8_list_to_binary(UTF8Val2).</input>
-{ok,&lt;&lt;0,196,128,239,191,191,248,191,191,191,191&gt;&gt;}
-10> <input>{ok,B2} = 'UTF':encode('UTF',UTF8bin2).</input>
-{ok,[12,
-     11,
-     &lt;&lt;0,196,128,239,191,191,248,191,191,191,191&gt;&gt;]}
-11> <input>Bin2 = list_to_binary(B2).</input>
-&lt;&lt;12,11,0,196,128,239,191,191,248,191,191,191,191&gt;&gt;
-12> <input>{ok,UTF8bin2} = 'UTF':decode('UTF',Bin2).</input>
-{ok,&lt;&lt;0,196,128,239,191,191,248,191,191,191,191&gt;&gt;}
-13> <input>asn1rt:utf8_binary_to_list(UTF8bin2).</input>
-{ok,[0,256,65535,16777215]}
-14>       </pre>
+9> <input>unicode:characters_to_list(Bin1).</input>
+[1043,1085,1086,1084]
+      </pre>
     </section>
 
     <section>
@@ -853,9 +864,11 @@ OidVal1 = {1,2,55},
     <section>
       <marker id="Object Descriptor"></marker>
       <title>Object Descriptor</title>
-      <p>Values of this type can be assigned a value as an ordinary string i.e.        <br></br>
+      <p>Values of this type can be assigned a value as an ordinary string
+      like this:</p>
 
-        "This is the value of an Object descriptor"</p>
+      <pre>
+      "This is the value of an Object descriptor"</pre>
     </section>
 
     <section>
@@ -898,19 +911,31 @@ Pdu ::= SEQUENCE {
       <pre>
 MyPdu = #'Pdu'{a=22,b=77.99,c={0,1,2,3,4},d='NULL'}.      </pre>
       <p>The decode functions will return a record as result when decoding 
-        a <c>SEQUENCE</c> or a <c>SET</c>.
-                <marker id="DEFAULT"></marker>
-</p>
-      <p>A <c>SEQUENCE</c> and a <c>SET</c> may contain a component with a
-        <c>DEFAULT</c> key word followed by the actual value that is the
-        default value. In case of BER encoding it is optional to encode the
-        value if it equals the default value. If the application uses the
-        atom asn1_DEFAULT as value or if the value is a primitive value 
-        that equals the default value the encoding omits the bytes for
-        this value, which is more efficient and it results in fever 
-        bytes to send to the receiving application.</p>
-      <p>For instance, if the following types exists in a file "File.asn":</p>
+      a <c>SEQUENCE</c> or a <c>SET</c>.</p>
+
+      <p>A <c>SEQUENCE</c> and a <c>SET</c> may contain a component
+      with a <c>DEFAULT</c> key word followed by the actual value that
+      is the default value. The <c>DEFAULT</c> keyword means that the
+      application doing the encoding can omit encoding of the value,
+      thus resulting in fewer bytes to send to the receiving
+      application.</p>
+
+      <p>An application can use the atom <c>asn1_DEFAULT</c> to indicate
+      that the encoding should be omitted for that position in
+      the SEQUENCE.</p>
+
+      <p>Depending on the encoding rules, the encoder may also compare
+      the given value to the default value and automatically omit the
+      encoding if they are equal. How much effort the encoder makes to
+      to compare the values depends on the encoding rules. The DER
+      encoding rules forbids encoding a value equal to the default value,
+      so it has a more thorough and time-consuming comparison than the
+      encoders for the other encoding rules.</p>
+
+      <p>In the following example we will use this ASN.1 specification:</p>
       <pre>
+File DEFINITIONS AUTOMATIC TAGS ::=
+BEGIN
 Seq1 ::= SEQUENCE {
     a INTEGER DEFAULT 1,
     b Seq2 DEFAULT {aa TRUE, bb 15}
@@ -920,131 +945,50 @@ Seq2 ::= SEQUENCE {
     aa BOOLEAN,
     bb INTEGER
 }
-      </pre>
-      <p>Some values and the corresponding encoding in an Erlang terminal
-        is shown below:</p>
+
+Seq3 ::= SEQUENCE {
+    bs BIT STRING {a(0), b(1), c(2)} DEFAULT {a, c}
+}
+END </pre>
+      <p>Here is an example where the BER encoder is able to omit encoding
+      of the default values:</p>
       <pre>
-1> <input>asn1ct:compile('File').</input>
-Erlang ASN.1 version "1.3.2" compiling "File.asn1" 
-Compiler Options: []
---{generated,"File.asn1db"}--
---{generated,"File.hrl"}--
---{generated,"File.erl"}--
+1> <input>asn1ct:compile('File', [ber]).</input>
 ok
-2> <input>'File':encode('Seq1',{'Seq1',asn1_DEFAULT,asn1_DEFAULT}).</input>
-{ok,["0",[0],[[],[]]]}
-3> <input>lists:flatten(["0",[0],[[],[]]]).</input>
-[48,0]
-4> <input>'File':encode('Seq1',{'Seq1',1,{'Seq2',true,15}}).</input>
-{ok,["0","\\b",[[],["\\241",[6],[[[128],[1],"\\377"],[[129],[1],[15]]]]]]}
-5> <input>lists:flatten(["0","\\b",[[],["\\241",[6],[[[128],[1],"\\377"],[[129],[1],[15]]]]]]).</input>
-[48,8,161,6,128,1,255,129,1,15]
-6>      </pre>
-      <p>The result after command line 3, in the example above,shows that the
-        encoder omits the encoding of default values when they are specific 
-        by asn1_DEFAULT. Line 5 shows that even primitive values that equals
-        the default value are detected and not encoded. But the constructed
-        value of component <c>b</c> in <c>Seq1</c> is not recognized as the
-        default value. Checking of default values in <c>BER</c> is not done
-        in case of complex values, because it would be to expensive.
-                <marker id="DEFAULT DER"></marker>
-</p>
-      <p>But, the DER encoding format has stronger requirements regarding 
-        default values both for SET and SEQUENCE. A more elaborate and time 
-        expensive check of default values will take place. The following is
-        an example with the same types and values as above but with der 
-        encoding format.</p>
-      <pre>
-1> <input>asn1ct:compile('File',[der]).</input>
-Erlang ASN.1 version "1.3.2" compiling "File.asn1" 
-Compiler Options: [der]
---{generated,"File.asn1db"}--
---{generated,"File.hrl"}--
---{generated,"File.erl"}--
+2> <input>'File':encode('Seq1', {'Seq1',asn1_DEFAULT,asn1_DEFAULT}).</input>
+{ok,&lt;&lt;48,0>>}
+3> <input>'File':encode('Seq1', {'Seq1',1,{'Seq2',true,15}}).</input>
+{ok,&lt;&lt;48,0>>}   </pre>
+
+     <p>And here is an example with a named BIT STRING where the BER
+     encoder will not omit the encoding:</p>
+     <pre>
+4> <input>'File':encode('Seq3', {'Seq3',asn1_DEFAULT).</input>
+{ok,&lt;&lt;48,0>>}
+5> <input>'File':encode('Seq3', {'Seq3',&lt;&lt;16#101:3>>).</input>
+{ok,&lt;&lt;48,4,128,2,5,160>>}     </pre>
+
+     <p>The DER encoder will omit the encoding for the same BIT STRING:</p>
+     <pre>
+6> <input>asn1ct:compile('File', [ber,der]).</input>
 ok
-2> <input>'File':encode('Seq1',{'Seq1',asn1_DEFAULT,asn1_DEFAULT}).</input>
-{ok,["0",[0],[[],[]]]}
-3> <input>lists:flatten(["0",[0],[[],[]]]).</input>
-[48,0]
-4> <input>'File':encode('Seq1',{'Seq1',1,{'Seq2',true,15}}).</input>
-{ok,["0",[0],[[],[]]]}
-5> <input>lists:flatten(["0",[0],[[],[]]]).</input>
-[48,0]
-6> 
-      </pre>
-      <p>Line 5 shows that even values of constructed types is checked and if 
-        it equals the default value it will not be encoded.</p>
+7> <input>'File':encode('Seq3', {'Seq3',asn1_DEFAULT).</input>
+{ok,&lt;&lt;48,0>>}
+8> <input>'File':encode('Seq3', {'Seq3',&lt;&lt;16#101:3>>).</input>
+{ok,&lt;&lt;48,0>>}     </pre>
     </section>
 
     <section>
       <marker id="SET"></marker>
       <title>SET</title>
-      <p>The SET type is an unusual construct and normally the SEQUENCE 
-        type is more appropriate to use. Set is also inefficient compared with SEQUENCE, as the components can be in any order. Hence, it must be possible
-        to distinguish every component in 'SET', both when
-        encoding and decoding a value of a type defined to be a SET.
-        The tags of all components must be different from each other
-        in order to  be easily recognizable.</p>
-      <p>A SET may be defined as:</p>
-      <pre>
-Pdu2 ::= SET {
-    a INTEGER,
-    b BOOLEAN,
-    c ENUMERATED {on(0),off(1)} }      </pre>
-      <p>A SET is represented as an Erlang record.
-        For each SEQUENCE and <c>SET</c> in
-        an ASN.1 module an Erlang record declaration is generated. For
-        <c>Pdu2</c> above a record is defined like this:</p>
-      <pre>
--record('Pdu2',{a, b, c}).      </pre>
-      <p>The record declarations for a module <c>M</c> are placed in a 
-        separate <c>M.hrl</c> file.</p>
-      <p>Values can be assigned in Erlang as demonstrated below:</p>
-      <pre>
-V = #'Pdu2'{a=44,b=false,c=off}.      </pre>
-      <p>The decode functions will return a record as result when decoding 
-        a SET.
-        </p>
-      <p>The difference between SET and SEQUENCE is that the order of
-        the components (in the BER encoded format) is undefined for SET
-        and defined as the lexical order from the ASN.1 definition for
-        SEQUENCE. The ASN.1 compiler for Erlang will always encode a
-        SET in the lexical order. The decode routines can handle SET
-        components encoded in any order but will always return the
-        result as a record. Since all components of the SET must be
-        distinguishable both in the encoding phase as well as the
-        decoding phase the following type is not allowed in a module
-        with EXPLICIT or IMPLICIT as tag-default :</p>
-      <p></p>
-      <pre>
-Bad ::= SET {i INTEGER,
-             j INTEGER }      </pre>
-      <p>The  ASN.1 to Erlang compiler  rejects the above type. We
-        shall not explain the concept of tag further here, we refer to
-        [<cite id="X.680"></cite>].
-        </p>
-      <p>Encoding of a SET with components with DEFAULT values behaves
-        similar as a SEQUENCE, <seealso marker="#DEFAULT">see above</seealso>. The DER encoding format restrictions on DEFAULT 
-        values is the same for SET as for SEQUENCE, and is supported by 
-        the compiler, <seealso marker="#DEFAULT DER">see above</seealso>.</p>
-      <p>Moreover, in DER the elements of a SET will be sorted. If a 
-        component is an un-tagged choice the sorting have to take place
-        in run-time. This fact emphasizes the following recommendation
-        if DER encoding format is used.</p>
-      <p>The concept of SET is an unusual
-        construct and one  cannot think of one single application
-        where the set type is essential. (Imagine if someone
-        "invented'' the shuffled array in 'C') People tend to think
-        that 'SET' sounds nicer and more mathematical than 'SEQUENCE'
-        and hence use it when  'SEQUENCE' would have been more
-        appropriate. It is also most inefficient, since every correct
-        implementation of SET must always be prepared to accept the
-        components in any order. So, if possible use SEQUENCE instead
-        of SET.</p>
+      <p>In Erlang, the SET type is used exactly as SEQUENCE. Note
+      that if the BER or DER encoding rules are used, decoding a
+      SET is slower than decoding a SEQUENCE because the components
+      must be sorted.</p>
     </section>
 
     <section>
-      <title>Notes about Extend-ability for SEQUENCE and SET</title>
+      <title>Notes about extensibility for SEQUENCE and SET</title>
       <p>When a SEQUENCE or SET contains an extension marker and 
         extension components like this:</p>
       <pre>
@@ -1071,51 +1015,28 @@ SExt ::= SEQUENCE {
       <marker id="CHOICE"></marker>
       <title>CHOICE</title>
       <p>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.
-        </p>
+        'union' in the C language.</p>
       <p>Assume:</p>
       <pre>
+SomeModuleName DEFINITIONS AUTOMATIC TAGS ::=
+BEGIN
 T ::= CHOICE {
-        x [0] REAL,
-        y [1] INTEGER,
-        z [2] OBJECT IDENTIFIER }
-      </pre>
+        x REAL,
+        y INTEGER,
+        z OBJECT IDENTIFIER }
+END </pre>
       <p>It is then possible to assign values:</p>
       <pre>
 TVal1 = {y,17},
 TVal2 = {z,{0,1,2}},
       </pre>
-      <p>A CHOICE value is  always represented as the tuple
+      <p>A CHOICE value is always represented as the tuple
         <c>{ChoiceAlternative, Val}</c> where <c>ChoiceAlternative</c>
-        is an atom denoting the selected choice
-        alternative.
-        </p>
-      <p>It is also allowed to have a CHOICE type tagged as follow:</p>
-      <p></p>
-      <pre>
-C ::= [PRIVATE 111] CHOICE {
-        C1,
-        C2 }
-
-C1 ::= CHOICE { 
-         a [0] INTEGER,
-         b [1] BOOLEAN }
-
-C2 ::= CHOICE {
-         c [2] INTEGER,
-         d [3] OCTET STRING }      </pre>
-      <p>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.
         </p>
 
       <section>
-        <title>Extendable CHOICE</title>
+        <title>Extensible CHOICE</title>
         <p>When a CHOICE contains an extension marker and the decoder detects
           an unknown alternative of the CHOICE the value is represented as:</p>
         <pre>
@@ -1192,26 +1113,29 @@ Arr2Val = ["abc",[14,34,54],"Octets"],      </pre>
         Where <c>Value</c> may be a value of yet another type T2.</p>
       <p>For example:</p>
       <pre>
+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 }      </pre>
-      <p>The above example can be assigned like this in Erlang:</p>
+        x REAL,
+        y INTEGER,
+        z OBJECT IDENTIFIER }
+        END      </pre>
+      <p>The SEQUENCE b can be encoded like this in Erlang:</p>
       <pre>
-V2 = #'B'{a=[4,5,6,7,8], b={x,7.77}}.
-      </pre>
+1> 'EmbeddedExample':encode('B', {'B',[4,5,6,7,8],{x,"7.77"}}).
+{ok,&lt;&lt;5,56,0,8,3,55,55,55,46,69,45,50>>} </pre>
     </section>
   </section>
 
   <section>
     <title>Naming of Records in .hrl Files</title>
-    <p>When an asn1 specification is compiled all defined types of
+    <p>When an ASN.1 specification is compiled all defined types of
       type SET or SEQUENCE will result in a corresponding record in the
       generated hrl file. This is because the values for SET/SEQUENCE
       as mentioned in sections above are represented as records.</p>
@@ -1227,8 +1151,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 } }
@@ -1299,7 +1223,7 @@ PType{T} ::= SEQUENCE{
       <p>Types may refer to themselves. Suppose:</p>
       <pre>
 Rec ::= CHOICE {
-     nothing [0] NULL,
+     nothing NULL,
      something SEQUENCE {
           a INTEGER,
           b OCTET STRING,
@@ -1331,7 +1255,7 @@ tt TT ::= {a 77,b {"kalle","kula"}}    </pre>
       Firstly, it could be used as the value in some DEFAULT component:</p>
     <pre>
 SS ::= SET {
-    s [0] OBJECT IDENTIFIER,
+    s OBJECT IDENTIFIER,
     val TT DEFAULT tt }    </pre>
     <p>It could also be used from inside an Erlang program. If the above ASN.1
       code was defined in ASN.1 module <c>Values</c>, then the ASN.1 value
@@ -1365,8 +1289,8 @@ SS ::= SET {
     <marker id="Information Object"></marker>
     <title>ASN.1 Information Objects (X.681)</title>
     <p>Information Object Classes, Information Objects and Information
-      Object Sets, (in the following called classes, objects and
-      object sets respectively), are defined in the standard
+      Object Sets (in the following called classes, objects and
+      object sets respectively) are defined in the standard
       definition [<cite id="X.681"></cite>]. In the following only a brief
       explanation is given. </p>
     <p>These constructs makes it possible to define open types,
@@ -1435,9 +1359,26 @@ StartMessage  ::= SEQUENCE {
     <p><c>StartMessage</c> can in the <c>content</c> field be
       encoded with a value of any type that an object in the
       <c>GENERAL-PROCEDURES</c> object set has in its <c>NEW MESSAGE</c> field. This field refers to a type field
-      <c><![CDATA[&amp;Message]]></c> in the class. The <c>msgId</c> field is always
+      <c>&amp;Message</c> in the class. The <c>msgId</c> field is always
       encoded as a PrintableString, since the field refers to a fixed type
       in the class.</p>
+    <p>In practice, object sets are usually declared to be extensible so
+    so that more objects can be added to the set later. Extensibility is
+    indicated like this:</p>
+    <pre>
+GENERAL-PROCEDURES GENERAL-PROCEDURE ::= {
+    object1 | object2, ...}    </pre>
+     <p>When decoding a type that uses an extensible set constraint,
+     there is always the possibility that the value in the UNIQUE
+     field is unknown (i.e. the type has been encoded with a later
+     version of the ASN.1 specification). When that happens, the
+     unencoded data will be returned wrapped in a tuple like this:</p>
+
+     <pre>
+{asn1_OPENTYPE,Binary}</pre>
+     <p>where <c>Binary</c> is an Erlang binary that contains the encoded
+     data. (If the option <c>legacy_erlang_types</c> has been given,
+     just the binary will be returned.)</p>
   </section>
 
   <section>
@@ -1466,132 +1407,11 @@ T1 ::= General{PrintableString}
 T2 ::= General{BIT STRING}
     </pre>
     <p>An example of a value that can be encoded as type T1 is {12,"hello"}.</p>
-    <p>Observe that the compiler not generates encode/decode functions for
-      parameterized types, only for the instances of the parameterized 
-      types. So, if a file contains the types General{}, T1 and T2 above,
+    <p>Note that the compiler does not generate encode/decode functions for
+      parameterized types, but only for the instances of the parameterized
+      types. Therefore, if a file contains the types General{}, T1 and T2 above,
       encode/decode functions will only be generated for T1 and T2.
       </p>
   </section>
-
-  <section>
-    <title>Tags</title>
-    <p>Every built-in ASN.1 type, except CHOICE and ANY have a universal tag.
-      This is a unique number that clearly identifies the type.      <br></br>
- 
-      It is essential for all users of ASN.1  to
-      understand  all the details about tags.</p>
-    <p>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.</p>
-    <p>There are four different types of tags.</p>
-    <taglist>
-      <tag><em>universal</em></tag>
-      <item>
-        <p>For types whose meaning is the same in all 
-          applications. Such as integers, sequences and so on; that is, all the built in
-          types.</p>
-      </item>
-      <tag><em>application</em></tag>
-      <item>
-        <p>For application specific types for example, the types in
-          X.400 Message handling service have this sort of tag.</p>
-      </item>
-      <tag><em>private</em></tag>
-      <item>
-        <p>For your own private types.</p>
-      </item>
-      <tag><em>context</em></tag>
-      <item>
-        <p>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 <c>INTEGER</c> values, there is no
-          way for the decoder to 
-          decipher which component was actually chosen, since both
-          components will be
-          tagged as <c>INTEGER</c>. When this or similar situations occur,  
-          one or both of the components should be given a  context specific
-          to resolve the ambiguity.</p>
-      </item>
-    </taglist>
-    <p>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 <em>only</em> one  ASN.1
-      type.
-      </p>
-    <p>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.</p>
-    <p></p>
-    <table>
-      <row>
-        <cell align="left" valign="middle">Tag</cell>
-        <cell align="left" valign="middle">Len</cell>
-        <cell align="left" valign="middle">Value</cell>
-      </row>
-      <tcaption>Structure of a BER encoded series of bytes</tcaption>
-    </table>
-  </section>
-
-  <section>
-    <title>Encoding Rules</title>
-    <p>When the first recommendation on ASN.1 was released 1988 it was
-      accompanied with the Basic Encoding Rules, BER, as the only 
-      alternative for encoding.
-      BER is a somewhat verbose protocol. It adopts a so-called TLV (type, 
-      length, value) approach to encoding in which every element of the 
-      encoding carries some type information, some length information and 
-      then the value of that element. Where the element is itself 
-      structured, then the Value part of the element is itself a series of 
-      embedded TLV components, to whatever depth is necessary. In summary, 
-      BER is not a compact encoding but is relatively fast and easy to 
-      produce.</p>
-    <p>The DER (Distinguished Encoding Rule) encoding format was included in
-      the standard in 1994. It is a specialized form of BER, which gives 
-      the encoder the option to encode some entities differently. For
-      instance, is the value for TRUE any octet with any bit set to one. But,
-      DER does not leave any such choices. The value for TRUE in the DER 
-      case is encoded as the octet <c>11111111</c>. So, the same value 
-      encoded by two different DER encoders must result in the same bit 
-      stream.</p>
-    <p>A more compact encoding is achieved with the Packed Encoding
-    Rules PER which was introduced together with the revised
-    recommendation in 1994. PER takes a rather different approach from
-    that taken by BER. The first difference is that the tag part in
-    the TLV is omitted from the encodings, and any tags in the
-    notation are not encoded. The potential ambiguities are resolved
-    as follows:</p>
-    <list type="bulleted">
-      <item>
-        <p>A CHOICE is encoded by first encoding a choice index which
-          identifies the chosen
-          alternative by its position in the notation.</p>
-      </item>
-      <item>
-        <p>The elements of a SEQUENCE are transmitted in textual
-        order. OPTIONAL or DEFAULT elements are preceded by a bit map
-        to identify which elements are present. After sorting the
-        elements of a SET in the "canonical tag order" as defined in
-        X.680 8.6 they are treated as a SEQUENCE regarding OPTIONAL
-        and DEFAULT elements. A SET is transferred in the sorted
-        order.</p>
-      </item>
-    </list>
-    <p>A second difference is that PER takes full account of the sub-typing
-      information in that the encoded bytes are affected by the constraints.
-      The BER encoded bytes are unaffected by the constraints.
-      PER uses the sub-typing information to for example omit length fields 
-      whenever possible. </p>
-    <p>The run-time functions, sometimes take the constraints into account
-      both for BER and PER. For instance are SIZE constrained strings checked.</p>
-    <p>There are two variants of PER, <em>aligned</em> and <em>unaligned</em>.
-      In summary, PER results in compact encodings which require much more
-      computation to produce than  BER.
-      </p>
-  </section>
 </chapter>
 
diff --git a/lib/asn1/doc/src/asn1ct.xml b/lib/asn1/doc/src/asn1ct.xml
index 4d5a1a402a..32ff2d52cf 100644
--- a/lib/asn1/doc/src/asn1ct.xml
+++ b/lib/asn1/doc/src/asn1ct.xml
@@ -45,10 +45,11 @@
 	<p>By default in OTP 17, the representation of the BIT STRING
 	and OCTET STRING types as Erlang terms have changed. BIT
 	STRING values are now Erlang bitstrings and OCTET STRING values
-	are binaries.  For details see <seealso
-	marker="asn1_ug#BIT STRING">BIT STRING</seealso> and <seealso
-	marker="asn1_ug#OCTET STRING">OCTET STRING</seealso> in User's
-	Guide.</p>
+	are binaries.  Also, an undecoded open type will now be wrapped in
+	a <c>asn1_OPENTYPE</c> tuple. For details see <seealso
+	marker="asn1_ug#BIT STRING">BIT STRING</seealso>, <seealso
+	marker="asn1_ug#OCTET STRING">OCTET STRING</seealso>, and
+	<seealso marker="asn1_ug#Information%20Object">ASN.1 Information Objects</seealso> in User's Guide.</p>
 	<p>To revert to the old representation of the types, use the
 	<c>legacy_erlang_types</c> option.</p>
       </note>