Subject: [regext] Proposal about jCard replacement

From: Mario Loffredo <[email-masked]>
Date: Tue, 2 Jul 2019 08:58:45 +0200

Hi all,

I would like to invite you to take a look at this document: 
https://tools.ietf.org/html/draft-stepanek-jscontact-03

It aims to define a JSON representation of contact information that 
fixes the issues with jCard deserialization and, at the same time, 
expands vCard semantics.

Just to give an idea of the new contact representation in the RDAP 
context, I have implemented an ad-hoc optional capability in .it public 
test server (e.g. https://rdap.pubtest.nic.it/domain/nic.it?jscard=1).

The draft was presented for the first time at last dispatch session in 
Prague and, since then, some feedbacks have been posted on dispatch 
mailing list which have contributed to improve the initial proposal.

Anyway, since the jCard replacement has been debated within this WG, it 
seems to me quite obvious to bring it to your attention.

Any feedback will be very appreciated.

Thanks in advance,

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:[email-masked]
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

---

From: Gavin Brown <[email-masked]>
Date: Tue, 2 Jul 2019 13:05:36 +0100

Hi Mario,

I like JSContact and the current draft certainly looks good enough to be usable in RDAP. I imagine more work will be needed before JSContact will have feature parity with vCard/jCard.

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.

G.

> On 2 Jul 2019, at 07:58, Mario Loffredo <[email-masked]> wrote:
> 
> Hi all,
> 
> I would like to invite you to take a look at this document: https://tools.ietf.org/html/draft-stepanek-jscontact-03
> 
> It aims to define a JSON representation of contact information that fixes the issues with jCard deserialization and, at the same time, expands vCard semantics.
> 
> Just to give an idea of the new contact representation in the RDAP context, I have implemented an ad-hoc optional capability in .it public test server (e.g. https://rdap.pubtest.nic.it/domain/nic.it?jscard=1).
> 
> The draft was presented for the first time at last dispatch session in Prague and, since then, some feedbacks have been posted on dispatch mailing list which have contributed to improve the initial proposal.
> 
> Anyway, since the jCard replacement has been debated within this WG, it seems to me quite obvious to bring it to your attention.
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 3 Jul 2019 09:46:08 +0200

Hi Gavin,

> I like JSContact and the current draft certainly looks good enough to be usable in RDAP. I imagine more work will be needed before JSContact will have feature parity with vCard/jCard.

Yes, the JSCard structure is not completed. I have already defined, 
together with Robert Stepanek, a mapping between JSCard and JCard and it 
seems to us that almost all the information described by JCard can be 
represented by JSCard.  Some JCard elements have a 1-to-1 mapping to as 
many JSCard fields, while some others corresponds to the same field. For 
example, the JCard uri type elements can be represented as items of the 
"online" array, each with appropriate values for "type" and "label" 
properties.

We are also evaluating to add a generic field to represent all the 
information which is not considered at present but it could be in the 
future.

> 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 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? How could an RDAP server inform a client that 
it is able to return contact information according to the JSCard format?

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

Cheers,

mario

> G.
>
>> On 2 Jul 2019, at 07:58, Mario Loffredo<[email-masked]>  wrote:
>>
>> Hi all,
>>
>> I would like to invite you to take a look at this document:https://tools.ietf.org/html/draft-stepanek-jscontact-03
>>
>> Just to give an idea of the new contact representation in the RDAP context, I have implemented an ad-hoc optional capability in .it public test server (e.g.https://rdap.pubtest.nic.it/domain/nic.it?jscard=1).
>>

---

From: Gavin Brown <[email-masked]>
Date: Fri, 5 Jul 2019 15:57:09 +0100

Hi Mario,

> 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

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 5 Jul 2019 17:24:39 +0200

Hi Gavin,

> I'd be very happy to contribute.
Perfect.
> 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…
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?
> 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 th…
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 Ba…
I'm geared towards option (b)  :-))
> 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.

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: [email-masked]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo