This document defines the guideline for replacing jCard with JSContact Card in RDAP responses as described in draft-ietf-regext-rdap-jscontact.
The JSContact specification defines a data model and JSON representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate. JSContact is defined in RFC9553.
While the jCard element in the RDAP response is named "vcardArray", its JSContact Card counterpart is named "jscard". The guideline for converting JSContact Card from and to vCard are described in RFC9555.
Here in the following an example of mapping.
"vcardArray":[
"vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"],
["org", {}, "text", "Example"],
["adr",
{},
"text",
[
"",
"Suite 1234",
"4321 Rue Somewhere",
"Quebec",
"QC",
"G1V 2M2",
"Canada"
]
],
["tel",
{ "type":"voice"},
"uri",
"tel:+1-555-555-1234"
],
["tel",
{ "type":"fax"},
"uri",
"tel:+1-555-555-4321"
],
["email",
{ },
"text",
"joe.user@example.com"
]
]
]
"jscard":{
"@type" : "Card",
"@version": "1.0",
"uid": "YYYY",
"name": {
"full":"Joe User"
},
"organizations": {
"org" : {
"name": "Example"
}
},
"addresses": {
"addr" : {
"components": [
{ "kind": "extension", "value": "Suite 1234" },
{ "kind": "name", "value": "4321 Rue Somewhere" },
{ "kind": "locality", "value": "Quebec" },
{ "kind": "region", "value": "QC" },
{ "kind": "postcode", "value": "G1V 2M2" },
{ "kind": "country", "value": "Canada" }
]
}
},
"phones": {
"voice" :{
"features": {"voice": true},
"number": "tel:+1-555-555-1234"
},
"fax" :{
"features": {"fax": true},
"number": "tel:+1-555-555-4321"
}
},
"emails": {
"email": {
"address": "joe.user@example.com"
}
}
}
The migration from jCard to JSContact Card includes 3 stages each one corresponding to as many alternatives with regard to the provisioning of the contact card. During the migration, the presence "jscard" tag in the rdapConformance array means that JSContact Card is provided instead of jCard.
This stage corresponds to providing jCard as default contact card. The RDAP server is not able to provide an alternate contact card. The rdapConformance array doesn't contain the "jscard" tag.
During this stage, the server uses jCard by default, but the RDAP server will return JSCard if the client sets the query parameter jscard to 1/true/yes. The rdapConformance array MUST contain the jscard tag if JSCard is returned.
From this stage on, the RDAP server MUST include the jscard tag in the rdapConformance array of the help response to signal clients that JSCard can be returned instead of jCard
If JSContact Card is not requested, RDAP servers are RECOMMENDED to return a notice about the ongoing jCard deprecation process. Such a notice SHOULD include two links:
This stage corresponds to providing JSCard as default contact card. The rdapConformance array always contains jscard tag. The RDAP server doesn't include any notice about the jCard deprecation process. The jscard query parameter MUST be ignored
The migration dates will appear soon. Currently, the .it Registry RDAP server is at Stage 2.