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 > <marc.blanc...@viagenie.ca> 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. > - 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. > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
