Subject: [ldapext] Fwd: New Version Notification for draft-stroeder-mailboxrelatedobject-04.txt

From: Michael Ströder <[email-masked]>
Date: Thu, 08 Aug 2013 09:24:30 +0200

HI!

Some modifications based on comments I received off-list.

Please review this draft intended to be published as informational RFC.
Thanks in advance.

Ouch! There's a typo in DESC of object class definition. Will change this to
RFC 2821 in next version.

Ciao, Michael.

-------- Original Message --------
Subject: New Version Notification for draft-stroeder-mailboxrelatedobject-04.txt
Date: Thu, 08 Aug 2013 00:20:29 -0700
From: [email-masked]
To: Michael Stroeder <[email-masked]>

A new version of I-D, draft-stroeder-mailboxrelatedobject-04.txt
has been successfully submitted by Michael Stroeder and posted to the
IETF repository.

Filename:	 draft-stroeder-mailboxrelatedobject
Revision:	 04
Title:		 Lightweight Directory Access Protocol (LDAP): Auxiliary Object Class
'mailboxRelatedObject'
Creation date:	 2013-08-08
Group:		 Individual Submission
Number of pages: 5
URL:
http://www.ietf.org/internet-drafts/draft-stroeder-mailboxrelatedobject-04.txt
Status:
http://datatracker.ietf.org/doc/draft-stroeder-mailboxrelatedobject
Htmlized:        http://tools.ietf.org/html/draft-stroeder-mailboxrelatedobject-04
Diff:
http://www.ietf.org/rfcdiff?url2=draft-stroeder-mailboxrelatedobject-04

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
   'intlMailAdr' is defined for storing fully internationalized Internet
   mail addresses.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Aug 2013 17:39:06 +0100

> RFC 2821 in next version.
Hi Michael,
I reviewed the document and it mostly looks quite sensible.

Some comments below:

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.

       SUBSTR caseIgnoreSubstringsMatch
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

    Note that the directory will not ensure that values of this attribute
    conform to the <Mailbox> production [RFC2821].

RFC 2821 --> RFC 5321.

3.  Object Class Definition

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

     ( 1.3.6.1.4.1.5427.1.389.6.9
       NAME 'mailboxRelatedObject'
       DESC 'Associated RFC 2822 mailbox for any entry'

Please use RFC 5322 here, which obsoleted RFC 2822. This also needs to 
be added to the Normative References. Unless you meant RFC 5321 here.

       AUXILIARY
       MAY ( displayName $ mail $ intlMailAdr ) )

Best Regards,
Alexey

---

From: Charlie <[email-masked]>
Date: Thu, 8 Aug 2013 14:10:53 -0400

>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.

Because we already have lots of email schemas that are empirically
useless in the real world.

If you need a case-sensitive match, you just pull the
case-insensitively matched data from the server, and quickly perform a
second comparison in the client.  This is trivial and imposes no great
load on the server or client.

The vast majority of email addresses in use today are
case-insensitive.  If your schema prevents case-insensitive matching
on the server, all email address objects have to be pulled every
single time an email is processed, so that the client code can do
appropriately case-insensitive matching locally.

--Charlie
[email-masked]

On Thu, Aug 8, 2013 at 12:39 PM, Alexey Melnikov
<[email-masked]> wrote:
> 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.
>
> Please use RFC 5322 here, which obsoleted RFC 2822. This also needs to be
> added to the Normative References. Unless you meant RFC 5321 here.
>
>       AUXILIARY
> _______________________________________________
> Ldapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldapext

---

From: Michael Ströder <[email-masked]>
Date: Thu, 08 Aug 2013 20:39:05 +0200

Alexey,

> Some comments below:

Thanks for your time.

>    compliant addresses [RFC6530].

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-masked]
intlMailAdr: [email-masked]

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.