headers
Erik Østlyngen | 20 Dec 2007 12:01
Picon
Picon

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?

Kind regards,
Erik Østlyngen
UNINETT Norid
(Continue reading)

Permalink | Reply | 9 comments |
headers
Hollenbeck, Scott | 20 Dec 2007 13:04
Picon
Favicon

RE: Multiple email addresses for contacts

> -----Original Message-----
> From: owner-ietf-provreg <at> cafax.se 
> [mailto:owner-ietf-provreg <at> cafax.se] On Behalf Of Erik Østlyngen
> Sent: Thursday, December 20, 2007 6:01 AM
> To: ietf-provreg <at> 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.
(Continue reading)

Permalink | Reply | 8 comments |
headers
James Gould | 20 Dec 2007 16:20
Picon
Favicon

Re: Multiple email addresses for contacts

Erik,

We've implemented both option 2 (Jobs Contact Extension) and option 3 (RCC
Contact Mapping) in our systems.  As Scott points out option 2 is best if
you only need to make a small number of changes and option 3 is best if the
mapping needs to be very different from the standard contact mapping.  In
the case of our "Jobs Contact Extension" we needed to add three optional
attributes (title, industryType, and isAssociationMember), so this could
easily be done with a simple extension that allows complete reuse of the
standard contact mapping specification and code (client-side and
server-side).  In the case of our "RCC Contact Mapping" we had a product
that functioned as a proxy to the ccTLD Registries, where the standard
contact mapping was not a good fit.  We later even had to create extensions
to our custom "RCC Contact" mapping to integrate with specific ccTLD
Registries but without impacting existing Registrars.

In your case I recommend option 2, since the change is small and it's easy
to create a new extension with maximum reuse of the standard contact
mapping.       

--

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould <at> verisign.com
Direct: 703.948.3271
(Continue reading)

Permalink | Reply | 7 comments |

Gmane