Subject: [Ietf-not43] #7 Email addresses in contacts

From: anewton at ecotroph.net (Andrew Newton)
Date: Mon Aug 18 16:53:36 2003

#7 Email addresses in contacts

FIRS seems to require a contact to have their email address in the DN.

 From draft-ietf-crips-firs-contact-02:

>      The inetContactSyntax is unstructured, in that it uses 
>      standardized procedures to produce heavily-normalized email 
>      addresses rather than using structured syntax rules. The principle 
>      reason for this is due to conflicting syntax rules in different 
>      canonical email addressing rules, with these rules preventing the 
>      use of a common syntax. 

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.

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

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.

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

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 18 18:09:11 2003

> 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

>  I think this has privacy implications all over it.

What privacy does [email-masked] 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
[email-masked] 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.
> 

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 

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/

---

From: shane at ripe.net (Shane Kerr)
Date: Tue Aug 19 03:51:16 2003

Andrew Newton wrote:
> reference to the contact must expose the email address of the contact. I 
> think this has privacy implications all over it.

Plus in our (RIPE NCC) schema, e-mail address is an optional attribute 
for contacts, and role contacts can have multiple e-mail addresses. 
We cannot elegantly use a system where e-mail is the lookup key.

-- 
Shane Kerr
RIPE NCC

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Aug 19 04:06:49 2003

> We cannot elegantly use a system where e-mail is the lookup key.

"Email addresses" are optional here too.

Take a deep breath.

Every entry of every type has a name which is qualified enough to allow a
client to build a fully-formed query, using just the name and type values.
In the case of domain resources, the entry key name is a fully-qualified
domain name. In the case of IP addresses, it's an address/prefix pair.
Okay, so we need a key name for contacts, and one that provides enough
qualifier data to be fully-resolvable by just the key name and type...

Golly, how about we use the identifiers that everybody uses for everything
on the Internet, that thing with localpart@domain syntax. Then we can find
the servers for the @domain, we can use identifiers that may have meaning
to people who want to use them, we can layer indirection into the service
so that providers can manage @their.own.freaking.domain entries, and so forth.

These are just identifiers for contact entries within distributed
partitions, nothing more. They use a friendly syntax for those places
where people want to reuse the identifier for other things, such as email,
or for publishing a public key associated with that identifer, or whatever.

If you look at the contents of the schema, you'll see that there's an
explicit attribute for email addresses.

The identifier is just an identifier which is globally resolvable.