Hi all,
Please find below some comments I didn't make at last meeting due to
time constraints.
1) Chapter "JSContact extra information"
Like vCard, JSContact is a generic representation for contacts. Hence,
it includes information that is likely inapplicable to the RDAP context.
The queston is: Can the existence of such extra information be a factor
to exclude the use of JSContact in RDAP ?
To support my answer I need to make a brief recall of the RFC 7483
history. The first two versions included a contact representation very
close to SimpleContact, maybe exactly the same as the one proposed by
Andy in the first post introducing SimpleContact as opposed to
JSContact. As far as I have deduced from the mails (please correct me if
I'm wrong), after a discussion, the WEIRD WG decided to opt for vCard
due to the following reasons:
a) vCard was an IETF spec
b) It defined a superset of the information needed by RDAP
c) Every registry would have fitted its own information into vCard
d) There was no need to reinvent the wheel
AFAIU, nobody complained about the vCard data inapplicable to the RDAP
context.
If I remember well the outcomes of the ICANN RDAP Pilot Project, the
main concern with jCard was about its format rather than its content.
Having to completely map the vCard information, the original JSContact
proposal already included those data but this was deemed irrelevant in
order to adopt rdap-jscontact.
That said, I'm very surprised to know now that the main reason
supporting the replacement of JSContact with SimpleContact is something
that has been considered negligible for a decade.
2) Chapter "Make it simpler"
Prefer "Make it better". I mean, simplicity cannot be the only parameter
used within IETF to evaluate a technical solution. IMO there are other
parameters that are more important: flexibility, estensibility, efficiency.
In addition, no one in their right mind deliberately makes a proposal
inherently complex. JSContact started as simple as possible and get more
complex to meet the requirements.
Indeed, the collections were first represented as arrays and the
language dependent variants were treated as instances of the
LocalizedString object (i.e. a <text, language> pair).
Later, we opted for PatchObject to model every localization regardless
of the type of the JSON value to localize and whether such value was
pre-defined or introduced by an extension.
Almost at the same time, we realized that maps were most suitable for
both getting the items and referring to items to be localized and, then,
we decided to use maps for all the unordered collections.
Arrays are used for the collections where the order matters (i.e. name
components and address components) and, to avoid the issue about
selecting an array item when localizing, the spec requires to localize
the entire array.
RDAP presents requirements close to those inspiring the implementation
choices in JSContact.
Maybe localizing cannot be so frequent but redacting is usual instead,
and redacting a map entry is less troublesome than redacting an array item.
The JSContact "localizations" property allows to separate the main
values related to the default language from their language dependent
variants (see recent Pawel's feedback about SimpleContact).
Every new extension doesn't require an additional effort to handle its
possible localizations because, once the PatchObject have been
implemented , you don't need to do anything else.
Please note as well that JSON patching is an IETF spec and has already
been used in other RFCs.
Finally, JSContact allows to define addresses and names in both
unstructured and structured fashion and let implementers to opt for the
desired level of accuracy through the use of components.
3) Chapter "JSContact implementation"
In addition to mine and Gavin's from RegExt (I guess Gavin limits his
implementation to handle the properties used in RDAP), there are other
full implementations from CalExt guys (see
https://github.com/cyrusimap/cyrus-imapd and
https://www.audriga.com/en/Index)
We have also collected feedback and expressions of interest in other
forums. Therefore, to help implementers, I and Robert Stepanek have
published the interoperation tests at
https://github.com/jmapio/jscontact-tests.
4) Chaper "About the future of JSContact in RDAP"
I strongly disagree about having two specs with the same puropose and I
do believe that the WG should take the responsibility to decide what is
mostly suitable for RDAP now and for the future.
It makes no sense to me to let the market decide especially because, in
doing it, RDAP clients and servers wouldn't be absolutely free as they
would have to follow the RDAP profiles.
After all, this WG was chartered in order to "coordinate and
standardize extensions and profiles to be used by registries" so we
shouldn't delegate such a task to someone else.
My apologies for the long post.
Best,
Mario
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
