Re: [regext] EPP Contact Mapping for RDAP

[Gavin Brown <[e-mail]>]

This was published earlier today:

https://tools.ietf.org/html/draft-stepanek-jscontact-00

Abstract

   This specification defines a data model and JSON representation of
   contact information that can be used for data storage and exchange in
   address book or directory applications.  It aims to be an alternative
   to the vCard data format and to be unambiguous, extendable and simple
   to process.  In contrast to the JSON-based jCard format, it is not a
   direct mapping from the vCard data model and expands semantics where
   appropriate.

On 22/02/2019 13:41, Gavin Brown wrote:
> Thanks Andy, Mario and Bernhard for the useful feedback.
> 
> It seems to me that there is a lot of appetite for a way to replace
> jCard: in addition to F2F conversations and discussions in the ICANN
> world, I've also had private feedback on this draft which indicates a
> lot of frustration with jCard from implementers.
> 
> If anyone implementing an RDAP client or server has some experiences
> with jCard that they can share that would be very helpful in
> understanding the demand for an alternative.
> 
> jCard was added in draft-ietf-weirds-json-response-03, so the last
> version to have "native" contacts was -02.
> 
> In it, entities in DNRs had a different syntax to entities in RIRs,
> however, there was a lot of similarity. Adding jCard helped in that the
> contact information got moved into a subordinate object property rather
> than being mixed in with the metadata (handle, roles, links, etc).
> 
> You can use the syntax for the contact info in the -02 draft and replace
> the "eppContactInfo" object in my draft with a generic "contactInfo"
> object such as the following:
> 
> {
>   "objectClassName": "entity",
>   "handle": "XXXX",
> 
>   "contactInfo": {
>     "entityNames": [
>       "Joe Bob, Inc.",
>       "Bobby Joe Shopping"
>     ],
>     "postalAddress": [
>       "123 Maple Ave",
>       "Suite 90001",
>       "Vancouver",
>       "BC",
>       "12393"
>     ],
>     "emails": [
>       "[e-mail]",
>       "[e-mail]"
>     ],
>     "phones": {
>       "office": [
>         "1-958-555-4321",
>         "1-958-555-4322"
>       ],
>       "fax": [
>         "1-958-555-4323"
>       ],
>       "mobile": [
>         "1-958-555-4324"
>       ]
>     }
>   },
> 
>   // rest of metadata
> }
> 
> G.
> 
> On 19/02/2019 11:23, Andy Newton wrote:
>> On Tue, Feb 19, 2019 at 08:05:50AM +0100, Mario Loffredo wrote:
>>> Hi Gavin,
>>>
>>> if I understand correctly, this extension involves only those RDAP entities
>>> in common with EPP (i.e registrant, admin, tech, billing), doesn't it?
>>>
>>> If so, what about the other entities (e.g. registrar, reseller) ? Should
>>> they be represented by jCard ?
>>
>> I have the same question and concern. While I support moving away
>> from jCard, we should not be focusing only on EPP especially since RDAP was
>> first widely adopted and is used today by non-EPP communities. RDAP itself is
>> not a product of the EPP community but was an outgrowth of experiments
>> conducted by the RIRs.
>>
>> That said, being compatible with EPP is certainly a requirement in my opinion.
>>
>> Given this is a rather substantial change, we should also be thorough in our
>> approach:
>>
>>   1. We should dig up the pre-jCard RDAP drafts and see if there is good stuff
>> there.
>>   2. We should either consult or repeat the work of CN-NIC during the WEIRDS
>> working group where they study the Whois output of all available registries and
>> found what was needed.
>>   3. We should also pay attention to the discussions around contacts in JMAP
>> now going on in the IETF.
>>
>> Overall, what is specified here looks good to me. Here are my comments for
>> improvements:
>>
>>   1. The country and region codes should be tied to ISO-3166 or a superset.
>>   2. There should be a place to spell out both region and country. Some
>> registries do not collect 3166 codes.
>>   3. Phone, fax, email should be arrays because some registries collect
>> multiples of these.
>>   4. There should be an indicator noting that the contact information is for an
>> individual.
>>
>> -andy
>>
> 

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.