Re: Fwd: New Version Notification for draft-stroeder-mailboxrelatedobject-04.txt

>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 protected]


On Thu, Aug 8, 2013 at 12:39 PM, Alexey Melnikov
<[email protected]> wrote:
> On 08/08/2013 08:24, Michael Ströder wrote:
>>
>> 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.
>
> 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
>
> _______________________________________________
> Ldapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ldapext