Re: [regext] jCard fix/replacement discussion

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.loffredo@iit.cnr.it
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo