Re: [ietf-provreg] Multiple email addresses for contacts

[James Gould <jgould@verisign.com>]

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@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.


> From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
> Date: Thu, 20 Dec 2007 07:04:35 -0500
> To: Erik Østlyngen <erik.ostlyngen@uninett.no>, <ietf-provreg@cafax.se>
> Conversation: [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-
>