Lightweight Directory Access Protocol (LDAP): Auxiliary Object Class 'mailboxRelatedObject'
draft-stroeder-mailboxrelatedobject-07

Abstract

This document defines the auxiliary object class 'mailboxRelatedObject' that can be used to associate an arbitrary object with an Internet mail address. Furthermore an attribute 'intlMailAddr' is defined for storing fully internationalized Internet mail addresses.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 30, 2015.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Attribute Type Definition
• 3. Object Class Definition
• 4. IANA Considerations
• 5. Security Considerations
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Author's Address

1. Introduction

The attribute 'mail' [RFC4524] can be used to store Internet mail addresses with internationalized <domain> by using the the A-label form [RFC5890] to produce <sub-domain> components of the <Mailbox> production. But it cannot be used to store addresses with <local-part> containing non-ASCII characters.

Therefore this document defines a new attribute type 'intlMailAddr' for fully internationalized Internet mail addresses as defined in [RFC6530].

Often the need arises to associate an Internet mail address (which most times is not personal) with an arbitrary object (a service or system user) so applications can look up where to send mail for this object. Many times the commonly available object class 'inetOrgPerson' [RFC2798] is wrongly used for storing such non-personal Internet mail addresses in attribute 'mail' [RFC4524].

Therefore this document defines the auxiliary object class 'mailboxRelatedObject' that can be used to associate an arbitrary object with an Internet mail address. It allows adding an Internet mail address attribute to any entry and allows to use either one or both of attributes 'mail' and 'intlMailAddr'.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

This document is being discussed on the ldapext@ietf.org mailing list.

2. Attribute Type Definition

The attribute type 'intlMailAddr' is defined for storing SMTPUTF8 compliant addresses [RFC6530].

    ( 1.3.6.1.4.1.5427.1.389.4.18
      NAME 'intlMailAddr'
      DESC 'Internationalized Email Address'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      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 and the 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described in [RFC4517].

Note that an application might have used the A-label form [RFC5890] to produce <sub-domain> components of the <Mailbox> production. This leads to different possible string representations of the same internationalized Internet mail address which could be listed as different values entry's 'intlMailAddr' attribute, operational issues may arise.

The following issues like described for attribute type 'mail' in [RFC4524] have to be considered also for 'intlMailAddr' defined above:

Note that the directory will not ensure that values of this attribute conform to the <Mailbox> production [RFC5321]. It is the application's responsibility to ensure that domains it stores in this attribute are appropriately represented.

Additionally, the directory will compare values per the matching rules named in the above attribute type description. As these rules differ from rules that normally apply to <Mailbox> comparisons, operational issues may arise. For example, the assertion (mail=joe@example.com) will match "JOE@example.com" even though the <local-parts> differ. Also, where a user has two <Mailbox>es whose addresses differ only by case of the <local-part>, both cannot be listed as values of the entry's 'intlMailAddr' attribute in the same entry (as they are considered equal by the 'caseIgnoreMatch' rule).

3. Object Class Definition

Entries of auxiliary object class 'mailboxRelatedObject' MAY contain the following optional attributes: 'mail' [RFC4524] 'displayName' [RFC2798] 'intlMailAddr'

    ( 1.3.6.1.4.1.5427.1.389.6.9
      NAME 'mailboxRelatedObject'
      DESC 'Associated RFC 5321 mailbox for any entry'
      AUXILIARY
      MAY ( displayName $ mail $ intlMailAddr ) )
      

'mail' and 'intlMailAddr' are listed as optional attributes to allow to use only one of both.

If 'mail' and 'intlMailAddr' are both set an application MAY choose one or the other to send mail to the entity represented by the directory entry. Therefore Internet mail addresses in attributes 'mail' and 'intlMailAddr' SHOULD represent the same mailbox if both are set or at least the entity MUST be able to retrieve the mail sent to either one of the addresses.

4. IANA Considerations

The OID arc used for the attribute type and object class definition is:
iso(1) org(3) dod(6) internet(1) private(4) enter-prise(1) stroeder.com(5427) public(1) ldap(389)

5. Security Considerations

The introduction of these object classes does not impact the security of the Internet or a particular LDAP directory service.

Security considerations for LDAP in general are discussed in documents comprising the technical specification [RFC4510].

6. References

6.1. Normative References

6.2. Informative References

Author's Address