8 draft-legg-ldap-gser-01.txt Adacel Technologies
9 Intended Category: Standard Track August 19, 2002
12 Generic String Encoding Rules for ASN.1 Types
14 Copyright (C) The Internet Society (2002). 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 19 February 2002.
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 19 February 2002 [Page 1]
60 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
65 1. Abstract ...................................................... 1
66 2. Table of Contents ............................................. 2
67 3. Introduction .................................................. 2
68 4. Conventions ................................................... 3
69 5. Generic String Encoding Rules ................................. 3
70 5.1 Type Referencing Notations ................................ 4
71 5.2 Restricted Character String Types ......................... 4
72 5.3 ChoiceOfStrings Types ..................................... 5
73 5.4 Identifiers ............................................... 7
74 5.5 BIT STRING ................................................ 7
75 5.6 BOOLEAN ................................................... 8
76 5.7 ENUMERATED ................................................ 8
77 5.8 INTEGER ................................................... 8
78 5.9 NULL ...................................................... 8
79 5.10 OBJECT IDENTIFIER and RELATIVE-OID ....................... 9
80 5.11 OCTET STRING ............................................. 9
81 5.12 CHOICE ................................................... 9
82 5.13 SEQUENCE and SET ......................................... 10
83 5.14 SEQUENCE OF and SET OF ................................... 11
84 5.15 CHARACTER STRING ......................................... 11
85 5.16 EMBEDDED PDV ............................................. 11
86 5.17 EXTERNAL ................................................. 11
87 5.18 INSTANCE OF .............................................. 12
88 5.19 REAL ..................................................... 12
89 5.20 Variant Encodings ........................................ 12
90 6. GSER Transfer Syntax .......................................... 13
91 7. Security Considerations ....................................... 13
92 8. Normative References .......................................... 13
93 9. Informative References ........................................ 14
94 10. Copyright Notice ............................................. 15
95 11. Author's Address ............................................. 15
100 This document defines a set of ASN.1 [8] encoding rules, called the
101 Generic String Encoding Rules or GSER, that produce a human readable
102 UTF8 [6] character string encoding of ASN.1 values of any given
103 arbitrary ASN.1 type.
105 Note that "ASN.1 value" does not mean a BER [17] encoded value. The
106 ASN.1 value is an abstract concept that is independent of any
107 particular encoding. BER is just one possible encoding of an ASN.1
110 GSER is based on ASN.1 value notation [8], with changes to
114 Legg Expires 19 February 2002 [Page 2]
116 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
119 accommodate the notation's use as a transfer syntax, and to support
120 well established ad-hoc string encodings for LDAP [13] directory data
123 Though primarily intended for defining the LDAP-specific encoding of
124 new LDAP attribute syntaxes and assertion syntaxes, these encoding
125 rules could also be used in other domains where human readable
126 renderings of ASN.1 values would be useful.
128 Referencing the Generic String Encoding Rules (GSER) is sufficient to
129 define a human readable text encoding for values of a specific ASN.1
130 type, however other specifications may wish to provide a customized
131 ABNF [3] description, independent of the ASN.1, as a convenience for
132 the implementor (equivalent ABNF for the GSER encodings for ASN.1
133 types commonly occuring in LDAP syntaxes is provided in [14]). Such
134 a specification SHOULD state that if there is a discrepancy between
135 the customized ABNF and the GSER encoding defined by this document,
136 that the GSER encoding takes precedence.
141 Throughout this document "type" shall be taken to mean an ASN.1 type,
142 and "value" shall be taken to mean an ASN.1 value.
144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
146 document are to be interpreted as described in RFC 2119 [1].
149 5. Generic String Encoding Rules
151 The GSER encoding of a value of any ASN.1 type is described by the
154 Value = BitStringValue /
156 CharacterStringValue /
161 GeneralizedTimeValue /
165 ObjectDescriptorValue /
166 ObjectIdentifierValue /
170 Legg Expires 19 February 2002 [Page 3]
172 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
186 The ABNF for each of the above rules is given in the following
190 5.1 Type Referencing Notations
192 A value of a type with a defined type name is encoded according to
193 the type definition on the right hand side of the type assignment for
196 A value of a type denoted by the use of a parameterized type with
197 actual parameters is encoded according to the parameterized type with
198 the DummyReferences [12] substituted with the actual parameters.
200 A value of a tagged or constrained type is encoded as a value of the
201 type without the tag or constraint, respectively. Tags do not appear
202 in the string encodings defined by this document. See [8] and [11]
203 for the details of ASN.1 constraint notation.
205 A value of an open type denoted by an ObjectClassFieldType (Clause 14
206 of [10]) is encoded according to the specific type of the value.
208 A value of a fixed type denoted by an ObjectClassFieldType is encoded
209 according to that fixed type.
211 A value of a selection type is encoded according to the type
212 referenced by the selection type.
214 A value of a type described by TypeFromObject notation (Clause 15 of
215 [10]) is encoded according to the denoted type.
217 A value of a type described by ValueSetFromObjects notation (Clause
218 15 of [10]) is encoded according to the governing type.
221 5.2 Restricted Character String Types
226 Legg Expires 19 February 2002 [Page 4]
228 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
231 The contents of a string value are encoded as a UTF8 character string
232 between double quotes, regardless of the ASN.1 string type.
233 Depending on the ASN.1 string type, and an application's internal
234 representation of that string type, a translation to or from the UTF8
235 character encoding may be required. NumericString, PrintableString,
236 IA5String, VisibleString (ISO646String) are compatible with UTF8 and
237 do not require any translation. BMPString (UCS-2) and
238 UniversalString (UCS-4) have a direct mapping to and from UTF8 [6].
239 For the remaining string types see [8]. Any embedded double quotes
240 in the resulting UTF8 character string are escaped by repeating the
241 double quote characters.
243 A value of the NumericString, PrintableString, TeletexString
244 (T61String), VideotexString, IA5String, GraphicString, VisibleString
245 (ISO646String), GeneralString, BMPString, UniversalString or
246 UTF8String type is encoded according to the <StringValue> rule.
248 StringValue = dquote *SafeUTF8Character dquote
250 dquote = %x22 ; " (double quote)
252 SafeUTF8Character = %x00-21 / %x23-7F / ; ASCII minus dquote
253 dquote dquote / ; escaped double quote
254 %xC0-DF %x80-BF / ; 2 byte UTF8 character
255 %xE0-EF 2(%x80-BF) / ; 3 byte UTF8 character
256 %xF0-F7 3(%x80-BF) / ; 4 byte UTF8 character
257 %xF8-FB 4(%x80-BF) / ; 5 byte UTF8 character
258 %xFC-FD 5(%x80-BF) ; 6 byte UTF8 character
260 A value of the GeneralizedTime type, UTCTime type or ObjectDescriptor
261 type is encoded as a string value. GeneralizedTime and UTCTime use
262 the VisibleString character set so the conversion to UTF8 is trivial.
263 ObjectDescriptor uses the GraphicString type.
265 GeneralizedTimeValue = StringValue
266 UTCTimeValue = StringValue
267 ObjectDescriptorValue = StringValue
270 5.3 ChoiceOfStrings Types
272 It is not uncommon for ASN.1 specifications to define types that are
273 a CHOICE between two or more alternative ASN.1 string types, where
274 the particular alternative chosen carries no semantic significance
275 (DirectoryString [7] being a prime example). Such types are defined
276 to avoid having to use a complicated character encoding for all
277 values when most values could use a simpler string type, or to deal
278 with evolving requirements that compel the use of a broader character
282 Legg Expires 19 February 2002 [Page 5]
284 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
287 set while still maintaining backward compatibility.
289 GSER encodes values of all the ASN.1 string types as UTF8 character
290 strings so the alternative chosen in a purely syntactic CHOICE of
291 string types makes no material difference to the final encoding of
294 While there are certain ASN.1 constructs that betray the semantic
295 significance of the alternatives within a CHOICE type, the absence of
296 those constructs does not necessarily mean a CHOICE type is purely
297 syntactic. Therefore, it is necessary for specifications to declare
298 the purely syntactic CHOICE types so that they may be more compactly
299 encoded (see Section 5.12). These declared CHOICE types are referred
300 to as ChoiceOfStrings types.
302 To be eligible to be declared a ChoiceOfStrings type an ASN.1 type
303 MUST satisfy the following conditions.
305 a) The type is a CHOICE type.
307 b) The component type of each alternative is one of the following
308 ASN.1 restricted string types: NumericString, PrintableString,
309 TeletexString (T61String), VideotexString, IA5String,
310 GraphicString, VisibleString (ISO646String), GeneralString,
311 BMPString, UniversalString or UTF8String.
313 c) All the alternatives are of different restricted string types,
314 i.e. no two alternatives have the same ASN.1 restricted string
317 d) Either none of the alternatives has a constraint, or all of the
318 alternatives have exactly the same constraint.
320 Tagging on the alternative types is ignored.
322 Consider the ASN.1 parameterized type definition of DirectoryString.
324 DirectoryString { INTEGER : maxSize } ::= CHOICE {
325 teletexString TeletexString (SIZE (1..maxSize)),
326 printableString PrintableString (SIZE (1..maxSize)),
327 bmpString BMPString (SIZE (1..maxSize)),
328 universalString UniversalString (SIZE (1..maxSize)),
329 uTF8String UTF8String (SIZE (1..maxSize)) }
331 Any use of the DirectoryString parameterized type with an actual
332 parameter defines a ASN.1 type that satisfies the above conditions.
333 Recognising that the alternative within a DirectoryString carries no
334 semantic significance, this document declares (each and every use of)
338 Legg Expires 19 February 2002 [Page 6]
340 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
343 DirectoryString{} to be a ChoiceOfStrings type.
345 Other specifications MAY declare other types satisfying the above
346 conditions to be ChoiceOfStrings types. The declaration SHOULD be
347 made at the point where the ASN.1 type is defined, otherwise it
348 SHOULD be made at the point where it is introduced as, or in, an LDAP
349 attribute or assertion syntax.
354 An <identifier> conforms to the definition of an identifier in ASN.1
355 notation (Clause 11.3 of [8]). It begins with a lowercase letter and
356 is followed by zero or more letters, digits, and hyphens. A hyphen
357 is not permitted to be the last character and a hyphen is not
358 permitted to be followed by another hyphen. The case of letters in
359 an identifier is always significant.
361 identifier = lowercase *alphanumeric *(hyphen 1*alphanumeric)
362 alphanumeric = uppercase / lowercase / decimal-digit
363 uppercase = %x41-5A ; "A" to "Z"
364 lowercase = %x61-7A ; "a" to "z"
365 decimal-digit = %x30-39 ; "0" to "9"
371 A value of the BIT STRING type is encoded according to the
372 <BitStringValue> rule. If the definition of the BIT STRING type
373 includes a named bit list, the <bit-list> form of <BitStringValue>
374 rule MAY be used. If the number of bits in a BIT STRING value is a
375 multiple of four the <hstring> form of <BitStringValue> MAY be used.
376 The <bstring> form of <BitStringValue> is used otherwise.
378 BitStringValue = bstring / hstring / bit-list
380 The <bit-list> rule encodes the one bits in the bit string value as a
381 comma separated list of identifiers. Each <identifier> MUST be one
382 of those in the named bit list. An <identifier> MUST NOT appear more
383 than once in the same <bit-list>. The <bstring> rule encodes each
384 bit as the character "0" or "1" in order from the first bit to the
385 last bit. The <hstring> rule encodes each group of four bits as a
386 hexadecimal number where the first bit is the most significant. An
387 odd number of hexadecimal digits is permitted.
389 bit-list = "{" [ sp identifier
390 *( "," sp identifier ) ] sp "}"
394 Legg Expires 19 February 2002 [Page 7]
396 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
399 hstring = squote *hexadecimal-digit squote %x48 ; '...'H
400 hexadecimal-digit = %x30-39 / ; "0" to "9"
403 bstring = squote *binary-digit squote %x42 ; '...'B
404 binary-digit = "0" / "1"
406 sp = *%x20 ; zero, one or more space characters
407 squote = %x27 ; ' (single quote)
412 A value of the BOOLEAN type is encoded according to the
415 BooleanValue = %x54.52.55.45 / ; "TRUE"
416 %x46.41.4C.53.45 ; "FALSE"
421 A value of the ENUMERATED type is encoded according to the
422 <EnumeratedValue> rule. The <identifier> MUST be one of those in the
423 list of enumerations in the definition of the ENUMERATED type.
425 EnumeratedValue = identifier
430 A value of the INTEGER type is encoded according to the
431 <IntegerValue> rule. If the definition of the INTEGER type includes
432 a named number list, the <identifier> form of <IntegerValue> MAY be
433 used, in which case the <identifier> MUST be one of those in the
438 ("-" positive-number) /
441 positive-number = non-zero-digit *decimal-digit
442 non-zero-digit = %x31-39 ; "1" to "9"
450 Legg Expires 19 February 2002 [Page 8]
452 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
455 A value of the NULL type is encoded according to the <NullValue>
458 NullValue = %x4E.55.4C.4C ; "NULL"
461 5.10 OBJECT IDENTIFIER and RELATIVE-OID
463 A value of the OBJECT IDENTIFIER type is encoded according to the
464 <ObjectIdentifierValue> rule. The <ObjectIdentifierValue> rule
465 allows either a dotted decimal representation of the OBJECT
466 IDENTIFIER value or an object descriptor name, i.e. <descr>. The
467 <descr> rule is described in [4]. An object descriptor name is
468 potentially ambiguous and should be used with care.
470 ObjectIdentifierValue = numeric-oid / descr
471 numeric-oid = oid-component 1*( "." oid-component )
472 oid-component = "0" / positive-number
474 A value of the RELATIVE-OID [9] type is encoded according to the
475 <RelativeOIDValue> rule.
477 RelativeOIDValue = oid-component *( "." oid-component )
482 A value of the OCTET STRING type is encoded according to the
483 <OctetStringValue> rule. The octets are encoded in order from the
484 first octet to the last octet. Each octet is encoded as a pair of
485 hexadecimal digits where the first digit corresponds to the four most
486 significant bits of the octet. If the hexadecimal string does not
487 have an even number of digits the four least significant bits in the
488 last octet are assumed to be zero.
490 OctetStringValue = hstring
495 A value of a CHOICE type is encoded according to the <ChoiceValue>
496 rule. The <ChoiceOfStringsValue> encoding MAY be used if the
497 corresponding CHOICE type has been declared a ChoiceOfStrings type.
498 This document declares DirectoryString to be a ChoiceOfStrings type
499 (see Section 5.3). The <IdentifiedChoiceValue> form of <ChoiceValue>
502 ChoiceValue = IdentifiedChoiceValue /
506 Legg Expires 19 February 2002 [Page 9]
508 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
513 IdentifiedChoiceValue = identifier ":" Value
514 ChoiceOfStringsValue = StringValue
516 For implementations that recognise the internal structure of the
517 DirectoryString CHOICE type (e.g. X.500 directories [15]), if the
518 character string between the quotes in a <StringValue> contains only
519 characters that are permitted in a PrintableString the
520 DirectoryString is assumed to use the printableString alternative,
521 otherwise it is assumed to use the uTF8String alternative. The
522 <IdentifiedChoiceValue> rule MAY be used for a value of type
523 DirectoryString to indicate a different alternative to the one that
524 would otherwise be assumed from the string contents. No matter what
525 alternative is chosen, the <Value> will still be a UTF8 encoded
526 character string, however it is a syntax error if the characters in
527 the UTF8 string cannot be represented in the string type of the
530 Implementations that don't care about the internal structure of a
531 DirectoryString value MUST be able to parse the
532 <IdentifiedChoiceValue> form for a DirectoryString value, though the
533 particular identifier found will be of no interest.
535 5.13 SEQUENCE and SET
537 A value of a SEQUENCE type is encoded according to the
538 <SequenceValue> rule. The <ComponentList> rule encodes a comma
539 separated list of the particular component values present in the
540 SEQUENCE value, where each component value is preceded by the
541 corresponding identifier from the SEQUENCE type definition. The
542 components are encoded in the order of their definition in the
545 SequenceValue = ComponentList
547 ComponentList = "{" [ sp NamedValue *( "," sp NamedValue) ] sp "}"
548 NamedValue = identifier msp Value
549 msp = 1*%x20 ; one or more space characters
551 A value of a SET type is encoded according to the <SetValue> rule.
552 The components are encoded in the order of their definition in
553 the SET type (i.e. just like a SEQUENCE value).
554 This is a deliberate departure from ASN.1 value notation where
555 the components of a SET can be written in any order.
557 SetValue = ComponentList
562 Legg Expires 19 February 2002 [Page 10]
564 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
567 SEQUENCE and SET type definitions are sometimes extended by the
568 inclusion of additional component types, so an implementation SHOULD
569 be capable of skipping over any <NamedValue> encoding with an
570 identifier that is not recognised, on the assumption that the sender
571 is using a more recent definition of the SEQUENCE or SET type.
574 5.14 SEQUENCE OF and SET OF
576 A value of a SEQUENCE OF type is encoded according to the
577 <SequenceOfValue> rule, as a comma separated list of the instances in
578 the value. Each instance is encoded according to the component type
579 of the SEQUENCE OF type.
581 SequenceOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
583 A value of a SET OF type is encoded according to the <SetOfValue>
584 rule, as a list of the instances in the value. Each instance is
585 encoded according to the component type of the SET OF type.
587 SetOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
590 5.15 CHARACTER STRING
592 A value of the unrestricted CHARACTER STRING type is encoded
593 according to the corresponding SEQUENCE type defined in Clause 39.5
594 of [8] (see [14] for equivalent ABNF).
596 CharacterStringValue = SequenceValue
601 A value of the EMBEDDED PDV type is encoded according to the
602 corresponding SEQUENCE type defined in Clause 32.5 of [8] (see [14]
603 for equivalent ABNF).
605 EmbeddedPDVValue = SequenceValue
610 A value of the EXTERNAL type is encoded according to the
611 corresponding SEQUENCE type defined in Clause 33.5 of [8] (see [14]
612 for equivalent ABNF).
614 ExternalValue = SequenceValue
618 Legg Expires 19 February 2002 [Page 11]
620 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
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 [16]) or as a
637 value of the corresponding SEQUENCE type for REAL defined in Clause
638 20.5 of [8] (see [14] 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 5.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 19 February 2002 [Page 12]
676 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
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 6. 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 EXTERNAL or
714 7. Security Considerations
716 The Generic String Encoding Rules do not necessarily enable the exact
717 octet encoding of values of the TeletexString, VideotexString,
718 GraphicString or GeneralString types to be reconstructed, so a
719 transformation from DER to GSER and back to DER may not reproduce the
720 original DER encoding. This has consequences for the verification of
724 8. Normative References
726 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
730 Legg Expires 19 February 2002 [Page 13]
732 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
735 Levels", BCP 14, RFC 2119, March 1997.
737 [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
738 between X.400 and RFC 822/MIME", RFC 2156, January 1998.
740 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
741 Specifications: ABNF", RFC 2234, November 1997.
743 [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
744 Directory Access Protocol (v3): Attribute Syntax Definitions",
745 RFC 2252, December 1997.
747 [5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
748 Protocol (v3): UTF-8 String Representation of Distinguished
749 Names", RFC 2253, December 1997.
751 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
754 [7] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
755 Information Technology - Open Systems Interconnection - The
756 Directory: Selected attribute types
758 [8] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
759 Information Technology - Abstract Syntax Notation One (ASN.1):
760 Specification of basic notation
762 [9] ITU-T Recommendation X.680 - Amendment 1 (06/99) | ISO/IEC
763 8824-1:1998/Amd 1:2000 Relative object identifiers
765 [10] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998
766 Information Technology - Abstract Syntax Notation One (ASN.1):
767 Information object specification
769 [11] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998
770 Information Technology - Abstract Syntax Notation One (ASN.1):
771 Constraint specification
773 [12] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998
774 Information Technology - Abstract Syntax Notation One (ASN.1):
775 Parameterization of ASN.1 specifications
778 9. Informative References
780 [13] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
781 Protocol (v3)", RFC 2251, December 1997.
786 Legg Expires 19 February 2002 [Page 14]
788 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
791 [14] Legg, S., "Common Elements of GSER Encodings",
792 draft-legg-ldap-gser-abnf-xx.txt, a work in progress, August
795 [15] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
796 Information Technology - Open Systems Interconnection - The
797 Directory: Overview of concepts, models and services
799 [16] ITU-T Recommendation X.680 - Corrigendum 3 (02/2001)
801 [17] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
802 Information Technology - ASN.1 encoding rules: Specification of
803 Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
804 Distinguished Encoding Rules (DER)
809 Copyright (C) The Internet Society (2002). All Rights Reserved.
811 This document and translations of it may be copied and furnished to
812 others, and derivative works that comment on or otherwise explain it
813 or assist in its implementation may be prepared, copied, published
814 and distributed, in whole or in part, without restriction of any
815 kind, provided that the above copyright notice and this paragraph are
816 included on all such copies and derivative works. However, this
817 document itself may not be modified in any way, such as by removing
818 the copyright notice or references to the Internet Society or other
819 Internet organizations, except as needed for the purpose of
820 developing Internet standards in which case the procedures for
821 copyrights defined in the Internet Standards process must be
822 followed, or as required to translate it into languages other than
825 The limited permissions granted above are perpetual and will not be
826 revoked by the Internet Society or its successors or assigns.
828 This document and the information contained herein is provided on an
829 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
830 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
831 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
832 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
833 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
842 Legg Expires 19 February 2002 [Page 15]
844 INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
847 Adacel Technologies Ltd.
848 405-409 Ferntree Gully Road
849 Mount Waverley, Victoria 3149
852 Phone: +61 3 9451 2107
854 EMail: steven.legg@adacel.com.au
898 Legg Expires 19 February 2002 [Page 16]