Remove the section about encoding rules

The section about encoding rules serves no useful purpose. Most users
already know which encoding rule to use for their specifications.  The
few users that have their own specification and need to decide on
which encoding rule to use will need much more information.

1 files changed, 0 insertions, 57 deletions

diff --git a/lib/asn1/doc/src/asn1_ug.xml b/lib/asn1/doc/src/asn1_ug.xml
index ce8da39e6d..2522333d77 100644
--- a/lib/asn1/doc/src/asn1_ug.xml
+++ b/lib/asn1/doc/src/asn1_ug.xml
@@ -1415,62 +1415,5 @@ T2 ::= General{BIT STRING}
       encode/decode functions will only be generated for T1 and T2.
       </p>
   </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>