[Ietf-not43] #7 Email addresses in contacts

[Eric A. Hall]

on 8/18/2003 4:20 PM Andrew Newton wrote:

> #7 Email addresses in contacts
> 
> FIRS seems to require a contact to have their email address in the DN.

That's incorrect.

The syntax mimics email so that it is POSSIBLE for a contact to accept
email, but this is not a requirement.

Maybe this is too abstract

> This means that in order to reference the contact, a referral or 
> reference to the contact must expose the email address of the contact.
>  I think this has privacy implications all over it.

What privacy does eh26 at registry.netsol.com expose that any other pointer
mechanism to that portion of the namespace wouldn't?

If I choose to publish my actual email address as part of a supplemental
layered service, that's my option. If I don't want to do so, I can use
admins at ehsco.com instead.

If anybody sends email to any of those addresses, it's a crapshoot as to
whether the mail actually goes anywhere.

>> The normalization procedure produces UTF-8 [RFC2279] email addresses
>> as output, with these domain names being suitable for direct
>> comparisons, substring searches, and other lightweight comparisons.
>> Servers tend to be more heavily-loaded than clients, and requiring
>> the data to be normalized before it is used for comparison operations
>> ensures that a broader range of comparison operations can be
>> performed with minimal impact on those servers.
> 
> I assume this is the same escaped Unicode as discussed earlier?
> Correct?

Yes

> Why do email addresses have to be handled differently?  I thought one
> of the points of IDN was that we wouldn't have to change things like
> email addresses?  Not being an IDN person, I could have this all
> screwed up.

What do you mean by differently? The domain elements are the same. The
localpart elements are undeclared since nothing has emerged from that work
as of yet.

> Is the point that the email addresses cannot be the xn-- versions and 
> must be Unicode?

The domain element can be rendered locally as IDNA if the client chooses.
The localpart element shouldn't exist as anything other than RFC 2822
syntax rules at the moment, since nothing else has been defined (note that
the liberal rules in the contact syntax are there for whenever the new
syntax shows up, but at the moment the only rules are RFC 2822).

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/