Subject: [Ietf-not43] IRIS contact lookups

From: ehall at ehsco.com (Eric A. Hall)
Date: Fri Aug 29 01:11:53 2003

It seems that contact lookups are embedded in the domain lookups, and thus
aren't independently searachable. I say this because there doesn't appear
to be any sort of indicator about the partition that is authoritative for
the contact identifier(s), meaning that the query data must contain the
identifier as well as the location information. Ergo, a contact identifier
must always be passed around as part of a URI, and has no meaning outside
of the URI context. If all of that is true, then do you consider the URI
to be part of the "contact reference" from the requirements?:

 | 3.2.1.1 Protocol Requirement

 |   1.  Contact lookup given a unique reference to a contact of a
 |       resource.

This is why I use fully self-descriptive identifiers for all the lookup
keys. For example, fqdn.domain.dom self-identifies as a domain name, and
provides embedded information about the governing partition hierarchy.
While that is also feasible with IRIS, you aren't doing the same with
contact identifiers, whereas FIRS uses [email-masked] to
self-identify as a contact key value, and to provide embedded hinting
information about the governing partition hierarchy.

Also, I notice that you aren't providing an i18n for the email address,
which is likely to be necessary when mail clients start transforming IDNA
addresses more frequently.

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

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Fri Aug 29 02:36:41 2003

> information about the governing partition hierarchy.

In the domain registry, they are directly searchable by the 
<findContacts> search.  In addition, contacts have their own entity 
class of 'contact-handle' for doing direct lookups.  The entity names in 
this entity class could be of the form [email-masked] if the 
registry wants to do that.  However, I think most will stick to the 
handles they have instead of creating new ones.

A contact reference is like any other entity reference.  It consists of 
all but one of the components in an IRIS URI (the scheme).  It is 
purposefully decomposed into XML attributes to allow servers doing 
hosting of multiple authorities to manipulate the authority component on 
the fly (useful for implementations using things like DOM trees).

> addresses more frequently.

Well, the schema does allow for 2 email addresses per contact.  Which 
part of the email address are you concerned with being 
internationalized, the display name or the smtp address?

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Fri Aug 29 03:38:44 2003

on 8/29/2003 1:36 AM Andrew Newton wrote:

> <findContacts> search.

You need the partition context though, and that's external, not part of
"the identifier" (the identifier "eh26" is meaningless by itself, and
doesn't tell you if this is for netsol or for arin). So this is basically
a search-by-value, constrained to a partition.

> In addition, contacts have their own entity 
> class of 'contact-handle' for doing direct lookups.

Again, you need fore knowledge or external hinting data for the auth
partition right? Unless you always have the URI, this is actually another
search-by-value constrained to a partition, rather than a global lookup.

> The entity names in

The @partition syntax doesn't affect the handle@ management, it just makes
the handle global, self-contained and self-identifying. Plus it's useful
for layered edge services like ~"give me the PGP key for [email-masked]"
or ~"dial the sip phone for [email-masked]", in that the most
commonly-used identifier for persons is reusable.

> internationalized, the display name or the smtp address?

I was referring to the transformed @domain.

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Fri Aug 29 07:04:15 2003

> search-by-value constrained to a partition, rather than a global lookup.

Like a URI, an entity reference contains the necessary data to make the 
lookup global.

> commonly-used identifier for persons is reusable.

The contact handle is not intended to be overloaded as a universal key 
for all applications as a uniform naming mechanism.  There are other 
standards for that, such as URN's.

> I was referring to the transformed @domain.

Email addresses are defined in RFC 2822.

-andy

---

From: sanz at denic.de (Marcos Sanz/Denic)
Date: Fri Aug 29 07:50:16 2003

Andy,

On 29.08.2003 08:36 Andrew Newton <[email-masked]> wrote:
> 
> Well, the schema does allow for 2 email addresses per contact. 

We currently support N email addresses per contact. The same goes for fax 
and phone. I suggest leaving maxOccurs for these three elements in the 
contact result unbounded.

Regards,
Marcos

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Fri Aug 29 08:28:36 2003

> contact result unbounded.

That sounds good.  Should we add fax and sip as separate elements, also 
unbounded?

-andy

---

From: sanz at denic.de (Marcos Sanz/Denic)
Date: Fri Aug 29 09:08:28 2003

> That sounds good.  Should we add fax and sip as separate elements, also

That can't be harmful.

Regards,
Marcos

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Fri Aug 29 10:42:34 2003

>> partition right? Unless you always have the URI, this is actually
>> another search-by-value constrained to a partition, rather than a
>> global lookup.
> 

Right, the identifiers are meaningless without the support attributes, so
all of the attributes have to be specifically enumerated and then bundled
with the identifier as support data.

> standards for that, such as URN's.

How is a URN to a contact handle not an overloaded universal key?

> Email addresses are defined in RFC 2822.

I take it that this means you don't plan on supporting IDNA transformed
mail domain syntaxes period.

Again, you need to specify the normalization routines if you expect the
client to always force a drop-down. Substring matching for contact email
addresses will break as well, again.

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Fri Aug 29 11:48:55 2003

> How is a URN to a contact handle not an overloaded universal key?

A URN is not overloaded for this purpose because that is the intent of a 
URN.  The contact handles in IRIS are not specified as URN's or any 
other type of universal key because that is also not their intent. 
However, if a registry wants to specify contact handles as URN's (or any 
other type of universal key), then so be it.  IRIS doesn't stop them.

> addresses will break as well, again.

If that is the consensus of the working group, but I personally question 
the utility of substring matches on email addresses.  IRIS DREG 
currently provides two types of email matching: 1) you know the exact 
email address, or 2) you know the domain name of the email address. 
Other than that, I do not see how it is practical.

Why would you want to search for domains or contacts by every person 
with an email address that starts with 'an' such as [email-masked]? 
Or anewton@*troph.net?  Or anewton@*.*?  This starts to become a 
data-miners dream.  Just my opinion.

-andy