asn1: Update commentary on grammar

lib/asn1/asn1parse.y

@@ -305,6 +305,9 @@ static unsigned long idcounter;
  * We have sinned by allowing types to have names that start with lower-case,
  * and values that have names that start with upper-case.
  *
+ * UPDATE: We sin no more.  However, parts of this block comment are still
+ * relevant.
+ *
  * That worked when we only supported basic X.680 because the rules for
  * TypeAssignment and ValueAssignment are clearly unambiguous in spite of the
  * case issue.
@@ -313,35 +316,41 @@ static unsigned long idcounter;
  * have to help us distinguish certain rules is the form of an identifier: the
  * case of its first letter.
  *
- * We have begun to undo our sin by not allowing wrong-case identifiers in
+ * We have cleansed our sin by not allowing wrong-case identifiers any more.
- * certain situations.
  *
  * Some historical instances of this sin in-tree:
  *
- *  - DOMAIN-X500-COMPRESS (value (enum) but name starts with upper-case)
+ *  - DOMAIN-X500-COMPRESS  (value (enum) but name starts with upper-case)
- *  - krb5int32		   (type         but name starts with lower-case)
+ *  - krb5int32		    (type         but name starts with lower-case)
- *  - krb5uint32	   (type         but name starts with lower-case)
+ *  - krb5uint32	    (type         but name starts with lower-case)
- *  - hdb_keyset	   (type         but name starts with lower-case)
+ *  - hdb_keyset	    (type         but name starts with lower-case)
- *  - hdb_entry		   (type         but name starts with lower-case)
+ *  - hdb_entry		    (type         but name starts with lower-case)
- *  - hdb_entry_alias      (type         but name starts with lower-case)
+ *  - hdb_entry_alias       (type         but name starts with lower-case)
+ *  - HDB_DB_FORMAT INTEGER (value (int)  but name starts with upper-case)
  *
- * We have fixed most of these, in some cases leaving behind aliases in header
+ * We have fixed all of these and others, in some cases leaving behind aliases
- * files as needed.
+ * in header files as needed.
  *
- * This issue is probably also the source of remaining shift/reduce conflicts.
+ * We have one shift/reduce conflict (shift ObjectClassAssignment, reduce
+ * TypeAssignment) and one reduce/reduce conflict (ObjectAssignment vs
+ * ValueAssignment) that we avoid by requiring CLASS names to start with an
+ * underscore.
  *
- * In the FieldSetting rule in particular, we get a reduce/reduce conflict if
+ * In the FieldSetting rule, also, we get a reduce/reduce conflict if we use
- * we use `Identifier' instead of `TYPE_IDENTIFIER' for type field settings and
+ * `Identifier' instead of `TYPE_IDENTIFIER' for type field settings and
  * `VALUE_IDENTIFIER' for value field settings, and then we can't make
  * progress.
  *
  * Looking forward, we may not (will not) be able to distinguish ValueSet and
- * ObjectSet field settings from each other either even without committing this
+ * ObjectSet field settings from each other either, and we may not (will not)
- * leading-identifier-character-case sin, and we may not (will not) be able
+ * be able distinguish Object and Value field settings from each other as well.
- * distinguish Object and Value field settings from each other as well.  To
+ * To deal with those we will have to run-time type-tag and type-pun the C
- * deal with those we will have to run-time type-tag/pun the C structures for
+ * structures for valueset/objectset and value/object, and have one rule for
- * valueset/objectset and value/object, and have one rule for each of those
+ * each of those that inspects the type of the item to decide what kind of
- * that inspects the type of the item to decide what kind of setting it is.
+ * setting it is.
+ *
+ * Sadly, the extended syntax for ASN.1 (x.680 + x.681/2/3) appears to have
+ * ambiguities that cannot be resolved with bison/yacc.
  */
 Identifier	: TYPE_IDENTIFIER { $$ = $1; }
 		| VALUE_IDENTIFIER { $$ = $1; };