Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4912

Abstract Syntax Notation X (ASN.X)

Pages: 165
Experimental
Part 1 of 6 – Pages 1 to 17
None   None   Next

Top   ToC   RFC4912 - Page 1
Network Working Group                                            S. Legg
Request for Comments: 4912                                       eB2Bcom
Category: Experimental                                         July 2007


                   Abstract Syntax Notation X (ASN.X)

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

Abstract Syntax Notation X (ASN.X) is a semantically equivalent Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. ASN.X, together with the Robust XML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents.
Top   ToC   RFC4912 - Page 2

Table of Contents

1. Introduction ....................................................4 2. Conventions .....................................................5 3. General Considerations ..........................................6 3.1. Annotations ................................................7 4. ModuleDefinition Translation ....................................8 5. Translation of Assignments .....................................11 5.1. Referencing Named Constructs ..............................11 5.2. Importing Namespaces ......................................12 5.3. TypeAssignment Translation ................................14 5.4. ValueAssignment and XMLValueAssignment Translation ........14 5.5. ValueSetTypeAssignment Translation ........................15 5.6. ObjectClassAssignment Translation .........................15 5.7. ObjectAssignment Translation ..............................16 5.8. ObjectSetAssignment Translation ...........................16 5.9. ParameterizedAssignment Translation .......................17 6. Translation of Types ...........................................17 6.1. Identifier Replacement ....................................17 6.2. DefinedType Translation ...................................18 6.3. Translation of Built-in Types .............................20 6.4. BitStringType Translation .................................21 6.5. IntegerType Translation ...................................22 6.6. EnumeratedType Translation ................................24 6.7. PrefixedType Translation ..................................25 6.7.1. Short Form TaggedType Translation ..................28 6.7.2. Long Form TaggedType Translation ...................29 6.8. SelectionType Translation .................................30 6.9. InstanceOfType Translation ................................31 6.10. ObjectClassFieldType Translation .........................31 6.11. TypeFromObject and ValueSetFromObjects Translation .......32 6.12. Translation of Combining Types ...........................32 6.12.1. NamedType Translation .............................32 6.12.2. SequenceType Translation ..........................36 6.12.3. SetType Translation ...............................38 6.12.4. ChoiceType Translation ............................39 6.12.5. Translation of UNION Types ........................40 6.12.6. SequenceOfType Translation ........................41 6.12.7. Translation of LIST Types .........................42 6.12.8. SetOfType Translation .............................42 6.12.9. Effect of Insertion Encoding Instructions .........43 6.13. Translation of Constrained Types .........................43 6.13.1. Constraint Translation ............................46 6.13.2. UserDefinedConstraint Translation .................46 6.13.3. TableConstraint Translation .......................47 6.13.4. ContentsConstraint Translation ....................49 6.13.5. ExceptionSpec Translation .........................50
Top   ToC   RFC4912 - Page 3
   7. Translation of Values ..........................................51
      7.1. Translation of Literal Values .............................53
      7.2. Translation of Notational Values ..........................54
           7.2.1. DefinedValue Translation ...........................56
           7.2.2. BuiltinValue Translation ...........................57
           7.2.3. ValueFromObject Translation ........................60
           7.2.4. ObjectClassFieldValue Translation ..................60
   8. Translation of Value Sets ......................................61
      8.1. ElementSetSpecs Translation ...............................62
      8.2. ElementSetSpec Translation ................................62
      8.3. SubtypeElements Translation ...............................63
           8.3.1. ValueRange Translation .............................64
           8.3.2. InnerTypeConstraints Translation ...................65
   9. Translation of Object Classes ..................................66
      9.1. DefinedObjectClass Translation ............................66
      9.2. ObjectClassDefn Translation ...............................68
           9.2.1. TypeFieldSpec Translation ..........................68
           9.2.2. FixedTypeValueFieldSpec Translation ................69
           9.2.3. FixedTypeValueSetFieldSpec Translation .............70
           9.2.4. VariableTypeValueFieldSpec Translation .............71
           9.2.5. VariableTypeValueSetFieldSpec Translation ..........73
           9.2.6. FieldName Translation ..............................74
           9.2.7. ObjectFieldSpec Translation ........................75
           9.2.8. ObjectSetFieldSpec Translation .....................76
   10. Translation of Objects ........................................77
      10.1. DefinedObject Translation ................................77
      10.2. ObjectDefn Translation ...................................78
      10.3. ObjectFromObject Translation .............................80
   11. Translation of Object Sets ....................................80
      11.1. DefinedObjectSet Translation .............................81
      11.2. ObjectSetElements Translation ............................82
           11.2.1. ObjectSetFromObjects Translation ..................83
   12. Translation of Information From Objects .......................83
   13. Translation of Parameterized Definitions ......................83
   14. EncodingControlSections Translation ...........................93
   15. Security Considerations .......................................94
   16. Acknowledgements ..............................................94
   17. References ....................................................95
      17.1. Normative References .....................................95
      17.2. Informative References ...................................97
   Appendix A. ASN.1 for ASN.X .......................................95
   Appendix B. ASN.X for ASN.X ......................................115
Top   ToC   RFC4912 - Page 4

1. Introduction

A full parser for the Abstract Syntax Notation One (ASN.1) language [X.680][X.680-1][X.681][X.682][X.683] is difficult to implement due to numerous ambiguities in the notation. For example, certain notations for a Value are syntactically indistinguishable from notation for a ValueSet, Object, ObjectSet, DummyReference, or SimpleTableConstraint. An ObjectClassAssignment, ObjectAssignment, or ObjectSetAssignment resembles respectively a TypeAssignment, ValueAssignment, or ValueSetTypeAssignment. A FixedTypeValueFieldSpec or FixedTypeValueSetFieldSpec resembles respectively an ObjectFieldSpec or ObjectSetFieldSpec, and an ObjectClassFieldType resembles InformationFromObjects notation. In general, such ambiguities can only be resolved once the entire specification has been parsed. There are other notations that are not mutually ambiguous but still require several lexical tokens to be scanned before they can be distinguished from each other. The difficulty of parsing ASN.1 is an impediment to its wider adoption. This document defines a semantically equivalent Extensible Markup Language (XML) [XML10][XML11] representation for ASN.1 specifications called Abstract Syntax Notation X (ASN.X). An ASN.X module is a well-formed and valid XML document conforming to XML namespaces [XMLNS10][XMLNS11]. ASN.X completely avoids the inherent ambiguities of the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. For example, any conformant XML processor forms the basis of an ASN.1 toolkit. ASN.X, together with the Robust XML Encoding Rules (RXER) [RXER], constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents conforming to an ASN.X specification. ASN.X definitions can also incorporate type, element, and attribute definitions from XML Schema [XSD1] documents, RELAX NG [RNG] documents, or Document Type Definitions (DTDs) [XML10][XML11]. ASN.X is defined in terms of rules for translating from an ASN.1 specification. This does not preclude an ASN.X module being written directly without a pre-existing ASN.1 module; however, such an ASN.X module is considered valid if and only if there exists, in principle, an ASN.1 module that when translated would yield the ASN.X module. The format for ASN.X has also been designed so that the content of an ASN.X module conforms to the RXER encoding of an abstract value of an ASN.1 type, the ModuleDefinition type, presented in Appendix A. This means that it is possible to decode an ASN.X module using an RXER decoder and then re-encode the abstract value (for storage or
Top   ToC   RFC4912 - Page 5
   transmission) using any of the other encoding rules for ASN.1.  Thus,
   the "X" in ASN.X can be regarded as standing for either XML or RXER,
   or more generally, for any set of ASN.1 encoding rules.

   The ASN.X translation of the ASN.1 module in Appendix A is presented
   in Appendix B.

2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [BCP14]. The key word "OPTIONAL" is exclusively used with its ASN.1 meaning. Throughout this document "type" shall be taken to mean an ASN.1 type, and "value" shall be taken to mean an ASN.1 abstract value. A reference to an ASN.1 production [X.680] (e.g., Type, NamedType) is a reference to the text in an ASN.1 specification corresponding to that production. The description of the translation of an ASN.1 module into an ASN.X module makes use of definitions from the XML Information Set (Infoset) [INFOSET]. In particular, information item property names follow the Infoset convention of being shown in square brackets, e.g., [local name]. Literal values of Infoset properties are enclosed in double quotes; however, the double quotes are not part of the property values. In the sections that follow, "information item" will be abbreviated to "item", e.g., "element information item" is abbreviated to "element item". Element items will be referred to by their [local name] in angle brackets, e.g., "the <type> element item" means the element item with the [local name] "type". Attribute items will be referred to by their [local name], e.g., "the type attribute item" means the attribute item with the [local name] "type". This document uses the namespace prefix "asnx:" to stand for the namespace name "urn:ietf:params:xml:ns:asnx", though in practice any valid namespace prefix is permitted in ASN.X. Encoding instructions [X.680-1] referenced by name in this specification are encoding instructions for RXER [RXEREI]. The associated provisions do not apply to encoding instructions for other encoding rules that happen to have the same name. Code points for characters [UNICODE] are expressed using the Unicode convention U+n, where n is four to six hexadecimal digits, e.g., the space character is U+0020.
Top   ToC   RFC4912 - Page 6

3. General Considerations

ASN.X is defined in terms of rules for translating an ASN.1 module into a synthetic Infoset. This synthetic Infoset is then serialized into a well-formed and valid XML document (the ASN.X module) in the same manner that the synthetic Infoset for a non-canonical RXER encoding is serialized into an XML document (see Section 6.12 of the specification for RXER [RXER]). Aside: The serialization permits CDATA sections, character references, and parsed entity references. However, note that an ASN.X module may be transferred as data in a protocol and that some protocols disallow entity references. Apart from the [document element] of the document item for an ASN.X module, the translation of some ASN.1 construct belongs to the [children] or [attributes] of an enclosing element item. Where the translation of the construct is an element item, it is appended to the [children] of the enclosing element item. Elements MUST be appended to the [children] of the enclosing element item in the order described. Translators MAY add white space character items (i.e., U+0020, U+0009, U+000D and U+000A) to the [children] of any element item (to improve the layout) except element items with the [local name] "literalValue", "fieldName", or "restrictBy". Aside: White space in the [children] of <fieldName> and <restrictBy> element items is explicitly covered under their respective descriptions. Where the translation of the construct is an attribute item, it is added to the [attributes] of the enclosing element item. The order of attribute items is not significant. Translators MAY add leading and trailing white space characters to the [normalized value] of any attribute item except an attribute item with the [local name] "literalValue". Aside: An attribute or element item with the [local name] "literalValue" holds an RXER Infoset translation of an abstract value, and white space characters may be significant in that abstract value. In most cases, RXER itself permits optional leading and trailing white space characters in the Infoset translation. Translators MAY add comment and processing instruction (PI) items to the [children] of any element item except an element item with the [local name] "literalValue".
Top   ToC   RFC4912 - Page 7
      Aside: In most cases, RXER itself permits comment and PI items in
      the [children] of the element items with the [local name]
      "literalValue".

      Aside: Note that an ASN.X module may be transferred as data in a
      protocol and that some protocols disallow processing instructions.

   The [in-scope namespaces] and [namespace attributes] for
   <literalValue> and <restrictBy> element items are determined
   according to Section 6.10 of the specification for RXER [RXER].  The
   [in-scope namespaces] and [namespace attributes] for other element
   items in the translation are determined according to Section 6.2.2.1
   of the specification for RXER.

   The [namespace name] of any element item or attribute item generated
   by the translation from an ASN.1 specification has no value unless
   specified otherwise.  In those cases where the [namespace name] of an
   element item has a value, the [prefix] of the element item is
   determined according to Section 6.2.2.2 of the specification for
   RXER.  In those cases where the [namespace name] of an attribute item
   has a value, the [prefix] of the attribute item is determined
   according to Section 6.2.3.1 of the specification for RXER.

      Aside: Non-canonical RXER allows all valid namespace prefixes and
      all valid placements for their corresponding namespace declaration
      attributes.

   Whenever an element item is added to the [children] of an enclosing
   element item, the enclosing element item becomes the [parent] of the
   element item.

   Whenever an attribute item is added to the [attributes] of an element
   item, the element item becomes the [owner element] of the attribute
   item.  For each attribute item, the [specified] property is set to
   true, the [attribute type] has no value, and the value of the
   [references] property is set to unknown.

3.1. Annotations

In a number of places, as indicated in subsequent sections, the translator is permitted to add an element item with the [local name] "annotation". The [children] and [attributes] of the <annotation> element item are at the discretion of the translator. Typical uses of the <annotation> element item would be to hold comments from the ASN.1 specification that are normative in nature, e.g., a comment in a user-defined constraint, or to hold directives for an ASN.1 compiler.
Top   ToC   RFC4912 - Page 8
   Free text or XML comments in an <annotation> element will be
   preserved in a Canonical RXER (CRXER) encoding [RXER] (because the
   corresponding ASN.1 type for the <annotation> element item is the
   Markup type [RXER]), while XML comments outside <annotation> elements
   will not be preserved.

   Vendors using the <annotation> element items to hold ASN.1 compiler
   directives (as attributes or child elements of the <annotation>
   element) SHOULD use element or attribute names that are qualified
   with a namespace name specific to the vendor.

4. ModuleDefinition Translation

The translation of a ModuleDefinition [X.680] (an ASN.1 module) is an element item with the [local name] "module" and the [namespace name] "urn:ietf:params:xml:ns:asnx" (i.e., an <asnx:module> element item). The element item is typically the [document element] of a document item. An attribute item with the [local name] "format" and [normalized value] "1.0" MAY be added to the [attributes] of the <asnx:module> element item. An ASN.1 module has a schema identity URI if it contains a SCHEMA-IDENTITY encoding instruction, in which case the schema identity URI is the character string specified by the AnyURIValue of the SCHEMA-IDENTITY encoding instruction. If the ASN.1 module being translated has a schema identity URI, then an attribute item with the [local name] "schemaIdentity" SHALL be added to the [attributes] of the <asnx:module> element item. The [normalized value] of this attribute item is the schema identity URI of the module. If the target namespace [RXEREI] for the ASN.1 module is not absent, then an attribute item with the [local name] "targetNamespace" SHALL be added to the [attributes] of the <asnx:module> element item. The [normalized value] of this attribute item is the target namespace of the module. Aside: An ASN.1 module has a target namespace if it contains a TARGET-NAMESPACE encoding instruction. If the ASN.1 module contains a TARGET-NAMESPACE encoding instruction that specifies a Prefix, then an attribute item with the [local name] "targetPrefix" SHALL be added to the [attributes] of the
Top   ToC   RFC4912 - Page 9
   <asnx:module> element item.  The [normalized value] of this attribute
   item is the character string specified by the NCNameValue in the
   Prefix.

   In examples in the remainder of this document, the namespace prefix
   "tns:" is used to stand for the target namespace of the module being
   translated.

   An attribute item with the [local name] "name" SHALL be added to the
   [attributes] of the <asnx:module> element item.  The
   [normalized value] of this attribute item is the modulereference in
   the ModuleIdentifier in the ModuleDefinition.

   If the DefinitiveIdentifier in the ModuleIdentifier in the
   ModuleDefinition is not empty, then an attribute item with the
   [local name] "identifier" SHALL be added to the [attributes] of the
   <asnx:module> element item.  The [normalized value] of this attribute
   item is the RXER character data translation [RXER] of the
   DefinitiveIdentifier.

   If the TagDefault in the ModuleDefinition is empty, then an attribute
   item with the [local name] "tagDefault" and [normalized value]
   "explicit" SHALL be added to the [attributes] of the <asnx:module>
   element item.

   If the TagDefault in the ModuleDefinition is not empty and the first
   keyword in the TagDefault is not "AUTOMATIC", then an attribute item
   with the [local name] "tagDefault" SHALL be added to the [attributes]
   of the <asnx:module> element item.  The [normalized value] of this
   attribute item is the first keyword in the TagDefault with all
   letters downcased, i.e., "explicit" or "implicit".

   If the TagDefault in the ModuleDefinition is not empty and the first
   keyword in the TagDefault is "AUTOMATIC", then an attribute item with
   the [local name] "tagDefault" and [normalized value] "automatic" MAY
   be added to the [attributes] of the <asnx:module> element item.

   If the ExtensionDefault in the ModuleDefinition is not empty, then an
   attribute item with the [local name] "extensibilityImplied" and
   [normalized value] "true" or "1" SHALL be added to the [attributes]
   of the <asnx:module> element item.

   If the ExtensionDefault in the ModuleDefinition is empty, then an
   attribute item with the [local name] "extensibilityImplied" and
   [normalized value] "false" or "0" MAY be added to the [attributes] of
   the <asnx:module> element item.
Top   ToC   RFC4912 - Page 10
   An element item with the [local name] "annotation" MAY be added to
   the [children] of the <asnx:module> element item.

   The translation of each Assignment in the AssignmentList in the
   ModuleBody in the ModuleDefinition of the module being translated
   SHALL be appended to the [children] of the <asnx:module> element
   item.

   If the EncodingControlSections instance in the ModuleDefinition
   contains an EncodingControlSection for RXER, then the translation of
   each NamedType in a TopLevelComponent [RXEREI] nested in the
   EncodingInstructionAssignmentList SHALL be added to the [children] of
   the <asnx:module> element item.  The relative order of the top-level
   components [RXEREI] SHOULD be preserved in the translation; however,
   the translations of the top-level components MAY be interspersed with
   the translations of the assignments in the AssignmentList.

   The translation of the EncodingControlSections instance in the
   ModuleDefinition of the module being translated SHALL be appended to
   the [children] of the <asnx:module> element item.

   Example

      MyModule DEFINITIONS
      IMPLICIT TAGS
      EXTENSIBILITY IMPLIED ::=
      BEGIN

      MyType ::= INTEGER

      ENCODING-CONTROL RXER

          SCHEMA-IDENTITY  "http://example.com/id/MyModule"
          TARGET-NAMESPACE "http://example.com/ns/MyModule"

          COMPONENT myElement INTEGER

      END

      <asnx:module xmlns:asnx="urn:ietf:params:xml:ns:asnx"
                   name="MyModule"
                   schemaIdentity="http://example.com/id/MyModule"
                   targetNamespace="http://example.com/ns/MyModule"
                   tagDefault="implicit"
                   extensibilityImplied="true">

       <namedType name="MyType" type="asnx:INTEGER"/>
Top   ToC   RFC4912 - Page 11
       <element name="myElement" type="asnx:INTEGER"/>

      </asnx:module>

5. Translation of Assignments

5.1. Referencing Named Constructs

An Assignment in ASN.1 associates a reference name with a Type, Value, ValueSet, ObjectClass, Object, or ObjectSet. For ASN.X, an Assignment is also regarded as associating an expanded name [XMLNS10][XMLNS11] with the Type, Value, ValueSet, ObjectClass, Object, or ObjectSet. ASN.X uses these expanded names, rendered as qualified names [XMLNS10][XMLNS11], in place of the references in an ASN.1 specification. In every case, the local name of the expanded name is the typereference, valuereference, objectclassreference, objectreference, or objectsetreference in the Assignment (i.e., the [normalized value] of the name attribute item in the translation of the Assignment, ignoring white space characters). If the target namespace of the ASN.1 module in which the Assignment is defined is not absent, then the namespace name of the expanded name is that target namespace; otherwise, the namespace name of the expanded name has no value. When the expanded name is rendered as a qualified name, the namespace prefix is determined according to Section 6.7.11.1 of the specification for RXER [RXER]. If an ASN.1 specification contains two or more modules where the target namespace is absent, then there exists the possibility that the expanded names defined by the ASN.X translations of those modules are not distinct. The expanded names are not distinct if: (1) two or more type or value set assignments define the same typereference, or (2) two or more value assignments define the same valuereference, or (3) two or more object class assignments define the same objectclassreference, or (4) two or more object assignments define the same objectreference, or (5) two or more object set assignments define the same objectsetreference, or
Top   ToC   RFC4912 - Page 12
   (6) two or more top-level element components [RXEREI] have the same
       local name, or

   (7) two or more top-level attribute components [RXEREI] have the same
       local name.

   If the expanded names are not distinct, then an unambiguous
   translation into ASN.X does not exist unless each of the modules has
   a SCHEMA-IDENTITY encoding instruction.  Consequently, if two or more
   modules where the target namespace is absent are being translated
   into ASN.X and the reference names defined in those modules will not
   be distinct, then as a local action prior to the translation, a
   SCHEMA-IDENTITY encoding instruction MUST be added to each of the
   modules that defines one or more of the indistinct expanded names and
   that does not already have a SCHEMA-IDENTITY encoding instruction.
   The character string (a URI) specified by the AnyURIValue of each
   added SCHEMA-IDENTITY encoding instruction is freely chosen by the
   translator, subject to the condition that these character strings are
   distinct [RXEREI].

      Aside: Although this means that different translators might
      produce ASN.X modules that are syntactically different for any
      given ASN.1 module, those ASN.X modules will be semantically
      equivalent to each other and to the original ASN.1 module.

   TARGET-NAMESPACE and SCHEMA-IDENTITY encoding instructions are
   RECOMMENDED for every ASN.1 module.

5.2. Importing Namespaces

An Assignment is referenced from an ASN.X module if its associated expanded name appears as a qualified name in the [normalized value] of an attribute item with the [local name] "type", "value", "class", "object", or "objectSet". These references are categorized as direct references. An Assignment or top-level component is also referenced from an ASN.X module if its expanded name appears as a qualified name in the [normalized value] of an attribute item with the [local name] "ref". This reference is only categorized as direct if the ref attribute is not the result of the translation of a DefinedType subject to a TYPE-REF encoding instruction or a NamedType subject to an ATTRIBUTE-REF or ELEMENT-REF encoding instruction. Aside: In the case of an indirect reference, an attribute item with the [local name] "embedded" and [normalized value] "true" or "1" will also be present.
Top   ToC   RFC4912 - Page 13
   Definition (external module): An external module is any module other
   than the module being translated and the AdditionalBasicDefinitions
   module [RXER].

      Aside: The AdditionalBasicDefinitions module is always assumed to
      be imported, as are all the built-in types and object classes of
      ASN.1.

   An element item with the [local name] "import" SHALL be added to the
   [children] of the <asnx:module> element item for each external module
   containing Assignments or top-level components that are directly
   referenced from the ASN.X module.  An <import> element item MAY be
   added to the [children] of the <asnx:module> element item for any
   other external module.

   An attribute item with the [local name] "name" SHOULD be added to the
   [attributes] of the <import> element item.  The [normalized value] of
   this attribute item is the modulereference in the ModuleIdentifier in
   the ModuleDefinition of the external module.

   If the DefinitiveIdentifier in the ModuleIdentifier in the
   ModuleDefinition of the external module is not empty, then an
   attribute item with the [local name] "identifier" SHALL be added to
   the [attributes] of the <import> element item.  The
   [normalized value] of this attribute item is the RXER character data
   translation of the DefinitiveIdentifier.

   If the external module has a schema identity URI, then an attribute
   item with the [local name] "schemaIdentity" SHALL be added to the
   [attributes] of the <import> element item.  The [normalized value] of
   this attribute item is the schema identity URI of the external
   module.

   If the target namespace of the external module is not absent, then an
   attribute item with the [local name] "namespace" SHALL be added to
   the [attributes] of the <import> element item.  The
   [normalized value] of this attribute item is the target namespace of
   the external module.

   An attribute item with the [local name] "schemaLocation" MAY be added
   to the [attributes] of the <import> element item.  The
   [normalized value] of this attribute item is a URI [URI] indicating
   the physical location of the ASN.X translation of the external
   module.

   The <import> element items MUST follow an <annotation> element item
   (if present) and MUST precede any other element items in the
   [children] of the <asnx:module> element item.
Top   ToC   RFC4912 - Page 14
   Note that because of the way parameterized references are expanded in
   ASN.X (see Section 13), the modules in the Imports in the ModuleBody
   in the ModuleDefinition may not correspond exactly to the <import>
   element items.

5.3. TypeAssignment Translation

The translation of a TypeAssignment is an element item with the [local name] "namedType". An attribute item with the [local name] "name" SHALL be added to the [attributes] of the <namedType> element item. The [normalized value] of this attribute item is the typereference on the left-hand side of the assignment. An element item with the [local name] "annotation" MAY be added to the [children] of the <namedType> element item. The translation of the Type on the right-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedType> element item. Example MyType ::= INTEGER <namedType name="MyType" type="asnx:INTEGER"/>

5.4. ValueAssignment and XMLValueAssignment Translation

The translation of a ValueAssignment is an element item with the [local name] "namedValue". An attribute item with the [local name] "name" SHALL be added to the [attributes] of the <namedValue> element item. The [normalized value] of this attribute item is the valuereference on the left-hand side of the assignment. An element item with the [local name] "annotation" MAY be added to the [children] of the <namedValue> element item. The translation of the Type on the left-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedValue> element item. The translation of the Value on the right-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedValue> element item. Example myValue INTEGER ::= 10 <namedValue name="myValue" type="asnx:INTEGER" literalValue="10"/>
Top   ToC   RFC4912 - Page 15
   An XMLValueAssignment is converted into the equivalent
   ValueAssignment and then translated as a ValueAssignment.  Note that
   the ASN.X representation for a Value is unrelated to XMLTypedValue.

5.5. ValueSetTypeAssignment Translation

The translation of a ValueSetTypeAssignment is an element item with the [local name] "namedValueSet". An attribute item with the [local name] "name" SHALL be added to the [attributes] of the <namedValueSet> element item. The [normalized value] of this attribute item is the typereference on the left-hand side of the assignment. An element item with the [local name] "annotation" MAY be added to the [children] of the <namedValueSet> element item. The translation of the Type on the left-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedValueSet> element item. The translation of the ValueSet on the right-hand side of the assignment SHALL be added to the [children] of the <namedValueSet> element item. Example MyValueSet INTEGER ::= { 10 } <namedValueSet name="MyValueSet" type="asnx:INTEGER"> <valueSet> <literalValue>10</literalValue> </valueSet> </namedValueSet>

5.6. ObjectClassAssignment Translation

The translation of an ObjectClassAssignment is an element item with the [local name] "namedClass". An attribute item with the [local name] "name" SHALL be added to the [attributes] of the <namedClass> element item. The [normalized value] of this attribute item is the objectclassreference on the left-hand side of the assignment. An element item with the [local name] "annotation" MAY be added to the [children] of the <namedClass> element item. The translation of the ObjectClass on the right-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedClass> element item.
Top   ToC   RFC4912 - Page 16
   Example

      MY-CLASS ::= TYPE-IDENTIFIER

      <namedClass name="MY-CLASS" class="asnx:TYPE-IDENTIFIER"/>

5.7. ObjectAssignment Translation

The translation of an ObjectAssignment is an element item with the [local name] "namedObject". An attribute item with the [local name] "name" SHALL be added to the [attributes] of the <namedObject> element item. The [normalized value] of this attribute item is the objectreference on the left-hand side of the assignment. An element item with the [local name] "annotation" MAY be added to the [children] of the <namedObject> element item. The translation of the DefinedObjectClass on the left-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedObject> element item. The translation of the Object on the right-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedObject> element item. Example myObject TYPE-IDENTIFIER ::= { NULL IDENTIFIED BY { 1 3 14 3 2 26 } } <namedObject name="myObject" class="asnx:TYPE-IDENTIFIER"> <object> <field name="id" literalValue="1.3.14.3.2.26"/> <field name="Type" type="asnx:NULL"/> </object> </namedObject>

5.8. ObjectSetAssignment Translation

The translation of an ObjectSetAssignment is an element item with the [local name] "namedObjectSet". An attribute item with the [local name] "name" SHALL be added to the [attributes] of the <namedObjectSet> element item. The [normalized value] of this attribute item is the objectsetreference on the left-hand side of the assignment. An element item with the [local name] "annotation" MAY be added to the [children] of the <namedObjectSet> element item. The translation of the DefinedObjectClass on the left-hand side of the assignment SHALL be added to the [children] or [attributes] of the <namedObjectSet> element item. The translation of the ObjectSet on
Top   ToC   RFC4912 - Page 17
   the right-hand side of the assignment SHALL be added to the
   [children] or [attributes] of the <namedObjectSet> element item.

   Example

      MyObjectSet TYPE-IDENTIFIER ::= { myObject }

      <namedObjectSet name="MyObjectSet" class="asnx:TYPE-IDENTIFIER">
       <objectSet>
        <object ref="tns:myObject"/>
       </objectSet>
      </namedObjectSet>

5.9. ParameterizedAssignment Translation

The translation of an ASN.1 specification into ASN.X replaces any reference to a parameterized definition [X.683] with the definition expanded in-line. Consequently, there is no direct translation for a ParameterizedAssignment, though its definition may come into play in the translation of references to the parameterized definition (see Section 13).


(page 17 continued on part 2)

Next Section