8 draft-legg-ldap-gser-03.txt Adacel Technologies
9 Intended Category: Standard Track May 7, 2003
12 Generic String Encoding Rules for ASN.1 Types
14 Copyright (C) The Internet Society (2003). All Rights Reserved.
19 This document is an Internet-Draft and is in full conformance with
20 all provisions of Section 10 of RFC2026.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress".
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 Distribution of this document is unlimited. Comments should be sent
39 to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
42 This Internet-Draft expires on 7 November 2003.
47 This document defines a set of Abstract Syntax Notation One (ASN.1)
48 encoding rules, called the Generic String Encoding Rules, that
49 produce a human readable text encoding for values of any given ASN.1
58 Legg Expires 7 November 2003 [Page 1]
60 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
65 1. Table of Contents ............................................. 2
66 2. Introduction .................................................. 2
67 3. Conventions ................................................... 3
68 4. Generic String Encoding Rules ................................. 3
69 4.1 Type Referencing Notations ................................ 4
70 4.2 Restricted Character String Types ......................... 4
71 4.3 ChoiceOfStrings Types ..................................... 5
72 4.4 Identifiers ............................................... 7
73 4.5 BIT STRING ................................................ 7
74 4.6 BOOLEAN ................................................... 8
75 4.7 ENUMERATED ................................................ 8
76 4.8 INTEGER ................................................... 8
77 4.9 NULL ...................................................... 8
78 4.10 OBJECT IDENTIFIER and RELATIVE-OID ....................... 9
79 4.11 OCTET STRING ............................................. 9
80 4.12 CHOICE ................................................... 9
81 4.13 SEQUENCE and SET ......................................... 10
82 4.14 SEQUENCE OF and SET OF ................................... 11
83 4.15 CHARACTER STRING ......................................... 11
84 4.16 EMBEDDED PDV ............................................. 11
85 4.17 EXTERNAL ................................................. 11
86 4.18 INSTANCE OF .............................................. 12
87 4.19 REAL ..................................................... 12
88 4.20 Variant Encodings ........................................ 12
89 5. GSER Transfer Syntax .......................................... 13
90 6. Security Considerations ....................................... 13
91 7. Normative References .......................................... 14
92 8. Informative References ........................................ 15
93 9. Copyright Notice .............................................. 15
94 10. Author's Address ............................................. 16
99 This document defines a set of ASN.1 [8] encoding rules, called the
100 Generic String Encoding Rules or GSER, that produce a human readable
101 UTF8 [6] character string encoding of ASN.1 values of any given
102 arbitrary ASN.1 type.
104 Note that "ASN.1 value" does not mean a BER [13] encoded value. The
105 ASN.1 value is an abstract concept that is independent of any
106 particular encoding. BER is just one possible encoding of an ASN.1
109 GSER is based on ASN.1 value notation [8], with changes to
110 accommodate the notation's use as a transfer syntax, and to support
114 Legg Expires 7 November 2003 [Page 2]
116 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
119 well established ad-hoc string encodings for LDAP [14] directory data
122 Though primarily intended for defining the LDAP-specific encoding of
123 new LDAP attribute syntaxes and assertion syntaxes, these encoding
124 rules could also be used in other domains where human readable
125 renderings of ASN.1 values would be useful.
127 Referencing the Generic String Encoding Rules (GSER) is sufficient to
128 define a human readable text encoding for values of a specific ASN.1
129 type, however other specifications may wish to provide a customized
130 ABNF [3] description, independent of the ASN.1, as a convenience for
131 the implementor (equivalent ABNF for the GSER encodings for ASN.1
132 types commonly occuring in LDAP syntaxes is provided in [15]). Such
133 a specification SHOULD state that if there is a discrepancy between
134 the customized ABNF and the GSER encoding defined by this document,
135 that the GSER encoding takes precedence.
140 Throughout this document "type" shall be taken to mean an ASN.1 type,
141 and "value" shall be taken to mean an ASN.1 value.
143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
145 document are to be interpreted as described in RFC 2119 [1].
148 4. Generic String Encoding Rules
150 The GSER encoding of a value of any ASN.1 type is described by the
153 Value = BitStringValue /
155 CharacterStringValue /
160 GeneralizedTimeValue /
164 ObjectDescriptorValue /
165 ObjectIdentifierValue /
170 Legg Expires 7 November 2003 [Page 3]
172 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
185 The ABNF for each of the above rules is given in the following
189 4.1 Type Referencing Notations
191 A value of a type with a defined type name is encoded according to
192 the type definition on the right hand side of the type assignment for
195 A value of a type denoted by the use of a parameterized type with
196 actual parameters is encoded according to the parameterized type with
197 the DummyReferences [12] substituted with the actual parameters.
199 A value of a tagged or constrained type is encoded as a value of the
200 type without the tag or constraint, respectively. Tags do not appear
201 in the string encodings defined by this document. See [8] and [11]
202 for the details of ASN.1 constraint notation.
204 A value of an open type denoted by an ObjectClassFieldType (Clause 14
205 of [10]) is encoded according to the specific type of the value.
207 A value of a fixed type denoted by an ObjectClassFieldType is encoded
208 according to that fixed type.
210 A value of a selection type is encoded according to the type
211 referenced by the selection type.
213 A value of a type described by TypeFromObject notation (Clause 15 of
214 [10]) is encoded according to the denoted type.
216 A value of a type described by ValueSetFromObjects notation (Clause
217 15 of [10]) is encoded according to the governing type.
220 4.2 Restricted Character String Types
222 The contents of a string value are encoded as a UTF8 character string
226 Legg Expires 7 November 2003 [Page 4]
228 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
231 between double quotes, regardless of the ASN.1 string type.
232 Depending on the ASN.1 string type, and an application's internal
233 representation of that string type, a translation to or from the UTF8
234 character encoding may be required. NumericString, PrintableString,
235 IA5String, VisibleString (ISO646String) are compatible with UTF8 and
236 do not require any translation. BMPString (UCS-2) and
237 UniversalString (UCS-4) have a direct mapping to and from UTF8 [6].
238 For the remaining string types see [8]. Any embedded double quotes
239 in the resulting UTF8 character string are escaped by repeating the
240 double quote characters.
242 A value of the NumericString, PrintableString, TeletexString
243 (T61String), VideotexString, IA5String, GraphicString, VisibleString
244 (ISO646String), GeneralString, BMPString, UniversalString or
245 UTF8String type is encoded according to the <StringValue> rule.
247 StringValue = dquote *SafeUTF8Character dquote
249 dquote = %x22 ; " (double quote)
251 SafeUTF8Character = %x00-21 / %x23-7F / ; ASCII minus dquote
252 dquote dquote / ; escaped double quote
253 %xC0-DF %x80-BF / ; 2 byte UTF8 character
254 %xE0-EF 2(%x80-BF) / ; 3 byte UTF8 character
255 %xF0-F7 3(%x80-BF) / ; 4 byte UTF8 character
256 %xF8-FB 4(%x80-BF) / ; 5 byte UTF8 character
257 %xFC-FD 5(%x80-BF) ; 6 byte UTF8 character
259 A value of the GeneralizedTime type, UTCTime type or ObjectDescriptor
260 type is encoded as a string value. GeneralizedTime and UTCTime use
261 the VisibleString character set so the conversion to UTF8 is trivial.
262 ObjectDescriptor uses the GraphicString type.
264 GeneralizedTimeValue = StringValue
265 UTCTimeValue = StringValue
266 ObjectDescriptorValue = StringValue
269 4.3 ChoiceOfStrings Types
271 It is not uncommon for ASN.1 specifications to define types that are
272 a CHOICE between two or more alternative ASN.1 string types, where
273 the particular alternative chosen carries no semantic significance
274 (DirectoryString [7] being a prime example). Such types are defined
275 to avoid having to use a complicated character encoding for all
276 values when most values could use a simpler string type, or to deal
277 with evolving requirements that compel the use of a broader character
278 set while still maintaining backward compatibility.
282 Legg Expires 7 November 2003 [Page 5]
284 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
287 GSER encodes values of all the ASN.1 string types as UTF8 character
288 strings so the alternative chosen in a purely syntactic CHOICE of
289 string types makes no material difference to the final encoding of
292 While there are certain ASN.1 constructs that betray the semantic
293 significance of the alternatives within a CHOICE type, the absence of
294 those constructs does not necessarily mean a CHOICE type is purely
295 syntactic. Therefore, it is necessary for specifications to declare
296 the purely syntactic CHOICE types so that they may be more compactly
297 encoded (see Section 4.12). These declared CHOICE types are referred
298 to as ChoiceOfStrings types.
300 To be eligible to be declared a ChoiceOfStrings type an ASN.1 type
301 MUST satisfy the following conditions.
303 a) The type is a CHOICE type.
305 b) The component type of each alternative is one of the following
306 ASN.1 restricted string types: NumericString, PrintableString,
307 TeletexString (T61String), VideotexString, IA5String,
308 GraphicString, VisibleString (ISO646String), GeneralString,
309 BMPString, UniversalString or UTF8String.
311 c) All the alternatives are of different restricted string types,
312 i.e. no two alternatives have the same ASN.1 restricted string
315 d) Either none of the alternatives has a constraint, or all of the
316 alternatives have exactly the same constraint.
318 Tagging on the alternative types is ignored.
320 Consider the ASN.1 parameterized type definition of DirectoryString.
322 DirectoryString { INTEGER : maxSize } ::= CHOICE {
323 teletexString TeletexString (SIZE (1..maxSize)),
324 printableString PrintableString (SIZE (1..maxSize)),
325 bmpString BMPString (SIZE (1..maxSize)),
326 universalString UniversalString (SIZE (1..maxSize)),
327 uTF8String UTF8String (SIZE (1..maxSize)) }
329 Any use of the DirectoryString parameterized type with an actual
330 parameter defines a ASN.1 type that satisfies the above conditions.
331 Recognising that the alternative within a DirectoryString carries no
332 semantic significance, this document declares (each and every use of)
333 DirectoryString{} to be a ChoiceOfStrings type.
338 Legg Expires 7 November 2003 [Page 6]
340 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
343 Other specifications MAY declare other types satisfying the above
344 conditions to be ChoiceOfStrings types. The declaration SHOULD be
345 made at the point where the ASN.1 type is defined, otherwise it
346 SHOULD be made at the point where it is introduced as, or in, an LDAP
347 attribute or assertion syntax.
352 An <identifier> conforms to the definition of an identifier in ASN.1
353 notation (Clause 11.3 of [8]). It begins with a lowercase letter and
354 is followed by zero or more letters, digits, and hyphens. A hyphen
355 is not permitted to be the last character and a hyphen is not
356 permitted to be followed by another hyphen. The case of letters in
357 an identifier is always significant.
359 identifier = lowercase *alphanumeric *(hyphen 1*alphanumeric)
360 alphanumeric = uppercase / lowercase / decimal-digit
361 uppercase = %x41-5A ; "A" to "Z"
362 lowercase = %x61-7A ; "a" to "z"
363 decimal-digit = %x30-39 ; "0" to "9"
369 A value of the BIT STRING type is encoded according to the
370 <BitStringValue> rule. If the definition of the BIT STRING type
371 includes a named bit list, the <bit-list> form of <BitStringValue>
372 MAY be used. If the number of bits in a BIT STRING value is a
373 multiple of four the <hstring> form of <BitStringValue> MAY be used.
374 The <bstring> form of <BitStringValue> is used otherwise.
376 BitStringValue = bstring / hstring / bit-list
378 The <bit-list> rule encodes the one bits in the bit string value as a
379 comma separated list of identifiers. Each <identifier> MUST be one
380 of those in the named bit list. An <identifier> MUST NOT appear more
381 than once in the same <bit-list>. The <bstring> rule encodes each
382 bit as the character "0" or "1" in order from the first bit to the
383 last bit. The <hstring> rule encodes each group of four bits as a
384 hexadecimal number where the first bit is the most significant. An
385 odd number of hexadecimal digits is permitted.
387 bit-list = "{" [ sp identifier
388 *( "," sp identifier ) ] sp "}"
390 hstring = squote *hexadecimal-digit squote %x48 ; '...'H
394 Legg Expires 7 November 2003 [Page 7]
396 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
399 hexadecimal-digit = %x30-39 / ; "0" to "9"
402 bstring = squote *binary-digit squote %x42 ; '...'B
403 binary-digit = "0" / "1"
405 sp = *%x20 ; zero, one or more space characters
406 squote = %x27 ; ' (single quote)
411 A value of the BOOLEAN type is encoded according to the
414 BooleanValue = %x54.52.55.45 / ; "TRUE"
415 %x46.41.4C.53.45 ; "FALSE"
420 A value of the ENUMERATED type is encoded according to the
421 <EnumeratedValue> rule. The <identifier> MUST be one of those in the
422 list of enumerations in the definition of the ENUMERATED type.
424 EnumeratedValue = identifier
429 A value of the INTEGER type is encoded according to the
430 <IntegerValue> rule. If the definition of the INTEGER type includes
431 a named number list, the <identifier> form of <IntegerValue> MAY be
432 used, in which case the <identifier> MUST be one of those in the
437 ("-" positive-number) /
440 positive-number = non-zero-digit *decimal-digit
441 non-zero-digit = %x31-39 ; "1" to "9"
446 A value of the NULL type is encoded according to the <NullValue>
450 Legg Expires 7 November 2003 [Page 8]
452 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
457 NullValue = %x4E.55.4C.4C ; "NULL"
460 4.10 OBJECT IDENTIFIER and RELATIVE-OID
462 A value of the OBJECT IDENTIFIER type is encoded according to the
463 <ObjectIdentifierValue> rule. The <ObjectIdentifierValue> rule
464 allows either a dotted decimal representation of the OBJECT
465 IDENTIFIER value or an object descriptor name, i.e. <descr>. The
466 <descr> rule is described in [4]. An object descriptor name is
467 potentially ambiguous and should be used with care.
469 ObjectIdentifierValue = numeric-oid / descr
470 numeric-oid = oid-component 1*( "." oid-component )
471 oid-component = "0" / positive-number
473 A value of the RELATIVE-OID [9] type is encoded according to the
474 <RelativeOIDValue> rule.
476 RelativeOIDValue = oid-component *( "." oid-component )
481 A value of the OCTET STRING type is encoded according to the
482 <OctetStringValue> rule. The octets are encoded in order from the
483 first octet to the last octet. Each octet is encoded as a pair of
484 hexadecimal digits where the first digit corresponds to the four most
485 significant bits of the octet. If the hexadecimal string does not
486 have an even number of digits the four least significant bits in the
487 last octet are assumed to be zero.
489 OctetStringValue = hstring
494 A value of a CHOICE type is encoded according to the <ChoiceValue>
495 rule. The <ChoiceOfStringsValue> encoding MAY be used if the
496 corresponding CHOICE type has been declared a ChoiceOfStrings type.
497 This document declares DirectoryString to be a ChoiceOfStrings type
498 (see Section 4.3). The <IdentifiedChoiceValue> form of <ChoiceValue>
501 ChoiceValue = IdentifiedChoiceValue /
506 Legg Expires 7 November 2003 [Page 9]
508 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
511 IdentifiedChoiceValue = identifier ":" Value
512 ChoiceOfStringsValue = StringValue
514 For implementations that recognise the internal structure of the
515 DirectoryString CHOICE type (e.g. X.500 directories [16]), if the
516 character string between the quotes in a <StringValue> contains only
517 characters that are permitted in a PrintableString the
518 DirectoryString is assumed to use the printableString alternative,
519 otherwise it is assumed to use the uTF8String alternative. The
520 <IdentifiedChoiceValue> rule MAY be used for a value of type
521 DirectoryString to indicate a different alternative to the one that
522 would otherwise be assumed from the string contents. No matter what
523 alternative is chosen, the <Value> will still be a UTF8 encoded
524 character string, however it is a syntax error if the characters in
525 the UTF8 string cannot be represented in the string type of the
528 Implementations that don't care about the internal structure of a
529 DirectoryString value MUST be able to parse the
530 <IdentifiedChoiceValue> form for a DirectoryString value, though the
531 particular identifier found will be of no interest.
533 4.13 SEQUENCE and SET
535 A value of a SEQUENCE type is encoded according to the
536 <SequenceValue> rule. The <ComponentList> rule encodes a comma
537 separated list of the particular component values present in the
538 SEQUENCE value, where each component value is preceded by the
539 corresponding identifier from the SEQUENCE type definition. The
540 components are encoded in the order of their definition in the
543 SequenceValue = ComponentList
545 ComponentList = "{" [ sp NamedValue *( "," sp NamedValue) ] sp "}"
546 NamedValue = identifier msp Value
547 msp = 1*%x20 ; one or more space characters
549 A value of a SET type is encoded according to the <SetValue> rule.
550 The components are encoded in the order of their definition in
551 the SET type (i.e. just like a SEQUENCE value).
552 This is a deliberate departure from ASN.1 value notation where
553 the components of a SET can be written in any order.
555 SetValue = ComponentList
557 SEQUENCE and SET type definitions are sometimes extended by the
558 inclusion of additional component types, so an implementation SHOULD
562 Legg Expires 7 November 2003 [Page 10]
564 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
567 be capable of skipping over any <NamedValue> encoding with an
568 identifier that is not recognised, on the assumption that the sender
569 is using a more recent definition of the SEQUENCE or SET type.
572 4.14 SEQUENCE OF and SET OF
574 A value of a SEQUENCE OF type is encoded according to the
575 <SequenceOfValue> rule, as a comma separated list of the instances in
576 the value. Each instance is encoded according to the component type
577 of the SEQUENCE OF type.
579 SequenceOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
581 A value of a SET OF type is encoded according to the <SetOfValue>
582 rule, as a list of the instances in the value. Each instance is
583 encoded according to the component type of the SET OF type.
585 SetOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
588 4.15 CHARACTER STRING
590 A value of the unrestricted CHARACTER STRING type is encoded
591 according to the corresponding SEQUENCE type defined in Clause 39.5
592 of [8] (see [15] for equivalent ABNF).
594 CharacterStringValue = SequenceValue
599 A value of the EMBEDDED PDV type is encoded according to the
600 corresponding SEQUENCE type defined in Clause 32.5 of [8] (see [15]
601 for equivalent ABNF).
603 EmbeddedPDVValue = SequenceValue
608 A value of the EXTERNAL type is encoded according to the
609 corresponding SEQUENCE type defined in Clause 8.18.1 of [13] (see
610 [15] for equivalent ABNF).
612 ExternalValue = SequenceValue
618 Legg Expires 7 November 2003 [Page 11]
620 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
625 A value of the INSTANCE OF type is encoded according to the
626 corresponding SEQUENCE type defined in Annex C of [10].
628 InstanceOfValue = SequenceValue
633 A value of the REAL type MUST be encoded as "0" if it is zero,
634 otherwise it is encoded as either the special value <PLUS-INFINITY>,
635 the special value <MINUS-INFINITY>, an optionally signed <realnumber>
636 (based on the extended value notation for REAL from [17]) or as a
637 value of the corresponding SEQUENCE type for REAL defined in Clause
638 20.5 of [8] (see [15] for equivalent ABNF).
640 RealValue = "0" ; zero REAL value
641 / PLUS-INFINITY ; positive infinity
642 / MINUS-INFINITY ; negative infinity
643 / realnumber ; positive base 10 REAL value
644 / "-" realnumber ; negative base 10 REAL value
645 / SequenceValue ; non-zero REAL value, base 2 or 10
646 realnumber = mantissa exponent
647 mantissa = (positive-number [ "." *decimal-digit ])
648 / ( "0." *("0") positive-number )
649 exponent = "E" ( "0" / ([ "-" ] positive-number))
651 PLUS-INFINITY = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59
653 MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59
657 4.20 Variant Encodings
659 The values of some named complex ASN.1 types have special string
660 encodings. These special encodings are always used instead of the
661 encoding that would otherwise apply based on the ASN.1 type
664 VariantEncoding = RDNSequenceValue /
665 RelativeDistinguishedNameValue /
668 A value of the RDNSequence type, i.e. a distinguished name, is
669 encoded according to the <RDNSequenceValue> rule, as a quoted LDAPDN
670 character string. The character string is first derived according to
674 Legg Expires 7 November 2003 [Page 12]
676 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
679 the <distinguishedName> rule in Section 3 of [5], and then it is
680 encoded as if it were a UTF8String value, i.e. between double quotes
681 with any embedded double quotes escaped by being repeated.
683 RDNSequenceValue = StringValue
685 A RelativeDistinguishedName value that is not part of an RDNSequence
686 value is encoded according to the <RelativeDistinguishedNameValue>
687 rule as a quoted character string. The character string is first
688 derived according to the <name-component> rule in Section 3 of [5],
689 and then it is encoded as if it were a UTF8String value.
691 RelativeDistinguishedNameValue = StringValue
693 A value of the ORAddress type is encoded according to the
694 <ORAddressValue> rule as a quoted character string. The character
695 string is first derived according to the textual representation of
696 MTS.ORAddress from [2], and then it is encoded as if it were an
699 ORAddressValue = StringValue
702 5. GSER Transfer Syntax
704 The following OBJECT IDENTIFIER has been assigned to identify the
705 Generic String Encoding Rules:
707 { 1 2 36 79672281 0 0 }
709 This OBJECT IDENTIFIER would be used, for example, to describe the
710 transfer syntax for a GSER encoded data-value in an EMBEDDED PDV
714 6. Security Considerations
716 The Generic String Encoding Rules do not define a canonical encoding.
717 That is, a transformation from a GSER encoding into some other
718 encoding (e.g. BER) and back into GSER will not necessarily reproduce
719 exactly the original GSER octet encoding. Therefore GSER SHOULD NOT
720 be used where a canonical encoding is needed.
722 Furthermore, GSER does not necessarily enable the exact octet
723 encoding of values of the TeletexString, VideotexString,
724 GraphicString or GeneralString types to be reconstructed, so a
725 transformation from DER to GSER and back to DER may not reproduce the
726 original DER encoding. Therefore GSER SHOULD NOT be used where
730 Legg Expires 7 November 2003 [Page 13]
732 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
735 reversibility to DER is needed, e.g. for the verification of digital
736 signatures. Instead, DER or a DER-reversible encoding should be
739 When interpreting security-sensitive fields, and in particular fields
740 used to grant or deny access, implementations MUST ensure that any
741 comparisons are done on the underlying abstract value, regardless of
742 the particular encoding used.
745 7. Normative References
747 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
748 Levels", BCP 14, RFC 2119, March 1997.
750 [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
751 between X.400 and RFC 822/MIME", RFC 2156, January 1998.
753 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
754 Specifications: ABNF", RFC 2234, November 1997.
756 [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
757 Directory Access Protocol (v3): Attribute Syntax Definitions",
758 RFC 2252, December 1997.
760 [5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
761 Protocol (v3): UTF-8 String Representation of Distinguished
762 Names", RFC 2253, December 1997.
764 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
767 [7] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
768 Information Technology - Open Systems Interconnection - The
769 Directory: Selected attribute types
771 [8] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
772 Information Technology - Abstract Syntax Notation One (ASN.1):
773 Specification of basic notation
775 [9] ITU-T Recommendation X.680 - Amendment 1 (06/99) | ISO/IEC
776 8824-1:1998/Amd 1:2000 Relative object identifiers
778 [10] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998
779 Information Technology - Abstract Syntax Notation One (ASN.1):
780 Information object specification
782 [11] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998
786 Legg Expires 7 November 2003 [Page 14]
788 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
791 Information Technology - Abstract Syntax Notation One (ASN.1):
792 Constraint specification
794 [12] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998
795 Information Technology - Abstract Syntax Notation One (ASN.1):
796 Parameterization of ASN.1 specifications
798 [13] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
799 Information Technology - ASN.1 encoding rules: Specification of
800 Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
801 Distinguished Encoding Rules (DER)
804 8. Informative References
806 [14] Hodges, J. and R. Morgan, "Lightweight Directory Access
807 Protocol (v3): Technical Specification", RFC 3377, September
810 [15] Legg, S., "Common Elements of GSER Encodings",
811 draft-legg-ldap-gser-abnf-xx.txt, a work in progress, May 2003.
813 [16] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
814 Information Technology - Open Systems Interconnection - The
815 Directory: Overview of concepts, models and services
817 [17] ITU-T Recommendation X.680 - Corrigendum 3 (02/2001)
822 Copyright (C) The Internet Society (2003). All Rights Reserved.
824 This document and translations of it may be copied and furnished to
825 others, and derivative works that comment on or otherwise explain it
826 or assist in its implementation may be prepared, copied, published
827 and distributed, in whole or in part, without restriction of any
828 kind, provided that the above copyright notice and this paragraph are
829 included on all such copies and derivative works. However, this
830 document itself may not be modified in any way, such as by removing
831 the copyright notice or references to the Internet Society or other
832 Internet organizations, except as needed for the purpose of
833 developing Internet standards in which case the procedures for
834 copyrights defined in the Internet Standards process must be
835 followed, or as required to translate it into languages other than
838 The limited permissions granted above are perpetual and will not be
842 Legg Expires 7 November 2003 [Page 15]
844 INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
847 revoked by the Internet Society or its successors or assigns.
849 This document and the information contained herein is provided on an
850 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
851 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
852 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
853 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
854 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
860 Adacel Technologies Ltd.
862 Brighton, Victoria 3186
865 Phone: +61 3 8530 7710
867 EMail: steven.legg@adacel.com.au
898 Legg Expires 7 November 2003 [Page 16]