D.4.2

The AUTOMATIC TAGS module directive is not used.

D.4.3

SEQUENCE and CHOICE tag numbers start at one.

D.4.4

ENUMERATED tag numbers start at one.

D.4.5

Anonymous types are not used. Non-trivial fields are assigned their own named type.

D.4.6

Consideration should be given to making types re-usable and independent of a particular release. Re-using or extending an existing type, where the intent is similar, is preferable to creating a new type.

D.4.7

Consideration should be given to making types extensible by declaring them as a SEQUENCE or CHOICE where possible.

D.4.8

Multiple smaller messages or structures with fewer OPTIONAL fields are preferred to larger structures with many OPTIONAL fields, as this increases the ability of the ASN.1 schema to enforce the intent of the specification.

D.4.9

Field names, tag numbers, field types and optional flags are be space-aligned where possible. An indent of four spaces is used.

D.4.10

Field and type names (when defining a type) are not in bold.

D.4.11

Braces are given their own line.

D.4.12

OIDs containing a version number are updated when the structure that uses the OID is changed, even if the change is solely to correct a syntactic error. Other OIDs in the same module need not be updated if they are not associated with structures that have been changed.

D.4.13

For backward compatibility, fields added to existing SEQUENCE or SET are defined as OPTIONAL, irrespective of their M/C/O designation in the main body of the specification.

D.4.14

When a field is deprecated, the ASN.1 is not changed but the main text is changed (see D.2.5).

D.4.15

XIRIEvent and IRIEvent tag numbers should be identical for the same field purpose. If the field is not present in one of XIRIEvent or IRIEvent, a comment reserving the tag should be added instead (see D.2.3).