idnits 2.17.1 draft-stroeder-mailboxrelatedobject-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 26, 2014) is 3499 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission M. Stroeder 3 Internet-Draft Independent consultant 4 Intended status: Informational September 26, 2014 5 Expires: March 30, 2015 7 Lightweight Directory Access Protocol (LDAP): 8 Auxiliary Object Class 'mailboxRelatedObject' 9 draft-stroeder-mailboxrelatedobject-06 11 Abstract 13 This document defines the auxiliary object class 14 'mailboxRelatedObject' that can be used to associate an arbitrary 15 object with an Internet mail address. Furthermore an attribute 16 'intlMailAdr' is defined for storing fully internationalized Internet 17 mail addresses. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 30, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Attribute Type Definition . . . . . . . . . . . . . . . . . . 3 55 3. Object Class Definition . . . . . . . . . . . . . . . . . . . 3 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 60 6.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 The attribute 'mail' [RFC4524] can be used to store Internet mail 66 addresses with internationalized by using the ToASCII method 67 [RFC3490]. But it cannot be used to store addresses with containing non-ASCII characters. 70 Therefore this documents defines a new attribute type 'intlMailAdr' 71 for fully internationalized Internet mail addresses as defined in 72 [RFC6530]. 74 Often there is a need to associate a, most times non-personal, 75 Internet mail address with an arbitrary object (a service or system 76 user) so applications can lookup where to send mail for this object. 77 Many times the commonly available object class 'inetOrgPerson' 78 [RFC2798] is wrongly used for storing such non-personal Internet mail 79 addresses in attribute 'mail' [RFC4524]. 81 Therefore this document defines the auxiliary object class 82 'mailboxRelatedObject' that can be used to associate an arbitrary 83 object with an Internet mail address. It allows to add an Internet 84 mail address attribute to any entry and allows to use either one or 85 both of attributes 'mail' and 'intlMailAdr'. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 This document is being discussed on the ldapext@ietf.org mailing 92 list. 94 2. Attribute Type Definition 96 The attribute type 'intlMailAdr' is defined for storing SMTPUTF8 97 compliant addresses [RFC6530]. 99 ( 1.3.6.1.4.1.5427.1.389.4.18 100 NAME 'intlMailAdr' 101 DESC 'Internationalized Email Address' 102 EQUALITY caseIgnoreMatch 103 SUBSTR caseIgnoreSubstringsMatch 104 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 106 The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the 107 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described 108 in [RFC4517]. 110 Note that an application might have used the ToASCII method [RFC3490] 111 to produce components of the production. This 112 leads to different possible string representations of the same 113 internationalized Internet mail address which could be listed as 114 different values entry's 'intlMailAdr' attribute, operational issues 115 may arise. 117 The following issues like described for attribute type 'mail' in 118 [RFC4524] have to be considered also for 'intlMailAdr' defined above: 120 Note that the directory will not ensure that values of this attribute 121 conform to the production [RFC5321]. It is the 122 application's responsibility to ensure that domains it stores in this 123 attribute are appropriately represented. 125 Additionally, the directory will compare values per the matching 126 rules named in the above attribute type description. As these rules 127 differ from rules that normally apply to comparisons, 128 operational issues may arise. For example, the assertion 129 (mail=joe@example.com) will match "JOE@example.com" even though the 130 differ. Also, where a user has two es whose 131 addresses differ only by case of the , both cannot be 132 listed as values of the entry's 'intlMailAdr' attribute in the same 133 entry (as they are considered equal by the 'caseIgnoreMatch' rule). 135 3. Object Class Definition 137 Entries of auxiliary object class 'mailboxRelatedObject' MAY contain 138 the following optional attributes: 'mail' [RFC4524] 'displayName' 139 [RFC2798] 'intlMailAdr' 140 ( 1.3.6.1.4.1.5427.1.389.6.9 141 NAME 'mailboxRelatedObject' 142 DESC 'Associated RFC 5321 mailbox for any entry' 143 AUXILIARY 144 MAY ( displayName $ mail $ intlMailAdr ) ) 146 'mail' and 'intlMailAdr' are listed as optional attributes to allow 147 to use only one of both. 149 If 'mail' and 'intlMailAdr' are both set an application MAY choose 150 one or the other to send mail to the entity represented by the 151 directory entry. Therefore Internet mail addresses in attributes 152 'mail' and 'intlMailAdr' SHOULD represent the same mailbox if both 153 are set or at least the entity MUST be able to retrieve the mail sent 154 to either one of the addresses. 156 4. IANA Considerations 158 The OID arc used for the attribute type and object class definition 159 is: 160 iso(1) org(3) dod(6) internet(1) private(4) enter-prise(1) 161 stroeder.com(5427) public(1) ldap(389) 163 5. Security Considerations 165 The introduction of these object classes does not impact the security 166 of the Internet or a particular LDAP directory service. 168 Security considerations for LDAP in general are discussed in 169 documents comprising the technical specification [RFC4510]. 171 6. References 173 6.1. Normative References 175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, March 1997. 178 [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object 179 Class", RFC 2798, April 2000. 181 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 182 (LDAP): Technical Specification Road Map", RFC 4510, June 183 2006. 185 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): 186 Syntaxes and Matching Rules", RFC 4517, June 2006. 188 [RFC4524] Zeilenga, K., "COSINE LDAP/X.500 Schema", RFC 4524, June 189 2006. 191 6.2. Informative References 193 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 194 "Internationalizing Domain Names in Applications (IDNA)", 195 RFC 3490, March 2003. 197 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 198 October 2008. 200 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 201 Internationalized Email", RFC 6530, February 2012. 203 Author's Address 205 Michael Stroeder 206 Independent consultant 207 Klauprechtstr. 11 208 Karlsruhe 76137 209 DE 211 Email: michael@stroeder.com 212 URI: http://www.stroeder.com