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: mario.loffr...@iit.cnr.it
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
