Re: [regext] Proposal about jCard replacement

[Gavin Brown <[e-mail]>]

Hi Mario,

>> I would be happy to publish a new version of draft-brown-epp-contacts-in-rdap which uses JSContact rather than its own representation of contact data. That would glue JSContact and RDAP together.
> 
> IMHO it would be better to write a new document with the contribution of who is willing to implement JSCard in his own RDAP server (you, me, maybe Andy).

I'd be very happy to contribute.

> I think other stuff has still to be discussed. For example, what to do to make the transition from JCard to JSCard as smooth as possible. Should JSCard become the default and JCard an optional capability or viceversa?

Good question. That's a decision for this WG to make. Adding JSContact as an optional extension would be straightforward: making it the default would essentially create RDAP 1.1 which is a somewhat more complex proposition.

> How could an RDAP server inform a client that it is able to return contact information according to the JSCard format?

Unless we define a way to know an RDAP server's capabilities in advance, the client has no way to find out except to send a query and see what it gets back. As a client implementer I'm fine with this: some servers will support jCard forever so I need to continue to support them (even if only as legacy code). Some will immediately move to JSContact. Some may offer both in parallel, especially during an upgrade period, as we have seen during the migration of EPP from secDNS-1.0 to secDNS1.1.

If we need provide a way to know in advance (I'm not sure we do) then we could (a) alter the structure of the bootstrap file, (b) use server specification mechanism as you outlined at the ROW in Bangkok[1], or come up with some other mechanism (maybe by specify how the OPTIONS method can be used with RDAP?).

> We can have a short talk about it at the next meeting.

Alas I will not be present but will try to join remotely if possible.

G.

[1] http://regiops.net/wp-content/uploads/2019/05/ROW8-PPT-An-RDAP-capability-for-server-specification-provisioning-Mario-Loffredo-Maurizio-Martinelli.pdf