From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4792.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc4792.txt (limited to 'doc/rfc/rfc4792.txt') diff --git a/doc/rfc/rfc4792.txt b/doc/rfc/rfc4792.txt new file mode 100644 index 0000000..4facb22 --- /dev/null +++ b/doc/rfc/rfc4792.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group S. Legg +Request for Comments: 4792 eB2Bcom +Updates: 3641 January 2007 +Category: Standards Track + + + Encoding Instructions for the + Generic String Encoding Rules (GSER) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + Abstract Syntax Notation One (ASN.1) defines a general framework for + annotating types in an ASN.1 specification with encoding instructions + that alter how values of those types are encoded according to ASN.1 + encoding rules. This document defines the supporting notation for + encoding instructions that apply to the Generic String Encoding Rules + (GSER) and, in particular, defines an encoding instruction to provide + a machine-processable representation for the declaration of a GSER + ChoiceOfStrings type. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Conventions .....................................................2 + 3. Notation for GSER Encoding Instructions .........................2 + 4. The CHOICE-OF-STRINGS Encoding Instruction ......................3 + 4.1. Effect on GSER Encodings ...................................5 + 4.2. Replacement of Existing ChoiceOfStrings Declarations .......6 + 5. Security Considerations .........................................7 + 6. Normative References ............................................7 + + + + + + + + + +Legg Standards Track [Page 1] + +RFC 4792 Encoding Instructions for GSER January 2007 + + +1. Introduction + + Abstract Syntax Notation One (ASN.1) [X.680] defines a general + framework for annotating types in an ASN.1 specification with + encoding instructions [X.680-1] that alter how values of those types + are encoded according to ASN.1 encoding rules. This document defines + the supporting notation for encoding instructions that apply to the + Generic String Encoding Rules (GSER) [GSER], and in particular + defines an encoding instruction, the CHOICE-OF-STRINGS encoding + instruction, to provide a machine-processable representation for the + declaration of a GSER ChoiceOfStrings type. + + The CHOICE-OF-STRINGS encoding instruction SHOULD be used instead of + simply declaring a ChoiceOfStrings type. + +2. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [BCP14]. + + Throughout this document, "type" shall be taken to mean an ASN.1 + type, and "value" shall be taken to mean an ASN.1 abstract value, + unless qualified otherwise. + + A reference to an ASN.1 production [X.680] (e.g., Type, NamedType) is + a reference to text in an ASN.1 specification corresponding to that + production. + +3. Notation for GSER Encoding Instructions + + The grammar of ASN.1 permits the application of encoding instructions + [X.680-1], through type prefixes and encoding control sections, that + modify how abstract values are encoded by nominated encoding rules. + + The generic notation for type prefixes and encoding control sections + is defined by the ASN.1 basic notation [X.680] [X.680-1], and + includes an encoding reference to identify the specific encoding + rules that are affected by the encoding instruction. + + The encoding reference that identifies the Generic String Encoding + Rules is literally GSER. + + The specific notation for an encoding instruction for a particular + set of encoding rules is left to the specification of those encoding + rules. Consequently, this companion document to the GSER + specification [GSER] defines the notation for GSER encoding + + + +Legg Standards Track [Page 2] + +RFC 4792 Encoding Instructions for GSER January 2007 + + + instructions. Specifically, it elaborates the EncodingInstruction + and EncodingInstructionAssignmentList placeholder productions of the + ASN.1 basic notation. + + In the context of the GSER encoding reference the EncodingInstruction + production is defined as follows, using the conventions of the ASN.1 + basic notation: + + EncodingInstruction ::= + ChoiceOfStringsInstruction + + In the context of the GSER encoding reference the + EncodingInstructionAssignmentList production (which only appears in + an encoding control section) is empty: + + EncodingInstructionAssignmentList ::= empty + +4. The CHOICE-OF-STRINGS Encoding Instruction + + The CHOICE-OF-STRINGS encoding instruction allows a GSER encoder to + encode the alternative of a CHOICE (of restricted string types) + without the leading identifier. The optional PrecedenceList also + allows a specification writer to alter the order in which a GSER + decoder will consider the alternatives of the CHOICE as it determines + which alternative has been encoded when the identifier is absent. + + The notation for a CHOICE-OF-STRINGS encoding instruction is defined + as follows: + + UnionInstruction ::= "CHOICE-OF-STRINGS" AlternativesPrecedence ? + + AlternativesPrecedence ::= "PRECEDENCE" PrecedenceList + + PrecedenceList ::= identifier PrecedenceList ? + + The Type in the EncodingPrefixedType for a CHOICE-OF-STRINGS encoding + instruction SHALL be: + + (a) a BuiltinType that is a ChoiceType, or + + (b) a ConstrainedType that is not a TypeWithConstraint where the Type + in the ConstrainedType is one of (a) to (d), or + + (c) a BuiltinType that is a PrefixedType that is a TaggedType where + the Type in the TaggedType is one of (a) to (d), or + + + + + + +Legg Standards Track [Page 3] + +RFC 4792 Encoding Instructions for GSER January 2007 + + + (d) a BuiltinType that is a PrefixedType that is an + EncodingPrefixedType where the Type in the EncodingPrefixedType + is one of (a) to (d). + + The effect of this condition is to force the CHOICE-OF-STRINGS + encoding instruction to be textually co-located with the CHOICE type + definition to which it applies. This makes it clear to a reader that + the encoding instruction applies to every use of the CHOICE type no + matter how it might be referenced. + + The ChoiceType in case (a) is said to be "subject to" the CHOICE-OF- + STRINGS encoding instruction. + + The Type of each NamedType of the ChoiceType in case (a) MUST be: + + (1) the NumericString, PrintableString, TeletexString (T61String), + VideotexString, IA5String, GraphicString, VisibleString + (ISO646String), GeneralString, BMPString, UniversalString, or + UTF8String type, or + + (2) a type notation that references a type that is one of (1) to (4), + or + + (3) a constrained type where the type that is constrained is one of + (1) to (4), or + + (4) a prefixed type where the type that is prefixed is one of (1) to + (4). + + ASIDE: A tagged type is a special case of a prefixed type. An + effect of case (4) is that tagging is not significant. + + The ASN.1 restricted string type in case (1) MUST be different for + each NamedType in the ChoiceType, i.e., no two alternatives have the + same restricted string type. + + If case (3) applies to any NamedType, then the constraint in case (3) + MUST be the same for each NamedType, i.e., either none of the + alternatives has a constraint, or all of the alternatives have + exactly the same constraint. + + Each identifier in the PrecedenceList MUST be the identifier of a + NamedType of the ChoiceType. + + A particular identifier SHALL NOT appear more than once in the same + PrecedenceList. + + + + + +Legg Standards Track [Page 4] + +RFC 4792 Encoding Instructions for GSER January 2007 + + +4.1. Effect on GSER Encodings + + A value of a CHOICE type is encoded according to the + [GSER] Augmented Backus-Naur Form [ABNF] rule. The ABNF for + is reproduced here for convenience: + + ChoiceValue = IdentifiedChoiceValue / + ChoiceOfStringsValue + + IdentifiedChoiceValue = identifier ":" Value + ChoiceOfStringsValue = StringValue + + The rule MUST be used to encode values of a + CHOICE type where the ChoiceType is not subject to a CHOICE-OF- + STRINGS encoding instruction. + + The chosen alternative of a value of a CHOICE type corresponds to + some NamedType in the definition of the type. The in + the is the identifier of this NamedType. + + Either the rule or the + rule is used to encode values of a CHOICE type where the ChoiceType + is subject to a CHOICE-OF-STRINGS encoding instruction. + + If has been used, then a GSER decoder MUST + determine the chosen alternative by considering the alternatives of + the CHOICE in the order prescribed below and accepting the first + alternative that allows all of the characters in the . + + If the CHOICE-OF-STRINGS encoding instruction has a PrecedenceList, + then the alternatives of the ChoiceType referenced by the + PrecedenceList are considered in the order identified by that + PrecedenceList, and then the remaining alternatives are considered in + the order of their definition in the ChoiceType. If the CHOICE-OF- + STRINGS encoding instruction does not have a PrecedenceList, then all + the alternatives of the ChoiceType are considered in the order of + their definition in the ChoiceType. + + A GSER encoder MUST use if a GSER decoder + would determine the chosen alternative to be something other than the + chosen alternative of the CHOICE value being encoded; otherwise, + MAY be used. + + + + + + + + + +Legg Standards Track [Page 5] + +RFC 4792 Encoding Instructions for GSER January 2007 + + + Example + + Consider this type definition: + + [GSER:CHOICE-OF-STRINGS PRECEDENCE basicName] CHOICE { + extendedName UTF8String, + basicName PrintableString + } + + If a has been used, then a GSER decoder + would first consider whether the was a valid + basicName (a PrintableString) before considering whether it was a + valid extendedName (a UTF8String). + +4.2. Replacement of Existing ChoiceOfStrings Declarations + + In line with the previous declaration [GSER] of the DirectoryString + type as a ChoiceOfStrings type, applications using GSER MUST add this + encoding instruction: + + [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString uTF8String] + + immediately before the "CHOICE" keyword in the definition of the + DirectoryString type in the third and every subsequent edition of the + SelectedAttributeTypes ASN.1 module of X.520 [X.520-3] [X.520-4] + [X.520-5]. + + For example, this is how the DirectoryString definition would appear + in the third, fourth and fifth editions: + + DirectoryString{INTEGER:maxSize} ::= + [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString uTF8String] + CHOICE { + teletexString TeletexString(SIZE (1..maxSize)), + printableString PrintableString(SIZE (1..maxSize)), + universalString UniversalString(SIZE (1..maxSize)), + bmpString BMPString(SIZE (1..maxSize)), + uTF8String UTF8String(SIZE (1..maxSize)) + } + + The uTF8String alternative did not appear in the second edition of + the SelectedAttributeTypes ASN.1 module of X.520 [X.520-2]. For + compatibility, applications using GSER with the second edition of + X.520 MUST add this encoding instruction: + + [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString] + + + + + +Legg Standards Track [Page 6] + +RFC 4792 Encoding Instructions for GSER January 2007 + + + immediately before the "CHOICE" keyword in the definition of the + DirectoryString type. + + For example, this is how the DirectoryString definition would appear + in the second edition: + + DirectoryString{INTEGER:maxSize} ::= + [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString] + CHOICE { + teletexString TeletexString(SIZE (1..maxSize)), + printableString PrintableString(SIZE (1..maxSize)), + universalString UniversalString(SIZE (1..maxSize)) + } + +5. Security Considerations + + This specification changes the manner in which ChoiceOfStrings types + are declared but does not alter the existing behaviour of GSER + implementations. The security considerations for GSER are unchanged + (see [GSER]). + +6. Normative References + + [BCP14] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [GSER] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 + Types", RFC 3641, October 2003. + + [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", RFC 4234, October 2005. + + [X.520-2] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, + Information Technology - Open Systems Interconnection - + The Directory: Selected attribute types + + [X.520-3] ITU-T Recommendation X.520 (08/97) | ISO/IEC 9594-6:1998, + Information Technology - Open Systems Interconnection - + The Directory: Selected attribute types + + [X.520-4] ITU-T Recommendation X.520 (02/01) | ISO/IEC 9594-6:2001, + Information technology - Open Systems Interconnection - + The Directory: Selected attribute types + + [X.520-5] ITU-T Recommendation X.520 (08/05) | ISO/IEC 9594-6:2005, + Information technology - Open Systems Interconnection - + The Directory: Selected attribute types + + + + +Legg Standards Track [Page 7] + +RFC 4792 Encoding Instructions for GSER January 2007 + + + [X.680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1, + Information technology - Abstract Syntax Notation One + (ASN.1): Specification of basic notation. + + [X.680-1] ITU-T Recommendation X.680 (2002) Amendment 1 (10/03) | + ISO/IEC 8824-1:2002/Amd 1:2004, Support for EXTENDED-XER. + +Author's Address + + Dr. Steven Legg + eB2Bcom + Suite 3, Woodhouse Corporate Centre + 935 Station Street + Box Hill North, Victoria 3129 + AUSTRALIA + + Phone: +61 3 9896 7830 + Fax: +61 3 9896 7801 + EMail: steven.legg@eb2bcom.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Legg Standards Track [Page 8] + +RFC 4792 Encoding Instructions for GSER January 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Legg Standards Track [Page 9] + -- cgit v1.2.3