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.loffr...@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.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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
