Re: Fwd: New Version Notification for draft-stroeder-mailboxrelatedobject-04.txt
Michael Ströder <[email protected]> Thu, 08 Aug 2013 20:39:05 +0200
| Newsgroups | gmane.ietf.ldapext |
|---|---|
| Message-ID | <[email protected]> |
Alexey, Alexey Melnikov wrote: > Some comments below: Thanks for your time. > 2. Attribute Type Definition > > The attribute type 'intlMailAdr' is defined for storing SMTPUTF8 > compliant addresses [RFC6530]. > > ( 1.3.6.1.4.1.5427.1.389.4.18 > NAME 'intlMailAdr' > DESC 'Internationalized Email Address' > EQUALITY caseIgnoreMatch > > You describe problems with case-insensitive matching later in this section. > Why not just use caseExactMatch? Strictly speaking left hand sides of email > addresses are not ASCII case-insensitive. 1. The definition of 'mail' in RFC 4524 also defines case-insensitive matching rules. Mainly the text pointing out the issue was taken from RFC 4524. 2. All applications are used to that. Note that the most important use-case is searching for / completing an e-mail address. Case-insensitive matching by default is more comfortable for that. 3. I'd rather expect only very few cases in which somebody want to add intlMailAdr: [email protected] intlMailAdr: [email protected] to a *single* entry meaning two *different* mailboxes. Do you know of any deployment like this? What would be the semantics for that? Note that 'intlMailAdr' is not meant as multi-valued attribute for mail group entries for which such a case would be slightly more likely. Also note that case-insensitive matching is a different thing to case-preserving storage. I will add a note about the latter. I'd appreciate if you propose text making this more clear if you feel it's needed. > RFC 2821 --> RFC 5321. Thanks. Updated all occurences in next version. Ciao, Michael. _______________________________________________ Ldapext mailing list [email protected] https://www.ietf.org/mailman/listinfo/ldapext
smime.p7s
(application/pkcs7-signature, 2.3 KB) - not displayed