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>