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:
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
