Subject: [regext] on jcard and jscontact migration

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 25 Jul 2019 16:20:58 -0400

There has been discussion on replacement of jcard. One of the 
considerations in the equation is how to handle the migration. Some 
people have (appropriatly) expressed concerns about this issue of 
migration. While I’m not yet sure if we need to deprecate jcard, I 
would like to suggest a way to manage the migration if we ever consider 
the new format:
- define in RDAP RESPONSE another property additional to vcardarray, at 
the same place as vcardarray appears. Say « jscontact »
- have servers to send both (for quite a long time). This is more work 
from the server side, but I think it is not that bad.
- clients not able to read the new format will just ignore it and will 
continue to parse the jcard.
- clients that are updated and prefer the new format just parse the new 
format and ignore the jcard.
- wait a while. at some point in time, deprecate jcard.

My point here is that there is a smooth path to the new format, which 
has some costs, but it is doable and not that complicated.

Regards, Marc.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 25 Jul 2019 17:43:10 -0400

Thanks for describing that. I think that makes sense, and if we have
to transition this plan seems like the way to go.

Given that there are many registries and clients whom have already
implemented jCard, does moving to JSContact mean hold-outs will
implement RDAP?
In other words, who is NOT doing RDAP because of jCard? Are there any
registries willing to step up and say they'll deploy RDAP if we move
to JSContact?

-andy

On Thu, Jul 25, 2019 at 4:21 PM Marc Blanchet <[email-masked]> wrote:
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 25 Jul 2019 18:30:01 -0400

Hi Marc and Andy,

I would like to propose another possible transition model. 
The model is based on the use of the rdapConformance array values and ad-hoc parameters in the query string.

Each RDAP server can work at ant time according to only one of the following two configurations:

1) This configuration is identified by the tag “rdap_level_0” value in the rdapConformance array. The server returns the vcardArray element by default or the jscard element (jscard is the name defined in the jscontact draft to identify the new contact card) when the query string contains the parameter jscard=1

When the jscard element is returned the server must insert the value “jscard_level_0” in the rdapConformance array.

2) This configuration is identified by the tag “rdap_level_1” value in the rdapConformance array. The server returns the jscard element by default or the vcardArray element when the query string contains the parameter jcard=1.

When the vcardArray element is returned the server must insert the value “vcardArray_level_0” in the rdapConformance array.

The configuration 1) is the current one, the configuration 2) is the one working after the transition. 

In my opinion, this transition model should have the following benefits:

1) At ant time and for any request, only one contact representation is provided by the server in the response.

2) The clients transitions from jcard to jscard don’t depend on server transition. 

3) At any moment, the response would be compliant with RFC7483

Best,
mario

Inviato da iPhone

> Il giorno 25 lug 2019, alle ore 16:20, Marc Blanchet <[email-masked]> ha scritto:
> 
> There has been discussion on replacement of jcard. One of the considerations in the equation is how to handle the migration. Some people have (appropriatly) expressed concerns about this issue of migration. While I’m not yet sure if we need to deprecate jcard, I would like to suggest a way to manage the migration if we ever consider the new format:
> - define in RDAP RESPONSE another property additional to vcardarray, at the same place as vcardarray appears. Say « jscontact »
> - have servers to send both (for quite a long time). This is more work from the server side, but I think it is not that bad.
> - clients not able to read the new format will just ignore it and will continue to parse the jcard.
> - clients that are updated and prefer the new format just parse the new format and ignore the jcard.
> My point here is that there is a smooth path to the new format, which has some costs, but it is doable and not that complicated.
> 
> Regards, Marc.
>

---

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 25 Jul 2019 18:35:25 -0400

Mario,
  your proposals are another interesting alternatives. thanks!

My conclusion is then that there are multiple ways to handle a smooth 
transition to a new card format. Therefore, I think we should put 
migration aside as an issue causing to not work on a new card format.

If we find a new card format and there is a wg concensus on using it, 
then one of those transition mechanism can then be discussed and agreed.

Marc.

On 25 Jul 2019, at 18:30, Mario Loffredo wrote:

> 1) This configuration is identified by the tag “rdap_level_0” 
> value in the rdapConformance array. The server returns the vcardArray 
> element by default or the jscard element (jscard is the name defined 
> in the jscontact draft to identify the new contact card) when the 
> query string contains the parameter jscard=1
>
> When the jscard element is returned the server must insert the value 
> “jscard_level_0” in the rdapConformance array.
>
> 2) This configuration is identified by the tag “rdap_level_1” 
> value in the rdapConformance array. The server returns the jscard 
> element by default or the vcardArray element when the query string 
> contains the parameter jcard=1.
>
> When the vcardArray element is returned the server must insert the 
> value “vcardArray_level_0” in the rdapConformance array.
>
>> would like to suggest a way to manage the migration if we ever 
>> consider the new format:
>> - define in RDAP RESPONSE another property additional to vcardarray, 
>> at the same place as vcardarray appears. Say « jscontact »
>> - have servers to send both (for quite a long time). This is more 
>> work from the server side, but I think it is not that bad.

---

From: Roger D Carney <[email-masked]>
Date: Thu, 25 Jul 2019 22:57:10 +0000

Good Evening,

+1 on the transition thoughts, thanks Marc for delving a bit deeper on this topic.

Just wanted to make one comment/clarification on one of Andy's questions: "Are there any registries willing to step up and say they'll deploy RDAP if we move to JSContact? Just wanted to add clarity to “registries” and suggest supplementing “RDAP servers “ as there will also be thousands of Registrar RDAP servers instances as well. As for GoDaddy, we look forward to migrating our server and clients to a more appropriate contact structure.

I can’t speak to Andy’s “holdout question” but I would like to also say I believe migrating will lessen the long term maintenance (e.g. new clients writing/debugging to your server, handling of unique data scenarios into these arrays of arrays) by going with a more simplified/precise structure.

Just some additional food for thought.

Thanks

Roger

-----Original Message-----
From: regext <[email-masked]> On Behalf Of Andrew Newton
Sent: Thursday, July 25, 2019 4:43 PM
To: Marc Blanchet <[email-masked]>
Cc: regext <[email-masked]>
Subject: Re: [regext] on jcard and jscontact migration

Notice: This email is from an external sender.

Thanks for describing that. I think that makes sense, and if we have to transition this plan seems like the way to go.

Given that there are many registries and clients whom have already implemented jCard, does moving to JSContact mean hold-outs will implement RDAP?

In other words, who is NOT doing RDAP because of jCard? Are there any registries willing to step up and say they'll deploy RDAP if we move to JSContact?

-andy

On Thu, Jul 25, 2019 at 4:21 PM Marc Blanchet <[email-masked]<mailto:[email-masked]>> wrote:

> - clients that are updated and prefer the new format just parse the

> new format and ignore the jcard.

> [email-masked]<mailto:[email-masked]>

regext mailing list

[email-masked]<mailto:[email-masked]>

---

From: Gavin Brown <[email-masked]>
Date: Fri, 26 Jul 2019 09:06:39 +0100

> registries willing to step up and say they'll deploy RDAP if we move

I'm not too concerned about jCard as a barrier to server deployment. I'm more concerned about how it impedes *client* deployment (and consequently, migration of legacy whois clients to RDAP).

If there were multiple, lossless jCard <=> vCard converters, implemented in different (popular) programming languages, then I would be less concerned. But there aren't (and I doubt there ever will be).

G.

--
Gavin Brown
Chief Innovation Officer
CentralNic Group plc (LSE:CNIC)
https://www.centralnicgroup.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 6AE.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 26 Jul 2019 05:36:20 -0400

Roger,

Yes, registrars will be running RDAP servers and I did not intend to
minimize your efforts. But it is my understanding that registrars are
being compelled to do RDAP and therefore will be implementing jCard as
getting a jCard replacement will take some time.

I was really thinking of the ccTLDs. Will this switch give sway to any
new entrants into the space? To me, that is unclear.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 26 Jul 2019 05:44:55 -0400

> I'm not too concerned about jCard as a barrier to server deployment. I'm more concerned about how it impedes *client* deployment (and consequently, migration of legacy whois clients to RDAP).

I agree, clients have the most pain wrt jCard. That said, having
implemented two clients I found it annoying but not super painful.
However, you are a client implementer as well, so maybe your
experience was different. I do think that clients will have the
biggest burden during a transition as they will need to support a new
representation in addition to the jCard wackiness. I'd be happier if
we had commitment from server operators to move to the new format as
soon as possible to avoid the need for multiple code paths in the
clients. Do we have that commitment?

> If there were multiple, lossless jCard <=> vCard converters, implemented in different (popular) programming languages, then I would be less concerned. But there aren't (and I doubt there ever will…

Yes, I doubt there will ever be libraries to help out here.

-andy