idnits 2.17.1 draft-legg-xed-rxer-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3655. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3666. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3679. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? == In addition to a regular copyright notice, the document also has a copyright notice embedded in the text. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 71 longer pages, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1709 has weird spacing: '... violet orang...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 22, 2006) is 6332 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 2442 -- Looks like a reference, but probably isn't: '1' on line 2443 -- Looks like a reference, but probably isn't: '2' on line 2444 -- Looks like a reference, but probably isn't: '3' on line 1217 -- Looks like a reference, but probably isn't: '4' on line 1220 -- Looks like a reference, but probably isn't: '5' on line 1223 == Missing Reference: 'LIST' is mentioned on line 3620, but not defined == Missing Reference: 'ISO10646' is mentioned on line 3142, but not defined == Missing Reference: 'ATTRIBUTE' is mentioned on line 3620, but not defined == Missing Reference: 'GLUE' is mentioned on line 3704, but not defined -- No information found for draft-legg-xed-rxer-ei-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RXEREI' -- Possible downref: Non-RFC (?) normative reference: ref. 'UCS' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML10' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML11' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLNS10' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLNS11' -- Possible downref: Non-RFC (?) normative reference: ref. 'INFOSET' -- Possible downref: Non-RFC (?) normative reference: ref. 'XSD1' Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Legg 3 draft-legg-xed-rxer-07.txt eB2Bcom 4 Intended Category: Standards Track D. Prager 5 December 22, 2006 7 Robust XML Encoding Rules (RXER) for 8 Abstract Syntax Notation One (ASN.1) 10 Copyright (C) The IETF Trust (2006). 12 Status of This Memo 14 By submitting this Internet-draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Technical discussion of this document should take place on the XED 36 developers mailing list . Please send editorial 37 comments directly to the editor . Further 38 information is available on the XED website: www.xmled.info. 40 This Internet-Draft expires on 22 June 2007. 42 Abstract 44 This document defines a set of Abstract Syntax Notation One (ASN.1) 45 encoding rules, called the Robust XML Encoding Rules or RXER, that 46 produce an Extensible Markup Language (XML) representation for values 47 of any given ASN.1 data type. Rules for producing a canonical RXER 48 encoding are also defined. 50 Table of Contents 52 1. Introduction ....................................................3 53 2. Conventions .....................................................4 54 3. Definitions .....................................................5 55 4. Additional Basic Types ..........................................5 56 4.1. The Markup Type ............................................6 57 4.1.1. Self-Containment ....................................8 58 4.1.2. Normalization for Canonical Encoding Rules .........10 59 4.2. The AnyURI Type ...........................................12 60 4.3. The NCName Type ...........................................12 61 4.4. The Name Type .............................................12 62 4.5. The QName Type ............................................13 63 5. Expanded Names for ASN.1 Types .................................13 64 6. Encoding Rules .................................................15 65 6.1. Identifiers ...............................................16 66 6.2. Component Encodings .......................................17 67 6.2.1. Referenced Components ..............................17 68 6.2.2. Element Components .................................17 69 6.2.2.1. Namespace Properties for Elements .........19 70 6.2.2.2. Namespace Prefixes for Element Names ......21 71 6.2.3. Attribute Components ...............................22 72 6.2.3.1. Namespace Prefixes for Attribute Names ....22 73 6.2.4. Unencapsulated Components ..........................23 74 6.2.5. Examples ...........................................23 75 6.3. Standalone Encodings ......................................24 76 6.4. Embedded ASN.1 Values .....................................24 77 6.5. Type Referencing Notations ................................28 78 6.6. TypeWithConstraint, SEQUENCE OF Type and SET OF Type ......29 79 6.7. Character Data Translations ...............................29 80 6.7.1. Restricted Character String Types ..................30 81 6.7.2. BIT STRING .........................................31 82 6.7.3. BOOLEAN ............................................32 83 6.7.4. ENUMERATED .........................................33 84 6.7.5. GeneralizedTime ....................................34 85 6.7.6. INTEGER ............................................35 86 6.7.7. NULL ...............................................36 87 6.7.8. ObjectDescriptor ...................................37 88 6.7.9. OBJECT IDENTIFIER and RELATIVE-OID .................37 89 6.7.10. OCTET STRING ......................................37 90 6.7.11. QName .............................................38 91 6.7.11.1. Namespace Prefixes for Qualified Names ...38 92 6.7.12. REAL ..............................................39 93 6.7.13. UTCTime ...........................................40 94 6.7.14. CHOICE as UNION ...................................40 95 6.7.15. SEQUENCE OF as LIST ...............................43 96 6.8. Combining Types ...........................................43 97 6.8.1. CHARACTER STRING ...................................44 98 6.8.2. CHOICE .............................................44 99 6.8.3. EMBEDDED PDV .......................................45 100 6.8.4. EXTERNAL ...........................................45 101 6.8.5. INSTANCE OF ........................................45 102 6.8.6. SEQUENCE and SET ...................................45 103 6.8.7. SEQUENCE OF and SET OF .............................46 104 6.8.8. Extensible Combining Types .........................47 105 6.8.8.1. Unknown Elements in Extensions ............48 106 6.8.8.2. Unknown Attributes in Extensions ..........51 107 6.9. Open Type .................................................52 108 6.10. Markup ...................................................53 109 6.11. Namespace Prefixes for CRXER .............................54 110 6.12. Serialization ............................................56 111 6.12.1. Non-canonical Serialization .......................56 112 6.12.2. Canonical Serialization ...........................58 113 6.12.3. Unicode Normalization in XML Version 1.1 ..........60 114 6.13. Syntax-Based Canonicalization ............................61 115 7. Transfer Syntax Identifiers ....................................61 116 7.1. RXER Transfer Syntax ......................................61 117 7.2. CRXER Transfer Syntax .....................................61 118 8. Relationship to XER ............................................62 119 9. Security Considerations ........................................63 120 10. Acknowledgements ..............................................64 121 11. IANA Considerations ...........................................64 122 12. References ....................................................65 123 12.1. Normative References .....................................65 124 12.2. Informative References ...................................66 125 Appendix A. Additional Basic Definitions Module ...................67 127 1. Introduction 129 This document defines a set of Abstract Syntax Notation One (ASN.1) 130 [X.680] encoding rules, called the Robust XML Encoding Rules or RXER, 131 that produce an Extensible Markup Language (XML) [XML10][XML11] 132 representation of ASN.1 values of any given ASN.1 type. 134 An ASN.1 value is regarded as analogous to the content and attributes 135 of an XML element, or in some cases, just an XML attribute value. 136 The RXER encoding of an ASN.1 value is the well-formed and valid 137 content and attributes of an element, or an attribute value, in an 138 XML document [XML10][XML11] conforming to XML namespaces 139 [XMLNS10][XMLNS11]. Simple ASN.1 data types such as PrintableString, 140 INTEGER and BOOLEAN define character data content or attribute 141 values, while the ASN.1 combining types (i.e., SET, SEQUENCE, SET OF, 142 SEQUENCE OF and CHOICE) define element content and attributes. The 143 attribute and child element names are generally provided by the 144 identifiers of the components in combining type definitions, i.e., 145 elements and attributes correspond to the NamedType notation. 147 RXER leaves some formatting details to the discretion of the encoder, 148 so there is not a single unique RXER encoding for an ASN.1 value. 149 However, this document also defines a restriction of RXER, called the 150 Canonical Robust XML Encoding Rules (CRXER), which does produce a 151 single unique encoding for an ASN.1 value. Obviously, the CRXER 152 encoding of a value is also a valid RXER encoding of that value. The 153 restrictions on RXER to produce the CRXER encoding are interspersed 154 with the description of the rules for RXER. 156 Note that "ASN.1 value" does not mean a Basic Encoding Rules (BER) 157 [X.690] encoding. The ASN.1 value is an abstract concept that is 158 independent of any particular encoding. BER is just one possible way 159 to encode an ASN.1 value. This document defines an alternative way 160 to encode an ASN.1 value. 162 A separate document [RXEREI] defines encoding instructions [X.680-1] 163 that may be used in an ASN.1 specification to modify how values are 164 encoded in RXER, for example, to encode a component of a combining 165 ASN.1 type as an attribute rather than as a child element. A 166 pre-existing ASN.1 specification will not have RXER encoding 167 instructions, so any mention of encoding instructions in this 168 document can be ignored when dealing with such specifications. 169 Encoding instructions for other encoding rules have no effect on RXER 170 encodings. 172 2. Conventions 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are 176 to be interpreted as described in BCP 14, RFC 2119 [BCP14]. The key 177 word "OPTIONAL" is exclusively used with its ASN.1 meaning. 179 A reference to an ASN.1 production [X.680] (e.g., Type, NamedType) is 180 a reference to the text in an ASN.1 specification corresponding to 181 that production. 183 The specification of RXER makes use of definitions from the XML 184 Information Set (Infoset) [INFOSET]. In particular, information item 185 property names follow the Infoset convention of being shown in square 186 brackets, e.g., [local name]. Literal values of Infoset properties 187 are enclosed in double quotes, however the double quotes are not part 188 of the property values. In the sections that follow, 189 "information item" will be abbreviated to "item", e.g., "element 190 information item" is abbreviated to "element item". The term 191 "element" or "attribute" (without the "item") is referring to an 192 element or attribute in an XML document, rather than an information 193 item. 195 Literal character strings to be used in an RXER encoding appear 196 within double quotes, however the double quotes are not part of the 197 literal value and do not appear in the encoding. 199 This document uses the namespace prefix [XMLNS10][XMLNS11] "asnx:" to 200 stand for the namespace name "urn:ietf:params:xml:ns:asnx", uses the 201 namespace prefix "xs:" to stand for the namespace name 202 "http://www.w3.org/2001/XMLSchema" and uses the namespace prefix 203 "xsi:" to stand for the namespace name 204 "http://www.w3.org/2001/XMLSchema-instance", though in practice any 205 valid namespace prefixes are permitted in non-canonical RXER 206 encodings (namespace prefixes are deterministically generated for 207 CRXER). 209 The encoding instructions [X.680-1] referenced by name in this 210 specification are encoding instructions for RXER [RXEREI]. 212 Throughout this document, references to the Markup, AnyURI, NCName, 213 Name and QName ASN.1 types are references to the types described in 214 Section 4 and consolidated in the AdditionalBasicDefinitions module 215 in Appendix A. Any provisions associated with the reference do not 216 apply to types defined in other ASN.1 modules that happen to have 217 these same names. 219 Code points for characters [UCS][UNICODE] are expressed using the 220 Unicode convention U+n, where n is four to six hexadecimal digits, 221 e.g., the space character is U+0020. 223 3. Definitions 225 Definition (white space character): A white space character is a 226 space (U+0020), tab (U+0009), carriage return (U+000D) or line feed 227 (U+000A) character. 229 Definition (white space): White space is a sequence of one or more 230 white space characters. 232 Definition (line break): A line break is any sequence of characters 233 that is normalized to a line feed by XML End-of-Line Handling 234 [XML10][XML11]. 236 Definition (serialized white space): Serialized white space is a 237 sequence of one or more white space characters and/or line breaks. 239 Definition (declaring the default namespace): A namespace declaration 240 attribute item is declaring the default namespace if the [prefix] of 241 the attribute item has no value, the [local name] of the attribute 242 item is "xmlns" and the [normalized value] is not empty. 244 Definition (undeclaring the default namespace): A namespace 245 declaration attribute item is undeclaring the default namespace if 246 the [prefix] of the attribute item has no value, the [local name] of 247 the attribute item is "xmlns" and the [normalized value] is empty 248 (i.e., xmlns=""). 250 Definition (canonical namespace prefix): A canonical namespace prefix 251 is an NCName [XMLNS10] beginning with the letter 'n' (U+006E) 252 followed by a non-negative number string. A non-negative number 253 string is either the digit character '0' (U+0030), or a non-zero 254 decimal digit character (U+0031-U+0039) followed by zero, one or more 255 of the decimal digit characters '0' to '9' (U+0030-U+0039). 257 For convenience, a CHOICE type where the ChoiceType is subject to a 258 UNION encoding instruction will be referred to as a UNION type, and a 259 SEQUENCE OF type where the SequenceOfType is subject to a LIST 260 encoding instruction will be referred to as a LIST type. 262 4. Additional Basic Types 264 This section defines an ASN.1 type for representing markup in 265 abstract values, as well as basic types that are useful in encoding 266 instructions [RXEREI] and other related specifications [ASN.X]. 268 The ASN.1 definitions in this section are consolidated in the 269 AdditionalBasicDefinitions ASN.1 module in Appendix A. 271 4.1. The Markup Type 273 A value of the Markup ASN.1 type holds the [prefix], [attributes], 274 [namespace attributes] and [children] of an element item, i.e., the 275 content and attributes of an element. 277 RXER has special provisions for encoding values of the Markup type 278 (see Section 6.10). For other encoding rules, a value of the Markup 279 type is encoded according to the following ASN.1 type definition 280 (with AUTOMATIC TAGS): 282 Markup ::= CHOICE { 283 text SEQUENCE { 284 prolog UTF8String (SIZE(1..MAX)) OPTIONAL, 285 prefix NCName OPTIONAL, 286 attributes UTF8String (SIZE(1..MAX)) OPTIONAL, 287 content UTF8String (SIZE(1..MAX)) OPTIONAL 288 } 289 } 291 The text alternative of the Markup CHOICE type provides for the 292 [prefix], [attributes], [namespace attributes] and [children] of an 293 element item to be represented as serialized XML using the UTF-8 294 character encoding [UTF-8]. 296 Aside: The CHOICE allows for one or more alternative compact 297 representations of the content and attributes of an element to be 298 supported in a future specification. 300 With respect to some element item whose content and attributes are 301 represented by a value of the text alternative of the Markup type: 303 (1) the prolog component of the value contains text that, after line 304 break normalization, conforms to the XML prolog production 305 [XML10][XML11], 307 (2) the prefix component is absent if the [prefix] of the element 308 item has no value, otherwise the prefix component contains the 309 [prefix] of the element item, 311 (3) the attributes component of the value contains an XML 312 serialization of the [attributes] and [namespace attributes] of 313 the element item, if any, with each attribute separated from the 314 next by serialized white space, and 316 (4) the content component is absent if the [children] property of the 317 element item is empty, otherwise the content component of the 318 value contains an XML serialization of the [children] of the 319 element item. 321 All the components of a value of the Markup type MUST use the same 322 version of XML, either version 1.0 [XML10] or version 1.1 [XML11]. 323 If XML version 1.1 is used, then the prolog component MUST be present 324 and MUST have an XMLDecl for version 1.1. If the prolog component is 325 absent, then XML version 1.0 is assumed. 327 If the prefix component is present, then there MUST be a namespace 328 declaration attribute in the attributes component that defines that 329 namespace prefix (since an element whose content and attributes are 330 described by a value of Markup is required to be self-contained; see 331 Section 4.1.1). 333 Note that the prefix component is critically related to the NamedType 334 that has Markup as its type. If a Markup value is extracted from one 335 enclosing abstract value and embedded in another enclosing abstract 336 value (i.e., becomes associated with a different NamedType), then the 337 prefix may no longer be appropriate, in which case it will need to be 338 revised. It may also be necessary to add another namespace 339 declaration attribute to the attributes component so as to declare a 340 new namespace prefix. 342 Leading and/or trailing serialized white space is permitted in the 343 attributes component. A value of the attributes component consisting 344 only of serialized white space (i.e., no actual attributes) is 345 permitted. 347 The attributes and content components MAY contain entity references 348 [XML10][XML11]. If any entity references are used (other than 349 references to the predefined entities), then the prolog component 350 MUST be present and MUST contain entity declarations for those 351 entities in the internal or external subset of the document type 352 definition. 354 Example 356 Given the following ASN.1 module: 358 MyModule DEFINITIONS 359 AUTOMATIC TAGS ::= BEGIN 361 Message ::= SEQUENCE { 362 messageType INTEGER, 363 messageValue Markup 364 } 366 ENCODING-CONTROL RXER 368 TARGET-NAMESPACE "http://example.com/ns/MyModule" 370 COMPONENT message Message 371 -- a top-level NamedType 373 END 375 consider the following XML document: 377 378 380 ]> 381 382 1 383 385 &TRUE; 386 387 388 390 A Markup value corresponding to the content and attributes of the 391 element is, in ASN.1 value notation [X.680] (where 392 "lf" represents the line feed character): 394 text:{ 395 prolog { "", lf, 396 "", lf, 398 "]>", lf }, 399 attributes { " xmlns:ns=""http://www.example.com/ABD""", 400 lf, 401 " ns:foo=""1"" bar=""0""" }, 402 content { lf, 403 " &TRUE;", lf, 404 " ", lf, " " } 405 } 407 The following Markup value is an equivalent representation of the 408 content and attributes of the element: 410 text:{ 411 attributes { 412 "bar=""0"" ns:foo=""1"" ", 413 "xmlns:ns=""http://www.example.com/ABD""" }, 414 content { lf, 415 " true", lf, 416 " ", lf, " " } 417 } 419 By itself, the Markup ASN.1 type imposes no data type restriction on 420 the markup contained by its values and is therefore analogous to the 421 XML Schema anyType [XSD1]. 423 There is no ASN.1 basic notation that can directly impose the 424 constraint that the markup represented by a value of the Markup type 425 must conform to the markup allowed by a specific type definition. 426 However, certain encoding instructions (i.e., the reference encoding 427 instructions [RXEREI]) have been defined to have this effect. 429 4.1.1. Self-Containment 431 An element, its attributes and its content, including descendent 432 elements, may contain qualified names [XMLNS10][XMLNS11] as the names 433 of elements and attributes, in the values of attributes, and as 434 character data content of elements. The binding between namespace 435 prefix and namespace name for these qualified names is potentially 436 determined by the namespace declaration attributes of ancestor 437 elements (which in the Infoset representation are inherited as 438 namespace items in the [in-scope namespaces]). 440 In the absence of complete knowledge of the data type of an element 441 item whose content and attributes are described by a value of the 442 Markup type, it is not possible to determine with absolute certainty 443 which of the namespace items inherited from the [in-scope namespaces] 444 of the [parent] element item are significant in interpreting the 445 Markup value. The safe and easy option would be to assume that all 446 the namespace items from the [in-scope namespaces] of the [parent] 447 element item are significant and need to be retained within the 448 Markup value. When the Markup value is re-encoded, any of the 449 retained namespace items that do not appear in the 450 [in-scope namespaces] of the enclosing element item in the new 451 encoding could be made to appear by outputting corresponding 452 namespace declaration attribute items in the [namespace attributes] 453 of the enclosing element item. 455 From the perspective of the receiver of the new encoding, this 456 enlarges the set of attribute items in the [namespace attributes] 457 represented by the Markup value. 459 In addition, there is no guarantee that the sender of the new 460 encoding has recreated the original namespace declaration attributes 461 on the ancestor elements, so the [in-scope namespaces] of the 462 enclosing element item is likely to have new namespace declarations 463 that the receiver will retain and pass on in the 464 [namespace attributes] when it in turn re-encodes the Markup value. 466 This unbounded growth in the set of attribute items in the 467 [namespace attributes] defeats any attempt to produce a canonical 468 encoding. 470 The principle of self-containment is introduced to avoid this 471 problem. An element item (the subject element item) is 472 self-contained if the constraints of Namespaces in XML 1.0 [XMLNS10] 473 are satisfied (i.e., that prefixes are properly declared) and none of 474 the following bindings are determined by a namespace declaration 475 attribute item in the [namespace attributes] of an ancestor element 476 item of the subject element item: 478 (1) the binding between the [prefix] and [namespace name] of the 479 subject element item, 481 (2) the binding between the [prefix] and [namespace name] of any 482 descendant element item of the subject element item, 484 (3) the binding between the [prefix] and [namespace name] of any 485 attribute item in the [attributes] of the subject element item or 486 the [attributes] of any descendant element item of the subject 487 element item, 489 (4) the binding between the namespace prefix and namespace name of 490 any qualified name in the [normalized value] of any attribute 491 item in the [attributes] of the subject element item or the 492 [attributes] of any descendant element item of the subject 493 element item, or 495 (5) the binding between the namespace prefix and namespace name of 496 any qualified name represented by a series of character items 497 (ignoring processing instruction and comment items) in the 498 [children] of the subject element item or the [children] of any 499 descendant element item of the subject element item. 501 Aside: If an element is self-contained, then separating the 502 element from its parent does not change the semantic 503 interpretation of its name and any names in its content and 504 attributes. 506 A supposedly self-contained element in a received RXER encoding that 507 is in fact not self-contained SHALL be treated as an ASN.1 constraint 508 violation. 510 Aside: ASN.1 does not require an encoding with a constraint 511 violation to be immediately rejected, however the constraint 512 violation must be reported at some point, possibly in a separate 513 validation step. 515 Implementors should note that an RXER decoder will be able to detect 516 some, but not all, violations of self-containment. For example, it 517 can detect element and attribute names that depend on namespace 518 declarations appearing in the ancestors of a supposedly 519 self-contained element. Similarly, where type information is 520 available, it can detect qualified names in character data that 521 depend on the namespace declarations of ancestor elements. However, 522 type information is not always available, so some qualified names 523 will escape constraint checking. Thus the onus is on the creator of 524 the original encoding to ensure that element items required to be 525 self-contained really are completely self-contained. 527 An element item whose content and attributes are described by a value 528 of the Markup type MUST be self-contained. 530 Aside: The procedures in Section 6 take account of the 531 requirements for self-containment so that an RXER encoder 532 following these procedures will not create violations of 533 self-containment. 535 4.1.2. Normalization for Canonical Encoding Rules 537 Implementations are given some latitude in how the content and 538 attributes of an element are represented as an abstract value of the 539 Markup type, in part because an Infoset can have different equivalent 540 serializations. For example, the order of attributes and the amount 541 and kind of white space characters between attributes are irrelevant 542 to the Infoset representation. The content can also include one or 543 more elements corresponding to an ASN.1 top-level NamedType or having 544 a data type that is an ASN.1 type. It is only necessary to preserve 545 the abstract value for such elements, and a particular abstract value 546 can have different Infoset representations. 548 These two characteristics mean that when an RXER encoded value of the 549 Markup type is decoded, the components of the recovered Markup value 550 may not be exactly the same, character for character, as the original 551 value that was encoded, though the recovered value will be 552 semantically equivalent. 554 However, canonical ASN.1 encoding rules such as the Distinguished 555 Encoding Rules (DER) and the Canonical Encoding Rules (CER) [X.690], 556 which encode Markup values according to the ASN.1 definition of the 557 Markup type, depend on character for character preservation of string 558 values. This requirement can be accommodated if values of the Markup 559 type are normalized when they are encoded according to a set of 560 canonical encoding rules. 562 Aside: The RXER encoding and decoding of a Markup value might 563 change the character string components of the value from the 564 perspective of BER, but there will be a single, repeatable 565 encoding for DER. 567 A value of the Markup type will appear as the content and attributes 568 of an element in an RXER encoding. When the value is encoded using a 569 set of ASN.1 canonical encoding rules other than CRXER, the 570 components of the text alternative of the value MUST be normalized as 571 follows, by reference to the element as it would appear in a CRXER 572 encoding: 574 (1) The value of the prolog component SHALL be the XMLDecl 575 with no other leading or trailing 576 characters. 578 (2) If the element's name is unprefixed in the CRXER encoding, then 579 the prefix component SHALL be absent, otherwise the value of the 580 prefix component SHALL be the prefix of the element's name in the 581 CRXER encoding. 583 (3) Take the character string representing the element's attributes, 584 including namespace declarations, in the CRXER encoding. If the 585 first attribute is a namespace declaration that undeclares the 586 default namespace (i.e., xmlns=""), then remove it. Remove any 587 leading space characters. If the resulting character string is 588 empty then the attributes component SHALL be absent, otherwise 589 the value of the attributes component SHALL be the resulting 590 character string. 592 Aside: Note that the attributes of an element can change if an 593 RXER encoding is re-encoded in CRXER. 595 (4) If the element has no characters between the start-tag and 596 end-tag [XML11] in the CRXER encoding, then the content component 597 SHALL be absent, otherwise the value of the content component 598 SHALL be identical to the character string in the CRXER encoding 599 bounded by the element's start-tag and end-tag. 601 Aside: A consequence of invoking the CRXER encoding is that any 602 nested element corresponding to an ASN.1 top-level NamedType, or 603 indeed the element itself, will be normalized according to its 604 ASN.1 value rather than its Infoset representation. Likewise for 605 an element whose data type is an ASN.1 type. Section 6.4 606 describes how these situations can arise. 608 Aside: It is only through values of the Markup type that 609 processing instructions and comments can appear in CRXER 610 encodings. 612 If an application uses DER, but has no knowledge of RXER, then it 613 will not know to normalize values of the Markup type. If RXER is 614 deployed into an environment containing such applications, then 615 Markup values SHOULD be normalized, even when encoding using 616 non-canonical encoding rules. 618 4.2. The AnyURI Type 620 A value of the AnyURI ASN.1 type is a character string conforming to 621 the format of a Uniform Resource Identifier (URI) [URI]. 623 AnyURI ::= UTF8String (CONSTRAINED BY 624 { -- conforms to the format of a URI -- }) 626 4.3. The NCName Type 628 A value of the NCName ASN.1 type is a character string conforming to 629 the NCName production of Namespaces in XML 1.0 [XMLNS10]. 631 NCName ::= UTF8String (CONSTRAINED BY 632 { -- conforms to the NCName production of 633 -- Namespaces in XML 1.0 -- }) 635 Aside: The NCName production for Namespaces in XML 1.1 [XMLNS11] 636 allows a wider range of characters than the NCName production for 637 Namespaces in XML 1.0. The NCName type for ASN.1 is currently 638 restricted to the characters allowed by Namespaces in XML 1.0, 639 though this may change in a future specification of RXER. 641 4.4. The Name Type 643 A value of the Name ASN.1 type is a character string conforming to 644 the Name production of XML version 1.0 [XML10]. 646 Name ::= UTF8String (CONSTRAINED BY 647 { -- conforms to the Name production of XML -- }) 649 4.5. The QName Type 651 A value of the QName ASN.1 type describes an expanded name [XMLNS10], 652 which appears as a qualified name [XMLNS10] in an RXER encoding. 654 RXER has special provisions for encoding values of the QName type 655 (see Section 6.7.11). For other encoding rules, a value of the Qname 656 type is encoded according to the following ASN.1 type definition 657 (with AUTOMATIC TAGS): 659 QName ::= SEQUENCE { 660 namespace-name AnyURI OPTIONAL, 661 local-name NCName 662 } 664 The namespace-name component holds the namespace name of the expanded 665 name. If the namespace name of the expanded name has no value, then 666 the namespace-name component is absent. 668 Aside: A namespace name can be associated with ASN.1 types and 669 top-level NamedType instances by using the TARGET-NAMESPACE 670 encoding instruction. 672 The local-name component holds the local name of the expanded name. 674 5. Expanded Names for ASN.1 Types 676 A TypeAssignment in ASN.1 associates a typereference with a Type. 677 For RXER and Abstract Syntax Notation X (ASN.X) [ASN.X], a 678 TypeAssignment is also regarded as associating an expanded name 679 [XMLNS10] with the Type. The local name of the expanded name is the 680 typereference on the left hand side of the TypeAssignment. If the 681 target namespace [RXEREI] of the ASN.1 module in which the 682 TypeAssignment is defined is not absent, then the namespace name of 683 the expanded name is that target namespace, otherwise the namespace 684 name of the expanded name has no value. 686 A Type that is a BuiltinType or ReferencedType that is one of the 687 productions in Table 1 is regarded as a reference to a built-in ASN.1 688 type. These built-in types also have expanded names. In each case, 689 the local name of the expanded name is as indicated in Table 1 and 690 the namespace name of the expanded name is 691 "urn:ietf:params:xml:ns:asnx". 693 Table 1: Local Names for Built-in Types 695 +------------------------------------+-------------------+ 696 | ASN.1 Production | Local Name | 697 +====================================+===================+ 698 | BitStringType | | 699 | without a NamedBitList | BIT-STRING | 700 +------------------------------------+-------------------+ 701 | BooleanType | BOOLEAN | 702 +------------------------------------+-------------------+ 703 | CharacterStringType | | 704 | RestrictedCharacterStringType | | 705 | BMPString | BMPString | 706 | GeneralString | GeneralString | 707 | GraphicString | GraphicString | 708 | IA5String | IA5String | 709 | ISO646String | ISO646String | 710 | NumericString | NumericString | 711 | PrintableString | PrintableString | 712 | TeletexString | TeletexString | 713 | T61String | T61String | 714 | UniversalString | UniversalString | 715 | UTF8String | UTF8String | 716 | VideotexString | VideotexString | 717 | VisibleString | VisibleString | 718 | UnrestrictedCharacterStringType | CHARACTER-STRING | 719 +------------------------------------+-------------------+ 720 | EmbeddedPDVType | EMBEDDED-PDV | 721 | ExternalType | EXTERNAL | 722 +------------------------------------+-------------------+ 723 | IntegerType | | 724 | without a NamedNumberList | INTEGER | 725 +------------------------------------+-------------------+ 726 | NullType | NULL | 727 | ObjectIdentifierType | OBJECT-IDENTIFIER | 728 | OctetStringType | OCTET-STRING | 729 | RealType | REAL | 730 | RelativeOIDType | RELATIVE-OID | 731 +------------------------------------+-------------------+ 732 | UsefulType | | 733 | GeneralizedTime | GeneralizedTime | 734 | UTCTime | UTCTime | 735 | ObjectDescriptor | ObjectDescriptor | 736 +------------------------------------+-------------------+ 738 When the expanded name for an ASN.1 type is used in an RXER encoding 739 it appears as a qualified name [XMLNS10][XMLNS11]. The namespace 740 prefix for the qualified name is determined according to 741 Section 6.7.11.1. 743 If a compatible XML Schema translation of an ASN.1 specification is 744 provided (see Section 6.4), then that schema SHOULD associate the 745 same expanded name with the XML Schema translation of an ASN.1 type. 747 Definition (namespace-qualified reference): An ASN.1 Type is a 748 namespace-qualified reference if one of the following applies: 750 (1) the Type is a typereference (not a DummyReference) or an 751 ExternalTypeReference in a DefinedType in a ReferencedType, the 752 ASN.1 module in which the referenced type is defined has a 753 TARGET-NAMESPACE encoding instruction, the referenced type is not 754 directly or indirectly an open type [X.681] and the referenced 755 type is not directly or indirectly the Markup type (Section 4.1), 756 or 758 (2) the Type is a BuiltinType or ReferencedType that is one of the 759 productions in Table 1. 761 The type definition referenced by a namespace-qualified reference 762 will have an expanded name with a value for the namespace name. 764 6. Encoding Rules 766 With respect to RXER, ASN.1 abstract values are uniformly regarded as 767 analogous to the content and attributes of an element, or just an 768 attribute value, not complete elements or attributes in their own 769 right. Elements and attributes in an RXER encoding are defined by 770 ASN.1 NamedType notation. Since elements are the fundamental 771 discrete structures of an XML document, the notion of a NamedType 772 having a value that can be encoded is useful for descriptive purposes 773 (particularly for describing the RXER encoding of values of the ASN.1 774 combining types). There is no conceptual basis in X.680 [X.680] for 775 talking about the value of a NamedType, or its encoding, so the 776 terminology is introduced here. 778 Definition (value of a NamedType): An abstract value of the Type in a 779 NamedType is also a value of that NamedType. The RXER encoding of 780 the value of a NamedType is the RXER encoding of the abstract value 781 of the Type encapsulated according to the definition of that 782 NamedType. 784 This document does not refer to a value of a NamedType as being an 785 abstract value so as to remain consistent with X.680. An abstract 786 value is exclusively a value of an ASN.1 type. 788 A complete ASN.1 encoding is traditionally the encoding of an 789 abstract value, but it is more natural to think of an XML document as 790 being the RXER encoding of a value of a NamedType (because an XML 791 document has a single root element that contains all the other 792 elements and attributes). The ASN.1 basic notation does not allow a 793 NamedType to appear on its own, outside of an enclosing combining 794 type. That is, the basic notation does not have a concept analogous 795 to a global element or attribute definition. However, an ASN.1 796 specification may use an RXER encoding control section [RXEREI] to 797 define global elements and attributes using the NamedType notation. 798 A NamedType that is not contained in an ASN.1 type definition is 799 called a top-level NamedType [RXEREI]. Thus an RXER encoding would 800 typically be described as the encoding of a value of a top-level 801 NamedType. 803 Section 6.2 describes how a value of a NamedType is encoded. 804 Section 6.3 defines an alternative method for encoding the document 805 element of an XML document when a top-level NamedType is not 806 specified. Section 6.4 describes how the encodings of ASN.1 values 807 can be embedded in an XML document where the other parts of the 808 document are validated by an XML Schema. 810 The RXER encoding of an abstract value, or the encoding of a value of 811 a NamedType, is described as a translation into a synthetic Infoset, 812 which is then serialized as XML. This separation has been chosen for 813 descriptive convenience and is not intended to impose any particular 814 architecture on RXER implementations. An RXER encoder is free to 815 encode an ASN.1 value directly to XML provided the result is 816 equivalent to following the two stage procedure described in this 817 document. 819 The process of translating an abstract value into an Infoset is 820 described as producing either: 822 (1) a string of characters that either becomes part of the 823 [normalized value] of an attribute item or becomes character 824 items among the [children] of an enclosing element item, or 826 (2) a collection of zero or more attribute items contributing to the 827 [attributes] of an enclosing element item, plus a series of zero 828 or more character, element, processing instruction (PI) or 829 comment items contributing to the [children] of the enclosing 830 element item. 832 NamedType notation in the ASN.1 specification controls whether the 833 translation of an abstract value is encapsulated in an element item 834 or in an attribute item. 836 Sections 6.5 to 6.10 describe the translation of abstract values into 837 an Infoset for each of the ASN.1 type notations. 839 Section 6.11 describes post-processing of namespace prefixes for 840 CRXER encodings. 842 Section 6.12 specifies how the Infoset translation is serialized as 843 XML. 845 This specification assumes that the COMPONENTS OF transformation 846 specified in X.680, Clause 24.4 [X.680] has already been applied to 847 all relevant types. 849 Examples of RXER encodings in the following sections use a 850 start-tag and end-tag to hold attributes and delimit the 851 content. These start-tags and end-tags are for illustration only and 852 are not part of the encoding of an abstract value. In normal use, 853 the name of the enclosing element is provided by the context of the 854 type of the abstract value, e.g., a NamedType in an enclosing 855 SEQUENCE type. 857 An RXER decoder is a conforming XML processor [XML10][XML11]. 859 6.1. Identifiers 861 An identifier, as defined in ASN.1 notation (Clause 11.3 of X.680 863 [X.680]), is a character string that begins with a latin lowercase 864 letter (U+0061-U+007A) and is followed by zero, one or more latin 865 letters (U+0041-U+005A, U+0061-U+007A), decimal digits 866 (U+0030-U+0039), and hyphens (U+002D). A hyphen is not permitted to 867 be the last character and a hyphen is not permitted to be followed by 868 another hyphen. The case of letters in an identifier is always 869 significant. 871 ASN.1 identifiers are used for the [local name] of attribute and 872 element items, and may also appear in the character data content of 873 elements or the values of attributes. RXER encoding instructions can 874 be used to substitute an NCName [XMLNS10] for an identifier. 876 6.2. Component Encodings 878 The translation of the value of a NamedType is the translation of the 879 abstract value of the Type of the NamedType encapsulated according to 880 the definition of that NamedType. This section specifies the form of 881 this encapsulation. 883 6.2.1. Referenced Components 885 A value of a NamedType that is subject to a COMPONENT-REF encoding 886 instruction is translated as a value of the top-level NamedType 887 referenced by the encoding instruction. 889 6.2.2. Element Components 891 A value of a NamedType that is not subject to an ATTRIBUTE, 892 ATTRIBUTE-REF, GROUP or SIMPLE-CONTENT encoding instruction is 893 translated as an element item, either as a child element item added 894 to the [children] of the enclosing element item or as the document 895 element item added to the [children] and [document element] of the 896 document item. If the element item is a child element item, then the 897 [parent] is the enclosing element item, otherwise the [parent] is the 898 document item. 900 The [local name] of the element item is the local name of the 901 expanded name of the NamedType (see [RXEREI]). 903 Aside: If there are no NAME, ATTRIBUTE-REF, COMPONENT-REF, 904 ELEMENT-REF or REF-AS-ELEMENT encoding instructions, then the 905 local name of the expanded name of a NamedType is the same as the 906 identifier of the NamedType. 908 If the namespace name of the expanded name has no value, then the 909 [namespace name] of the element item has no value (i.e., the 910 element's name is not namespace qualified), otherwise the 911 [namespace name] is the namespace name of the expanded name. 913 If the type of the NamedType is directly or indirectly the Markup 914 type, then the [in-scope namespaces] and [namespace attributes] of 915 the element item are constructed as specified in Section 6.10, 916 otherwise the [in-scope namespaces] and [namespace attributes] of the 917 element item are constructed as specified in Section 6.2.2.1. 919 If the [namespace name] of the element item has no value, then the 920 [prefix] of the element item has no value, otherwise if the type of 921 the NamedType is not directly or indirectly the Markup type, then the 922 [prefix] of the element item is determined as specified in 923 Section 6.2.2.2, otherwise the [prefix] is determined by the Markup 924 value as specified in Section 6.10. 926 The element item becomes the enclosing element item for the 927 translation of the value of the Type of the NamedType. 929 For a non-canonical RXER encoding, if the type of the NamedType is 930 not directly or indirectly the Markup type, then PI and comment items 931 MAY be added to the [children] of the element item (before or after 932 any other items). The element item becomes the [parent] for each PI 933 and comment item. These particular PI and comment items in a 934 received RXER encoding MAY be discarded by an application. 936 Aside: There is no provision for representing comments and PIs in 937 ASN.1 abstract values of types other than the Markup type. These 938 items will be lost if the abstract value is re-encoded using a 939 different set of encoding rules. 941 For a non-canonical RXER encoding, an attribute item with the 942 [local name] "type" and the [namespace name] 943 "http://www.w3.org/2001/XMLSchema-instance" (i.e., xsi:type [XSD1]) 944 SHOULD be added to the [attributes] of the element item if the 945 corresponding NamedType is subject to a TYPE-AS-VERSION encoding 946 instruction and MAY be added to the [attributes] of the element item 947 if the Type of the corresponding NamedType is a namespace-qualified 948 reference (see Section 5). The [prefix] of this attribute item is 949 determined as specified in Section 6.2.3.1. The [normalized value] 950 of this attribute item is a qualified name for the expanded name of 951 the referenced type, with the namespace prefix determined as 952 specified in Section 6.7.11.1. The element item is the 953 [owner element] for the attribute item. 955 Aside: Where a compatible XML Schema translation of the ASN.1 956 specification has been provided, the xsi:type attribute indicates 957 to an XML Schema validator which type definition it should use for 958 validating the RXER encoding. 960 Aside: An xsi:type attribute is generally not permitted in a CRXER 961 encoding. Section 6.4 describes some circumstances where it is 962 required in a CRXER encoding. An xsi:type attribute might also 963 appear in a CRXER encoding if it is contained in a value of the 964 Markup type. 966 For a non-canonical RXER encoding, if the type of the NamedType is 967 not directly or indirectly the Markup type, then attribute items with 968 the [local name] "schemaLocation" or "noNamespaceSchemaLocation" and 969 the [namespace name] "http://www.w3.org/2001/XMLSchema-instance" 970 [XSD1] MAY be added to the [attributes] of the element item. The 972 [prefix] for each of these attribute items is determined as specified 973 in Section 6.2.3.1. The [normalized value] of these attribute items 974 MUST reference a compatible XML Schema translation of the ASN.1 975 specification. The element item is the [owner element] for the 976 attribute items. 978 6.2.2.1. Namespace Properties for Elements 980 This section describes how the [in-scope namespaces] and 981 [namespace attributes] of an element item are constructed when the 982 content and attributes of the element item are not described by a 983 value of the Markup type (otherwise, see Section 6.10). 985 The [in-scope namespaces] property of the element item initially 986 contains only the mandatory namespace item for the "xml" prefix 987 [INFOSET]. 989 For a CRXER encoding, if the element item is not the 990 [document element] of the document item and the [in-scope namespaces] 991 property of the element item's [parent] contains a namespace item for 992 the default namespace, then a namespace declaration attribute item 993 that undeclares the default namespace (see Section 3) SHALL be added 994 to the element item's [namespace attributes]. 996 Definition (default namespace restricted): With respect to an element 997 item, the default namespace is restricted if: 999 (1) the [namespace name] of the element item has no value (i.e., the 1000 element's name is not namespace qualified), or 1002 (2) the element item is the enclosing element item for a value of the 1003 UNION type where the member attribute will be required (see 1004 Section 6.7.14), or 1006 (3) the element item is the enclosing element item for a value of the 1007 QName type where the namespace-name component is absent (see 1008 Section 6.7.11). This includes the case where the translation of 1009 the QName value is contained in the [normalized value] of an 1010 attribute item in the [attributes] of the element item. 1012 For a non-canonical RXER encoding, if the element item is not the 1013 [document element] of the document item and the [in-scope namespaces] 1014 property of the element item's [parent] contains a namespace item for 1015 the default namespace, then either: 1017 (1) that item is copied to the [in-scope namespaces] of the element 1018 item, or 1020 (2) a namespace declaration attribute item that declares the default 1021 namespace is added to the element item's [namespace attributes] 1022 (the namespace name is the encoder's choice) and an equivalent 1023 namespace item is added to the [in-scope namespaces] of the 1024 element item, or 1026 (3) a namespace declaration attribute item that undeclares the 1027 default namespace is added to the element item's 1028 [namespace attributes]. 1030 Options (1) and (2) SHALL NOT be used if the default namespace is 1031 restricted with respect to the element item. 1033 For a CRXER encoding, if the element item is not the 1034 [document element] of the document item and the element item is not 1035 required to be self-contained, then all the namespace items in the 1036 [in-scope namespaces] of the [parent], excluding the namespace item 1037 for the "xml" prefix and any namespace item for the default 1038 namespace, are copied to the [in-scope namespaces] of the element 1039 item. 1041 For a non-canonical RXER encoding, if the element item is not the 1042 [document element] of the document item and the element item is not 1043 required to be self-contained, then any subset (including none or 1044 all) of the namespace items in the [in-scope namespaces] of the 1045 [parent], excluding certain items, is copied to the 1046 [in-scope namespaces] of the element item. The excluded items that 1047 MUST NOT be copied are: the namespace item for the "xml" prefix, any 1048 namespace item for the default namespace and any namespace item that 1049 matches the [prefix], but not the [namespace name], of a namespace 1050 item retained for the re-encoding of an unknown attribute item (see 1051 Section 6.8.8) or an unknown alternative of a UNION (see 1052 Section 6.7.14). 1054 Aside: The descriptive approach used by this document only allows 1055 a namespace prefix to be used by a new namespace item if it is not 1056 currently used by another namespace item in the 1057 [in-scope namespaces]. By not inheriting a namespace item, the 1058 prefix of that namespace is again available for reuse without fear 1059 of breaking an existing dependency on the prefix. 1061 Element items that are required to be self-contained inherit none of 1062 the namespace items in the [in-scope namespaces] of the [parent]. 1064 Any namespace item that is retained for the re-encoding of an unknown 1065 attribute item (Section 6.8.8) or an unknown alternative of a UNION 1066 (Section 6.7.14) and which is not in the [in-scope namespaces] of the 1067 element item MUST be added to the [in-scope namespaces]. An 1068 equivalent namespace declaration attribute item MUST be added to the 1069 [namespace attributes] of the element item. 1071 Definition (unused namespace prefix): A namespace prefix is unused if 1072 it does not match the [prefix] of any namespace item in the 1073 [in-scope namespaces] of the element item. 1075 For a non-canonical RXER encoding, if the type of the NamedType is 1076 not directly or indirectly the Markup type, then additional namespace 1077 declaration attribute items for currently unused namespace prefixes 1078 MAY be added to the [namespace attributes] of the element item. An 1079 equivalent namespace item MUST be added to the [in-scope namespaces] 1080 of the element item for each additional namespace declaration 1081 attribute item. 1083 For a non-canonical RXER encoding, if the type of the NamedType is 1084 not directly or indirectly the Markup type and the 1085 [in-scope namespaces] property of the element item does not contain a 1086 namespace item for the default namespace and the default namespace is 1087 not restricted with respect to the element item, then a namespace 1088 declaration attribute item for the default namespace MAY be added to 1089 the [namespace attributes] of the element item, in which case an 1090 equivalent namespace item MUST be added to the [in-scope namespaces] 1091 of the element item. 1093 Whenever a namespace declaration attribute item is added to an 1094 element item's [namespace attributes] the [owner element] of the 1095 attribute item is set to the element item. 1097 6.2.2.2. Namespace Prefixes for Element Names 1099 This section describes how the [prefix] of an element item is 1100 determined when the element item has a value for its [namespace name] 1101 and the content and attributes of the element item are not described 1102 by a value of the Markup type (otherwise, see Section 6.10). 1104 For a CRXER encoding, if the [namespace name] of the element item has 1105 a value, then the [prefix] of the element item is any unused 1106 non-canonical namespace prefix, unless the [in-scope namespaces] 1107 property of the element item contains a namespace item with the same 1108 [namespace name] as the element item, in which case the [prefix] of 1109 that namespace item SHALL be used as the [prefix] of the element 1110 item. 1112 Aside: These prefixes will be rewritten to canonical namespace 1113 prefixes during the final step in producing the Infoset 1114 translation (see Section 6.11). Canonical namespace prefixes are 1115 not used here in the first instance because canonicalization 1116 depends on knowing the final [namespace attributes] produced by 1117 encoding the abstract value of the type of the NamedType. If an 1118 implementation looks ahead to determine this final set prior to 1119 translating the abstract value, then it can assign the appropriate 1120 canonical namespace prefix in this step and skip the rewriting 1121 step. 1123 For a non-canonical RXER encoding, if the [namespace name] has a 1124 value, then the [prefix] of the element item is any unused namespace 1125 prefix, unless the [in-scope namespaces] property of the element item 1126 contains a namespace item with the same [namespace name] as the 1127 element item, in which case the [prefix] of that namespace item MAY 1128 be used as the [prefix] of the element item. Note that the [prefix] 1129 of a namespace item for the default namespace has no value. 1131 If the [prefix] of the element item is an unused namespace prefix, 1132 then a namespace declaration attribute item associating the namespace 1133 prefix with the namespace name MUST be added to the 1135 [namespace attributes] of the element item, and a corresponding 1136 namespace item MUST be added to the [in-scope namespaces] of the 1137 element item. 1139 Aside: The [local name] of the namespace declaration attribute 1140 item is the same as the [prefix] of the element item, the 1141 [namespace name] of the attribute item is 1142 "http://www.w3.org/2000/xmlns/" and the [normalized value] of the 1143 attribute item is the same as the [namespace name] of the element 1144 item. The namespace item has the same [prefix] and 1145 [namespace name] as the element item. 1147 6.2.3. Attribute Components 1149 A value of a NamedType subject to an ATTRIBUTE or ATTRIBUTE-REF 1150 encoding instruction is translated as an attribute item added to the 1151 [attributes] of the enclosing element item (which becomes the 1152 [owner element] of the attribute item). 1154 The [local name] of the attribute item is the local name of the 1155 expanded name of the NamedType (see [RXEREI]). 1157 If the namespace name of the expanded name has no value, then the 1158 [namespace name] of the attribute item has no value, otherwise the 1159 [namespace name] is the namespace name of the expanded name. 1161 If the [namespace name] has a value, then the [prefix] of the 1162 attribute item is determined as specified in Section 6.2.3.1, 1163 otherwise the [prefix] of the attribute item has no value. 1165 The [normalized value] of the attribute item is the translation of 1166 the value of the Type of the NamedType. 1168 For completeness, the [specified] property is set to true, the 1169 [attribute type] has no value and the value of the [references] 1170 property is set to unknown. 1172 6.2.3.1. Namespace Prefixes for Attribute Names 1174 This section applies when an attribute item with a value for its 1175 [namespace name] is added to the [attributes] of an element item. 1177 For a CRXER encoding, the [prefix] of the attribute item is any 1178 unused non-canonical namespace prefix, unless the 1179 [in-scope namespaces] property of the [owner element] contains a 1180 namespace item with a value for the [prefix] (i.e., is not a 1181 namespace item for the default namespace) and the same 1182 [namespace name] as the attribute item, in which case the [prefix] of 1183 that namespace item SHALL be used as the [prefix] of the attribute 1184 item. 1186 For a non-canonical RXER encoding, the [prefix] of the attribute item 1187 is any unused namespace prefix, unless the [in-scope namespaces] 1188 property of the [owner element] contains a namespace item with a 1189 value for the [prefix] and the same [namespace name] as the attribute 1190 item, in which case the [prefix] of that namespace item MAY be used 1191 as the [prefix] of the attribute item. 1193 If the [prefix] of the attribute item is an unused namespace prefix, 1194 then a namespace declaration attribute item associating the namespace 1195 prefix with the namespace name MUST be added to the 1196 [namespace attributes] of the [owner element], and a corresponding 1197 namespace item MUST be added to the [in-scope namespaces] of the 1198 [owner element]. 1200 6.2.4. Unencapsulated Components 1202 A value of a NamedType subject to a GROUP or SIMPLE-CONTENT encoding 1203 instruction is translated as the value of the Type of the NamedType, 1204 i.e., without encapsulation in an element item or attribute item. 1205 Consequently, the enclosing element item for the translation of the 1206 value of the NamedType is also the enclosing element item for the 1207 translation of the value of the Type of the NamedType. 1209 6.2.5. Examples 1211 Consider this type definition: 1213 CHOICE { 1214 one [0] BOOLEAN, 1215 two [1] [RXER:ATTRIBUTE] INTEGER, 1216 three [2] [RXER:NAME AS "THREE"] OBJECT IDENTIFIER, 1217 four [3] [RXER:ATTRIBUTE-REF { 1218 namespace-name "http://www.example.com", 1219 local-name "foo" }] UTF8String, 1220 five [4] [RXER:ELEMENT-REF { 1221 namespace-name "http://www.example.com", 1222 local-name "bar" }] Markup, 1223 six [5] [RXER:GROUP] SEQUENCE { 1224 seven [0] [RXER:ATTRIBUTE] INTEGER, 1225 eight [1] INTEGER 1226 } 1227 } 1229 The content and attributes of each of the following elements 1230 are the RXER encoding of a value of the above type: 1232 1233 true 1234 1236 1238 1239 2.5.4.3 1240 1242 1245 1246 another string 1247 1249 1250 300 1251 1253 6.3. Standalone Encodings 1255 A typical RXER encoding is the encoding of a value of a nominated 1256 top-level NamedType. An abstract value MAY be encoded as an XML 1257 document without nominating an explicit top-level NamedType by 1258 invoking a Standalone RXER Encoding or Standalone CRXER Encoding. 1260 In a Standalone RXER Encoding or Standalone CRXER Encoding, the 1261 abstract value is encoded as the value of a notional NamedType where 1262 the identifier of the NamedType is "value" and the Type of the 1263 NamedType is the type of the abstract value. The NamedType is 1264 assumed to be subject to no encoding instructions. 1266 Aside: Thus the element item corresponding to the document element 1267 will have the [local name] "value" and no value for the 1268 [namespace name] and [prefix]. 1270 If RXER is chosen as the transfer syntax in an EMBEDDED PDV value, 1271 then the data-value OCTET STRING SHALL contain a Standalone RXER 1272 encoding. 1274 If CRXER is chosen as the transfer syntax in an EMBEDDED PDV value, 1275 then the data-value OCTET STRING SHALL contain a Standalone CRXER 1276 encoding. 1278 If RXER is chosen as the transfer syntax in an EXTERNAL value, then 1279 the octet-aligned OCTET STRING or arbitrary BIT STRING SHALL contain 1280 a Standalone RXER encoding. 1282 If CRXER is chosen as the transfer syntax in an EXTERNAL value, then 1283 the octet-aligned OCTET STRING or arbitrary BIT STRING SHALL contain 1284 a Standalone CRXER encoding. 1286 6.4. Embedded ASN.1 Values 1288 The reference encoding instructions [RXEREI] allow XML Schema 1289 definitions to be referenced from an ASN.1 specification. It is also 1290 possible to reference an ASN.1 type or top-level NamedType from an 1291 XML Schema definition, or from an information item validated by an 1292 XML Schema wildcard. The manner in which an XML Schema definition 1293 references an ASN.1 type or top-level NamedType has an effect on the 1294 CRXER encoding of a value of the type or top-level NamedType. 1296 This section also applies to XML Schema definitions that validate 1297 information items that are contained in a value of the Markup type. 1299 Aside: So the document element of an XML document might be 1300 described by an XML Schema definition that at some point 1301 references an ASN.1 definition that uses a reference encoding 1302 instruction to reference another XML Schema definition that then 1303 references another ASN.1 definition, and so on. 1305 In each of the following cases, an element or attribute item is only 1306 permitted to be, or to encapsulate, an RXER Infoset translation of an 1307 ASN.1 value if an XML Schema element declaration or ASN.1 NamedType 1308 is known for the [parent] element item ([owner element] in the case 1309 of an attribute declaration), for the [parent] of the [parent] 1310 element item, and so on, to the document element of the XML document. 1311 This condition is not satisfied by a NamedType where the Type is 1312 directly or indirectly the Markup type and the NamedType is not 1313 subject to a reference encoding instruction. 1315 Aside: An element declaration becomes known for an element item 1316 through assessment [XSD1]. A NamedType becomes known for an 1317 element item through decoding. 1319 Aside: If an XML Schema element declaration or ASN.1 NamedType is 1320 not known for an element item, then the type of the element item 1321 and the type of every nested element item are treated as unknown. 1322 Although an xsi:type attribute definitively identifies the type of 1323 an element item even if an element declaration for the element 1324 item is not known, this attribute is generally optional in an RXER 1325 encoding and so cannot be relied upon when seen in isolation from 1326 an element declaration. Although only top-level NamedType 1327 instances can have namespace-qualified names in the current RXER 1328 specification, a future version may allow nested NamedType 1329 instances to also have namespace-qualified names, in which case it 1330 will not necessarily be possible to distinguish a nested NamedType 1331 from a top-level NamedType without knowledge of the type of the 1332 [parent] element item. 1334 An ASN.1 type with an expanded name (Section 5) MAY be referenced by 1335 the type attribute of an XML Schema element declaration. The 1336 reference takes the form of a qualified name for the expanded name. 1337 An element item validated by such an element declaration encapsulates 1338 the Infoset translation of an abstract value of the ASN.1 type. The 1339 [namespace name] and [local name] of the element item are determined 1340 by the XML Schema element declaration. The remaining properties are 1341 determined according to RXER. The element item MUST be 1342 self-contained for a CRXER encoding. 1344 Aside: The element item is not required to be self-contained for a 1345 non-canonical RXER encoding. 1347 A top-level NamedType MAY be referenced by the ref attribute of an 1348 XML Schema element declaration if the NamedType is not subject to an 1349 ATTRIBUTE encoding instruction. The reference takes the form of a 1350 qualified name for the expanded name of the top-level NamedType 1352 [RXEREI]. An element item validated by such an element declaration 1353 is the Infoset translation of a value of the referenced top-level 1354 NamedType. All the properties of the element item are determined 1355 according to RXER. The element item MUST be self-contained for a 1356 CRXER encoding. 1358 A top-level NamedType MAY be referenced by the ref attribute of an 1359 XML Schema attribute declaration if the NamedType is subject to an 1360 ATTRIBUTE encoding instruction and the definition of the type of the 1361 NamedType does not depend on the QName type in any way. An attribute 1362 item validated by such an attribute declaration is the Infoset 1363 translation of a value of the referenced top-level NamedType, except 1364 that whatever valid [prefix] is initially chosen for the attribute 1365 item MUST be preserved in any re-encoding. The remaining properties 1366 of the attribute item are determined according to RXER. 1368 Aside: The exclusion of the QName type means that the attribute 1369 value is not dependent upon any namespace declarations of its 1370 parent element item. 1372 An element item that is validated by an XML Schema element 1373 declaration that has the ur-type (i.e., anyType) as its type 1374 definition MAY encapsulate the Infoset translation of a value of an 1375 ASN.1 type with an expanded name. The [namespace name] and 1376 [local name] of the element item are determined by the XML Schema 1377 element declaration. The remaining properties of the element item 1378 are determined according to RXER. The [attributes] of the element 1379 item SHALL contain an attribute item with the [local name] "type" and 1380 the [namespace name] "http://www.w3.org/2001/XMLSchema-instance" 1381 (i.e., an xsi:type attribute). The [prefix] of this attribute item 1382 is determined as specified in Section 6.2.3.1. The 1383 [normalized value] of this attribute item is a qualified name for the 1384 expanded name of the ASN.1 type, with the namespace prefix determined 1385 as specified in Section 6.7.11.1. The element item MUST be 1386 self-contained for a CRXER encoding. 1388 An element item that is validated by an XML Schema wildcard (i.e., 1389 ) MAY be the Infoset translation of a value of a top-level 1390 NamedType that is not subject to an ATTRIBUTE encoding instruction 1391 and comes from an ASN.1 module with a target namespace [RXEREI] that 1392 satisfies the namespace constraint of the wildcard. All the 1393 properties of the element item are determined according to RXER. The 1394 element item MUST be self-contained for a CRXER encoding. 1396 An attribute item that is validated by an XML Schema wildcard (i.e., 1397 ) MAY be the Infoset translation of a value of a 1398 top-level NamedType if the NamedType is subject to an ATTRIBUTE 1399 encoding instruction, comes from an ASN.1 module with a target 1400 namespace that satisfies the namespace constraint of the wildcard and 1401 has a type that does not depend on the QName type in any way. 1402 Whatever valid [prefix] is initially chosen for the attribute item 1403 MUST be preserved in any re-encoding. The remaining properties of 1404 the attribute item are determined according to RXER. 1406 No other mechanisms for referencing an ASN.1 type or top-level 1407 NamedType from a different XML schema language are supported in this 1408 version of RXER. In particular, this excludes an ASN.1 type being 1409 used as the base type in an XML Schema derivation by extension or 1410 restriction, as a member type for an XML Schema union type, as an 1411 item type for an XML Schema list type or as the type in an XML Schema 1412 attribute declaration. 1414 A fully conformant RXER implementation will understand both ASN.1 and 1415 XML Schema and will recognize the transitions between information 1416 items controlled by ASN.1 definitions and those controlled by 1417 XML Schema definitions. However, a purely XML Schema validator used 1418 to assess the validity of an RXER encoding will perceive any 1419 reference to an ASN.1 type or top-level NamedType as an unresolved 1420 reference. In order to enable such assessment, it is desirable to 1421 provide an XML Schema translation of the ASN.1 definitions being 1422 referenced from an XML Schema. Although XML Schema and ASN.1 are 1423 broadly similar, they each have unique features that cannot be 1424 adequately expressed in the other language, so a semantically 1425 equivalent translation is not possible in the general case. 1426 Fortunately, to simply achieve successful assessment it is sufficient 1427 for the XML Schema translation of an ASN.1 specification to be 1428 compatible with that ASN.1 specification. That is, the XML Schema 1429 translation MUST be constructed such that every correct RXER encoding 1430 is assessed as valid. Although not ideal, it is acceptable for the 1431 XML Schema to assess some incorrect RXER encodings as also being 1432 valid (a conformant RXER decoder will, of course, reject such an 1433 encoding). 1435 The simplest compatible XML Schema translation of an ASN.1 module is 1436 one in which every type is equivalent to the XML Schema ur-type. For 1437 example, given an ASN.1 type with the reference name MyType, a 1438 sufficient compatible XML Schema type definition is: 1440 1441 1442 1444 1445 1446 1448 OR 1450 1451 1452 1453 1454 1456 Aside: Because of the possible presence of an asnx:context 1457 attribute (Section 6.8.8.1), it is easiest to assume that all 1458 ASN.1 types translate into XML Schema complex types. 1460 Given an ASN.1 top-level NamedType that is not subject to an 1461 ATTRIBUTE encoding instruction and has the reference name myElement, 1462 a sufficient compatible XML Schema element declaration is: 1464 1466 Given an ASN.1 top-level NamedType that is subject to an ATTRIBUTE 1467 encoding instruction and has the reference name myAttribute, a 1468 sufficient compatible XML Schema attribute declaration is: 1470 1472 An application specification that mixes ASN.1 and XML Schema is free 1473 to provide a stricter translation of its ASN.1 definitions, however a 1474 more thorough treatment for translating an ASN.1 module into an 1475 XML Schema is out of scope for this document. 1477 6.5. Type Referencing Notations 1479 A value of a type with a defined type name is translated according to 1480 the type definition on the right hand side of the type assignment for 1481 the type name. 1483 A value of a type denoted by the use of a parameterized type with 1484 actual parameters is translated according to the parameterized type 1485 with the DummyReferences [X.683] substituted with the actual 1486 parameters. 1488 A value of a constrained type is translated as a value of the type 1489 without the constraint. See X.680 [X.680] and X.682 [X.682] for the 1490 details of ASN.1 constraint notation. 1492 A prefixed type [X.680-1] associates an encoding instruction with a 1493 type. A value of a prefixed type is translated as a value of the 1494 type without the prefix. 1496 Aside: This does not mean that RXER encoding instructions are 1497 ignored. It is simply easier to describe their effects in 1498 relation to specific built-in types, rather than as the 1499 translation of a value of a prefixed type. 1501 A tagged type is a special case of a prefixed type. A value of a 1502 tagged type is translated as a value of the type without the tag. 1503 ASN.1 tags do not appear in the XML encodings defined by this 1504 document. 1506 A value of a fixed type denoted by an ObjectClassFieldType is 1507 translated according to that fixed type (see Section 6.9 for the case 1508 of an ObjectClassFieldType denoting an open type). 1510 A value of a selection type is translated according to the type 1511 referenced by the selection type. Note that component encoding 1512 instructions are not inherited by the type referenced by a selection 1513 type [RXEREI]. 1515 A value of a type described by TypeFromObject notation [X.681] is 1516 translated according to the denoted type. 1518 A value of a type described by ValueSetFromObjects notation [X.681] 1519 is translated according to the governing type. 1521 6.6. TypeWithConstraint, SEQUENCE OF Type and SET OF Type 1523 For the purposes of this document, a TypeWithConstraint is treated as 1524 if it were the parent type [X.680] (either a SEQUENCE OF or SET OF 1525 type). 1527 For example, 1529 SEQUENCE SIZE(1..MAX) OF SomeType 1531 is treated like 1533 SEQUENCE OF SomeType 1535 Additionally, a "SEQUENCE OF Type" (including the case where it is 1536 the parent type for a TypeWithConstraint) is treated as if it were a 1537 "SEQUENCE OF NamedType", where the identifier of the NamedType is 1538 assumed to be "item". Similarly, a "SET OF Type" (including the case 1539 where it is the parent type for a TypeWithConstraint) is treated as 1540 if it were a "SET OF NamedType", where the identifier of the 1541 NamedType is assumed to be "item". 1543 For example, 1545 SEQUENCE SIZE(1..MAX) OF SomeType 1547 is ultimately treated like 1549 SEQUENCE OF item SomeType 1551 6.7. Character Data Translations 1553 For the majority of ASN.1 built-in types, encodings of values of 1554 those types never have element content. The encoding of a value of 1555 an ASN.1 combining type (except a UNION or LIST type) typically has 1556 element content. 1558 For those types that do not produce element content, the translation 1559 of an abstract value is described as a character string of ISO 10646 1560 characters [UCS]. This character data translation will either be 1561 destined to become part of the [normalized value] of an attribute 1562 item, or a series of character items in the [children] of an element 1563 item (which becomes the [parent] for the character items). The case 1564 that applies is determined in accordance with Section 6.2. 1566 For a non-canonical RXER encoding, if the type of the abstract value 1567 is not directly or indirectly a restricted character string type, the 1568 NULL type or a UNION type, then leading and/or trailing white space 1569 characters MAY be added to the character data translation. 1571 Aside: White space characters are significant in the encoding of a 1572 value of a restricted character string type and a restricted 1573 character string type can be a member type of a UNION type. The 1574 encoding of a NULL value produces no character data. 1576 Aside: Optional white space characters are not permitted in a 1577 CRXER encoding. 1579 For a non-canonical RXER encoding, if the type of the abstract value 1580 is directly or indirectly the AnyURI, NCName or Name type, then 1581 leading and trailing white space characters MAY be added to the 1582 character data translation. 1584 Aside: These types are indirectly a restricted character string 1585 type (UTF8String), however their definitions exclude white space 1586 characters, so any white space characters appearing in an encoding 1587 are not part of the abstract value and can be safely ignored. 1588 This exception does not apply to other subtypes of a restricted 1589 character string type that happen to exclude white space 1590 characters. 1592 6.7.1. Restricted Character String Types 1594 The character data translation of a value of a restricted character 1595 string type is the sequence of characters in the string. 1597 Depending on the ASN.1 string type, and an application's internal 1598 representation of that string type, a character may need to be 1599 translated to or from the equivalent ISO 10646 character code [UCS]. 1600 The NumericString, PrintableString, IA5String, VisibleString 1601 (ISO646String), BMPString, UniversalString and UTF8String character 1602 encodings use the same character codes as ISO 10646. For the 1603 remaining string types (GeneralString, GraphicString, TeletexString, 1604 T61String and VideotexString) see X.680 [X.680]. 1606 The null character (U+0000) is not a legal character for XML. It is 1607 omitted from the character data translation of a string value. 1609 Certain other control characters are legal for XML version 1.1, but 1610 not for version 1.0. If any string value contains these characters, 1611 then the RXER encoding must use XML version 1.1 (see Section 6.12). 1613 All white space characters in the RXER encoding of a value of a 1614 restricted character string type (excluding the AnyURI, NCName and 1615 Name subtypes) are significant, i.e., part of the abstract value. 1617 Examples 1619 The content of each of the following elements is the RXER 1620 encoding of an IA5String value: 1622 Don't run with scissors! 1623 Markup (e.g., <value>) has to be escaped. 1625 Markup (e.g., ]]>) 1626 has to be escaped. 1628 6.7.2. BIT STRING 1630 The character data translation of a value of the BIT STRING type is 1631 either a binary digit string, a hexadecimal digit string or a list of 1632 bit names. 1634 A binary digit string is a sequence of zero, one or more of the 1635 binary digit characters '0' and '1' (i.e., U+0030 and U+0031). Each 1636 bit in the BIT STRING value is encoded as a binary digit in order 1637 from the first bit to the last bit. 1639 For a non-canonical RXER encoding, if the BIT STRING type has a 1640 NamedBitList, then trailing zero bits MAY be omitted from a binary 1641 digit string. 1643 A hexadecimal digit string is permitted if and only if the number of 1644 bits in the BIT STRING value is zero or a multiple of eight and the 1645 character data translation is destined for the [children] of an 1646 element item. 1648 A hexadecimal digit string is a sequence of zero, one or more pairs 1649 of the hexadecimal digit characters '0'-'9', 'A'-'F' and 'a'-'f' 1650 (i.e., U+0030-U+0039, U+0041-U+0046 and U+0061-U+0066). Each group 1651 of eight bits in the BIT STRING value is encoded as a pair of 1652 hexadecimal digits where the first bit is the most significant. An 1653 odd number of hexadecimal digits is not permitted. The characters 1654 'a'-'f' (i.e., U+0061-U+0066) SHALL NOT be used in the CRXER encoding 1655 of a BIT STRING value. If a hexadecimal digit string is used, then 1656 the enclosing element's [attributes] MUST contain an attribute item 1657 with the [local name] "format", the [namespace name] 1658 "urn:ietf:params:xml:ns:asnx" and the [normalized value] "hex" (i.e., 1659 asnx:format="hex"). The [prefix] of the attribute item is determined 1660 as specified in Section 6.2.3.1. 1662 Aside: The hexadecimal digit string is intended to conform to the 1663 lexical representation of the XML Schema [XSD2] hexBinary data 1664 type. 1666 For a non-canonical RXER encoding, if the preconditions for using a 1667 hexadecimal digit string are satisfied, then a hexadecimal digit 1668 string MAY be used. 1670 A list of bit names is permitted if and only if the BIT STRING type 1671 has a NamedBitList and each '1' bit in the BIT STRING value has a 1672 corresponding identifier in the NamedBitList. 1674 Aside: ASN.1 does not require that an identifier be assigned for 1675 every bit. 1677 A list of bit names is a sequence of names for the '1' bits in the 1678 BIT STRING value, in any order, each separated from the next by at 1679 least one white space character. If the BitStringType is not subject 1680 to a VALUES encoding instruction, then each '1' bit in the BIT STRING 1681 value is represented by its corresponding identifier from the 1682 NamedBitList. If the BitStringType is subject to a VALUES encoding 1683 instruction, then each '1' bit in the BIT STRING value is represented 1684 by the replacement name [RXEREI] for its corresponding identifier. 1686 For a CRXER encoding, if the BIT STRING type has a NamedBitList, then 1687 a binary digit string MUST be used and trailing zero bits MUST be 1688 omitted from the binary digit string, otherwise if the number of bits 1689 in the BIT STRING value is greater than or equal to 64 and the 1690 preconditions for using a hexadecimal digit string are satisfied, 1691 then a hexadecimal digit string MUST be used, otherwise a binary 1692 digit string MUST be used. 1694 Aside: Because the asnx:format attribute adds an overhead to a 1695 hexadecimal encoding (including a namespace declaration for the 1696 "asnx" prefix), a bit string of less than 64 bits is more 1697 compactly encoded as a binary digit string. 1699 Examples 1701 Consider this type definition: 1703 BIT STRING { black(0), red(1), orange(2), yellow(3), 1704 green(4), blue(5), indigo(6), violet(7) } 1706 The content and attributes of each of the following 1707 elements are an RXER encoding of the same abstract value: 1709 green violet orange 1711 00101001 1713 1715 29 1716 1718 00101001 1720 The final case contains the CRXER encoding of the abstract value. 1722 6.7.3. BOOLEAN 1724 For a non-canonical RXER encoding, the character data translation of 1725 the BOOLEAN value TRUE is the string "true" or "1", at the encoder's 1726 discretion. For a CRXER encoding, the character data translation of 1727 the BOOLEAN value TRUE is the string "true". 1729 For a non-canonical RXER encoding, the character data translation of 1730 the BOOLEAN value FALSE is the string "false" or "0", at the 1731 encoder's discretion. For a CRXER encoding, the character data 1732 translation of the BOOLEAN value FALSE is the string "false". 1734 Aside: The RXER encoding of BOOLEAN values is intended to conform 1735 to the lexical representation of the XML Schema [XSD2] boolean 1736 data type. 1738 Examples 1740 The content of each of the following elements is the RXER 1741 encoding of a BOOLEAN value: 1743 1 1745 1746 false 1747 1749 false 1751 6.7.4. ENUMERATED 1753 The character data translation of a value of an ENUMERATED type where 1754 the EnumeratedType is not subject to a VALUES encoding instruction is 1755 the identifier corresponding to the actual value. 1757 Examples 1759 Consider this type definition: 1761 ENUMERATED { sunday, monday, tuesday, 1762 wednesday, thursday, friday, saturday } 1764 The content of both of the following elements is the RXER 1765 encoding of a value of the above type: 1767 monday 1769 1770 thursday 1771 1773 The character data translation of a value of an ENUMERATED type where 1774 the EnumeratedType is subject to a VALUES encoding instruction is the 1775 replacement name [RXEREI] for the identifier corresponding to the 1776 actual value. 1778 Examples 1780 Consider this type definition: 1782 [RXER:VALUES ALL CAPITALIZED, 1783 sunday AS "SUNDAY", saturday AS "SATURDAY"] 1784 ENUMERATED { sunday, monday, tuesday, 1785 wednesday, thursday, friday, saturday } 1787 The content of each of the following elements is the RXER 1788 encoding of a value of the above type: 1790 SUNDAY 1792 1793 Monday 1794 1796 Tuesday 1798 6.7.5. GeneralizedTime 1800 The character data translation of a value of the GeneralizedTime type 1801 is a date, the letter 'T' (U+0054), a time of day, optional 1802 fractional seconds and an optional time zone. 1804 The date is two decimal digits representing the century, followed by 1805 two decimal digits representing the year, a hyphen ('-', U+002D), two 1806 decimal digits representing the month, a hyphen ('-', U+002D), and 1807 two decimal digits representing the day. 1809 The time of day is two decimal digits representing the hour, followed 1810 by a colon (':', U+003A), two decimal digits representing the 1811 minutes, a colon (':', U+003A), and two decimal digits representing 1812 the seconds. 1814 Note that the hours value "24" is disallowed [X.680]. 1816 A GeneralizedTime value with fractional hours or minutes is first 1817 converted to the equivalent time with whole minutes and seconds and, 1818 if necessary, fractional seconds. 1820 The minutes are encoded as "00" if the GeneralizedTime value omits 1821 minutes. The seconds are encoded as "00" if the GeneralizedTime 1822 value omits seconds. 1824 The fractional seconds part is a full stop ('.', U+002E) followed by 1825 zero, one or more decimal digits (U+0030-U+0039). For a CRXER 1826 encoding, trailing zero digits (U+0030) in the fractional seconds 1827 SHALL be omitted and the full stop SHALL be omitted if there are no 1828 following digits. 1830 The time zone, if present, is either the letter 'Z' (U+005A) to 1831 indicate Coordinated Universal Time, a plus sign ('+', U+002B) 1832 followed by a time zone differential, or a minus sign ('-', U+002D) 1833 followed by a time zone differential. 1835 A time zone differential indicates the difference between local time 1836 (the time specified by the preceding date and time of day) and 1837 Coordinated Universal Time. Coordinated Universal Time can be 1838 calculated from the local time by subtracting the differential. 1840 For a CRXER encoding, a GeneralizedTime value with a time zone 1841 differential SHALL be encoded as the equivalent Coordinated Universal 1842 Time, i.e., the time zone will be "Z". 1844 A local time GeneralizedTime value is not converted to Coordinated 1845 Universal Time for a CRXER encoding. Other canonical ASN.1 encoding 1846 rules specify that local times must be encoded as Coordinated 1847 Universal Time but do not specify a method to convert a local time to 1848 a Coordinated Universal Time. Consequently, canonicalization of 1849 local time values is unreliable and applications SHOULD NOT use local 1850 time. 1852 A time zone differential is encoded as two decimal digits 1853 representing hours, a colon (':', U+003A), and two decimal digits 1854 representing minutes. The minutes are encoded as "00" if the 1855 GeneralizedTime value omits minutes from the time zone differential. 1857 Aside: The RXER encoding of GeneralizedTime values is intended to 1858 conform to the lexical representation of the XML Schema [XSD2] 1859 dateTime data type. 1861 Examples 1863 The content of each of the following elements is the RXER 1864 encoding of a GeneralizedTime value: 1866 2004-06-15T12:00:00Z 1868 2004-06-15T02:00:00+10:00 1870 1871 2004-06-15T12:00:00.5 1872 1874 6.7.6. INTEGER 1876 For a CRXER encoding, the character data translation of a value of an 1877 IntegerType is a canonical number string representing the integer 1878 value. 1880 A canonical number string is either the digit character '0' (U+0030), 1881 or an optional minus sign ('-', U+002D) followed by a non-zero 1882 decimal digit character (U+0031-U+0039) followed by zero, one or more 1883 of the decimal digit characters '0' to '9' (U+0030-U+0039). 1885 For a non-canonical RXER encoding, the character data translation of 1886 a value of the IntegerType without a NamedNumberList is a number 1887 string representing the integer value. 1889 A number string is a sequence of one or more of the decimal digit 1890 characters '0' to '9' (U+0030-U+0039), with an optional leading sign, 1891 either '+' (U+002B) or '-' (U+002D). Leading zero digits are 1892 permitted in a number string for a non-canonical RXER encoding. 1894 Aside: The RXER encoding of values of the IntegerType without a 1895 NamedNumberList is intended to conform to the lexical 1896 representation of the XML Schema [XSD2] integer data type. 1898 For a non-canonical RXER encoding, if the IntegerType has a 1899 NamedNumberList and the NamedNumberList defines an identifier for the 1900 actual value and the IntegerType is not subject to a VALUES encoding 1901 instruction, then the character data translation of the value is 1902 either a number string or the identifier. 1904 Examples 1906 Consider this type definition: 1908 INTEGER { zero(0), one(1) } 1910 The content of each of the following elements is the RXER 1911 encoding of a value of the above type: 1913 0 1915 zero 1917 2 1919 00167 1921 For a non-canonical RXER encoding, if the IntegerType is subject to a 1922 VALUES encoding instruction (it necessarily must have a 1923 NamedNumberList) and the NamedNumberList defines an identifier for 1924 the actual value, then the character data translation of the value is 1925 either a number string or the replacement name [RXEREI] for the 1926 identifier. 1928 Examples 1930 Consider this type definition: 1932 [RXER:VALUES ALL UPPERCASED] INTEGER { zero(0), one(1) } 1934 The content of both of the following elements is the RXER 1935 encoding of a value of the above type: 1937 0 1939 ZERO 1941 6.7.7. NULL 1943 The character data translation of a value of the NULL type is an 1944 empty character string. 1946 Examples 1947 1949 1951 1953 The final case is the CRXER encoding. 1955 6.7.8. ObjectDescriptor 1957 A value of the ObjectDescriptor type is translated according to the 1958 GraphicString type. 1960 6.7.9. OBJECT IDENTIFIER and RELATIVE-OID 1962 The character data translation of a value of the OBJECT IDENTIFIER or 1963 RELATIVE-OID type is a full stop ('.', U+002E) separated list of the 1964 object identifier components of the value. 1966 Each object identifier component is translated as a non-negative 1967 number string. A non-negative number string is either the digit 1968 character '0' (U+0030), or a non-zero decimal digit character 1969 (U+0031-U+0039) followed by zero, one or more of the decimal digit 1970 characters '0' to '9' (U+0030-U+0039). 1972 Examples 1974 The content of each of the following elements is the RXER 1975 encoding of an OBJECT IDENTIFIER value: 1977 2.5.6.0 1979 1980 2.5.4.10 1981 1983 2.5.4.3 1985 6.7.10. OCTET STRING 1987 The character data translation of a value of the OCTET STRING type is 1988 the hexadecimal digit string representation of the octets. 1990 The octets are encoded in order from the first octet to the last 1991 octet. Each octet is encoded as a pair of the hexadecimal digit 1992 characters '0'-'9', 'A'-'F' and 'a'-'f' (i.e., U+0030-U+0039, 1993 U+0041-U+0046 and U+0061-U+0066) where the first digit in the pair 1994 corresponds to the four most significant bits of the octet. An odd 1995 number of hexadecimal digits is not permitted. The characters 1996 'a'-'f' (i.e., U+0061-U+0066) SHALL NOT be used in the CRXER encoding 1997 of an OCTET STRING value. 1999 Aside: The RXER encoding of OCTET STRING values is intended to 2000 conform to the lexical representation of the XML Schema [XSD2] 2001 hexBinary data type. 2003 Examples 2005 The content of each of the following elements is the RXER 2006 encoding of an OCTET STRING value: 2008 27F69A0300 2010 2011 efA03bFF 2012 2014 6.7.11. QName 2016 The character data translation of a value of the QName type 2017 (Section 4.5) is a qualified name conforming to the QName production 2018 of Namespaces in XML 1.0 [XMLNS10]. 2020 The local part (i.e., LocalPart) of the qualified name SHALL be the 2021 the value of the local-name component of the QName value. 2023 If the namespace-name component of the QName value is absent, then 2024 the namespace prefix (i.e., Prefix) of the qualified name SHALL be 2025 absent, otherwise the namespace prefix is determined as specified in 2026 Section 6.7.11.1 using the value of the namespace-name component of 2027 the QName value as the namespace name. 2029 6.7.11.1. Namespace Prefixes for Qualified Names 2031 This section describes how the namespace prefix of a qualified name 2032 is determined given the namespace name to which the namespace prefix 2033 must map. 2035 For a CRXER encoding, the namespace prefix of the qualified name is 2036 any unused non-canonical namespace prefix, unless the 2037 [in-scope namespaces] property of the enclosing element item contains 2038 a namespace item with a [namespace name] that matches the namespace 2039 name, in which case the [prefix] of that namespace item SHALL be used 2040 as the namespace prefix of the qualified name. 2042 Aside: If the qualified name appears in the [normalized value] of 2043 an attribute item, then the enclosing element item is the 2044 [owner element] for that attribute item. 2046 For a non-canonical RXER encoding, the namespace prefix of the 2047 qualified name is any unused namespace prefix, unless the 2048 [in-scope namespaces] property of the enclosing element item contains 2049 a namespace item with the same [namespace name] as the element item, 2050 in which case the [prefix] of that namespace item MAY be used as the 2051 namespace prefix of the qualified name. Note that the [prefix] of a 2052 namespace item for the default namespace has no value. 2054 If the namespace prefix of the qualified name is an unused namespace 2055 prefix, then a namespace declaration attribute item associating the 2056 namespace prefix with the namespace name MUST be added to the 2057 [namespace attributes] of the enclosing element item, and a 2058 corresponding namespace item MUST be added to the 2059 [in-scope namespaces] of the enclosing element item. 2061 6.7.12. REAL 2063 The character data translation of a value of the REAL type is the 2064 character string "0" if the value is positive zero, the character 2065 string "-0" if the value is negative zero, the character string "INF" 2066 if the value is positive infinity, the character string "-INF" if the 2067 value is negative infinity, the character string "NaN" if the value 2068 is not a number, or a real number otherwise. 2070 A real number is the mantissa followed by either the character 'E' 2071 (U+0045) or 'e' (U+0065) and the exponent. The character 'e' SHALL 2072 NOT be used for a CRXER encoding. If the exponent is zero, then the 2073 'E' or 'e' and exponent MAY be omitted for a non-canonical RXER 2074 encoding. 2076 The mantissa is a decimal number with an optional leading sign, 2077 either '+' (U+002B) or '-' (U+002D). A decimal number is a sequence 2078 of one or more of the decimal digit characters '0' to '9' 2079 (U+0030-U+0039) optionally partitioned by a single full stop 2080 character ('.', U+002E) representing the decimal point. Multiple 2081 leading zero digits are permitted for a non-canonical RXER encoding. 2083 The exponent is encoded as a number string (see Section 6.7.6). 2085 Aside: The RXER encoding of REAL values is intended to be 2086 compatible with the lexical representation of the XML Schema 2087 [XSD2] double data type, but allows real values outside the set 2088 permitted by double. 2090 For a CRXER encoding: 2092 (1) The real number MUST be normalized so that the mantissa has a 2093 single non-zero digit immediately to the left of the decimal 2094 point. 2096 (2) Leading zero digits SHALL NOT be used. 2098 (3) A leading plus sign SHALL NOT be used in the mantissa or the 2099 exponent. 2101 (4) The fractional part of the mantissa (i.e., that part following 2102 the decimal point) MUST have at least one digit (which may be 2103 '0') and MUST NOT have any trailing zeroes after the first digit. 2105 (5) The exponent SHALL be present and SHALL be a canonical number 2106 string (see Section 6.7.6). 2108 Examples 2109 The content of each of the following elements is the RXER 2110 encoding of a REAL value: 2112 3.14159 2114 1.0e6 2116 INF 2118 2119 -01e-06 2120 2122 6.7.13. UTCTime 2124 The character data translation of a value of the UTCTime type is a 2125 date, the letter 'T' (U+0054), a time of day and a time zone. 2127 The date is two decimal digits representing the year (no century), a 2128 hyphen ('-', U+002D), two decimal digits representing the month, a 2129 hyphen ('-', U+002D), and two decimal digits representing the day. 2131 The time of day is two decimal digits representing the hour, followed 2132 by a colon (':', U+003A), two decimal digits representing the 2133 minutes, a colon (':', U+003A), and two decimal digits representing 2134 the seconds. 2136 Note that the hours value "24" is disallowed [X.680]. 2138 The seconds are encoded as "00" if the UTCTime value omits seconds. 2140 The time zone is either the letter 'Z' (U+005A) to indicate 2141 Coordinated Universal Time, a plus sign ('+', U+002B) followed by a 2142 time zone differential, or a minus sign ('-', U+002D) followed by a 2143 time zone differential. 2145 A time zone differential indicates the difference between local time 2146 (the time specified by the preceding date and time of day) and 2147 Coordinated Universal Time. Coordinated Universal Time can be 2148 calculated from the local time by subtracting the differential. 2150 For a CRXER encoding, a UTCTime value with a time zone differential 2151 SHALL be encoded as the equivalent Coordinated Universal Time, i.e., 2152 the time zone will be "Z". 2154 A time zone differential is encoded as two decimal digits 2155 representing hours, a colon (':', U+003A), and two decimal digits 2156 representing minutes. 2158 6.7.14. CHOICE as UNION 2160 The chosen alternative of a value of a UNION type corresponds to some 2161 NamedType in the UNION type definition (a ChoiceType). 2163 The character data translation of a value of a UNION type is the 2164 character data translation of the value of the type of the chosen 2165 alternative, i.e., without any kind of encapsulation. 2167 Leading and trailing white space characters are not permitted to be 2168 added to the character data translation of a value of a UNION type 2169 (see Section 6.7), however this does not preclude such white space 2170 being added to the character data translation of the value of the 2171 chosen alternative. 2173 The character data translation of a value of a UNION type is 2174 necessarily destined for the [children] of an enclosing element item. 2176 Aside: This is because the ATTRIBUTE encoding instruction cannot 2177 be applied to a NamedType with a type that is a UNION type. 2179 The chosen alternative can be identified by a member attribute item, 2180 i.e., an attribute item with the [local name] "member" and 2181 [namespace name] "urn:ietf:params:xml:ns:asnx", added to the 2182 [attributes] of the enclosing element item. The [prefix] of this 2183 attribute item is determined as specified in Section 6.2.3.1. The 2184 [normalized value] of the attribute item is a qualified name for the 2185 expanded name of the NamedType (see [RXEREI]) corresponding to the 2186 chosen alternative. 2188 Aside: It is not possible to associate a namespace name with a 2189 NamedType in a UNION type using the current specification for RXER 2190 encoding instructions. Consequently, the [normalized value] of 2191 the member attribute item will always contain a qualified name 2192 without a namespace prefix. 2194 For a CRXER encoding, the member attribute item MUST be used and the 2195 [normalized value] of the attribute item MUST be the CRXER 2196 translation of the QName value equal to the expanded name. 2198 In the absence of a member attribute item, an RXER decoder MUST 2199 determine the chosen alternative by considering the alternatives of 2200 the choice in the order prescribed below and accepting the first 2201 alternative for which the encoding is valid. 2203 If the UNION encoding instruction has a PrecedenceList, then the 2204 alternatives of the ChoiceType referenced by the PrecedenceList are 2205 considered in the order identified by that PrecedenceList, then the 2206 remaining alternatives are considered in the order of their 2207 definition in the ChoiceType. If the UNION encoding instruction does 2208 not have a PrecedenceList, then all the alternatives of the 2209 ChoiceType are considered in the order of their definition in the 2210 ChoiceType. 2212 A non-canonical RXER encoder MUST use the member attribute item if an 2213 RXER decoder would determine the chosen alternative to be something 2214 other than the actual chosen alternative of the CHOICE value being 2215 translated, otherwise the member attribute item MAY be used. 2217 Examples 2219 Consider this type definition: 2221 [RXER:UNION PRECEDENCE serialNumber] CHOICE { 2222 name [0] IA5String, 2223 serialNumber [1] INTEGER 2224 } 2226 In the absence of a member attribute an RXER decoder would first 2227 consider whether the received encoding was a valid serialNumber 2228 (an INTEGER) before considering whether it was a valid name (an 2229 IA5String). 2231 The content and attributes of each of the following 2232 elements are the RXER encoding of a value of the above type: 2234 Bob 2236 Alice 2239 2240 344 2241 2243 100 2246 The member attribute is required in the final case to prevent the 2247 value being interpreted as a serialNumber. 2249 If the UNION (i.e., CHOICE) type is extensible [X.680], then an 2250 application MUST accept and be prepared to re-encode (using the same 2251 encoding rules) any unknown extension in received encoded values of 2252 the type. An unknown extension in a value of a UNION type (an 2253 unknown alternative) takes the form of an unknown name in the 2254 [normalized value] of the member attribute and/or character data in 2255 the [children] of the enclosing element item that do not conform to 2256 any of the known alternatives. 2258 To enable re-encoding of an unknown alternative it is necessary to 2259 retain the [normalized value] of the member attribute, if present, 2260 and the [children] property of the enclosing element item. 2262 The character data for an unknown alternative may contain qualified 2263 names that depend on the [in-scope namespaces] of the enclosing 2264 element item for their interpretation. Therefore semantically 2265 faithful re-encoding of an unknown alternative may require 2266 reproduction of at least some part of the [in-scope namespaces] of 2267 the enclosing element item. The problem is deciding which of the 2268 namespace items are actually needed. In the absence of type 2269 information it is not possible to discern whether anything that 2270 syntactically resembles a qualified name in the character data of the 2271 enclosing element item actually is a qualified name. The simplest 2272 approach is to retain all the namespace items from the 2273 [in-scope namespaces] of the enclosing element item and output them 2274 as namespace declaration attribute items in the 2275 [namespace attributes] of the enclosing element item when re-encoding 2276 the unknown alternative. At best, an application can omit the 2277 namespace items that do not define the namespace prefix of any 2278 potential qualified name. 2280 An application MUST retain the namespace items in the 2281 [in-scope namespaces] of the enclosing element item that define the 2282 namespace prefixes of all the potential qualified names in the 2283 [children] of the enclosing element item. Other namespace items in 2284 the [in-scope namespaces] of the enclosing element item MAY be 2285 retained. The effect of these retained namespace items on the 2286 [namespace attributes] and [in-scope namespaces] of the enclosing 2287 element item when re-encoding is considered in Section 6.2.2.1. 2289 Aside: The context attribute (Section 6.8.8) is not added to the 2290 [attributes] of the enclosing element item when re-encoding an 2291 unknown alternative since the type of a NamedType in a UNION type 2292 cannot be the Markup type. 2294 6.7.15. SEQUENCE OF as LIST 2296 The character data translation of a value of a LIST type (a 2297 SEQUENCE OF NamedType) is the concatenation of the character data 2298 translations of the component values, i.e., the abstract values of 2299 the type of the NamedType, each separated from the next by at least 2300 one white space character. For a CRXER encoding, separating white 2301 space MUST be exactly one space character (U+0020). 2303 Example 2305 Consider this type definition: 2307 [LIST] SEQUENCE OF timeStamp GeneralizedTime 2309 The content of the following element is the RXER encoding 2310 of a value of the above type: 2312 2313 2004-06-15T12:14:56Z 2314 2004-06-15T12:18:13Z 2315 2004-06-15T01:00:25Z 2316 2318 6.8. Combining Types 2320 The encoding of a value of an ASN.1 combining type (except a UNION or 2321 LIST type) typically has element content. 2323 The Infoset translation of a value of a specific ASN.1 combining type 2324 (excluding a UNION or LIST type) contains zero or more attribute 2325 items to be added to the [attributes] of the enclosing element item 2326 and zero or more element items to be added to the [children] of the 2327 enclosing element item. These translations are described in Sections 2328 6.8.1 to 6.8.7. 2330 For a non-canonical RXER encoding, white space character items MAY be 2331 added to the [children] of the enclosing element item (before or 2332 after any other items). 2334 For a CRXER encoding, a character item with the [character code] 2335 U+000A (a line feed) MUST be inserted immediately before each element 2336 item in the [children] of the enclosing element item. No other white 2337 space character items are permitted to be added to the [children] of 2338 the enclosing element item. 2340 Aside: Without the single line feed character before each child 2341 element, a typical CRXER encoding would be a single, very long 2342 line. 2344 6.8.1. CHARACTER STRING 2346 A value of the unrestricted CHARACTER STRING type is translated 2347 according to the corresponding SEQUENCE type defined in Clause 40.5 2348 of X.680 [X.680]. 2350 6.8.2. CHOICE 2352 The chosen alternative of a value of a CHOICE type corresponds to, 2353 and is a value of (see Section 6), some NamedType in the CHOICE type 2354 definition. 2356 The translation of a value of a CHOICE type other than the Markup 2357 type or a UNION type (see Section 6.7.14) is the translation of the 2358 value of the NamedType corresponding to the actual chosen 2359 alternative. 2361 Examples 2363 Consider this type definition: 2365 CHOICE { 2366 name [0] IA5String, 2367 serialNumber [1] INTEGER 2368 } 2370 The content of each of the following elements is the RXER 2371 encoding of a value of the above type: 2373 Bob 2375 2376 Alice 2377 2378 2379 2380 2381 344 2382 2383 2385 2386 2387 100 2388 2390 If the CHOICE type is extensible [X.680], then an application MUST 2391 accept, and be prepared to re-encode (in RXER), any attribute item or 2392 child element item with a name that is not recognised (see 2393 Section 6.8.8). 2395 6.8.3. EMBEDDED PDV 2397 A value of the EMBEDDED PDV type is translated according to the 2398 corresponding SEQUENCE type defined in Clause 33.5 of X.680 [X.680]. 2400 6.8.4. EXTERNAL 2402 A value of the EXTERNAL type is translated according to the 2403 corresponding SEQUENCE type defined in Clause 8.18.1 of X.690 2404 [X.690]. 2406 6.8.5. INSTANCE OF 2408 A value of the INSTANCE OF type is translated according to the 2409 corresponding SEQUENCE type defined in Annex C of X.681 [X.681]. 2411 6.8.6. SEQUENCE and SET 2413 Each component value of a value of a SEQUENCE or SET type corresponds 2414 to, and is a value of (see Section 6), some NamedType in the SEQUENCE 2415 or SET type definition. 2417 A value of a SEQUENCE or SET type, other than the QName type 2418 (Section 4.5), is translated by translating in turn each component 2419 value actually present in the SEQUENCE or SET value and adding the 2420 resulting attribute items and/or element items to the [attributes] 2421 and/or [children] of the enclosing element item. Attribute items may 2422 be added to the [attributes] of the enclosing element item in any 2423 order. Element items resulting from the translation of component 2424 values MUST be appended to the [children] of the enclosing element 2425 item in the order of the component values' corresponding NamedType 2426 definitions in the SEQUENCE or SET type definition. 2428 Aside: In the case of the SET type, this is a deliberate departure 2429 from BER [X.690], where the components of a SET can be encoded in 2430 any order. 2432 If a DEFAULT value is defined for a NamedType and the value of the 2433 NamedType is the same as the DEFAULT value, then the translation of 2434 the value of the NamedType SHALL be omitted for a CRXER encoding and 2435 MAY be omitted for a non-canonical RXER encoding. 2437 Examples 2439 Consider this type definition: 2441 SEQUENCE { 2442 name [0] IA5String OPTIONAL, 2443 partNumber [1] INTEGER, 2444 quantity [2] INTEGER DEFAULT 0 2445 } 2447 The content of each of the following elements is the RXER 2448 encoding of a value of the above type: 2450 2451 23 2452 2453 2455 2456 chisel 2457 37 2458 0 2459 2461 2462 2463 1543 2464 29 2465 2467 If the SEQUENCE or SET type is extensible [X.680], then an 2468 application MUST accept, and be prepared to re-encode (in RXER), any 2469 attribute item or child element item with a name that is not 2470 recognised (see Section 6.8.8). 2472 6.8.7. SEQUENCE OF and SET OF 2474 Each component value of a value of a type that is a SET OF NamedType 2475 or a SEQUENCE OF NamedType corresponds to, and is a value of (see 2476 Section 6), the NamedType in the type definition. 2478 A value of a type that is a SET OF NamedType, or a 2479 SEQUENCE OF NamedType other than a LIST type (see Section 6.7.15), is 2480 translated by adding the translation of each value of the NamedType 2481 to the [children] of the enclosing element item. 2483 Aside: An ATTRIBUTE encoding instruction cannot appear in the 2484 component type for a SEQUENCE OF or SET OF type, so there are no 2485 attribute items to add to the [attributes] of the enclosing 2486 element item. 2488 If the type is a SEQUENCE OF NamedType, then the values of the 2489 NamedType are translated in the order in which they appear in the 2490 value of the type. 2492 For a non-canonical RXER encoding, if the type is a SET OF NamedType, 2493 then the values of the NamedType may be translated in any order. 2495 For a CRXER encoding, if the type is a SET OF NamedType, then the 2496 values of the NamedType MUST be translated in ascending order where 2497 the order is determined by comparing the octets of their CRXER 2498 encodings (which will be UTF-8 encoded character strings, see 2499 Section 6.12.2). A shorter encoding is ordered before a longer 2500 encoding that is identical up to the length of the shorter encoding. 2502 Examples 2504 Consider this type definition: 2506 SEQUENCE OF timeStamp GeneralizedTime 2508 The content of the following element is the RXER encoding 2509 of a value of the above type: 2511 2512 2004-06-15T12:14:56Z 2513 2004-06-15T12:18:13Z 2514 2515 2004-06-15T01:00:25Z 2516 2517 2519 Consider this type definition (also see Section 6.6): 2521 SEQUENCE OF INTEGER 2523 The content of the following element is the RXER encoding 2524 of a value of the above type: 2526 2527 12 2528 2529 9 2530 2531 7 2532 2534 6.8.8. Extensible Combining Types 2536 An application must accept and be prepared to re-encode (using the 2537 same encoding rules) any unknown extension appearing in the encoding 2538 of a value of an extensible CHOICE, SEQUENCE or SET type. An unknown 2539 extension in a value of an extensible combining type (except UNION 2540 types) takes the form of unknown element and/or attribute items. 2541 Section 6.8.8.1 describes the processing of unknown element items and 2542 Section 6.8.8.2 describes the processing of unknown attribute items. 2544 An application cannot produce a canonical encoding if an abstract 2545 value contains unknown extensions. However, the method for 2546 re-encoding unknown extensions does not prevent a receiving 2547 application with knowledge of the extension from producing the 2548 correct canonical encoding. 2550 6.8.8.1. Unknown Elements in Extensions 2552 To enable re-encoding of an unknown element item it is necessary to 2553 retain the [prefix], [local name], [attributes], 2554 [namespace attributes] and [children] properties of the element item. 2556 Definition (inherited namespace item): An inherited namespace item is 2557 a namespace item in the [in-scope namespaces] of an element item for 2558 which there is no corresponding namespace declaration attribute item 2559 in the [namespace attributes] of the element item. 2561 The content and attributes of an unknown element item may contain 2562 qualified names whose interpretation depends on inherited namespace 2563 items. Semantically faithful re-encoding of the unknown item may 2564 require reproduction of at least some of the inherited namespace 2565 items. The problem is deciding which of the inherited namespace 2566 items are actually needed. Qualified names as the names of elements 2567 and attributes are easily recognized, but in the absence of type 2568 information it is not possible to discern whether anything that 2569 syntactically resembles a qualified name in the value of an attribute 2570 or the character data of an element actually is a qualified name. 2572 The simplest approach is to retain all the inherited namespace items 2573 and output corresponding namespace declaration attribute items in the 2574 [namespace attributes] of the unknown element item when re-encoding 2575 the element item. At best, an application can omit the inherited 2576 namespace items that do not define the namespace prefix of any 2577 definite or potential qualified name, though this requires examining 2578 the content and attributes of the unknown extension. 2580 Regardless of how clever an implementation tries to be, adding any 2581 namespace declaration attribute items to an unknown element item is 2582 harmful to canonicalization if the ASN.1 type for the element item 2583 turns out to be the Markup type. To counter this problem, a special 2584 attribute is used to identify the namespace declaration attribute 2585 items added to an unknown element item so that they can be removed 2586 later, if it proves necessary. 2588 If the outermost element item in an unknown extension does not have 2589 an attribute item with the [local name] "context" and 2590 [namespace name] "urn:ietf:params:xml:ns:asnx" in its [attributes], 2591 then namespace declaration attribute items corresponding to the 2592 inherited namespace items that define the namespace prefixes of all 2593 the definite and potential qualified names in the content and 2594 attributes of the element item MUST be added to the retained 2595 [namespace attributes]. Other inherited namespace items MAY be added 2596 to the retained [namespace attributes]. 2598 If there are one or more of these added namespace declaration 2599 attribute items, then an attribute item with the [local name] 2600 "context" and [namespace name] "urn:ietf:params:xml:ns:asnx" MUST be 2601 added to the retained [attributes]. 2603 The [prefix] of the context attribute item is any namespace prefix 2604 that does not match the [local name] of any namespace declaration 2605 attribute item in the [namespace attributes], unless the 2606 [namespace attributes] property contains a namespace declaration 2607 attribute item with a non-empty [prefix] and a [normalized value] of 2608 "urn:ietf:params:xml:ns:asnx", in which case the [local name] of that 2609 namespace declaration attribute item MAY be used as the [prefix] of 2610 the context attribute item. 2612 If the [prefix] of the context attribute item does not match the 2613 [local name] of any namespace declaration attribute item, then an 2614 attribute item with the [prefix] "xmlns", [namespace name] 2615 "urn:ietf:params:xml:ns:asnx" and [local name] equal to the [prefix] 2616 of the context attribute item MUST be added to the retained 2617 [namespace attributes] of the element item. 2619 The [normalized value] of the context attribute is the white space 2620 separated unordered list of the [local names] of the added namespace 2621 declaration attribute items (i.e., a list of the namespace prefixes), 2622 including any namespace declaration attribute item added to define 2623 the [prefix] of the context attribute. Note that the [local name] 2624 for a namespace declaration attribute item declaring the default 2625 namespace is "xmlns". 2627 Aside: A receiver that knows about the extension will use the 2628 context attribute to strip out the added namespace declaration 2629 attributes if the type of the associated NamedType is the Markup 2630 type (Section 6.10), and will discard the context attribute 2631 otherwise. A receiver that does not know about the extension will 2632 re-encode the extension as is. 2634 Adding the required namespace declaration attribute items to an 2635 element item effectively makes the element item self-contained. A 2636 received encoding has an encoding error if it contains an element 2637 item that is not self-contained but has a context attribute item in 2638 its [attributes]. 2640 An RXER encoder MUST NOT add the context attribute item to an element 2641 item corresponding to a NamedType that is known to it. 2643 An RXER decoder MUST accept the context attribute item on an element 2644 item corresponding to a NamedType that does not appear to be an 2645 extension. 2647 Aside: It is not uncommon for extension markers to be neglected in 2648 specifications traditionally using only BER, since extension 2649 markers do not alter BER encodings. Consequently, it is not 2650 immediately obvious in later versions of the specification which 2651 instances of NamedType belong to extensions of the original base 2652 specification. 2654 Example 2656 Suppose there are three applications, A, B and C. Suppose that 2657 Application A uses the first edition of an ASN.1 specification 2658 containing the following type definition: 2660 MyType ::= SEQUENCE { 2661 field1 INTEGER, -- present in first edition 2662 ... 2663 } 2665 Suppose that Application B uses the second edition of the ASN.1 2666 specification: 2668 MyType ::= SEQUENCE { 2669 field1 INTEGER, -- present in first edition 2670 ..., 2671 field2 QName -- added in second edition 2672 } 2674 Suppose that Application C uses the third edition of the ASN.1 2675 specification: 2677 MyType ::= SEQUENCE { 2678 field1 INTEGER, -- present in first edition 2679 ..., 2680 field2 QName, -- added in second edition 2681 field3 Markup -- added in third edition 2682 } 2684 Application C produces the following RXER encoding and sends it to 2685 Application B: 2687 2688 100 2689 p2:foobar 2690 p1:foobar 2691 2693 Application B doesn't know about , so it adds the 2694 asnx:context attribute to when it re-encodes the abstract 2695 value to send to Application A: 2697 2698 2700 100 2701 p1:foobar 2702 2704 p1:foobar 2708 2710 Application A doesn't know about and , so it adds 2711 the asnx:context attribute to and leaves alone 2712 when it re-encodes the abstract value: 2714 2715 2717 100 2718 2720 p1:foobar 2723 p1:foobar 2727 2729 If Application C receives this final encoding it has sufficient 2730 information to discard the asnx:context, xmlns:asnx and xmlns:p2 2731 attributes from the received Markup value of to recover 2732 the original value. Application C knows about , so it 2733 uses the namespace declaration for p1 when decoding the QName 2734 value and ignores the other declarations. 2736 6.8.8.2. Unknown Attributes in Extensions 2738 To enable re-encoding of an unknown attribute item it is necessary to 2739 retain at least the [local name], [namespace name] and 2740 [normalized value] properties of the attribute item. 2742 The [normalized value] of an unknown attribute item may contain 2743 qualified names whose interpretation depends on the 2744 [in-scope namespaces] of the [owner element]. Semantically faithful 2745 re-encoding of the unknown attribute item may require reproduction of 2746 at least some part of the [in-scope namespaces]. In the absence of 2747 type information it is not possible to discern whether anything that 2748 syntactically resembles a qualified name in the [normalized value] of 2749 an unknown attribute item actually is a qualified name. 2751 The simplest approach is to retain all the namespace items of the 2752 [in-scope namespaces] and output corresponding namespace declaration 2753 attribute items in the [namespace attributes] of the [owner element] 2754 when re-encoding the extension. At best, an application can omit the 2755 namespace items that do not define the namespace prefix of any 2756 potential qualified name in the [normalized value]. 2758 An application MUST retain the namespace items in the 2759 [in-scope namespaces] of the [owner element] that define the 2760 namespace prefixes of all the potential qualified names in the 2761 [normalized value] of the unknown attribute item. Other namespace 2762 items in the [in-scope namespaces] of the [owner element] MAY be 2763 retained. 2765 Aside: If the enclosing element item has more than one unknown 2766 attribute item, then it is sufficient to save the union of the 2767 retained namespace items with the element item, rather than saving 2768 the retained namespace items with each unknown attribute item. 2770 When the unknown attribute item is re-encoded, the retained namespace 2771 items affect the [namespace attributes] and [in-scope namespaces] of 2772 the enclosing element item as specified in Section 6.2.2.1, and the 2773 [prefix] of the attribute item is determined as specified in 2774 Section 6.2.3.1. 2776 Aside: The context attribute is not added to the [attributes] of 2777 the [owner element] when re-encoding an unknown attribute item 2778 because the type of a NamedType subject to an ATTRIBUTE or 2779 ATTRIBUTE-REF encoding instruction cannot be the Markup type. 2781 6.9. Open Type 2783 A value of an open type denoted by an ObjectClassFieldType [X.681] is 2784 translated according to the specific Type of the value. 2786 If the specific Type of the value is directly or indirectly the 2787 Markup type, then the enclosing element item MUST be self-contained. 2789 For a non-canonical RXER encoding, if the translation of the value 2790 does not generate an attribute item with the [local name] "type" and 2791 the [namespace name] "http://www.w3.org/2001/XMLSchema-instance" 2792 (i.e., xsi:type) and the specific Type of the value is a 2793 namespace-qualified reference (Section 5), then an attribute item 2794 with the [local name] "type" and the [namespace name] 2795 "http://www.w3.org/2001/XMLSchema-instance" (i.e., xsi:type) MAY be 2796 added to the [attributes] of the enclosing element item. The 2797 [normalized value] of this attribute item is a qualified name for the 2798 expanded name of the referenced type, with the namespace prefix 2799 determined as specified in Section 6.7.11.1. 2801 Aside: The xsi:type attribute is added by RXER encoders for the 2802 benefit of XML Schema validators. This attribute tells an 2803 XML Schema validator which type definition in a compatible 2804 XML Schema translation of the ASN.1 specification it should use 2805 for validating the content and attributes of the enclosing 2806 element. For an RXER decoder, the actual type in an open type 2807 value is generally determined by an associated component relation 2808 constraint [X.682], so the xsi:type attribute can be ignored. 2810 Example 2812 The content and attributes of the following element are 2813 the RXER encoding of an open type value containing a BOOLEAN 2814 value: 2816 true 2820 If the ObjectClassFieldType denoting an open type is not constrained 2821 by a TableConstraint, or is constrained by a TableConstraint where 2822 the constraining object set is extensible, then an application MUST 2823 accept and be prepared to re-encode (using the same encoding rules) 2824 any value of the open type where the specific Type of the value is 2825 unknown. In such cases, the enclosing element item is treated like 2826 an unknown element item in the value of an extensible combining ASN.1 2827 type (see Section 6.8.8.1). 2829 6.10. Markup 2831 Conceptually, a value of the Markup type holds the [prefix], 2832 [attributes], [namespace attributes] and [children] of an element 2833 item. The Infoset translation of a value of the Markup type 2834 initially simply sets the [prefix], [attributes], 2835 [namespace attributes] and [children] of the enclosing element item 2836 to the corresponding properties represented by the Markup value. 2838 Recall that the enclosing element item for the translation of a 2839 Markup value is required to be self-contained (Section 4.1.1). 2841 If the enclosing element item is not the [document element] of the 2842 document item and the [in-scope namespaces] property of the enclosing 2843 element item's [parent] contains a namespace item for the default 2844 namespace and the [namespace attributes] property represented by the 2845 Markup value does not contain a namespace item declaring or 2846 undeclaring the default namespace, then a namespace declaration 2847 attribute item that undeclares the default namespace SHALL be added 2848 to the enclosing element item's [namespace attributes]. 2850 It is not necessary to populate the [in-scope namespaces] of the 2851 enclosing element item for encoding purposes (though it may be 2852 warranted for other purposes). 2854 An element item nested in the [children] is potentially the Infoset 2855 translation of a value of a top-level NamedType (as allowed by 2856 Section 6.4), and the entire Markup value can represent the content 2857 and attributes of an element item that is the translation of a value 2858 of a top-level NamedType. 2860 Aside: The latter case arises when an ELEMENT-REF encoding 2861 instruction references a top-level NamedType. 2863 The content and attributes of an element item nested in the 2865 [children] of a Markup value are potentially the Infoset translation 2866 of an abstract value of an ASN.1 type (as allowed by Section 6.4), 2867 and the entire Markup value can represent the translation of a single 2868 abstract value. 2870 Aside: The latter case arises when a TYPE-REF encoding instruction 2871 references an ASN.1 type. 2873 For a non-canonical RXER encoding, any element item, at any level of 2874 nesting (including the enclosing element item itself), that 2875 corresponds to the value of a top-level NamedType MAY be replaced 2876 with any valid translation of that value. 2878 For a non-canonical RXER encoding, any element item, at any level of 2879 nesting (including the enclosing element item itself), with content 2880 and attributes that correspond to an abstract value of an ASN.1 type 2881 MAY have that content and those attributes replaced with any valid 2882 translation of that abstract value. If the content and attributes 2883 are replaced, then the [prefix], [in-scope namespaces] and 2884 [namespace attributes] of the element item are constructed as 2885 specified in Section 6.2.2.1 and Section 6.2.2.2. The enclosing 2886 element item for the Markup value is still required to be 2887 self-contained. 2889 Aside: Insofar as a Markup value represents ASN.1 abstract values, 2890 it is sufficient for the RXER encoding of the Markup value to 2891 preserve the abstract values rather than preserve the exact 2892 Infoset representation. 2894 For a CRXER encoding, any element item, at any level of nesting 2895 (including the enclosing element item itself), that corresponds to a 2896 value of a top-level NamedType MUST be replaced with the CRXER 2897 translation of that value. 2899 For a CRXER encoding, any element item, at any level of nesting 2900 (including the enclosing element item itself), with content and 2901 attributes that correspond to an abstract value of an ASN.1 type MUST 2902 have that content and those attributes replaced with the CRXER 2903 translation of that abstract value. The [prefix], 2904 [in-scope namespaces] and [namespace attributes] of the element item 2905 are constructed as specified in Section 6.2.2.1 and Section 6.2.2.2. 2907 If the [attributes] property of the enclosing element item from a 2908 received RXER encoding contains an attribute item with the 2909 [local name] "context" and [namespace name] 2910 "urn:ietf:params:xml:ns:asnx" (i.e., asnx:context), then this 2911 attribute item MUST be omitted from the [attributes] represented by 2912 the Markup value, and each namespace declaration attribute item with 2913 a [local name] matching an NCName in the [normalized value] of the 2914 attribute item MUST be omitted from the [namespace attributes] 2915 represented by the Markup value. 2917 6.11. Namespace Prefixes for CRXER 2918 The final step in translating the value of a top-level NamedType for 2919 a CRXER encoding, or an abstract value for a Standalone CRXER 2920 Encoding, is the replacement of the arbitrarily chosen namespace 2921 prefixes with algorithmically determined canonical namespace 2922 prefixes. This procedure for prefix replacement applies to each 2923 element item where the [namespace attributes] have been constructed 2924 according to Section 6.2.2.1. This includes any element item 2925 corresponding to a value of a top-level NamedType, or with content 2926 and attributes that correspond to an abstract value of an ASN.1 type, 2927 that is nested in a value of the Markup type. 2929 For each element item where prefix replacement applies, the following 2930 sequence of steps is repeated until there are no more eligible 2931 attribute items to select in step (1): 2933 (1) Select the attribute item with the least [normalized value] from 2934 amongst the attribute items of the [namespace attributes] that 2935 have a [local name] that is not a canonical namespace prefix 2936 (i.e., select from the namespace declaration attribute items that 2937 have not already been processed). A [normalized value] is less 2938 than another [normalized value] if the former appears before the 2939 latter in an ordering of the values determined by comparing the 2940 ISO 10646 code points [ISO10646] of their characters, from first 2941 to last. A shorter string of characters is ordered before a 2942 longer string of characters that is identical up to the length of 2943 the shorter string. 2945 Aside: Note that when a namespace declaration (other than for 2946 the default namespace) is represented as an attribute item in 2947 the [namespace attributes], the attribute's [prefix] is 2948 "xmlns", its [local name] is the namespace prefix, and its 2949 [normalized value] is the namespace name. 2951 (2) A canonical namespace prefix is unused if it is not currently the 2952 [prefix] of any namespace item in the [in-scope namespaces] of 2953 the element item. Replace the [local name] of the selected 2954 attribute item with the unused canonical namespace prefix that 2955 has the non-negative number string with the least integer value 2956 (e.g., n2 is less than n10). 2958 (3) The selected attribute item has a corresponding namespace item in 2959 the [in-scope namespaces] of the element. Replace the [prefix] 2960 of this corresponding namespace item with the canonical namespace 2961 prefix determined in step (2). 2963 (4) The element item and its [attributes] property, and descendent 2964 element items and their [attributes] properties, may depend on 2965 the selected attribute item to determine the binding between 2966 their [prefix] and [namespace name]. Replace the [prefix] of any 2967 such dependent element items and attribute items with the 2968 canonical namespace prefix determined in step (2). 2970 Note that a namespace prefix can be redeclared (reused). 2971 Replacement of the prefix does not apply to an element item 2972 wherein the prefix is redeclared, or to the descendants of such 2973 an element item. 2975 (5) The character data translations for values of the QName ASN.1 2976 type may depend on the selected attribute item to determine the 2977 binding between their namespace prefix and namespace name. 2978 Replace the namespace prefix of any such dependent character data 2979 translation with the canonical namespace prefix determined in 2980 step (2). 2982 Note that a character data translation can appear in the 2983 [normalized value] of an attribute item, or as a sequence of 2984 character items in the [children] of an element item. 2986 6.12. Serialization 2988 The final RXER encoding is produced by serializing the Infoset 2989 translation as an XML document. An implementation MUST serialize the 2990 Infoset translation as an XML document in such a way that the Infoset 2991 of the resulting XML document matches the Infoset translation, after 2992 ignoring the following properties: 2994 (1) all properties of the document item except the 2995 [document element], 2997 (2) the [base URI] of any item, 2999 (3) the [element content whitespace] of character items, 3001 (4) the [notation] of processing instruction items, 3003 (5) the [in-scope namespaces] of element items. 3005 Aside: The [in-scope namespaces] of a parent element item are only 3006 selectively inherited by its child element items in the Infoset 3007 translations of ASN.1 values. This means that the Infoset 3008 reconstructed by parsing the XML document serialization of the 3009 original Infoset will generally have more namespace items in its 3010 [in-scope namespaces], but these extra namespace items will not be 3011 significant. 3013 Aside: A consequence of case (1) is that comments and PIs before 3014 and after the document element are permitted. 3016 In general there is more than one possible serialization for any 3017 given Infoset translation. Section 6.12.1 highlights some important 3018 considerations in producing a correct serialization and discusses 3019 some of the serialization options. 3021 Section 6.12.2 applies to CRXER encodings and limits the 3022 serialization options so that each distinct Infoset has only one 3023 possible serialization. 3025 6.12.1. Non-canonical Serialization 3026 This section discusses aspects of Infoset serialization for 3027 non-canonical RXER encodings, but is not an exhaustive list of the 3028 options for non-canonical serialization. 3030 If one or more character items have a [character code] in the range 3031 U+0001 to U+0008, U+000B to U+000C or U+000E to U+001F, or one or 3032 more characters in any attribute's [normalized value] are in the 3033 range U+0001 to U+0008, U+000B to U+000C or U+000E to U+001F, then 3034 the Infoset translation MUST be serialized as an XML version 1.1 3035 document, otherwise the Infoset translation is serialized as either 3036 an XML version 1.0 or version 1.1 document. 3038 A non-canonical RXER encoding may use any of the allowed character 3039 encoding schemes for XML. RXER encoders and decoders MUST support 3040 the UTF-8 character encoding. 3042 An element item may be serialized as an empty-element tag if it has 3043 no items in its [children]. 3045 Attributes of an element can appear in any order since the 3046 [attributes] and [namespace attributes] of an element item are 3047 unordered. 3049 Ampersand ('&', U+0026) and open angle bracket ('<', U+003C) 3050 characters in the [normalized value] of an attribute item must be 3051 escaped appropriately [XML10][XML11] (with a character reference or a 3052 predefined entity reference). Double quote (U+0022) and single quote 3053 (U+0027) characters in an attribute item's [normalized value] may 3054 also need to be escaped. Character items with the [character code] 3055 U+0026 (ampersand, '&') or U+003C (open angle bracket, '<') must be 3056 escaped appropriately (with a character reference, a predefined 3057 entity reference or a CDATA section). 3059 Line break normalization by XML processors allows some freedom in how 3060 a character item for a line feed character (U+000A) is serialized: 3062 (1) If XML version 1.0 is selected, then a character item with the 3063 [character code] U+000A (line feed) is serialized as either a 3064 line feed character (U+000A), a carriage return character 3065 (U+000D) followed by a line feed character (U+000A), or just a 3066 carriage return character (U+000D) provided the next item is not 3067 a character item that is serialized as a line feed character 3068 (U+000A). 3070 (2) If XML version 1.1 is selected, then a character item with the 3071 [character code] U+000A (line feed) is serialized as either a 3072 line feed character (U+000A), a next line character (U+0085), a 3073 line separator character (U+2028), a carriage return character 3074 (U+000D) followed by a line feed character (U+000A), a carriage 3075 return character (U+000D) followed by a next line character 3076 (U+0085), or just a carriage return character (U+000D) provided 3077 the next item is not a character item that is serialized as a 3078 line feed (U+000A) or next line (U+0085) character. 3080 Aside: All these sequences will be normalized to a line feed 3081 character (U+000A) during decoding. 3083 A character item with the [character code] U+000D (carriage return), 3084 U+0085 (next line) or U+2028 (line separator) must be serialized as a 3085 character reference to protect the character from line break 3086 normalization during decoding. 3088 The attribute value normalization performed by XML processors allows 3089 some freedom in how a space character (U+0020) is serialized: 3091 (1) If XML version 1.0 is selected, then a space character (U+0020) 3092 in an attribute item's [normalized value] is serialized as either 3093 a space character (U+0020), a tab character (U+0009), a carriage 3094 return character (U+000D), a line feed character (U+000A), a 3095 carriage return character (U+000D) followed by a line feed 3096 character (U+000A), or just a carriage return character (U+000D) 3097 provided the next character in the [normalized value] is not 3098 serialized as a line feed character (U+000A). 3100 (2) If XML version 1.1 is selected, then a space character (U+0020) 3101 in an attribute item's [normalized value] is serialized as either 3102 a space character (U+0020), a tab character (U+0009), a carriage 3103 return character (U+000D), a line feed character (U+000A), a next 3104 line character (U+0085), a line separator character (U+2028), a 3105 carriage return character (U+000D) followed by a line feed 3106 character (U+000A), a carriage return character (U+000D) followed 3107 by a next line character (U+0085), or just a carriage return 3108 character (U+000D) provided the next character in the 3109 [normalized value] is not serialized as a line feed (U+000A) or 3110 next line (U+0085) character. 3112 Aside: All these sequences will be normalized to a space 3113 character (U+0020) during decoding, through a combination of 3114 line break normalization and attribute value normalization. 3116 Each tab (U+0009), line feed (U+000A) or carriage return (U+000D) 3117 character in an attribute item's [normalized value] must be 3118 serialized as a character reference to protect the character from 3119 attribute value normalization during decoding. In addition, if XML 3120 version 1.1 is selected, then each next line (U+0085) or line 3121 separator (U+2028) character must be serialized as a character 3122 reference. 3124 Parsed entity references may be used (unless the environment in which 3125 the RXER encoding is used disallows entity references). If entity 3126 references to other than the predefined entities are used, then the 3127 XML document containing the RXER encoding must necessarily contain a 3128 document type declaration and the internal or external subset of the 3129 document type definition must contain entity declarations for those 3130 entities. 3132 6.12.2. Canonical Serialization 3133 This section discusses Infoset serialization for CRXER encodings. 3134 The serialization of an Infoset for a CRXER encoding is restricted so 3135 that each distinct Infoset has only one possible serialization as an 3136 XML document. 3138 Aside: These restrictions have been chosen so as to be consistent 3139 with Canonical XML [CXML], where possible. 3141 The document SHALL be encoded in UTF-8 without a leading Byte Order 3142 Mark [ISO10646]. 3144 The XMLDecl of the document SHALL be . 3146 A document type declaration (doctypedecl) SHALL NOT be used. 3148 Aside: This has the effect of excluding entity references, except 3149 those for the predefined entities (e.g., &). 3151 A single line feed character (U+000A) MUST be inserted immediately 3152 before the document element. 3154 No other white space characters are permitted before or after the 3155 document element. 3157 There SHALL NOT be any PIs or comments before or after the document 3158 element. 3160 An element item MUST NOT be serialized as an empty-element tag. 3162 Aside: If an element item has no items in its [children], then it 3163 is serialized as a start-tag followed by an end-tag. 3165 There SHALL NOT be any white space characters immediately before the 3166 closing '>' of an element's start-tag and end-tag. The white space 3167 preceding each attribute SHALL be exactly one space character 3168 (U+0020). There SHALL NOT be any white space characters immediately 3169 before or after the equals sign (U+003D) in an attribute. 3171 The delimiter for attribute values SHALL be the double quote 3172 character (U+0022). 3174 Namespace declaration attributes MUST appear before any other 3175 attributes of an element. A namespace declaration for the default 3176 namespace, if present, MUST appear as the first attribute. The 3177 remaining namespace declaration attributes MUST appear in 3178 lexicographic order based on [local name]. 3180 Aside: In particular, this means that xmlns:n10 comes before 3181 xmlns:n2. 3183 The attributes that are not namespace declarations MUST be 3184 lexicographically ordered on [namespace name] as the primary key and 3185 [local name] as the secondary key. 3187 CDATA sections SHALL NOT be used. 3189 Each ampersand character ('&', U+0026) in an attribute item's 3190 [normalized value] MUST be serialized as the entity reference &. 3191 Each open angle bracket character ('<', U+003C) in an attribute 3192 item's [normalized value] MUST be serialized as the entity reference 3193 <. Each double quote character (U+0022) in an attribute item's 3194 [normalized value] MUST be serialized as the entity reference ". 3195 Each character in the range U+0001 to U+001F or U+007F to U+009F in 3196 an attribute item's [normalized value] MUST be serialized as a 3197 character reference. No other character in a [normalized value] is 3198 permitted to be serialized as an entity reference or character 3199 reference. 3201 Each character item with the [character code] U+0026 (the ampersand 3202 character) MUST be serialized as the entity reference &. Each 3203 character item with the [character code] U+003C (the open angle 3204 bracket character) MUST be serialized as the entity reference <. 3205 Each character item with the [character code] U+003E (the closing 3206 angle bracket character) MUST be serialized as the entity reference 3207 >. Each character item with a [character code] in the range 3208 U+0001 to U+0008, U+000B to U+001F or U+007F to U+009F MUST be 3209 serialized as a character reference. No other character item is 3210 permitted to be serialized as an entity reference or character 3211 reference. 3213 Character references, where they are permitted, SHALL use uppercase 3214 hexadecimal with no leading zeroes. For example, the carriage return 3215 character is represented as . 3217 A space character (U+0020) in an attribute item's [normalized value] 3218 MUST be serialized as a single U+0020 character. 3220 A character item with the [character code] U+000A MUST be serialized 3221 as a single U+000A character. 3223 The white space separating the [target] and [content] in the 3224 serialization of a processing instruction item SHALL be exactly one 3225 space character (U+0020). 3227 Aside: A processing instruction or comment can only appear in a 3228 CRXER encoding if it is embedded in a Markup value. 3230 6.12.3. Unicode Normalization in XML Version 1.1 3232 XML Version 1.1 recommends, but does not absolutely require, that 3233 text be normalized according to Unicode Normalization Form C 3234 [UNICODE]. ASN.1 has no similar requirement on abstract values of 3235 string types, and ASN.1 canonical encoding rules depend on the code 3236 points of characters being preserved. 3238 To accommodate both requirements, applications SHOULD normalize 3239 abstract values of ASN.1 character string types according to Unicode 3240 Normalization Form C at the time the values are created, but MUST NOT 3241 normalize a previously decoded abstract value of an ASN.1 character 3242 string type prior to re-encoding it. An application may, of course, 3243 normalize a decoded abstract value for other purposes, such as 3244 display to a user. 3246 6.13. Syntax-Based Canonicalization 3248 ASN.1 encoding rules are designed to preserve abstract values, but 3249 not to preserve every detail of each transfer syntax that is used. 3250 In the case of RXER, this means that the Infoset representation of an 3251 abstract value is not necessarily preserved when the abstract value 3252 is decoded and re-encoded (regardless of the encoding rules used). 3253 However, syntax-based canonicalization for XML documents (e.g., 3254 Canonical XML [CXML]) depends on the Infoset of an XML document being 3255 preserved. The Infoset representation of an XML document containing 3256 the RXER encoding of an ASN.1 abstract value potentially changes if 3257 that value is decoded and re-encoded, disrupting the Canonical XML 3258 representation. Extra normalization is required if RXER is to be 3259 usefully deployed in environments where syntax-based canonicalization 3260 is used. 3262 Prior to applying syntax-based canonicalization to an XML document, 3263 any element items in the Infoset representation of the document that 3264 correspond to the value of an ASN.1 top-level NamedType or have 3265 content and attributes that correspond to an ASN.1 abstract value 3266 MUST be replaced by the translation of the value according to CRXER. 3268 If an application uses Canonical XML but has no knowledge of RXER, 3269 then it will not know to normalize RXER encodings. If RXER is 3270 deployed into an environment containing such applications, then the 3271 Infoset translation for CRXER SHOULD be used for all RXER encodings. 3273 7. Transfer Syntax Identifiers 3275 7.1. RXER Transfer Syntax 3277 The following OBJECT IDENTIFIER has been assigned by xmled.org to 3278 identify the Robust XML Encoding Rules, under an arc assigned to 3279 xmled.org by the Internet Assigned Numbers Authority (IANA): 3281 { iso(1) identified-organization(3) dod(6) 3282 internet(1) private(4) enterprise(1) 3283 xmled(21472) asnx(1) encoding(1) rxer(0) } 3285 This OBJECT IDENTIFIER would be used, for example, to describe the 3286 transfer syntax for an RXER encoded data-value in an EMBEDDED PDV 3287 value. 3289 7.2. CRXER Transfer Syntax 3291 The following OBJECT IDENTIFIER has been assigned by xmled.org to 3292 identify the Canonical Robust XML Encoding Rules, under an arc 3293 assigned to xmled.org by the IANA: 3295 { iso(1) identified-organization(3) dod(6) 3296 internet(1) private(4) enterprise(1) 3297 xmled(21472) asnx(1) encoding(1) crxer(1) } 3299 This OBJECT IDENTIFIER would be used, for example, to describe the 3300 transfer syntax for a CRXER encoded data-value in an EMBEDDED PDV 3301 value. 3303 8. Relationship to XER 3305 The Robust XML Encoding Rules (RXER) and the XML Encoding Rules (XER) 3306 [X.693] are separate, distinctly different and incompatible ASN.1 3307 encoding rules for producing XML markup from ASN.1 abstract values. 3308 RXER is therefore unrelated to the XML value notation of X.680 3309 [X.680]. 3311 This section describes some of the major differences between RXER and 3312 XER. 3314 There are essentially two varieties of XER; BASIC-XER (with a 3315 canonical form called CANONICAL-XER) and EXTENDED-XER. The 3316 significant difference between the two varieties is that XER encoding 3317 instructions are used by EXTENDED-XER, but are ignored by BASIC-XER 3318 (and therefore by CANONICAL-XER). There isn't a canonical variant of 3319 EXTENDED-XER. Characteristics that are common to BASIC-XER and 3320 EXTENDED-XER will simply be noted as being characteristics of XER. 3322 Elements and attributes are the fundamental discrete structures of an 3323 XML document. Not surprisingly, schema languages for XML typically 3324 have the means to describe, name and reference global (i.e., 3325 top-level) elements and attributes. Global type definitions are seen 3326 more as a convenience for defining the contents of elements and 3327 attributes. Traditional ASN.1 has the means to define global types 3328 (and other global constructs that support the definition of types) 3329 but nothing akin to a global element or attribute definition. The 3330 fundamental difference between RXER and XER is in how this omission 3331 is addressed. 3333 With XER, type definitions are also regarded as being element 3334 definitions by default, or as attribute definitions in the presence 3335 of an XER ATTRIBUTE encoding instruction. In some circumstances an 3336 anonymous Type is required to define an element, which leads to 3337 element names like and . NamedType notation also 3338 defines local elements, and there are some curious cases in 3339 EXTENDED-XER where NamedType notation can define a global type. So 3340 under XER, types can be defined by either Type or NamedType notation, 3341 and elements and attributes can also be defined by either Type or 3342 NamedType notation. 3344 With RXER, types are only defined by Type notation and elements and 3345 attributes are only defined by NamedType notation. Global element 3346 and attribute definitions are made possible by top-level NamedType 3347 notation in an RXER encoding control section. 3349 RXER, with its clean separation of Type notation for types and 3350 NamedType notation for elements and attributes, is a better basis 3351 than XER for translating an ASN.1 specification into an XML 3352 representation (i.e., ASN.X [ASN.X]) or a compatible XML Schema, 3353 where type, element and attribute definitions are also distinctly 3354 separate constructs. 3356 There is usually a requirement on applications specified in ASN.1 to 3357 maintain backward compatibility with the encodings generated by 3358 previous versions. The encodings in question are typically BER. 3359 Even with the backward compatibility constraint there is still 3360 considerable leeway for specification writers to rewrite the earlier 3361 specification. For example, renaming types, factoring out an in-line 3362 type definition as a defined type (or the reverse), or replacing a 3363 type definition with an equivalent parameterized reference. These 3364 changes produce no change to BER, DER, CER [X.690], Packed Encoding 3365 Rules (PER) [X.691], or Generic String Encoding Rules (GSER) [GSER] 3366 encodings (so specification writers have felt free to make such 3367 changes to improve their specification), but can change the names of 3368 elements in the XER encoding because XER uses types as element 3369 definitions. The RXER encoding is immune to this problem, thus RXER 3370 encodings are more stable than XER encodings over successive 3371 revisions of an ASN.1 specification (which explains the first 'R' in 3372 RXER). This has an obvious benefit for interoperability. 3374 RXER has special provisions for encoding values of the QName and 3375 Markup types. QName is used to hold qualified names and Markup can 3376 be used to hold arbitrary untyped markup. XER doesn't recognize any 3377 special types like these, but it is possible to get the same effects 3378 as RXER's QName and Markup types by using XER encoding instructions. 3379 Since CANONICAL-XER ignores encoding instructions, this means that 3380 under XER an application can either support qualified names and 3381 untyped markup, or support canonical XML encodings, but not both. In 3382 contrast, CRXER has canonicalization rules for qualified names and 3383 for Markup. Furthermore, EXTENDED-XER does not address the issues of 3384 normalization of untyped data for other ASN.1 canonical encoding 3385 rules (e.g., for DER, see Section 4.1.2) or normalization of XML 3386 encodings for syntax-based canonicalization (e.g., for Canonical XML, 3387 see Section 6.13). 3389 Both EXTENDED-XER and RXER use encoding instructions to define 3390 attributes, union types and list types, among other things. Since 3391 CANONICAL-XER ignores encoding instructions, this means that under 3392 XER an application must choose between making use of attributes, 3393 union types, list types, etc., or supporting canonical XML encodings. 3394 In contrast, the canonicalization rules for CRXER encompass all the 3395 encoding instructions for RXER. 3397 9. Security Considerations 3399 RXER does not necessarily enable the exact BER octet encoding of 3400 values of the TeletexString, VideotexString, GraphicString or 3401 GeneralString types to be reconstructed, so a transformation from DER 3402 to RXER and back to DER may not reproduce the original DER encoding. 3404 This is a result of inadequate normalization of values of these 3405 string types in DER. A character in a TeletexString value (for 3406 example) that corresponds to a specific ISO 10646 character can be 3407 encoded for BER in a variety of ways that are indistinguishable in an 3408 RXER re-encoding of the TeletexString value. DER does not mandate 3409 one of these possible character encodings in preference to all 3410 others. 3412 Because of the above, RXER MUST NOT be used to re-encode, whether for 3413 storage or transmission, ASN.1 abstract values whose original DER or 3414 CER encoding must be recoverable, and whose type definitions involve 3415 the TeletexString, VideotexString, GraphicString or GeneralString 3416 type. Such recovery is needed for the verification of digital 3417 signatures. In such cases, protocols ought to use DER or a DER- 3418 reversible encoding. In other cases where ASN.1 canonical encoding 3419 rules are used, values of the Markup type must be normalized as 3420 described in Section 4.1.2. 3422 A transformation from CRXER to BER and back to CRXER does reproduce 3423 the original CRXER encoding, therefore it is safe to use BER, DER or 3424 CER to re-encode ASN.1 abstract values whose original CRXER encoding 3425 must be recoverable. 3427 Digital signatures may also be calculated on the Canonical XML 3428 representation of an XML document. If RXER encodings appear in such 3429 documents, then applications must normalize the encodings as 3430 described in Section 6.13. 3432 The null character (U+0000) cannot be represented in XML and hence 3433 cannot be transmitted in an RXER encoding. Null characters in 3434 abstract values of ASN.1 string types will be dropped if the values 3435 are RXER encoded, therefore RXER MUST NOT be used by applications 3436 that attach significance to the null character. 3438 When interpreting security-sensitive fields, and in particular fields 3439 used to grant or deny access, implementations MUST ensure that any 3440 comparisons are done on the underlying abstract value, regardless of 3441 the particular encoding used. Comparisons of Markup values MUST 3442 operate as though the values have been normalized as specified in 3443 Section 4.1.2. 3445 10. Acknowledgements 3447 The technology described in this document is the product of a 3448 research project begun jointly by Adacel Technologies Limited and 3449 Deakin University, and subsequently refined and completed by eB2Bcom. 3451 11. IANA Considerations 3453 The IANA is requested to register a new XML namespace in accordance 3454 with RFC 3688 [XMLREG]. 3456 URI: urn:ietf:params:xml:ns:asnx 3457 Registrant Contact: Steven Legg 3459 XML: None 3461 12. References 3463 12.1. Normative References 3465 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 3466 Requirement Levels", BCP 14, RFC 2119, March 1997. 3468 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 3469 10646", RFC 3629, November 2003. 3471 [XMLREG] Mealling, M., "The IETF XML Registry", RFC 3688, January 3472 2004. 3474 [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 3475 Resource Identifiers (URI): Generic Syntax", STD 66, RFC 3476 3986, January 2005. 3478 [RXEREI] Legg, S., "Encoding Instructions for the Robust XML 3479 Encoding Rules (RXER)", draft-legg-xed-rxer-ei-xx.txt, a 3480 work in progress, December 2006. 3482 [ASN.X] Legg, S., "Abstract Syntax Notation X (ASN.X)", 3483 draft-legg-xed-asd-xx.txt, a work in progress, December 3484 2006. 3486 [X.680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1, 3487 Information technology - Abstract Syntax Notation One 3488 (ASN.1): Specification of basic notation. 3490 [X.680-1] ITU-T Recommendation X.680 (2002) Amendment 1 (10/03) | 3491 ISO/IEC 8824-1:2002/Amd 1:2004, Support for EXTENDED-XER. 3493 [X.681] ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2, 3494 Information technology - Abstract Syntax Notation One 3495 (ASN.1): Information object specification. 3497 [X.682] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3, 3498 Information technology - Abstract Syntax Notation One 3499 (ASN.1): Constraint specification. 3501 [X.683] ITU-T Recommendation X.683 (07/02) | ISO/IEC 8824-4, 3502 Information technology - Abstract Syntax Notation One 3503 (ASN.1): Parameterization of ASN.1 specifications. 3505 [X.690] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1, 3506 Information technology - ASN.1 encoding rules: 3507 Specification of Basic Encoding Rules (BER), Canonical 3508 Encoding Rules (CER) and Distinguished Encoding Rules 3509 (DER). 3511 [UCS] ISO/IEC 10646-1:2000, Information technology - Universal 3512 Multiple-Octet Coded Character Set (UCS) - Part 1: 3513 Architecture and Basic Multilingual Plane. 3515 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 3516 4.0", Boston, MA, Addison-Wesley Developers Press, 2003. 3517 ISBN 0-321-18578-1. 3519 [XML10] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and 3520 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 3521 Edition)", W3C Recommendation, 3522 http://www.w3.org/TR/2006/REC-xml-20060816, August 2006. 3524 [XML11] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., 3525 Yergeau, F., and J. Cowan, "Extensible Markup Language 3526 (XML) 1.1 (Second Edition)", W3C Recommendation, 3527 http://www.w3.org/TR/2006/REC-xml11-20060816, August 2006. 3529 [XMLNS10] Bray, T., Hollander, D., Layman, A., and R. Tobin, 3530 "Namespaces in XML 1.0 (Second Edition)", W3C 3531 Recommendation, 3532 http://www.w3.org/TR/2006/REC-xml-names-20060816, August 3533 2006. 3535 [XMLNS11] Bray, T., Hollander, D., Layman, A. and R. Tobin, 3536 "Namespaces in XML 1.1 (Second Edition)", W3C 3537 Recommendation, 3538 http://www.w3.org/TR/2006/REC-xml-names11-20060816, August 3539 2006. 3541 [INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second 3542 Edition)", W3C Recommendation, 3543 http://www.w3.org/TR/2004/REC-xml-infoset-20040204, 3544 February 2004. 3546 [XSD1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, 3547 "XML Schema Part 1: Structures Second Edition", W3C 3548 Recommendation, 3549 http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/, 3550 October 2004. 3552 12.2. Informative References 3554 [GSER] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 3555 Types", RFC 3641, October 2003. 3557 [X.691] ITU-T Recommendation X.691 (07/02) | ISO/IEC 8825-4:2002, 3558 Information technology - ASN.1 encoding rules: 3559 Specification of Packed Encoding Rules (PER) 3561 [X.693] ITU-T Recommendation X.693 (12/01) | ISO/IEC 8825-4:2002, 3562 Information technology - ASN.1 encoding rules: XML 3563 encoding rules (XER) 3565 [XSD2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 3566 Second Edition", W3C Recommendation, 3567 http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/, 3568 October 2004. 3570 [CXML] Boyer, J., "Canonical XML Version 1.0", W3C 3571 Recommendation, 3572 http://www.w3.org/TR/2001/REC-xml-c14n-20010315, March 3573 2001. 3575 Appendix A. Additional Basic Definitions Module 3577 This appendix is normative. 3579 AdditionalBasicDefinitions 3580 { iso(1) identified-organization(3) dod(6) 3581 internet(1) private(4) enterprise(1) 3582 xmled(21472) asnx(1) module(0) basic(0) } 3584 -- Copyright (C) The IETF Trust (2006). This version of 3585 -- this ASN.1 module is part of RFC XXXX; see the RFC itself 3586 -- for full legal notices. 3588 DEFINITIONS 3589 RXER INSTRUCTIONS 3590 AUTOMATIC TAGS 3591 EXTENSIBILITY IMPLIED ::= BEGIN 3593 Markup ::= CHOICE { 3594 text SEQUENCE { 3595 prolog UTF8String (SIZE(1..MAX)) OPTIONAL, 3596 prefix NCName OPTIONAL, 3597 attributes UTF8String (SIZE(1..MAX)) OPTIONAL, 3598 content UTF8String (SIZE(1..MAX)) OPTIONAL 3599 } 3600 } 3602 AnyURI ::= UTF8String (CONSTRAINED BY 3603 { -- conforms to the format of a URI -- }) 3605 NCName ::= UTF8String (CONSTRAINED BY 3606 { -- conforms to the NCName production of 3607 -- Namespaces in XML 1.0 -- }) 3609 Name ::= UTF8String (CONSTRAINED BY 3610 { -- conforms to the Name production of XML -- }) 3612 QName ::= SEQUENCE { 3613 namespace-name AnyURI OPTIONAL, 3614 local-name NCName 3615 } 3617 ENCODING-CONTROL RXER 3618 TARGET-NAMESPACE "urn:ietf:params:xml:ns:asnx" PREFIX "asnx" 3620 COMPONENT context [ATTRIBUTE] [LIST] SEQUENCE OF prefix NCName 3622 END 3624 Authors' Addresses 3626 Dr. Steven Legg 3627 eB2Bcom 3628 Suite 3, Woodhouse Corporate Centre 3629 935 Station Street 3630 Box Hill North, Victoria 3129 3631 AUSTRALIA 3633 Phone: +61 3 9896 7830 3634 Fax: +61 3 9896 7801 3635 EMail: steven.legg@eb2bcom.com 3637 Dr. Daniel Prager 3639 EMail: dap@austhink.com 3641 Full Copyright Statement 3643 Copyright (C) The IETF Trust (2006). 3645 This document is subject to the rights, licenses and restrictions 3646 contained in BCP 78, and except as set forth therein, the authors 3647 retain all their rights. 3649 This document and the information contained herein are provided on an 3650 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3651 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3652 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3653 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3654 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3655 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3657 Intellectual Property 3659 The IETF takes no position regarding the validity or scope of any 3660 Intellectual Property Rights or other rights that might be claimed to 3661 pertain to the implementation or use of the technology described in 3662 this document or the extent to which any license under such rights 3663 might or might not be available; nor does it represent that it has 3664 made any independent effort to identify any such rights. Information 3665 on the procedures with respect to rights in RFC documents can be 3666 found in BCP 78 and BCP 79. 3668 Copies of IPR disclosures made to the IETF Secretariat and any 3669 assurances of licenses to be made available, or the result of an 3670 attempt made to obtain a general license or permission for the use of 3671 such proprietary rights by implementers or users of this 3672 specification can be obtained from the IETF on-line IPR repository at 3673 http://www.ietf.org/ipr. 3675 The IETF invites any interested party to bring to its attention any 3676 copyrights, patents or patent applications, or other proprietary 3677 rights that may cover technology that may be required to implement 3678 this standard. Please address the information to the IETF at 3679 ietf-ipr@ietf.org. 3681 Note to the RFC Editor: the remainder of this document is to be removed 3682 before final publication. 3684 Changes in Draft 00 3686 The Directory XML Encoding Rules (DXER) have been renamed to the 3687 Robust XML Encoding Rules (RXER). The previous file name for this 3688 draft was draft-legg-xed-dxer-00.txt . 3690 The rules for forming the [local name] and [namespace name] of the 3691 [document element] of a Standalone DXER(RXER) Encoding have been 3692 changed to remove any dependency on type reference names. 3694 Changes in Draft 01 3696 The namespace name for the ASN.1 namespace has been shortened. 3698 Additional insignificant leading and trailing white space is 3699 permitted in the encodings for some of the simple ASN.1 types in 3700 order to align them fully with their analogous XML Schema types. 3702 Changes in Draft 02 3704 The AnyType ASN.1 type from [GLUE] has been revised to be a CHOICE 3705 whose only alternative is the previous SEQUENCE type. The 3706 description of the RXER encoding of values of AnyType has been 3707 revised to account for the change. 3709 Examples of RXER encodings have been added to the specification. 3711 Changes in Draft 03 3713 Descriptions of the effects of RXER encoding instructions on RXER 3714 encodings have been added. Rules for a canonical variant of RXER 3715 (CRXER) have been added. Both of these changes have forced a radical 3716 reorganization of the document. 3718 The OBJECT IDENTIFIER identifying RXER (Section 7.1) has been 3719 replaced. An OBJECT IDENTIFIER identifying CRXER (Section 7.2) has 3720 been allocated. 3722 This draft incorporates the SchemaLanguageIntegration module and 3723 associated descriptions from "The XML Enabled Directory: Schema 3724 Language Integration" draft (draft-legg-xed-glue-02.txt). Changes to 3725 the incorporated material are described here. 3727 The mechanism of constraining values of AnyType using user defined 3728 constraint notation with specially assigned object identifiers has 3729 been discarded in favour of RXER reference encoding instructions 3730 [RXEREI]. The parts of the SchemaLanguageIntegration module 3731 pertaining to this old mechanism have been stripped out. 3733 The OBJECT IDENTIFIER for the SchemaLanguageIntegration module has 3734 been replaced. 3736 The SchemaLanguageIntegration module has been renamed to 3737 AdditionalBasicDefinitions. 3739 The QName ASN.1 type has been introduced into the 3740 AdditionalBasicDefinitions module. 3742 The definition of the AnyType type in the AdditionalBasicDefinitions 3743 module has been changed. 3745 The century pad digits for a UTCTime value have been removed. The 3746 pad digits were there to allow UTCTime to be translated into 3747 XML Schema dateTime, but a forthcoming time types amendment will add 3748 more time types that don't have a natural counterpart in XML Schema. 3749 Forcing UTCTime into dateTime will then seem rather arbitrary. 3751 Use of the xsi:type attribute to identify BIT STRING values encoded 3752 in hexadecimal has been discarded in favour of the format attribute. 3754 The provisions for ChoiceOfString types have been subsumed by the 3755 UNION encoding instruction. Use of the xsi:type attribute to 3756 identify the alternative in a UNION/ChoiceOfStrings type has been 3757 discarded in favour of the member attribute. 3759 Changes in Draft 04 3761 The requirement for self-containment of extensions has been dropped. 3762 The asnx:context attribute is now used to identify which namespace 3763 declarations have been added to an unknown extension so that they can 3764 be removed later if it proves necessary. 3766 The CONTENT encoding instruction has been renamed to the GROUP 3767 encoding instruction. 3769 More text has been added to Section 8 comparing RXER to XER. 3771 Changes in Draft 05 3773 The format and member attributes are now namespace qualified. 3775 The BIT STRING type is no longer permitted to be the component type 3776 of a LIST type. 3778 Changes in Draft 06 3780 The AnyType ASN.1 type has been renamed to Markup. 3782 The effects of the SIMPLE-CONTENT and COMPONENT-REF encoding 3783 instructions have been added. 3785 The requirement for elements corresponding to top-level components to 3786 always be self-contained has been relaxed. 3788 The URL for the ASN.1 namespace has been replaced. A permanent URN 3789 will be requested from the IANA. 3791 Changes in Draft 07 3793 Table 1 from the ASN.X specification has been moved to this 3794 specification. 3796 The effective name definition has been replaced by the expanded name 3797 definition from Namespaces in XML. Section 5 has been added to 3798 describe expanded names for ASN.1 types. 3800 The Qualified Reference Name concept has been reworked into the 3801 namespace-qualified reference concept. The effects on an RXER 3802 encoding are the same. 3804 The manner in which an ASN.1 value is embedded in an XML document has 3805 important consequences for canonicalization, so Section 6.4 has been 3806 added to formalize the practice.