Hi Gavin,
at first sight it could be a starting point even if, in my opinion, some
useful information is missing:
1) A "formattedName" property should be present in order to:
- represent an organization rather than an individual;
- match cases where the name is stored in a unique database field;
- be compliant with RFC7482 "entities?fn" search path.
2) A property about the kind of contact (see "kind" in jCard) seems
appropriate
3) Maybe an information to model data in multiple languages could be
also useful
4) The "Address" object doesn't include the country code information
5) As I wrote in my last mail, a JSON-based contact representation
should contain a property matching custom information. It might be
enough to add, for example, the following:
"otherDetails": "ContactInformation[]" (optional) where each item has
type="other"
6) Some information has the same meaning in jCard but different name
(e.g. company<->org, jobTitle<->role). It could worth keeping the
compliance with jCard as much as possible.
In addition, defining "uid" as mandatory as well as requiring it must be
unique across different applications are not practical within the RegExt
context. Maybe it makes sense for DISPATCH WG.
Finally, if I read it right, there is an error related to the "File"
object: it is defined but never used. Maybe "JSContact" should include
an optional "files" property as an array of "File" objects ?!
What about to collect all the feedbacks from RegExt WG and send them to
DISPATCH mailing list or plan a joint meeting with both the author and
DISPATCH members during open time at IETF4?
mario
Il 28/02/2019 22:11, Gavin Brown ha scritto:
This was published earlier today:
https://tools.ietf.org/html/draft-stepanek-jscontact-00
Abstract
This specification defines a data model and JSON representation of
contact 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.
On 22/02/2019 13:41, Gavin Brown wrote:
Thanks Andy, Mario and Bernhard for the useful feedback.
It seems to me that there is a lot of appetite for a way to replace
jCard: in addition to F2F conversations and discussions in the ICANN
world, I've also had private feedback on this draft which indicates a
lot of frustration with jCard from implementers.
If anyone implementing an RDAP client or server has some experiences
with jCard that they can share that would be very helpful in
understanding the demand for an alternative.
jCard was added in draft-ietf-weirds-json-response-03, so the last
version to have "native" contacts was -02.
In it, entities in DNRs had a different syntax to entities in RIRs,
however, there was a lot of similarity. Adding jCard helped in that the
contact information got moved into a subordinate object property rather
than being mixed in with the metadata (handle, roles, links, etc).
You can use the syntax for the contact info in the -02 draft and replace
the "eppContactInfo" object in my draft with a generic "contactInfo"
object such as the following:
{
"objectClassName": "entity",
"handle": "XXXX",
"contactInfo": {
"entityNames": [
"Joe Bob, Inc.",
"Bobby Joe Shopping"
],
"postalAddress": [
"123 Maple Ave",
"Suite 90001",
"Vancouver",
"BC",
"12393"
],
"emails": [
"[email protected]",
"[email protected]"
],
"phones": {
"office": [
"1-958-555-4321",
"1-958-555-4322"
],
"fax": [
"1-958-555-4323"
],
"mobile": [
"1-958-555-4324"
]
}
},
// rest of metadata
}
G.
On 19/02/2019 11:23, Andy Newton wrote:
On Tue, Feb 19, 2019 at 08:05:50AM +0100, Mario Loffredo wrote:
Hi Gavin,
if I understand correctly, this extension involves only those RDAP entities
in common with EPP (i.e registrant, admin, tech, billing), doesn't it?
If so, what about the other entities (e.g. registrar, reseller) ? Should
they be represented by jCard ?
I have the same question and concern. While I support moving away
from jCard, we should not be focusing only on EPP especially since RDAP was
first widely adopted and is used today by non-EPP communities. RDAP itself is
not a product of the EPP community but was an outgrowth of experiments
conducted by the RIRs.
That said, being compatible with EPP is certainly a requirement in my opinion.
Given this is a rather substantial change, we should also be thorough in our
approach:
1. We should dig up the pre-jCard RDAP drafts and see if there is good stuff
there.
2. We should either consult or repeat the work of CN-NIC during the WEIRDS
working group where they study the Whois output of all available registries and
found what was needed.
3. We should also pay attention to the discussions around contacts in JMAP
now going on in the IETF.
Overall, what is specified here looks good to me. Here are my comments for
improvements:
1. The country and region codes should be tied to ISO-3166 or a superset.
2. There should be a place to spell out both region and country. Some
registries do not collect 3166 codes.
3. Phone, fax, email should be arrays because some registries collect
multiples of these.
4. There should be an indicator noting that the contact information is for an
individual.
-andy
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
--
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [email protected]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
