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 draft-ietf-calext-jscontact.
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 draft-ietf-calext-jscontact-vcard.
Here in the following an example of mapping.
"vcardArray":[
"vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"],
["org", {"type":"work"}, "text", "Example"],
["adr",
{ "type":"work" },
"text",
[
"",
"Suite 1234",
"4321 Rue Somewhere",
"Quebec",
"QC",
"G1V 2M2",
"Canada"
]
],
["tel",
{
"type":["work", "voice"],
"pref":"1"
},
"uri",
"tel:+1-555-555-1234;ext=102"
],
["email",
{ "type":"work" },
"text",
"joe.user@example.com"
]
]
]
"jscard":{
"@type" : "Card",
"@version": "1.0",
"uid": "YYYY",
"fullName": "Joe User",
"organizations": {
"org" : {
"@type" : "Organization",
"name": "Example"
}
},
"addresses": {
"addr" : {
"@type" : "Address",
"contexts": {"work": true},
"street": [
{"@type" : "StreetComponent", "type": "name", "value": "4321 Rue Somewhere"},
{"@type" : "StreetComponent", "type": "extension", "value":"Suite 1234"} ]
"locality": "Quebec",
"region": "QC",
"postcode": "G1V 2M2",
"country": "Canada"
}
},
"phones": {
"voice" :{
"@type" : "Phone",
"contexts": {"work": true},
"features": {"voice": true},
"pref": 1,
"number": "tel:+1-555-555-1234;ext=102"
}
},
"emails": {
"email": {
"@type" : "EmailAddress",
"contexts": {"work": true},
"address": "joe.user@example.com"
}
}
}
The migration from jCard to JSContact Card includes 4 stages each one corresponding to as many alternatives with regards 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.
This stage corresponds to providing jCard as default contact card but the RDAP server is also able to return JSContact Card if the client sets the query parameter "jscard" to 1/true. The rdapConformance array contains the "jscard" tag if JSCard is requested. 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 the provisioning of JSContact Card as default contact card but the RDAP server is also able to return jCard if the client sets the query parameter "jcard" to 1/true. The rdapConformance array contains the "jscard" tag unless jCard is requested. If jCard 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 JSContact Card as default contact card. The RDAP server is not able to provide an alternate contact card. The rdapConformance array always contains the "jscard" tag. The RDAP servers don't include any notice about the jCard replacement process. Both the query parameters "jscard" and "jcard" are ignored.
The migration dates will appear soon. Currently, the .it Registry RDAP server is at Stage 2.