Subject: [regext] jCard fix/replacement discussion

From: Andrew Newton <[email-masked]>
Date: Tue, 26 Mar 2019 05:22:52 -0400

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.

  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.

2. Issues with jCard

  a. Is fn always required in jCard? There is confusion on this point.

  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.

  c. If we moved away from jCard, how does that transition work?

3. JSContact - based on the DISPATCH meeting on Monday, it is unclear
if JSContact will be moving forward in the IETF.

-andy

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 26 Mar 2019 18:11:16 +0100

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.

> understanding that jCard supports this.

I agree. This distinction may reflect, for example, that existing in EPP 
between international and local postal info.

> code of a contact. It is my understanding that jCard does not support

I agree. While a country name can be different according to the given 
language, the country code remains the same and is universally known.

>    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?

> this causes quite a lot of problems with clients and leads to many

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.

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

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 26 Mar 2019 21:13:58 +0100

I wrote “entityFn” instead of “entities?fn”.
I apologize for the error.
Maybe I’m thinking too much to the reverse search draft :-))

mario

Inviato da iPhone

> Il giorno 26 mar 2019, alle ore 18:11, Mario Loffredo <[email-masked]> ha scritto:
> 
> Hi Andy,
> 
> 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.
> 
> 
> I agree. This distinction may reflect, for example, that existing in EPP between international and local postal info.
> 
> 
> 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
>> 
> 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?
> 
> 
>> 
> 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?
> 
> 
> 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.
> 
> 
>> 
> 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
>>

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 28 Mar 2019 09:59:53 -0400

Hi,

> > if JSContact will be moving forward in the IETF.

Speaking as an ART AD, I think I am happy to move quickly on this work if enough interest is expressed in something better than jCard.

> all JSContact objects by a UUID seems to me impracticable in the context 

I think it would be valuable if people can feed their comments on JSContact and express general interest in something that replaces jCard to the author of JSContact ([email-masked])

Thank you,
Alexey