You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by ak...@apache.org on 2005/05/21 04:53:55 UTC
svn commit: r171188 [3/3] - in /directory/apacheds/trunk/xdocs: drafts/
drafts/draft-ietf-ldapext-acl-model-08.txt rfcs/ rfcs/rfc3642.html
rfcs/rfc3642_files/ rfcs/rfc3642_files/library.jpg rfcs/rfc3698.html
rfcs/rfc3698_files/ rfcs/rfc3698_files/library.jpg
Added: directory/apacheds/trunk/xdocs/rfcs/rfc3642.html
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/rfcs/rfc3642.html?rev=171188&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/rfcs/rfc3642.html (added)
+++ directory/apacheds/trunk/xdocs/rfcs/rfc3642.html Fri May 20 19:53:55 2005
@@ -0,0 +1,621 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html><head><title>RFC 3642 (rfc3642) - Common Elements of Generic String Encoding Rules (GSE</title>
+
+<meta name="description" content="RFC 3642 - Common Elements of Generic String Encoding Rules (GSER) Encodings">
+<script language="JavaScript1.2">
+function erfc(s)
+{document.write("<A href=\"/rfccomment.php?rfcnum="+s+"\" target=\"_blank\" onclick=\"window.open('/rfccomment.php?rfcnum="+s+"','Popup','toolbar=no,location=no,status=no,menubar=no,scrollbars=yes,resizable=yes,width=680,height=530,left=30,top=43'); return false;\")>Comment on RFC "+s+"</A>\n");}
+//-->
+</script></head>
+
+<body bgcolor="#ffffff" text="#000000">
+<p align="center"><img src="rfc3642_files/library.jpg" alt="" align="middle" border="0" height="62" width="150"></p>
+<h1 align="center">RFC 3642 (RFC3642)</h1>
+<p align="center">Internet RFC/STD/FYI/BCP Archives</p>
+
+<div align="center">[ <a href="http://www.faqs.org/rfcs/">RFC Index</a> | <a href="http://www.faqs.org/rfcs/rfcsearch.html">RFC Search</a> | <a href="http://www.faqs.org/faqs/">Usenet FAQs</a> | <a href="http://www.faqs.org/contrib/">Web FAQs</a> | <a href="http://www.faqs.org/docs/">Documents</a> | <a href="http://www.city-data.com/">Cities</a> ]
+<p>
+<strong>Alternate Formats:</strong>
+ <a href="http://www.faqs.org/ftp/rfc/rfc3642.txt">rfc3642.txt</a> |
+ <a href="http://www.faqs.org/ftp/rfc/pdf/rfc3642.txt.pdf">rfc3642.txt.pdf</a></p></div>
+<p align="center"><script language="JavaScript"><!--
+erfc("3642");
+// --></script><a href="http://www.faqs.org/rfccomment.php?rfcnum=3642" target="_blank" onclick="window.open('/rfccomment.php?rfcnum=3642','Popup','toolbar=no,location=no,status=no,menubar=no,scrollbars=yes,resizable=yes,width=680,height=530,left=30,top=43'); return false;" )="">Comment on RFC 3642</a>
+</p>
+<h3 align="center">RFC 3642 - Common Elements of Generic String Encoding Rules (GSER) Encodings</h3>
+<hr noshade="noshade" size="2">
+<pre>
+Network Working Group S. Legg
+Request for Comments: 3642 Adacel Technologies
+Category: Informational October 2003
+
+ Common Elements of Generic String Encoding Rules (GSER) Encodings
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ The Generic String Encoding Rules (GSER) describe a human readable
+ text encoding for an Abstract Syntax Notation One (ASN.1) value of
+ any ASN.1 type. Specifications making use of GSER may wish to
+ provide an equivalent Augmented Backus-Naur Form (ABNF) description
+ of the GSER encoding for a particular ASN.1 type as a convenience for
+ implementors. This document supports such specifications by
+ providing equivalent ABNF for the GSER encodings for ASN.1 types that
+ commonly occur in Lightweight Directory Access Protocol (LDAP)
+ syntaxes.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Separators . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 4. ASN.1 Built-in Types . . . . . . . . . . . . . . . . . . . . . 2
+ 5. ASN.1 Restricted String Types. . . . . . . . . . . . . . . . . 7
+ 6. Directory ASN.1 Types. . . . . . . . . . . . . . . . . . . . . 9
+ 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 10
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 11
+ 9. Intellectual Property Notice . . . . . . . . . . . . . . . . . 12
+ 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
+ 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
+
+1. Introduction
+
+ The Generic String Encoding Rules (GSER) [7] define a human readable
+ text encoding, based on ASN.1 [8] value notation, for an ASN.1 value
+ of any ASN.1 type. Specifications making use of GSER may wish to
+ provide a non-normative equivalent ABNF [3] description of the GSER
+ encoding for a particular ASN.1 type as a convenience for
+ implementors unfamiliar with ASN.1. This document supports such
+ specifications by providing equivalent ABNF for the GSER encodings
+ for ASN.1 types that commonly occur in LDAP [10] or X.500 [11]
+ attribute and assertion syntaxes, as well as equivalent ABNF for the
+ GSER encodings for the ASN.1 built-in types.
+
+ The ABNF given in this document does not replace or alter GSER in any
+ way. If there is a discrepancy between the ABNF specified here and
+ the encoding defined by GSER [7], then GSER is to be taken as
+ definitive.
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+ to be interpreted as described in BCP 14, <a href="http://www.faqs.org/rfcs/rfc2119.html">RFC 2119</a> [1]. The key word
+ "OPTIONAL" is exclusively used with its ASN.1 meaning.
+
+3. Separators
+
+ Certain separators are commonly used in constructing equivalent ABNF
+ for SET and SEQUENCE types.
+
+ sp = *%x20 ; zero, one or more space characters
+ msp = 1*%x20 ; one or more space characters
+
+ sep = [ "," ]
+
+ The <sep> rule is used in the ABNF description of the encoding for
+ ASN.1 SET or SEQUENCE types where all the components are either
+ OPTIONAL or DEFAULT. It encodes to an empty string if and only if
+ the immediately preceding character in the encoding is "{", i.e., it
+ is only empty for the first optional component actually present in
+ the SET or SEQUENCE value being encoded.
+
+4. ASN.1 Built-in Types
+
+ This section describes the GSER encoding of values of the ASN.1
+ built-in types, except for the restricted character string types.
+
+ The <BIT-STRING> rule describes the GSER encoding of values of the
+ BIT STRING type without a named bit list.
+
+ BIT-STRING = bstring / hstring
+
+ If the number of bits in a BIT STRING value is a multiple of four the
+ <hstring> form of <BIT-STRING> MAY be used. Otherwise, the <bstring>
+ form of <BIT-STRING> is used. The <bstring> rule encodes each bit as
+ the character "0" or "1" in order from the first bit to the last bit.
+ The <hstring> rule encodes each group of four bits as a hexadecimal
+ number where the first bit is the most significant. An odd number of
+ hexadecimal digits is permitted.
+
+ hstring = squote *hexadecimal-digit squote %x48 ; '...'H
+ hexadecimal-digit = %x30-39 / ; "0" to "9"
+ %x41-46 ; "A" to "F"
+
+ bstring = squote *binary-digit squote %x42 ; '...'B
+ binary-digit = "0" / "1"
+
+ squote = %x27 ; ' (single quote)
+
+ The <BOOLEAN> rule describes the GSER encoding of values of the
+ BOOLEAN type.
+
+ BOOLEAN = %x54.52.55.45 / ; "TRUE"
+ %x46.41.4C.53.45 ; "FALSE"
+
+ The <CHARACTER-STRING> rule describes the GSER encoding of values of
+ the associated type for the unrestricted CHARACTER STRING type.
+
+ CHARACTER-STRING = "{" sp id-identification msp Identification ","
+ sp id-data-value msp OCTET-STRING
+ sp "}"
+
+ id-identification = %x69.64.65.6E.74.69.66.69.63.61.74.69.6F.6E
+ ; "identification"
+ id-data-value = %x64.61.74.61.2D.76.61.6C.75.65 ; "data-value"
+
+ Identification = ( id-syntaxes ":" Syntaxes ) /
+ ( id-syntax ":" OBJECT-IDENTIFIER ) /
+ ( id-presentation-context-id ":" INTEGER ) /
+ ( id-context-negotiation ":"
+ ContextNegotiation ) /
+ ( id-transfer-syntax ":" OBJECT-IDENTIFIER ) /
+ ( id-fixed ":" NULL )
+
+ id-syntaxes = %x73.79.6E.74.61.78.65.73
+ ; "syntaxes"
+ id-syntax = %x73.79.6E.74.61.78 ; "syntax"
+ id-presentation-context-id = %x70.72.65.73.65.6E.74.61.74.69.6F.6E
+ %x2D.63.6F.6E.74.65.78.74.2D.69.64
+ ; "presentation-context-id"
+ id-context-negotiation = %x63.6F.6E.74.65.78.74.2D.6E.65.67.6F
+ %x74.69.61.74.69.6F.6E
+ ; "context-negotiation"
+ id-transfer-syntax = %x74.72.61.6E.73.66.65.72.2D.73.79.6E
+ %x74.61.78 ; "transfer-syntax"
+ id-fixed = %x66.69.78.65.64 ; "fixed"
+
+ Syntaxes = "{" sp id-abstract msp OBJECT-IDENTIFIER ","
+ sp id-transfer msp OBJECT-IDENTIFIER
+ sp "}"
+ id-abstract = %x61.62.73.74.72.61.63.74 ; "abstract"
+ id-transfer = %x74.72.61.6E.73.66.65.72 ; "transfer"
+
+ ContextNegotiation = "{" sp id-presentation-context-id msp
+ INTEGER ","
+ sp id-transfer-syntax msp
+ OBJECT-IDENTIFIER
+ sp "}"
+
+ The <INTEGER> rule describes the GSER encoding of values of the
+ INTEGER type without a named number list. The <INTEGER-0-MAX> rule
+ describes the GSER encoding of values of the constrained type INTEGER
+ (0..MAX). The <INTEGER-1-MAX> rule describes the GSER encoding of
+ values of the constrained type INTEGER (1..MAX).
+
+ INTEGER = "0" / positive-number / ("-" positive-number)
+ INTEGER-0-MAX = "0" / positive-number
+ INTEGER-1-MAX = positive-number
+ positive-number = non-zero-digit *decimal-digit
+ decimal-digit = %x30-39 ; "0" to "9"
+ non-zero-digit = %x31-39 ; "1" to "9"
+
+ The <EMBEDDED-PDV> rule describes the GSER encoding of values of the
+ associated type for the EMBEDDED PDV type.
+
+ EMBEDDED-PDV = "{" sp id-identification msp Identification ","
+ sp id-data-value msp OCTET-STRING
+ sp "}"
+
+ The <EXTERNAL> rule describes the GSER encoding of values of the
+ associated type for the EXTERNAL type.
+
+ EXTERNAL = "{" [ sp id-direct-reference msp
+ OBJECT-IDENTIFIER "," ]
+ [ sp id-indirect-reference msp INTEGER "," ]
+ [ sp id-data-value-descriptor msp
+ ObjectDescriptor "," ]
+ sp id-encoding msp Encoding
+ sp "}"
+
+ id-direct-reference = %x64.69.72.65.63.74.2D.72.65.66.65.72
+ %x65.6E.63.65
+ ; "direct-reference"
+ id-indirect-reference = %x69.6E.64.69.72.65.63.74.2D.72.65.66
+ %x65.72.65.6E.63.65
+ ; "indirect-reference"
+ id-data-value-descriptor = %x64.61.74.61.2D.76.61.6C.75.65.2D.64
+ %x65.73.63.72.69.70.74.6F.72
+ ; "data-value-descriptor"
+ id-encoding = %x65.6E.63.6F.64.69.6E.67
+ ; "encoding"
+
+ Encoding = ( id-single-ASN1-type ":" Value ) /
+ ( id-octet-aligned ":" OCTET-STRING ) /
+ ( id-arbitrary ":" BIT-STRING )
+
+ id-single-ASN1-type = %x73.69.6E.67.6C.65.2D.41.53.4E.31.2D.74.79
+ %x70.65
+ ; "single-ASN1-type"
+ id-octet-aligned = %x6F.63.74.65.74.2D.61.6C.69.67.6E.65.64
+ ; "octet-aligned"
+
+ id-arbitrary = %x61.72.62.69.74.72.61.72.79
+ ; "arbitrary"
+
+ The <Value> rule is defined by GSER [7]. It represents the GSER
+ encoding of a single value of the ASN.1 type identified by the
+ direct-reference and/or indirect-reference components.
+
+ The <NULL> rule describes the GSER encoding of values of the NULL
+ type.
+
+ NULL = %x4E.55.4C.4C ; "NULL"
+
+ The <OBJECT-IDENTIFIER> rule describes the GSER encoding of values of
+ the OBJECT IDENTIFIER type.
+
+ OBJECT-IDENTIFIER = numeric-oid / descr
+ numeric-oid = oid-component 1*( "." oid-component )
+ oid-component = "0" / positive-number
+
+ An OBJECT IDENTIFIER value is encoded using either the dotted decimal
+ representation or an object descriptor name, i.e., <descr>. The
+ <descr> rule is described in <a href="http://www.faqs.org/rfcs/rfc2252.html">RFC 2252</a> [4]. An object descriptor name
+ is potentially ambiguous and should be used with care.
+
+ The <OCTET-STRING> rule describes the GSER encoding of values of the
+ OCTET STRING type.
+
+ OCTET-STRING = hstring
+
+ The octets are encoded in order from the first octet to the last
+ octet. Each octet is encoded as a pair of hexadecimal digits where
+ the first digit corresponds to the four most significant bits of the
+ octet. If the hexadecimal string does not have an even number of
+ digits, the four least significant bits in the last octet are assumed
+ to be zero.
+
+ The <REAL> rule describes the GSER encoding of values of the REAL
+ type.
+
+ REAL = "0" ; zero
+ / PLUS-INFINITY ; positive infinity
+ / MINUS-INFINITY ; negative infinity
+ / realnumber ; positive base 10 REAL value
+ / ( "-" realnumber ) ; negative base 10 REAL value
+ / real-sequence-value ; non-zero base 2 or 10 REAL value
+
+ PLUS-INFINITY = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59
+ ; "PLUS-INFINITY"
+
+ MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59
+ ; "MINUS-INFINITY"
+
+ realnumber = mantissa exponent
+ mantissa = (positive-number [ "." *decimal-digit ])
+ / ( "0." *("0") positive-number )
+ exponent = "E" ( "0" / ([ "-" ] positive-number))
+
+ real-sequence-value = "{" sp id-mantissa msp INTEGER ","
+ sp id-base msp ( "2" / "10" ) ","
+ sp id-exponent msp INTEGER sp "}"
+ id-mantissa = %x6D.61.6E.74.69.73.73.61 ; "mantissa"
+ id-base = %x62.61.73.65 ; "base"
+ id-exponent = %x65.78.70.6F.6E.65.6E.74 ; "exponent"
+
+ A value of the REAL type MUST be encoded as "0" if it is zero.
+
+ The <RELATIVE-OID> rule describes the GSER encoding of values of the
+ RELATIVE-OID type.
+
+ RELATIVE-OID = oid-component *( "." oid-component )
+
+5. ASN.1 Restricted String Types
+
+ This section describes the GSER encoding of values of the ASN.1
+ restricted character string types. The characters of a value of a
+ restricted character string type are always encoded as a UTF-8
+ character string between double quotes. For some of the ASN.1 string
+ types, this requires a translation to or from the UTF-8 encoding.
+ Some of the ASN.1 string types permit only a subset of the characters
+ representable in UTF-8. Any double quote characters in the character
+ string, where allowed by the character set, are escaped by being
+ repeated.
+
+ The <UTF8String> rule describes the GSER encoding of values of the
+ UTF8String type. The characters of this string type do not require
+ any translation before being encoded.
+
+ UTF8String = StringValue
+ StringValue = dquote *SafeUTF8Character dquote
+
+ dquote = %x22 ; " (double quote)
+
+ SafeUTF8Character = %x00-21 / %x23-7F / ; ASCII minus dquote
+ dquote dquote / ; escaped double quote
+ %xC0-DF %x80-BF / ; 2 byte UTF-8 character
+ %xE0-EF 2(%x80-BF) / ; 3 byte UTF-8 character
+ %xF0-F7 3(%x80-BF) ; 4 byte UTF-8 character
+
+ The <NumericString>, <PrintableString>, <VisibleString>,
+ <ISO646String>, <IA5String>, <GeneralizedTime> and <UTCTime> rules
+ describe the GSER encoding of values of the correspondingly named
+ ASN.1 types. The characters of these string types are compatible
+ with UTF-8 and do not require any translation before being encoded.
+ The GeneralizedTime and UTCTime types use the VisibleString character
+ set, but have a strictly defined format.
+
+ NumericString = dquote *(decimal-digit / space) dquote
+ space = %x20
+
+ PrintableString = dquote *PrintableCharacter dquote
+ PrintableCharacter = decimal-digit / space
+ / %x41-5A ; A to Z
+ / %x61-7A ; a to z
+ / %x27-29 ; ' ( )
+ / %x2B-2F ; + , - . /
+ / %x3A ; :
+ / %x3D ; =
+ / %x3F ; ?
+
+ ISO646String = VisibleString
+ VisibleString = dquote *SafeVisibleCharacter dquote
+ SafeVisibleCharacter = %x20-21
+ / %x23-7E ; printable ASCII minus dquote
+ / dquote dquote ; escaped double quote
+
+ IA5String = dquote *SafeIA5Character dquote
+ SafeIA5Character = %x00-21 / %x23-7F ; ASCII minus dquote
+ / dquote dquote ; escaped double quote
+
+ century = 2(%x30-39) ; "00" to "99"
+ year = 2(%x30-39) ; "00" to "99"
+ month = ( %x30 %x31-39 ) ; "01" (January) to "09"
+ / ( %x31 %x30-32 ) ; "10" to "12"
+ day = ( %x30 %x31-39 ) ; "01" to "09"
+ / ( %x31-32 %x30-39 ) ; "10" to "29"
+ / ( %x32 %x30-31 ) ; "30" to "31"
+ hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
+ minute = %x30-35 %x30-39 ; "00" to "59"
+ second = ( %x30-35 %x30-39 ) ; "00" to "59"
+ / ( %x36 %x30 ) ; "60" (a leap second)
+
+ UTCTime = dquote year month day hour minute [ second ]
+ [ %x5A / u-differential ] dquote
+ u-differential = ( "-" / "+" ) hour minute
+
+ GeneralizedTime = dquote century year month day hour
+ [ minute [ second ] ] [ fraction ]
+ [ %x5A / g-differential ] dquote
+ fraction = ( "." / "," ) 1*(%x30-39)
+ g-differential = ( "-" / "+" ) hour [ minute ]
+
+ The <BMPString> and <UniversalString> rules describe the GSER
+ encoding of values of the BMPString and UniversalString types
+ respectively. BMPString (UCS-2) and UniversalString (UCS-4) values
+ are translated into UTF-8 [6] character strings before being encoded
+ according to <StringValue>.
+
+ BMPString = StringValue
+ UniversalString = StringValue
+
+ The <TeletexString>, <T61String>, <VideotexString>, <GraphicString>,
+ <GeneralString> and <ObjectDescriptor> rules describe the GSER
+ encoding of values of the correspondingly named ASN.1 types. Values
+ of these string types are translated into UTF-8 character strings
+ before being encoded according to <StringValue>. The
+ ObjectDescriptor type uses the GraphicString character set.
+
+ TeletexString = StringValue
+ T61String = StringValue
+ VideotexString = StringValue
+ GraphicString = StringValue
+ GeneralString = StringValue
+ ObjectDescriptor = GraphicString
+
+6. Directory ASN.1 Types
+
+ This section describes the GSER encoding of values of selected ASN.1
+ types defined for LDAP and X.500. The ABNF rule names beginning with
+ uppercase letters describe the GSER encoding of values of the ASN.1
+ type with the same name.
+
+ AttributeType = OBJECT-IDENTIFIER
+
+ The characters of a DirectoryString are translated into UTF-8
+ characters as required before being encoded between double quotes
+ with any embedded double quotes escaped by being repeated.
+
+ DirectoryString = StringValue /
+ ( id-teletexString ":" TeletexString ) /
+ ( id-printableString ":" PrintableString ) /
+ ( id-bmpString ":" BMPString ) /
+ ( id-universalString ":" UniversalString ) /
+ ( id-uTF8String ":" UTF8String )
+
+ id-teletexString = %x74.65.6C.65.74.65.78.53.74.72.69.6E.67
+ ; "teletexString"
+ id-printableString = %x70.72.69.6E.74.61.62.6C.65
+ %x53.74.72.69.6E.67 ; "printableString"
+ id-bmpString = %x62.6D.70.53.74.72.69.6E.67 ; "bmpString"
+ id-universalString = %x75.6E.69.76.65.72.73.61.6C
+ %x53.74.72.69.6E.67 ; "universalString"
+ id-uTF8String = %x75.54.46.38.53.74.72.69.6E.67
+ ; "uTF8String"
+
+ The <RDNSequence> rule describes the GSER encoding of values of the
+ RDNSequence type, which is syntactically equivalent to the
+ DistinguishedName and LocalName types. The <RDNSequence> rule
+ encodes a name as an LDAPDN character string between double quotes.
+ The character string is first derived according to the
+ <distinguishedName> rule in Section 3 of <a href="http://www.faqs.org/rfcs/rfc2253.html">RFC 2253</a> [5], and then it is
+ encoded between double quotes with any embedded double quotes escaped
+ by being repeated.
+
+ DistinguishedName = RDNSequence
+ LocalName = RDNSequence
+ RDNSequence = dquote *SafeUTF8Character dquote
+
+ The <RelativeDistinguishedName> rule describes the GSER encoding of
+ values of the RelativeDistinguishedName type that are not part of an
+ RDNSequence value. The <RelativeDistinguishedName> rule encodes an
+ RDN as a double quoted string containing the RDN as it would appear
+ in an LDAPDN character string. The character string is first derived
+ according to the <name-component> rule in Section 3 of <a href="http://www.faqs.org/rfcs/rfc2253.html">RFC 2253</a> [5],
+ and then any embedded double quote characters are escaped by being
+ repeated. This resulting string is output between double quotes.
+
+ RelativeDistinguishedName = dquote *SafeUTF8Character dquote
+
+ The <ORAddress> rule encodes an X.400 address as an IA5 character
+ string between double quotes. The character string is first derived
+ according to Section 4.1 of <a href="http://www.faqs.org/rfcs/rfc2156.html">RFC 2156</a> [2], and then any embedded
+ double quotes are escaped by being repeated. This resulting string
+ is output between double quotes.
+
+ ORAddress = dquote *SafeIA5Character dquote
+
+7. Security Considerations
+
+ This document contains an alternative description of parts of the
+ Generic String Encoding Rules, but does not replace or alter GSER in
+ any way. For the full security implications of using GSER, see the
+ Security Considerations section for GSER [7].
+
+8. References
+
+8.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, <a href="http://www.faqs.org/rfcs/rfc2119.html">RFC 2119</a>, March 1997.
+
+ [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
+ between X.400 and <a href="http://www.faqs.org/rfcs/rfc822.html">RFC 822</a>/MIME", <a href="http://www.faqs.org/rfcs/rfc2156.html">RFC 2156</a>, January 1998.
+
+ [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", <a href="http://www.faqs.org/rfcs/rfc2234.html">RFC 2234</a>, November 1997.
+
+ [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ <a href="http://www.faqs.org/rfcs/rfc2252.html">RFC 2252</a>, December 1997.
+
+ [5] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished
+ Names", <a href="http://www.faqs.org/rfcs/rfc2253.html">RFC 2253</a>, December 1997.
+
+ [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+ 2279, January 1998.
+
+ [7] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+ Types", <a href="http://www.faqs.org/rfcs/rfc3641.html">RFC 3641</a>, October 2003.
+
+ [8] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002
+ Information technology - Abstract Syntax Notation One (ASN.1):
+ Specification of basic notation
+
+8.2. Informative References
+
+ [9] Hovey, R. and S. Bradner, "The Organizations Involved in the
+ IETF Standards Process", BCP 11, <a href="http://www.faqs.org/rfcs/rfc2028.html">RFC 2028</a>, October 1996.
+
+ [10] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol
+ (v3): Technical Specification", <a href="http://www.faqs.org/rfcs/rfc3377.html">RFC 3377</a>, September 2002.
+
+ [11] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Overview of concepts, models and services
+
+9. Intellectual Property Notice
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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 implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+10. Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
+
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ EMail: <a href="mailto:steven.legg@adacel.com.au">steven.legg@adacel.com.au</a>
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+</pre>
+<p align="center"><script language="JavaScript"><!--
+erfc("3642");
+// --></script><a href="http://www.faqs.org/rfccomment.php?rfcnum=3642" target="_blank" onclick="window.open('/rfccomment.php?rfcnum=3642','Popup','toolbar=no,location=no,status=no,menubar=no,scrollbars=yes,resizable=yes,width=680,height=530,left=30,top=43'); return false;" )="">Comment on RFC 3642</a>
+</p>
+ <br>
+<div align="center">
+<table border="0" cellpadding="3" cellspacing="3" width="100%">
+<tbody><tr><td width="45%">
+<p align="left">Previous: <a href="http://www.faqs.org/rfcs/rfc3641.html">RFC 3641 - Generic String Encoding Rules (GSER) for ASN.1 Types</a>
+</p></td><td width="10%"> </td><td width="45%">
+<p align="right">Next: <a href="http://www.faqs.org/rfcs/rfc3643.html">RFC 3643 - Fibre Channel (FC) Frame Encapsulation</a>
+</p></td></tr></tbody></table></div><p align="right"> </p>
+<hr noshade="noshade" size="2">
+<div align="center">[ <a href="http://www.faqs.org/rfcs/">RFC Index</a> | <a href="http://www.faqs.org/rfcs/rfcsearch.html">RFC Search</a> | <a href="http://www.faqs.org/faqs/">Usenet FAQs</a> | <a href="http://www.faqs.org/contrib/">Web FAQs</a> | <a href="http://www.faqs.org/docs/">Documents</a> | <a href="http://www.city-data.com/">Cities</a> ]
+<p>
+</p></div>
+<small>
+<address>
+<p align="center">
+
+</p>
+</address>
+</small>
+</body></html>
\ No newline at end of file
Added: directory/apacheds/trunk/xdocs/rfcs/rfc3642_files/library.jpg
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/rfcs/rfc3642_files/library.jpg?rev=171188&view=auto
==============================================================================
Binary file - no diff available.
Propchange: directory/apacheds/trunk/xdocs/rfcs/rfc3642_files/library.jpg
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: directory/apacheds/trunk/xdocs/rfcs/rfc3698.html
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/rfcs/rfc3698.html?rev=171188&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/rfcs/rfc3698.html (added)
+++ directory/apacheds/trunk/xdocs/rfcs/rfc3698.html Fri May 20 19:53:55 2005
@@ -0,0 +1,438 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html><head><title>RFC 3698 (rfc3698) - Lightweight Directory Access Protocol (LDAP): Additio</title>
+
+<meta name="description" content="RFC 3698 - Lightweight Directory Access Protocol (LDAP): Additional Matching Rules">
+<script language="JavaScript1.2">
+function erfc(s)
+{document.write("<A href=\"/rfccomment.php?rfcnum="+s+"\" target=\"_blank\" onclick=\"window.open('/rfccomment.php?rfcnum="+s+"','Popup','toolbar=no,location=no,status=no,menubar=no,scrollbars=yes,resizable=yes,width=680,height=530,left=30,top=43'); return false;\")>Comment on RFC "+s+"</A>\n");}
+//-->
+</script></head>
+
+<body bgcolor="#ffffff" text="#000000">
+<p align="center"><img src="rfc3698_files/library.jpg" alt="" align="middle" border="0" height="62" width="150"></p>
+<h1 align="center">RFC 3698 (RFC3698)</h1>
+<p align="center">Internet RFC/STD/FYI/BCP Archives</p>
+
+<div align="center">[ <a href="http://www.faqs.org/rfcs/">RFC Index</a> | <a href="http://www.faqs.org/rfcs/rfcsearch.html">RFC Search</a> | <a href="http://www.faqs.org/faqs/">Usenet FAQs</a> | <a href="http://www.faqs.org/contrib/">Web FAQs</a> | <a href="http://www.faqs.org/docs/">Documents</a> | <a href="http://www.city-data.com/">Cities</a> ]
+<p>
+<strong>Alternate Formats:</strong>
+ <a href="http://www.faqs.org/ftp/rfc/rfc3698.txt">rfc3698.txt</a> |
+ <a href="http://www.faqs.org/ftp/rfc/pdf/rfc3698.txt.pdf">rfc3698.txt.pdf</a></p></div>
+<p align="center"><script language="JavaScript"><!--
+erfc("3698");
+// --></script><a href="http://www.faqs.org/rfccomment.php?rfcnum=3698" target="_blank" onclick="window.open('/rfccomment.php?rfcnum=3698','Popup','toolbar=no,location=no,status=no,menubar=no,scrollbars=yes,resizable=yes,width=680,height=530,left=30,top=43'); return false;" )="">Comment on RFC 3698</a>
+</p>
+<h3 align="center">RFC 3698 - Lightweight Directory Access Protocol (LDAP): Additional Matching Rules</h3>
+<hr noshade="noshade" size="2">
+<pre>
+Network Working Group K. Zeilenga, Ed.
+Request for Comments: 3698 OpenLDAP Foundation
+Updates: 2798 February 2004
+Category: Standards Track
+
+ Lightweight Directory Access Protocol (LDAP):
+ Additional Matching Rules
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document provides a collection of matching rules for use with
+ the Lightweight Directory Access Protocol (LDAP). As these matching
+ rules are simple adaptations of matching rules specified for use with
+ the X.500 Directory, most are already in wide use.
+
+Table of Contents
+
+ 1. Background and Intended Use. . . . . . . . . . . . . . . . . . 2
+ 2. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2.1. booleanMatch . . . . . . . . . . . . . . . . . . . . . . 2
+ 2.2. caseExactMatch . . . . . . . . . . . . . . . . . . . . . 2
+ 2.3. caseExactOrderingMatch . . . . . . . . . . . . . . . . . 3
+ 2.4. caseExactSubstringsMatch . . . . . . . . . . . . . . . . 3
+ 2.5. caseIgnoreListSubstringsMatch. . . . . . . . . . . . . . 3
+ 2.6. directoryStringFirstComponentMatch . . . . . . . . . . . 4
+ 2.7. integerOrderingMatch . . . . . . . . . . . . . . . . . . 4
+ 2.8. keywordMatch . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.9. numericStringOrderingMatch . . . . . . . . . . . . . . . 5
+ 2.10. octetStringOrderingMatch . . . . . . . . . . . . . . . . 5
+ 2.11. storedPrefixMatch. . . . . . . . . . . . . . . . . . . . 5
+ 2.12. wordMatch. . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
+ 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
+ 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 7
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
+ 6.2. Informative References . . . . . . . . . . . . . . . . . 7
+ 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
+ 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9
+
+1. Background and Intended Use
+
+ This document adapts additional X.500 Directory [X.500] matching
+ rules [X.520] for use with the Lightweight Directory Access Protocol
+ (LDAP) [<a href="http://www.faqs.org/rfcs/rfc3377.html">RFC3377</a>]. Most of these rules are widely used today on the
+ Internet, such as in support of the inetOrgPerson [<a href="http://www.faqs.org/rfcs/rfc2798.html">RFC2798</a>] and
+ Policy Core Information Model [RFC3703] LDAP schemas. The rules are
+ applicable to many other applications.
+
+ This document supersedes the informational matching rules
+ descriptions provided in <a href="http://www.faqs.org/rfcs/rfc2798.html">RFC 2798</a> that are now provided in this
+ document. Specifically, section 2 of this document replaces section
+ 9.3.3 of <a href="http://www.faqs.org/rfcs/rfc2798.html">RFC 2798</a>.
+
+ Schema definitions are provided using LDAP description formats
+ [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>]. Definitions provided here are formatted (line wrapped)
+ for readability.
+
+2. Matching Rules
+
+2.1. booleanMatch
+
+ The booleanMatch rule compares for equality a asserted Boolean value
+ with an attribute value of BOOLEAN syntax. The rule returns TRUE if
+ and only if the values are the same, i.e., both are TRUE or both are
+ FALSE. (Source: X.520)
+
+ ( 2.5.13.13 NAME 'booleanMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
+
+ The BOOLEAN (1.3.6.1.4.1.1466.115.121.1.7) syntax is described in
+ [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>].
+
+2.2. caseExactMatch
+
+ The caseExactMatch rule compares for equality the asserted value with
+ an attribute value of DirectoryString syntax. The rule is identical
+ to the caseIgnoreMatch [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>] rule except that case is not
+ ignored. (Source: X.520)
+
+ ( 2.5.13.5 NAME 'caseExactMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>].
+
+2.3. caseExactOrderingMatch
+
+ The caseExactOrderingMatch rule compares the collation order of the
+ asserted string with an attribute value of DirectoryString syntax.
+ The rule is identical to the caseIgnoreOrderingMatch [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>] rule
+ except that letters are not folded. (Source: X.520)
+
+ ( 2.5.13.6 NAME 'caseExactOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>].
+
+2.4. caseExactSubstringsMatch
+
+ The caseExactSubstringsMatch rule determines whether the asserted
+ value(s) are substrings of an attribute value of DirectoryString
+ syntax. The rule is identical to the caseIgnoreSubstringsMatch
+ [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>] rule except that case is not ignored. (Source: X.520)
+
+ ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) syntax is
+ described in [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>].
+
+2.5. caseIgnoreListSubstringsMatch
+
+ The caseIgnoreListSubstringMatch rule compares the asserted substring
+ with an attribute value which is a sequence of DirectoryStrings, but
+ where the case (upper or lower) is not significant for comparison
+ purposes. The asserted value matches a stored value if and only if
+ the asserted value matches the string formed by concatenating the
+ strings of the stored value. This matching is done according to the
+ caseIgnoreSubstringsMatch [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>] rule; however, none of the
+ initial, any, or final values of the asserted value are considered to
+ match a substring of the concatenated string which spans more than
+ one of the strings of the stored value. (Source: X.520)
+
+ ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) syntax is
+ described in [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>].
+
+2.6. directoryStringFirstComponentMatch
+
+ The directoryStringFirstComponentMatch rule compares for equality the
+ asserted DirectoryString value with an attribute value of type
+ SEQUENCE whose first component is mandatory and of type
+ DirectoryString. The rule returns TRUE if and only if the attribute
+ value has a first component whose value matches the asserted
+ DirectoryString using the rules of caseIgnoreMatch [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>]. A
+ value of the assertion syntax is derived from a value of the
+ attribute syntax by using the value of the first component of the
+ SEQUENCE. (Source: X.520)
+
+ ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>].
+
+2.7. integerOrderingMatch
+
+ The integerOrderingMatch rule compares the ordering of the asserted
+ integer with an attribute value of INTEGER syntax. The rule returns
+ True if the attribute value is less than the asserted value. (Source:
+ X.520)
+
+ ( 2.5.13.15 NAME 'integerOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is described in
+ [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>].
+
+2.8. keywordMatch
+
+ The keywordMatch rule compares the asserted string with keywords in
+ an attribute value of DirectoryString syntax. The rule returns TRUE
+ if and only if the asserted value matches any keyword in the
+ attribute value. The identification of keywords in an attribute
+ value and of the exactness of match are both implementation specific.
+ (Source: X.520)
+
+ ( 2.5.13.33 NAME 'keywordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>].
+
+2.9. numericStringOrderingMatch
+
+ The numericStringOrderingMatch rule compares the collation order of
+ the asserted string with an attribute value of NumericString syntax.
+ The rule is identical to the caseIgnoreOrderingMatch [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>] rule
+ except that all space characters are skipped during comparison (case
+ is irrelevant as characters are numeric). (Source: X.520)
+
+ ( 2.5.13.9 NAME 'numericStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ The NumericString (1.3.6.1.4.1.1466.115.121.1.36) syntax is described
+ in [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>].
+
+2.10. octetStringOrderingMatch
+
+ The octetStringOrderingMatch rule compares the collation order of the
+ asserted octet string with an attribute value of OCTET STRING syntax.
+ The rule compares octet strings from first octet to last octet, and
+ from the most significant bit to the least significant bit within the
+ octet. The first occurrence of a different bit determines the
+ ordering of the strings. A zero bit precedes a one bit. If the
+ strings are identical but contain different numbers of octets, the
+ shorter string precedes the longer string. (Source: X.520)
+
+ ( 2.5.13.18 NAME 'octetStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ The OCTET STRING (1.3.6.1.4.1.1466.115.121.1.40) syntax is described
+ in [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>].
+
+2.11. storedPrefixMatch
+
+ The storedPrefixMatch rule determines whether an attribute value,
+ whose syntax is DirectoryString is a prefix (i.e., initial substring)
+ of the asserted value, without regard to the case (upper or lower) of
+ the strings. The rule returns TRUE if and only if the attribute
+ value is an initial substring of the asserted value with
+ corresponding characters identical except possibly with regard to
+ case. (Source: X.520)
+
+ ( 2.5.13.41 NAME 'storedPrefixMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ Note: This rule can be used, for example, to compare values in the
+ Directory which are telephone area codes with a purported value
+ which is a telephone number.
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>].
+
+2.12. wordMatch
+
+ The wordMatch rule compares the asserted string with words in an
+ attribute value of DirectoryString syntax. The rule returns TRUE if
+ and only if the asserted word matches any word in the attribute
+ value. Individual word matching is as for the caseIgnoreMatch
+ [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>] matching rule. The precise definition of a "word" is
+ implementation specific. (Source: X.520)
+
+ ( 2.5.13.32 NAME 'wordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>].
+
+3. Security Considerations
+
+ General LDAP security considerations [<a href="http://www.faqs.org/rfcs/rfc3377.html">RFC3377</a>] is applicable to the
+ use of this schema. Additional considerations are noted above where
+ appropriate.
+
+4. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ descriptors registry [<a href="http://www.faqs.org/rfcs/rfc3383.html">RFC3383</a>] as indicated in the following
+ template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comments
+ Person & email address to contact for further information:
+ Kurt Zeilenga <<a href="mailto:kurt@OpenLDAP.org">kurt@OpenLDAP.org</a>>
+ Usage: see comments
+ Specification: <a href="http://www.faqs.org/rfcs/rfc3698.html">RFC 3698</a>
+ Author/Change Controller: IESG
+ Comments:
+
+ The following descriptors have been added:
+
+ NAME Type OID
+ ------------------------ ---- ---------
+ booleanMatch M 2.5.13.13
+ caseExactMatch M 2.5.13.5
+ caseExactOrderingMatch M 2.5.13.6
+ caseExactSubstringsMatch M 2.5.13.7
+ caseIgnoreListSubstringsMatch M 2.5.13.12
+ directoryStringFirstComponentMatch M 2.5.13.31
+ integerOrderingMatch M 2.5.13.15
+ keywordMatch M 2.5.13.33
+ numericStringOrderingMatch M 2.5.13.9
+ octetStringOrderingMatch M 2.5.13.18
+ storedPrefixMatch M 2.5.13.41
+ wordMatch M 2.5.13.32
+
+ where Type M is Matching Rule.
+
+ This document makes no new OID assignments. It only associates LDAP
+ matching rule descriptions with existing X.500 matching rules.
+
+5. Acknowledgments
+
+ This document borrows from [X.520], an ITU-T Recommendation.
+
+6. References
+
+6.1. Normative References
+
+ [<a href="http://www.faqs.org/rfcs/rfc2252.html">RFC2252</a>] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", <a href="http://www.faqs.org/rfcs/rfc2252.html">RFC 2252</a>, December 1997.
+
+ [<a href="http://www.faqs.org/rfcs/rfc3377.html">RFC3377</a>] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", <a href="http://www.faqs.org/rfcs/rfc3377.html">RFC 3377</a>,
+ September 2002.
+
+6.2. Informative References
+
+ [<a href="http://www.faqs.org/rfcs/rfc2798.html">RFC2798</a>] Smith, M., "The LDAP inetOrgPerson Object Class", RFC
+ 2798, April 2000.
+
+ [<a href="http://www.faqs.org/rfcs/rfc3383.html">RFC3383</a>] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ <a href="http://www.faqs.org/rfcs/rfc3383.html">RFC 3383</a>, September 2002.
+
+ [RFC3703] Strassner, J., Moore, B., Moats, R. and E. Ellesson,
+ "Policy Core LDAP Schema", RFC 3703, February 2004.
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Overview of concepts, models and
+ services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.520] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Selected Attribute Types", X.520(1997).
+
+7. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: <a href="mailto:Kurt@OpenLDAP.org">Kurt@OpenLDAP.org</a>
+
+8. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). 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.
+
+ 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 <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
+
+ 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 <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+</pre>
+<p align="center"><script language="JavaScript"><!--
+erfc("3698");
+// --></script><a href="http://www.faqs.org/rfccomment.php?rfcnum=3698" target="_blank" onclick="window.open('/rfccomment.php?rfcnum=3698','Popup','toolbar=no,location=no,status=no,menubar=no,scrollbars=yes,resizable=yes,width=680,height=530,left=30,top=43'); return false;" )="">Comment on RFC 3698</a>
+</p>
+ <br>
+<div align="center">
+<table border="0" cellpadding="3" cellspacing="3" width="100%">
+<tbody><tr><td width="45%">
+<p align="left">Previous: <a href="http://www.faqs.org/rfcs/rfc3697.html">RFC 3697 - IPv6 Flow Label Specification</a>
+</p></td><td width="10%"> </td><td width="45%">
+<p align="right">Next: <a href="http://www.faqs.org/rfcs/rfc3700.html">RFC 3700 - Internet Official Protocol Standards</a>
+</p></td></tr></tbody></table></div><p align="right"> </p>
+<hr noshade="noshade" size="2">
+<div align="center">[ <a href="http://www.faqs.org/rfcs/">RFC Index</a> | <a href="http://www.faqs.org/rfcs/rfcsearch.html">RFC Search</a> | <a href="http://www.faqs.org/faqs/">Usenet FAQs</a> | <a href="http://www.faqs.org/contrib/">Web FAQs</a> | <a href="http://www.faqs.org/docs/">Documents</a> | <a href="http://www.city-data.com/">Cities</a> ]
+<p>
+</p></div>
+<small>
+<address>
+<p align="center">
+
+</p>
+</address>
+</small>
+</body></html>
\ No newline at end of file
Added: directory/apacheds/trunk/xdocs/rfcs/rfc3698_files/library.jpg
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/rfcs/rfc3698_files/library.jpg?rev=171188&view=auto
==============================================================================
Binary file - no diff available.
Propchange: directory/apacheds/trunk/xdocs/rfcs/rfc3698_files/library.jpg
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream