[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 4792

INTERNET-DRAFT                                                   S. Legg
draft-legg-ldap-gser-ei-01.txt                                   eB2Bcom
Intended Category: Standards Track                      October 24, 2005
Updates: RFC 3641


                     Encoding Instructions for the
                  Generic String Encoding Rules (GSER)

               Copyright (C) The Internet Society (2005).

   Status of this Memo

   By submitting this Internet-draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   By submitting this Internet-draft, I accept the provisions of
   Section 3 of BCP 78.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Technical discussion of this document should take place on the
   LDAPEXT mailing list <ldapext@ietf.org>.  Please send editorial
   comments directly to the editor <steven.legg@eb2bcom.com>.

   This Internet-Draft expires on 24 April 2006.


Abstract

   Abstract Syntax Notation One (ASN.1) defines a general framework for
   annotating types in an ASN.1 specification with encoding instructions



Legg                      Expires 24 April 2006                 [Page 1]

INTERNET-DRAFT       Encoding Instructions for GSER     October 24, 2005


   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.













































Legg                      Expires 24 April 2006                 [Page 2]

INTERNET-DRAFT       Encoding Instructions for GSER     October 24, 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions. . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Notation for GSER Encoding Instructions. . . . . . . . . . . .  3
   4.  The CHOICE-OF-STRINGS Encoding Instruction . . . . . . . . . .  4
       4.1.  Effect on GSER Encodings . . . . . . . . . . . . . . . .  6
       4.2.  Replacement of Existing ChoiceOfStrings Declarations . .  7
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  8
   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
   8.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .  9

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



Legg                      Expires 24 April 2006                 [Page 3]

INTERNET-DRAFT       Encoding Instructions for GSER     October 24, 2005


   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 specific 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
   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 ?



Legg                      Expires 24 April 2006                 [Page 4]

INTERNET-DRAFT       Encoding Instructions for GSER     October 24, 2005


   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, other than 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

   (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 ignored.

   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)



Legg                      Expires 24 April 2006                 [Page 5]

INTERNET-DRAFT       Encoding Instructions for GSER     October 24, 2005


   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.

4.1.  Effect on GSER Encodings

   A value of a CHOICE type is encoded according to the <ChoiceValue>
   [GSER] Augmented Backus-Naur Form (ABNF) [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, 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.




Legg                      Expires 24 April 2006                 [Page 6]

INTERNET-DRAFT       Encoding Instructions for GSER     October 24, 2005


   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.

   Example

      Consider this type definition:

         [GSER:CHOICE-OF-STRINGS PRECEDENCE extendedName] CHOICE {
             basicName     PrintableString,
             extendedName  UTF8String
         }

      If a <ChoiceOfStringsValue> has been used then a GSER decoder
      would first consider whether the <StringValue> was a valid
      extendedName (a UTF8String) before considering whether it was a
      valid basicName (a PrintableString).

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].

   For example, this is how the DirectoryString definition would appear
   in the third and four 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:



Legg                      Expires 24 April 2006                 [Page 7]

INTERNET-DRAFT       Encoding Instructions for GSER     October 24, 2005


      [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString]

   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.  IANA Considerations

   This document has no actions for IANA.

7.  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. 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 -



Legg                      Expires 24 April 2006                 [Page 8]

INTERNET-DRAFT       Encoding Instructions for GSER     October 24, 2005


              The Directory: Selected attribute types

   [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]  Draft Amendment 1 (to ITU-T Rec. X.680 | ISO/IEC 8824-1)
              Support for EXTENDED-XER.

8.  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

Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   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 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.



Legg                      Expires 24 April 2006                 [Page 9]

INTERNET-DRAFT       Encoding Instructions for GSER     October 24, 2005


   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.







































Legg                      Expires 24 April 2006                [Page 10]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/