Subject: [regext] EPP Contact Mapping for RDAP

From: Gavin Brown <[email-masked]>
Date: Mon, 18 Feb 2019 11:18:37 +0000

After some private discussions, I've come up with a rough draft of a
document specifying an alternative representation of contact data for
RDAP entities that does away with vCard, and uses the model from EPP
instead:

https://tools.ietf.org/html/draft-brown-epp-contacts-in-rdap-00

For your consideration.

G.

-- 
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.

---

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Mon, 18 Feb 2019 22:05:15 +0100

>https://tools.ietf.org/html/draft-brown-epp-contacts-in-rdap-00

Looks much more natural to me but I'm not a consumer, admittedly.

However, voice and fax are underspecified for they don't cover the respective extension properly. I don't like the intermittent "x" separator. Maybe have them as array or as 
fax:{num:"+43.12345", ext:0815}
hash ?
or s/num/number/ if folks prefer elaborate keys.

thanks,

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 19 Feb 2019 08:05:50 +0100

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 ?

Regards,

mario

Il 18/02/2019 12:18, Gavin Brown ha scritto:
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [email-masked]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

---

From: Andy Newton <[email-masked]>
Date: Tue, 19 Feb 2019 06:23:15 -0500

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?
> 

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

---

From: Gavin Brown <[email-masked]>
Date: Fri, 22 Feb 2019 13:41:34 +0000

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": [
      "[email-masked]",
      "[email-masked]"
    ],
    "phones": {
      "office": [
        "1-958-555-4321",
        "1-958-555-4322"
      ],
      "fax": [
        "1-958-555-4323"
      ],
      "mobile": [
        "1-958-555-4324"
      ]
    }
  },

  // rest of metadata
}

G.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 22 Feb 2019 13:56:12 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Gavin Brown
> Sent: Friday, February 22, 2019 8:42 AM
> To: Andy Newton <[email-masked]>; Mario Loffredo
> <[email-masked]>
> Cc: [email-masked]
> Subject: [EXTERNAL] Re: [regext] EPP Contact Mapping for RDAP
>
> 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"

Could we represent both an internationalized form of the postal address and an optional localized form, perhaps like this?

"postalAddressInt": [],
"postalAddressLoc": [],

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 22 Feb 2019 17:20:48 +0100

Hi all,

>    "objectClassName": "entity",

I would like to give my contribution to the discussion. In my opinion, 
the real mess of jCard is the massive use of jagged arrays which makes 
deserialization harder than having objects with fixed members.

On the other side, I think jCard provides a very flexible representation 
of entity information. Basically, it is a list of 4-tuples  where the 
fourth item is either simple or structured value and the addition of a 
new property results in defining a new value for the first item.

That being said, the possible representation for an RDAP entity coming 
in my mind are the following:

1) A structure including a set of fixed members each having a specific 
meaning (like the one proposed by Gavin).

*Pros*: Easy deserialization. Conceptually elegant. *Cons*: Not very 
flexible. Any additional information provided by a server will not be 
recognized in deserialization. If we consider the 80-20 ratio, 80% of 
most common information will be recognized, 20% of uncommon information 
will not.

2) A JSON transformation of vCard different than jCard. According to 
that, the contact information could be represented as an array of 
objects including a set of fixed members having a generic meaning like 
the following:

   { "key" : "string",

     "simple" : "string",

     "structured": [

                                {"key": "string",

                                 "simple": "string"}

                            ]

}

In brief, something more generic and, therefore, more flexible but, at 
the same time, simple to be deserialized. Obviously, "simple" and 
"structured" are alternatives.

*Pros*: Very flexible***Cons*: Not very conceptually elegant. The 
meaning of each contact property is specified by a string value (the 
same as it happens in jCard)

3) A hybrid solution. Most common properties are modelled by objects 
whose structure is fixed (e.g. "postalAddress" could be on object 
containing "street", "city", "cc" and so on)  like those proposed in the 
first solution, while the possible remaining properties could be 
represented as an array of the same item as described by the second 
solution. No information would be lost in deserialization.

Hope this could be useful.

Regards,

mario

---

From: Gavin Brown <[email-masked]>
Date: Thu, 28 Feb 2019 21:11:28 +0000

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.