idnits 2.17.1 draft-legg-ldap-gser-ei-02.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 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 406. ** 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? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (August 30, 2006) is 6442 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) ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Legg 3 draft-legg-ldap-gser-ei-02.txt eB2Bcom 4 Intended Category: Standards Track August 30, 2006 5 Updates: RFC 3641 7 Encoding Instructions for the 8 Generic String Encoding Rules (GSER) 10 Copyright (C) The Internet Society (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 36 LDAPEXT mailing list . Please send editorial 37 comments directly to the editor . 39 This Internet-Draft expires on 30 February 2007. 41 Abstract 43 Abstract Syntax Notation One (ASN.1) defines a general framework for 44 annotating types in an ASN.1 specification with encoding instructions 45 that alter how values of those types are encoded according to ASN.1 46 encoding rules. This document defines the supporting notation for 47 encoding instructions that apply to the Generic String Encoding Rules 48 (GSER), and in particular defines an encoding instruction to provide 49 a machine-processable representation for the declaration of a GSER 50 ChoiceOfStrings type. 52 Table of Contents 54 1. Introduction ....................................................3 55 2. Conventions .....................................................3 56 3. Notation for GSER Encoding Instructions .........................3 57 4. The CHOICE-OF-STRINGS Encoding Instruction ......................4 58 4.1. Effect on GSER Encodings ...................................6 59 4.2. Replacement of Existing ChoiceOfStrings Declarations .......7 60 5. Security Considerations .........................................8 61 6. IANA Considerations .............................................8 62 7. Normative References ............................................8 63 8. Author's Address ................................................9 65 1. Introduction 67 Abstract Syntax Notation One (ASN.1) [X.680] defines a general 68 framework for annotating types in an ASN.1 specification with 69 encoding instructions [X.680-1] that alter how values of those types 70 are encoded according to ASN.1 encoding rules. This document defines 71 the supporting notation for encoding instructions that apply to the 72 Generic String Encoding Rules (GSER) [GSER], and in particular 73 defines an encoding instruction, the CHOICE-OF-STRINGS encoding 74 instruction, to provide a machine-processable representation for the 75 declaration of a GSER ChoiceOfStrings type. 77 The CHOICE-OF-STRINGS encoding instruction SHOULD be used instead of 78 simply declaring a ChoiceOfStrings type. 80 2. Conventions 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 84 document are to be interpreted as described in BCP 14, RFC 2119 85 [BCP14]. 87 Throughout this document "type" shall be taken to mean an ASN.1 type, 88 and "value" shall be taken to mean an ASN.1 abstract value, unless 89 qualified otherwise. 91 A reference to an ASN.1 production [X.680] (e.g., Type, NamedType) is 92 a reference to text in an ASN.1 specification corresponding to that 93 production. 95 3. Notation for GSER Encoding Instructions 97 The grammar of ASN.1 permits the application of encoding instructions 98 [X.680-1], through type prefixes and encoding control sections, that 99 modify how abstract values are encoded by nominated encoding rules. 101 The generic notation for type prefixes and encoding control sections 102 is defined by the ASN.1 basic notation [X.680] [X.680-1], and 103 includes an encoding reference to identify the specific encoding 104 rules that are affected by the encoding instruction. 106 The encoding reference that identifies the Generic String Encoding 107 Rules is literally GSER. 109 The specific notation for an encoding instruction for a particular 110 set of encoding rules is left to the specification of those encoding 111 rules. Consequently, this companion document to the GSER 112 specification [GSER] defines the notation for GSER encoding 113 instructions. Specifically, it elaborates the EncodingInstruction 114 and EncodingInstructionAssignmentList placeholder productions of the 115 ASN.1 basic notation. 117 In the context of the GSER encoding reference the EncodingInstruction 118 production is defined as follows, using the conventions of the ASN.1 119 basic notation: 121 EncodingInstruction ::= 122 ChoiceOfStringsInstruction 124 In the context of the GSER encoding reference the 125 EncodingInstructionAssignmentList production (which only appears in 126 an encoding control section) is empty: 128 EncodingInstructionAssignmentList ::= empty 130 4. The CHOICE-OF-STRINGS Encoding Instruction 132 The CHOICE-OF-STRINGS encoding instruction allows a GSER encoder to 133 encode the alternative of a CHOICE (of restricted string types) 134 without the leading identifier. The optional PrecedenceList also 135 allows a specification writer to alter the order in which a GSER 136 decoder will consider the alternatives of the CHOICE as it determines 137 which alternative has been encoded when the identifier is absent. 139 The notation for a CHOICE-OF-STRINGS encoding instruction is defined 140 as follows: 142 UnionInstruction ::= "CHOICE-OF-STRINGS" AlternativesPrecedence ? 144 AlternativesPrecedence ::= "PRECEDENCE" PrecedenceList 146 PrecedenceList ::= identifier PrecedenceList ? 148 The Type in the EncodingPrefixedType for a CHOICE-OF-STRINGS encoding 149 instruction SHALL be: 151 (a) a BuiltinType that is a ChoiceType, or 153 (b) a ConstrainedType, other than a TypeWithConstraint, where the 154 Type in the ConstrainedType is one of (a) to (d), or 156 (c) a BuiltinType that is a PrefixedType that is a TaggedType where 157 the Type in the TaggedType is one of (a) to (d), or 159 (d) a BuiltinType that is a PrefixedType that is an 160 EncodingPrefixedType where the Type in the EncodingPrefixedType 161 is one of (a) to (d). 163 The effect of this condition is to force the CHOICE-OF-STRINGS 164 encoding instruction to be textually co-located with the CHOICE type 165 definition to which it applies. This makes it clear to a reader that 166 the encoding instruction applies to every use of the CHOICE type no 167 matter how it might be referenced. 169 The ChoiceType in case (a) is said to be "subject to" the 170 CHOICE-OF-STRINGS encoding instruction. 172 The Type of each NamedType of the ChoiceType in case (a) MUST be: 174 (1) the NumericString, PrintableString, TeletexString (T61String), 175 VideotexString, IA5String, GraphicString, VisibleString 176 (ISO646String), GeneralString, BMPString, UniversalString or 177 UTF8String type, or 179 (2) a type notation that references a type that is one of (1) to (4), 180 or 182 (3) a constrained type where the type that is constrained is one of 183 (1) to (4), or 185 (4) a prefixed type where the type that is prefixed is one of (1) to 186 (4). 188 ASIDE: A tagged type is a special case of a prefixed type. An 189 effect of case (4) is that tagging is not significant. 191 The ASN.1 restricted string type in case (1) MUST be different for 192 each NamedType in the ChoiceType, i.e., no two alternatives have the 193 same restricted string type. 195 If case (3) applies to any NamedType, then the constraint in case (3) 196 MUST be the same for each NamedType, i.e., either none of the 197 alternatives has a constraint, or all of the alternatives have 198 exactly the same constraint. 200 Each identifier in the PrecedenceList MUST be the identifier of a 201 NamedType of the ChoiceType. 203 A particular identifier SHALL NOT appear more than once in the same 204 PrecedenceList. 206 4.1. Effect on GSER Encodings 208 A value of a CHOICE type is encoded according to the 209 [GSER] Augmented Backus-Naur Form (ABNF) [ABNF] rule. The ABNF for 210 is reproduced here for convenience: 212 ChoiceValue = IdentifiedChoiceValue / 213 ChoiceOfStringsValue 215 IdentifiedChoiceValue = identifier ":" Value 216 ChoiceOfStringsValue = StringValue 218 The rule MUST be used to encode values of a 219 CHOICE type where the ChoiceType is not subject to a 220 CHOICE-OF-STRINGS encoding instruction. 222 The chosen alternative of a value of a CHOICE type corresponds to 223 some NamedType in the definition of the type. The in 224 the is the identifier of this NamedType. 226 Either the rule or the 227 rule is used to encode values of a CHOICE type where the ChoiceType 228 is subject to a CHOICE-OF-STRINGS encoding instruction. 230 If has been used, then a GSER decoder MUST 231 determine the chosen alternative by considering the alternatives of 232 the CHOICE in the order prescribed below and accepting the first 233 alternative that allows all of the characters in the . 235 If the CHOICE-OF-STRINGS encoding instruction has a PrecedenceList, 236 then the alternatives of the ChoiceType referenced by the 237 PrecedenceList are considered in the order identified by that 238 PrecedenceList, then the remaining alternatives are considered in the 239 order of their definition in the ChoiceType. If the 240 CHOICE-OF-STRINGS encoding instruction does not have a 241 PrecedenceList, then all the alternatives of the ChoiceType are 242 considered in the order of their definition in the ChoiceType. 244 A GSER encoder MUST use if a GSER decoder 245 would determine the chosen alternative to be something other than the 246 chosen alternative of the CHOICE value being encoded, otherwise 247 MAY be used. 249 Example 251 Consider this type definition: 253 [GSER:CHOICE-OF-STRINGS PRECEDENCE basicName] CHOICE { 254 extendedName UTF8String, 255 basicName PrintableString 256 } 258 If a has been used, then a GSER decoder 259 would first consider whether the was a valid 260 basicName (a PrintableString) before considering whether it was a 261 valid extendedName (a UTF8String). 263 4.2. Replacement of Existing ChoiceOfStrings Declarations 265 In line with the previous declaration [GSER] of the DirectoryString 266 type as a ChoiceOfStrings type, applications using GSER MUST add this 267 encoding instruction: 269 [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString uTF8String] 271 immediately before the "CHOICE" keyword in the definition of the 272 DirectoryString type in the third and every subsequent edition of the 273 SelectedAttributeTypes ASN.1 module of X.520 [X.520-3] [X.520-4] 274 [X.520-5]. 276 For example, this is how the DirectoryString definition would appear 277 in the third, fourth and fifth editions: 279 DirectoryString{INTEGER:maxSize} ::= 280 [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString uTF8String] 281 CHOICE { 282 teletexString TeletexString(SIZE (1..maxSize)), 283 printableString PrintableString(SIZE (1..maxSize)), 284 universalString UniversalString(SIZE (1..maxSize)), 285 bmpString BMPString(SIZE (1..maxSize)), 286 uTF8String UTF8String(SIZE (1..maxSize)) 287 } 289 The uTF8String alternative did not appear in the second edition of 290 the SelectedAttributeTypes ASN.1 module of X.520 [X.520-2]. For 291 compatibility, applications using GSER with the second edition of 292 X.520 MUST add this encoding instruction: 294 [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString] 296 immediately before the "CHOICE" keyword in the definition of the 297 DirectoryString type. 299 For example, this is how the DirectoryString definition would appear 300 in the second edition: 302 DirectoryString{INTEGER:maxSize} ::= 303 [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString] 304 CHOICE { 305 teletexString TeletexString(SIZE (1..maxSize)), 306 printableString PrintableString(SIZE (1..maxSize)), 307 universalString UniversalString(SIZE (1..maxSize)) 308 } 310 5. Security Considerations 312 This specification changes the manner in which ChoiceOfStrings types 313 are declared but does not alter the existing behaviour of GSER 314 implementations. The security considerations for GSER are unchanged 315 (see [GSER]). 317 6. IANA Considerations 319 This document has no actions for IANA. 321 7. Normative References 323 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997. 326 [GSER] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 327 Types", RFC 3641, October 2003. 329 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 330 Specifications: ABNF", RFC 4234, October 2005. 332 [X.520-2] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, 333 Information Technology - Open Systems Interconnection - 334 The Directory: Selected attribute types 336 [X.520-3] ITU-T Recommendation X.520 (08/97) | ISO/IEC 9594-6:1998, 337 Information Technology - Open Systems Interconnection - 338 The Directory: Selected attribute types 340 [X.520-4] ITU-T Recommendation X.520 (02/01) | ISO/IEC 9594-6:2001, 341 Information technology - Open Systems Interconnection - 342 The Directory: Selected attribute types 344 [X.520-5] ITU-T Recommendation X.520 (08/05) | ISO/IEC 9594-6:2005, 345 Information technology - Open Systems Interconnection - 346 The Directory: Selected attribute types 348 [X.680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1, 349 Information technology - Abstract Syntax Notation One 350 (ASN.1): Specification of basic notation. 352 [X.680-1] Draft Amendment 1 (to ITU-T Rec. X.680 | ISO/IEC 8824-1) 353 Support for EXTENDED-XER. 355 8. Author's Address 357 Dr. Steven Legg 358 eB2Bcom 359 Suite 3, Woodhouse Corporate Centre 360 935 Station Street 361 Box Hill North, Victoria 3129 362 AUSTRALIA 364 Phone: +61 3 9896 7830 365 Fax: +61 3 9896 7801 366 EMail: steven.legg@eb2bcom.com 368 Full Copyright Statement 370 Copyright (C) The Internet Society (2006). 372 This document is subject to the rights, licenses and restrictions 373 contained in BCP 78, and except as set forth therein, the authors 374 retain all their rights. 376 This document and the information contained herein are provided on an 377 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 378 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 379 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 380 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 381 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 382 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 384 Intellectual Property 386 The IETF takes no position regarding the validity or scope of any 387 Intellectual Property Rights or other rights that might be claimed to 388 pertain to the implementation or use of the technology described in 389 this document or the extent to which any license under such rights 390 might or might not be available; nor does it represent that it has 391 made any independent effort to identify any such rights. Information 392 on the procedures with respect to rights in RFC documents can be 393 found in BCP 78 and BCP 79. 395 Copies of IPR disclosures made to the IETF Secretariat and any 396 assurances of licenses to be made available, or the result of an 397 attempt made to obtain a general license or permission for the use of 398 such proprietary rights by implementers or users of this 399 specification can be obtained from the IETF on-line IPR repository at 400 http://www.ietf.org/ipr. 402 The IETF invites any interested party to bring to its attention any 403 copyrights, patents or patent applications, or other proprietary 404 rights that may cover technology that may be required to implement 405 this standard. Please address the information to the IETF at 406 ietf-ipr@ietf.org.