Hi Andy,
I provide my comments below.
First of all, I would like to clarify that, as a Java developer, I found
jCard more difficult to serialize/deserialize rather than other plain
JSON objects but not impossible.
Anyway, I would be happy to contribute to the definition of a more
efficient representation of an RDAP contact.
Il 26/03/2019 10:22, Andrew Newton ha scritto:
All,
During the meeting yesterday I stated that I would send my notes on
jCard to this list to facilitate discussion. Your comments are
encouraged.
The following items are comments and observations I have heard from
various people, etc.
1. Requirements for contact information
a. There is a need to represent contact information in multiple
languages. This is a separate requirement from tagging the language of
the contact. In other words, it should be possible to have the contact
given in a local language and given in another language. It is my
understanding that jCard supports this.
I agree. This distinction may reflect, for example, that existing in EPP
between international and local postal info.
b. There should be a way to clearly specify the ISO-3166-1 country
code of a contact. It is my understanding that jCard does not support
this.
I agree. While a country name can be different according to the given
language, the country code remains the same and is universally known.
2. Issues with jCard
a. Is fn always required in jCard? There is confusion on this point.
In my opinion, YES. Otherwise, how would it be possible to represent
both non-individuals' names and unstructured names? How would it be
possible to keep consistency with "entityFn" query path?
b. jCard allows for both structured and unstructured addresses, and
this causes quite a lot of problems with clients and leads to many
variations by servers.
I don't think we can automatically exclude the presence of unstructured
addresses so how about representing them by a "formatted address"
property instead of using the "label"parameter?
c. If we moved away from jCard, how does that transition work?
Deprecation should provide backward compatibility for a period of time.
Therefore, I think the best way to address transition is to treat the
new contact representation as a response extension.
3. JSContact - based on the DISPATCH meeting on Monday, it is unclear
if JSContact will be moving forward in the IETF.
My humble opinion is that, if we agree on replacing jCard, we should do
that ourselves rather than look at the DISPATCH JSContact. I attended
the DISPATCH session and I had the same your impression. In addition, as
I pointed out in a previous mail, I see some drawbacks in that proposal.
For example, the requirement of uniquely identifying a JSContact across
all JSContact objects by a UUID seems to me impracticable in the context
of registration data.
And two more things:
1) we should keep the jCard capability of expressing a preferred item in
a collection of items modelling the same information (e.g. a list of
emails) unless we agree to identify the first item in the collection as
the favorite.
2) we should enable RDAP providers to represent their own custom
properties without furtherly extending the contact structure. Maybe, an
array of pairs <key,value> could be enough. The default object members
should cover 90% of use cases while the collection of <key,value> pairs
could cover the remaining 10%.
Hope it could be useful.
mario
-andy
_______________________________________________
regext mailing list
regext@ietf.org
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: mario.loffr...@iit.cnr.it
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
