Update documentation

2 files changed, 64 insertions, 51 deletions

diff --git a/lib/asn1/doc/src/asn1_ug.xml b/lib/asn1/doc/src/asn1_ug.xml
index 74c4aa9948..eb9f000e75 100644
--- a/lib/asn1/doc/src/asn1_ug.xml
+++ b/lib/asn1/doc/src/asn1_ug.xml
@@ -653,7 +653,7 @@ Day1 = saturday,
 Bits1 ::= BIT STRING
 Bits2 ::= BIT STRING {foo(0),bar(1),gnu(2),gnome(3),punk(14)}
       </pre>
-      <p>There are five different notations available for representation of
+      <p>There are two notations available for representation of
         BIT STRING values in Erlang and as input to the encode functions.</p>
       <list type="ordered">
 	<item>A bitstring. By default, a BIT STRING with no
@@ -661,43 +661,10 @@ Bits2 ::= BIT STRING {foo(0),bar(1),gnu(2),gnome(3),punk(14)}
         <item>A list of atoms corresponding to atoms in the <c>NamedBitList</c> 
          in the BIT STRING definition. A BIT STRING with symbolic
 	 names will always be decoded to this format.</item>
-        <item>A list of binary digits (0 or 1). This format is always
-	  accepted as input to the encode functions. A BIT STRING will
-	  be decoded to this format if <em>legacy_bit_string</em> option
-	  has been given. <em>This format may be withdrawn in a future
-         release.</em>
-	</item>
-        <item>As <c>{Unused,Binary}</c> where <c>Unused</c> denotes how
-          many trailing zero-bits 0 to 7 that are unused in the least
-          significant byte in <c>Binary</c>. This format is always
-	  accepted as input to the encode functions. A BIT STRING will
-	  be decoded to this format if <em>compact_bit_string</em> has
-	  been given. <em>This format may be withdrawn in a future
-          release.</em>
-	</item>
-        <item>A hexadecimal number (or an integer). This format should be
-         avoided, since it is easy to misinterpret a <c>BIT STRING</c>
-         value in this format. <em>This format may be withdrawn in a future
-         release.</em>
-	</item>
       </list>
-      <note>
-        <p>It is recommended to either use the bitstring format (for
-	  BIT STRINGs with no symbolic names) or a list of symbolic
-	  names (for BIT STRINGs with symbolic names). The other formats
-	  should be avoided since they may be withdrawn in a future
-	  release.
-	</p>
-      </note>
+      <p>Example:</p>
       <pre>
 Bits1Val1 = &lt;&lt;0:1,1:1,0:1,1:1,1:1&gt;&gt;,
-Bits1Val2 = 16#1A,
-Bits1Val3 = {3,&lt;&lt;0:1,1:1,0:1,1:1,1:1,0:3&gt;&gt;},
-Bits1Val4 = [0,1,0,1,1]
-      </pre>
-      <p>Note that <c>Bits1Val1</c>, <c>Bits1Val2</c>, <c>Bits1Val3</c>,
-	and <c>Bits1Val1</c> denote the same value.</p>
-      <pre>
 Bits2Val1 = [gnu,punk],
 Bits2Val2 = &lt;&lt;2#1110:4&gt;&gt;,
 Bits2Val3 = [bar,gnu,gnome],
@@ -708,37 +675,60 @@ Bits2Val3 = [bar,gnu,gnome],
         2 and 14 are set to 1 and the rest set to 0. The symbolic values
         appear as a list of values. If a named value appears, which is not
         specified in the type definition, a run-time error will occur.</p>
-      <p>The compact notation equivalent to the empty BIT STRING is
-        <c><![CDATA[{0,<<>>}]]></c>, which in the other notations is
-	<c><![CDATA[<<>>]]></c>, <c>[]</c>, or
-        <c>0</c>.</p>
       <p>BIT STRINGS may also be sub-typed with, for example, a SIZE
         specification:</p>
       <pre>
 Bits3 ::= BIT STRING (SIZE(0..31))      </pre>
       <p>This means that no bit higher than 31 can ever be set.</p>
+
+      <section>
+	<title>Deprecated representations for BIT STRING</title>
+	<p>In addition to the representations described above, the
+	following deprecated representations are available if the
+	specification has been compiled with the
+	<c>legacy_erlang_types</c> option:</p>
+	<list type="ordered">
+	  <item>A list of binary digits (0 or 1). This format is
+	  accepted as input to the encode functions, and a BIT STRING
+	  will be decoded to this format if the
+	  <em>legacy_bit_string</em> option has been given.
+	  </item>
+	  <item>As <c>{Unused,Binary}</c> where <c>Unused</c> denotes
+	  how many trailing zero-bits 0 to 7 that are unused in the
+	  least significant byte in <c>Binary</c>. This format is
+	  accepted as input to the encode functions, and a <c>BIT
+	  STRING</c> will be decoded to this format if
+	  <em>compact_bit_string</em> has been given.
+	  </item>
+	  <item>A hexadecimal number (or an integer). This format
+	  should be avoided, since it is easy to misinterpret a BIT
+	  STRING value in this format.
+	  </item>
+	</list>
+      </section>
     </section>
 
     <section>
       <marker id="OCTET STRING"></marker>
       <title>OCTET STRING</title>
-      <p>The OCTET STRING is the simplest of all ASN.1 types The OCTET STRING
-        only moves or transfers e.g. binary files or other unstructured
-        information complying to two rules.
-        Firstly, the bytes consist of octets and secondly, encoding is 
-        not required.</p>
+      <p>The OCTET STRING is the simplest of all ASN.1 types. The
+      OCTET STRING only moves or transfers e.g. binary files or other
+      unstructured information complying to two rules.  Firstly, the
+      bytes consist of octets and secondly, encoding is not
+      required.</p>
       <p>It is possible to have the following ASN.1 type definitions:</p>
       <pre>
 O1 ::= OCTET STRING
 O2 ::= OCTET STRING (SIZE(28))      </pre>
       <p>With the following example assignments in Erlang:</p>
       <pre>
-O1Val = [17,13,19,20,0,0,255,254],
-O2Val = "must be exactly 28 chars....",      </pre>
-      <p>Observe that <c>O1Val</c> is assigned a series of numbers between 0 
-        and 255 i.e. octets.
-        <c>O2Val</c> is assigned using the string notation.
-        </p>
+O1Val = &lt;&lt;17,13,19,20,0,0,255,254&gt;&gt;,
+O2Val = &lt;&lt;"must be exactly 28 chars...."&gt;&gt;,</pre>
+       <p>By default, an OCTET STRING is always represented as
+       an Erlang binary. If the specification has been compiled with
+       the <c>legacy_erlang_types</c> option, the encode functions
+       will accept both lists and binaries, and the decode functions
+       will decode an OCTET STRING to a list.</p>
     </section>
 
     <section>
diff --git a/lib/asn1/doc/src/asn1ct.xml b/lib/asn1/doc/src/asn1ct.xml
index ada2aace87..5871c8ad68 100644
--- a/lib/asn1/doc/src/asn1ct.xml
+++ b/lib/asn1/doc/src/asn1ct.xml
@@ -42,6 +42,17 @@
       can be used in during development of applications which handles ASN.1
       data (encoded as BER or PER).</p>
       <note>
+	<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>
+	<p>To revert to the old representation of the types, use the
+	<c>legacy_erlang_types</c> option.</p>
+      </note>
+      <note>
 	<p>In R16, the options have been simplified. The back-end is chosen
 	using one of the options <c>ber</c>, <c>per</c>, or <c>uper</c>.
 	The options <c>optimize</c>, <c>nif</c>, and <c>driver</c> options
@@ -64,7 +75,7 @@
         <v>Asn1module = atom() | string()</v>
         <v>Options = [Option| OldOption]</v>
         <v>Option = ber | per | uper | der | compact_bit_string |
-	legacy_bit_string |
+	legacy_bit_string | legacy_erlang_types |
 	noobj | {n2n, EnumTypeName} |{outdir, Dir} | {i, IncludeDir} |
 	asn1config | undec_rest | no_ok_wrapper |
 	{macro_name_prefix, Prefix} | {record_name_prefix, Prefix} | verbose | warnings_as_errors</v>
@@ -163,6 +174,7 @@ File3.asn        </pre>
 		BIT STRING type section in the Users Guide
 	      </seealso>.
 	    </p>
+	    <p>This option implies the <c>legacy_erlang_types</c> option.</p>
 	  </item>
           <tag><c>legacy_bit_string</c></tag>
           <item>
@@ -175,8 +187,19 @@ File3.asn        </pre>
 	      <seealso marker="asn1_ug#BIT STRING">
 		BIT STRING type section in the Users Guide
 	      </seealso>.
+	      <p>This option implies the <c>legacy_erlang_types</c> option.</p>
 	    </p>
 	  </item>
+          <tag><c>legacy_erlang_types</c></tag>
+          <item>
+            <p>Use the same Erlang types to represent BIT STRING and
+            OCTET STRING as in R16. 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>
+	    <p><em>This option is not recommended for
+            new code.</em></p>
+	  </item>
           <tag><c>{n2n, EnumTypeName}</c></tag>
           <item>
             <p>