summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4792.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4792.txt')
-rw-r--r--doc/rfc/rfc4792.txt507
1 files changed, 507 insertions, 0 deletions
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 <ChoiceValue>
+ [GSER] Augmented Backus-Naur Form [ABNF] rule. The ABNF for
+ <ChoiceValue> is reproduced here for convenience:
+
+ ChoiceValue = IdentifiedChoiceValue /
+ ChoiceOfStringsValue
+
+ IdentifiedChoiceValue = identifier ":" Value
+ ChoiceOfStringsValue = StringValue
+
+ The <IdentifiedChoiceValue> 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 <identifier> in
+ the <IdentifiedChoiceValue> is the identifier of this NamedType.
+
+ Either the <IdentifiedChoiceValue> rule or the <ChoiceOfStringsValue>
+ rule is used to encode values of a CHOICE type where the ChoiceType
+ is subject to a CHOICE-OF-STRINGS encoding instruction.
+
+ If <ChoiceOfStringsValue> 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 <StringValue>.
+
+ 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 <IdentifiedChoiceValue> if a GSER decoder
+ would determine the chosen alternative to be something other than the
+ chosen alternative of the CHOICE value being encoded; otherwise,
+ <ChoiceOfStringsValue> 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 <ChoiceOfStringsValue> has been used, then a GSER decoder
+ would first consider whether the <StringValue> 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]
+