Re: [regext] Proposal about jCard replacement

[Mario Loffredo <[e-mail]>]

Hi Gavin,

Il 05/07/2019 16:57, Gavin Brown ha scritto:
> 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.
Perfect.
>
>> 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.
Yes, exactly. Provided that the WG considers JSCard as the best solution 
to replace JCard, the question is: should we migrate to a new RDAP 
version (rdap_level_1)  or should we define it as an optional capability 
of the current version?
>
>> 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.
I think that the solution should consider all the use cases.
>
> 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?).
I'm geared towards option (b)  :-))
>> 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.
OK, anyway we can keep in touch by email and go on with the discussion.
> G.
>
> [1] http://regiops.net/wp-content/uploads/2019/05/ROW8-PPT-An-RDAP-capability-for-server-specification-provisioning-Mario-Loffredo-Maurizio-Martinelli.pdf


Cheers,

mario

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