Re: [regext] jCard fix/replacement discussion

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 <mario.loffredo@iit.cnr.it> ha scritto:
> 
> 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
> 
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext