Subject: Protocol Action: 'LDAP: Schema for User Applications' to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 31 Jan 2006 12:07:28 -0500

The IESG has approved the following document:

- 'LDAP: Schema for User Applications '
   <draft-ietf-ldapbis-user-schema-11.txt> as a Proposed Standard

This document is the product of the LDAP (v3) Revision Working Group. 

The IESG contact persons are Ted Hardie and Scott Hollenbeck.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-user-schema-11.txt

Technical Summary
 
   This document provides an overview of attribute types and object
   classes intended for use by Lightweight Directory Access Protocol
   (LDAP) directory clients for many directory services, such as, White
   Pages.  Originally specified in the X.500 [X.500] documents, these
   objects are widely used as a basis for the schema in many LDAP
   directories.  This document does not cover attributes used for the
   administration of directory servers, nor does it include directory
   objects defined for specific uses in other documents.
 
Working Group Summary
 
The LDAPBIS working group came to consensus on this document
 
Protocol Quality
 
This document was reviewed for the IESG by Ted Hardie.

RFC Editor Note

OLD:

  The 'dc' ('domainComponent' in RFC 2247) attribute type is a string
   holding one component, a label, of a DNS domain name [RFC1034].  The
   encoding of IA5String for use in LDAP is simply the characters of the
   ASCII label.  The equality matching rule is case insensitive, as is
   today's DNS.
   (Source: RFC 2247 [RFC2247])

      ( 0.9.2342.19200300.100.1.25 NAME 'dc'
         EQUALITY caseIgnoreIA5Match
         SUBSTR caseIgnoreIA5SubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
         SINGLE-VALUE )

   1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
   [Syntaxes].

   Examples: Valid values include "example" and "com".  The value
             "example.com" is invalid, because it contains two label
             components.

   Directory applications supporting International Domain Names SHALL
   use the ToASCII method [RFC3490] to produce the domain name component
   label.  The special considerations discussed in section 4 of RFC 3490
   [RFC3490] should be taken, depending on whether the domain component
   is used for "stored" or "query" purposes.

NEW:

   The 'dc' ('domainComponent' in RFC 1274) attribute type is a string
   holding one component, a label, of a DNS domain name [RFC1034][RFC2181]
   naming a host [RFC1123].  That is, a value of this attribute is
   a string of ASCII characters adhering to the following ABNF [RFC2234]:

        label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
        ALPHA   = %x41-5A / %x61-7A     ; "A"-"Z" / "a"-"z"
        DIGIT   = %x30-39               ; "0"-"9"
        HYPHEN  = %x2D                  ; hyphen ("-")

   The encoding of IA5String for use in LDAP is simply the characters
   of the ASCII label.  The equality matching rule is case insensitive,
   as is today's DNS.  (Source: RFC 2247 [RFC2247] and RFC 1274 [RFC 1274])
   
      ( 0.9.2342.19200300.100.1.25 NAME 'dc'
         EQUALITY caseIgnoreIA5Match
         SUBSTR caseIgnoreIA5SubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26  
         SINGLE-VALUE )
   
   1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
   [Syntaxes].
                
   Examples: Valid values include "example" and "com" but not "example.com".
   The latter is invalid as it contains multiple domain components.

   It is noted that the directory service will not ensure that values
   of this attribute conform to the host label restrictions
   [RFC1123] illustrated by the <label> production provided above.
   It is the directory client's responsibility to ensure labels it
   stores in this attribute are appropriately restricted. 
  
   Directory applications supporting International Domain Names SHALL
   use the ToASCII method [RFC3490] to produce the domain component
   label.  The special considerations discussed in section 4 of RFC 3490
   [RFC3490] should be taken, depending on whether the domain component
   is used for "stored" or "query" purposes. 

and add the following citations to the normative references section:

[RFC1123]       Braden, R., "Requirements for Internet Hosts -
                Application and Support", STD 3, RFC 1123,
                October 1989.

[RFC2181]       Elz, R. and R. Bush, "Clarifications to the DNS               
Specification", RFC 2181, July 1997.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce