[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Erik Østlyngen <erik.ostlyngen@uninett.no>, <ietf-provreg@cafax.se>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Thu, 20 Dec 2007 07:04:35 -0500
Content-class: urn:content-classes:message
In-Reply-To: <476A4B84.6070009@uninett.no>
Sender: owner-ietf-provreg@cafax.se
Thread-Index: AchC+vkXGEmqUq7XQpu290CpIa7ztQABN0gQ
Thread-Topic: [ietf-provreg] Multiple email addresses for contacts
Subject: RE: [ietf-provreg] Multiple email addresses for contacts

> -----Original Message-----
> From: owner-ietf-provreg@cafax.se 
> [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Erik Østlyngen
> Sent: Thursday, December 20, 2007 6:01 AM
> To: ietf-provreg@cafax.se
> Subject: [ietf-provreg] Multiple email addresses for contacts
> 
> Hi.
> 
> At Norid, the Norwegian ccTLD, we are developing an EPP 
> interface to our registry. Our data model allows contacts to 
> have multiple email addresses. Our reason for supporting 
> multiple email addresses is that in some cases it is 
> important that we can reach our registrants.
> Multiple addresses may increase the likelyhood of them being 
> reached. We are wondering what would be the proper way to 
> implement this in EPP, since it conflicts with RFC4933. 
> Ideally, we want to register the multiple addresses with no order.
> 
> We have considered several different solutions:
> 
> 1. Allow several space or comma separated email addresses in the email
>     field (contact create, update and info commands). This might break
>     some client implementations if they are not prepared for it.
> 
> 2. Support the standard email field as a 'primary' email address, and
>     define multiple 'secondary' email addresses in an extension.
> 
> 3. Define our own contact mapping which is (accidentally) similar to
>     the RFC4933 mapping, but has multiple email fields.
> 
> It looks like the issue was discussed on this list in may 
> 2001. But with no conclusion. Does anyone know what would be 
> the right way to do this in the spirit of EPP?

Either 2 or 3 could work well.  If you only need multiple email addresses I'd suggest 2.  If you need "a lot" of other additional contact information, or decide not to use much of the info that's in the current contact mapping, I'd suggest 3.

Option 1 wouldn't conform to the schema, and (as you noted) introduces an interoperability risk.

-Scott-


Home | Date list | Subject list