directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From akaras...@apache.org
Subject 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
Date Sat, 21 May 2005 02:53:55 GMT
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 &lt;sep&gt; 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 &lt;BIT-STRING&gt; 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
+   &lt;hstring&gt; form of &lt;BIT-STRING&gt; MAY be used.  Otherwise, the &lt;bstring&gt;
+   form of &lt;BIT-STRING&gt; is used.  The &lt;bstring&gt; rule encodes each bit as
+   the character "0" or "1" in order from the first bit to the last bit.
+   The &lt;hstring&gt; 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 &lt;BOOLEAN&gt; rule describes the GSER encoding of values of the
+   BOOLEAN type.
+
+      BOOLEAN = %x54.52.55.45 /   ; "TRUE"
+                %x46.41.4C.53.45  ; "FALSE"
+
+   The &lt;CHARACTER-STRING&gt; 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 &lt;INTEGER&gt; rule describes the GSER encoding of values of the
+   INTEGER type without a named number list.  The &lt;INTEGER-0-MAX&gt; rule
+   describes the GSER encoding of values of the constrained type INTEGER
+   (0..MAX).  The &lt;INTEGER-1-MAX&gt; 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 &lt;EMBEDDED-PDV&gt; 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 &lt;EXTERNAL&gt; 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 &lt;Value&gt; 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 &lt;NULL&gt; rule describes the GSER encoding of values of the NULL
+   type.
+
+      NULL = %x4E.55.4C.4C  ; "NULL"
+
+   The &lt;OBJECT-IDENTIFIER&gt; 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., &lt;descr&gt;.  The
+   &lt;descr&gt; 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 &lt;OCTET-STRING&gt; 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 &lt;REAL&gt; 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 &lt;RELATIVE-OID&gt; 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 &lt;UTF8String&gt; 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 &lt;NumericString&gt;, &lt;PrintableString&gt;, &lt;VisibleString&gt;,
+   &lt;ISO646String&gt;, &lt;IA5String&gt;, &lt;GeneralizedTime&gt; and &lt;UTCTime&gt; 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 &lt;BMPString&gt; and &lt;UniversalString&gt; 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 &lt;StringValue&gt;.
+
+      BMPString       = StringValue
+      UniversalString = StringValue
+
+   The &lt;TeletexString&gt;, &lt;T61String&gt;, &lt;VideotexString&gt;, &lt;GraphicString&gt;,
+   &lt;GeneralString&gt; and &lt;ObjectDescriptor&gt; 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 &lt;StringValue&gt;.  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 &lt;RDNSequence&gt; rule describes the GSER encoding of values of the
+   RDNSequence type, which is syntactically equivalent to the
+   DistinguishedName and LocalName types.  The &lt;RDNSequence&gt; rule
+   encodes a name as an LDAPDN character string between double quotes.
+   The character string is first derived according to the
+   &lt;distinguishedName&gt; 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 &lt;RelativeDistinguishedName&gt; rule describes the GSER encoding of
+   values of the RelativeDistinguishedName type that are not part of an
+   RDNSequence value.  The &lt;RelativeDistinguishedName&gt; 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 &lt;name-component&gt; 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 &lt;ORAddress&gt; 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>
+&nbsp;<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%">&nbsp;</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">&nbsp;</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 &amp; email address to contact for further information:
+           Kurt Zeilenga &lt;<a href="mailto:kurt@OpenLDAP.org">kurt@OpenLDAP.org</a>&gt;
+       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>
+&nbsp;<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%">&nbsp;</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">&nbsp;</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



Mime
View raw message