At the ICANN RoW I said (and repeat here) the primary concern I have, is the maintenance of BOTH i8n, and multiple value responses.
This is because I am concerned we are heading back to an anglo-ASCII centric view, and I have to deal with significant numbers of non-western resource holders. I want multiple values (either as sets, or pairs within a single object, I don't care) because I want to be able to support the ASCII for westerners and non-locals, and the local language for local use. We have a HTTP signalling method to indicate language preference, which can guide how servers respond, and how clients interpret what they see. This feels like a useful, and significant improvement on WHOIS. I have no problem with jSContact in *hypothesis*, beyond having already made my (I am speaking in sweeping terms here: other people did the work) investment in the RIR RDAP, which as I have said is now complete and worldwide, and I find it strange that with a self-assessment of "not the smartest kid on the block" we were fine implementing JCard. Sure, it was a burden, but its a one-time burden. We've proposed a profile for JCard to try and set limits on the open-ended spec, and clarify what we need. I think a reasonable request in that context is for people looking at JSContact to look at our profile and help us understand what complexities remain if this is adopted. -George On Wed, Jul 10, 2019 at 6:38 PM Mario Loffredo <[email protected]> wrote: > > Hi George, > > Il 08/07/2019 08:11, George Michaelson ha scritto: > > I think we should have time at the Montreal meeting to discuss this > > f2f. You have a proposal for a simplified model requiring > > re-implementation, we have a proposal for a simplification of the > > existing implementation. Both are worth discussing. > > > > -George > > I agree. > > It is certain that jCard is considered inefficient in many contexts > because implementers need to define their own contact data model and > customize serialization/deserialization methods provided by JSON > libraries in order to convert jCard into/from their internal > representation. The idea of having a common JSON contact representation, > more efficient than jCard, inspired the JSContact proposal. > > It is also true that some RDAP implementers have raised objections to > the use of jCard, so much so that jCard fix/replacement has been debated > inside and outside this WG. > > As a JSContact co-author and RDAP implementer, I have developed a new > version of .it RDAP server providing the contact information according > to such a new format as an optional capability. I did it with the main > purpose of gathering feedbacks about JSContact "as is" and, secondly, > envisage its use in the RDAP context. > > Anyway, JSContact is indipendent of RDAP and the WG might decide that > there is no need to change the RDAP response or JSContact is not the > best solution for replacing jCard in RDAP. > > Best, > > mario > > > > On Mon, Jul 8, 2019 at 3:31 PM Cameron Hall > > <[email protected]> wrote: > >> Hi Tom, > >> > >> Having recently built our own RDAP server to meet the implementation > >> deadline, and experienced first hand the implementation of jCard; I don't > >> believe that simplifying the profile is sufficient enough. > >> > >> I'm under the assumption that jCard (vCard) was chosen due to its > >> flexibility and wide adoption in terms of email/calendar/contact clients. > >> While I can appreciate the flexibility, it was very tedious and complex to > >> implement given that it is not human readable and not "straight-forward" > >> so to speak. I do appreciate the specification of the fields required by > >> RDAP in your draft, but I still think that jCard is "over-engineered" for > >> the purpose of reporting contacts. The format for domain contact > >> objects/mappings haven't changed in nearly ten years and given the > >> direction the world is moving with privacy regulations I can't imagine us > >> taking full-advantage of what jCard has to offer. > >> > >> I believe that JSContact better fits the RDAP system due to its overall > >> simplicity. Being both human and machine readable is a huge advantage in > >> comparison, as it will lessen implementation time and be a not require one > >> to wrap their head around the complexities of the vCard/jCard formats. > >> > >> Not to mention, JSContact would complement the REST API quite nicely. > >> > >> - Cameron > >> > >> > >> On Mon, 8 Jul 2019 at 14:19, Tom Harrison<[email protected]> wrote: > >>> Hi all, > >>> > >>> This draft > >>> (https://tools.ietf.org/html/draft-harrison-regext-rdap-jcard-profile-00) > >>> is a profile of jCard for use in RDAP. It is based on the jCard > >>> properties/parameters etc. used by the current RDAP servers, plus some > >>> extras that will likely be in use soon (e.g. support for properties in > >>> multiple languages). Before moving forward with something like > >>> JSContact, we'd like to see whether profiling jCard will simplify it > >>> sufficiently for the group that it's no longer necessary to replace it > >>> with a new format (though obviously this can't fix problems that occur > >>> due to the format itself, such as difficulties with > >>> marshalling/unmarshalling jCard data). Feedback would be appreciated. > >>> > >>> -Tom > >>> > >>> _______________________________________________ > >>> regext mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/regext > >> _______________________________________________ > >> regext mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/regext > > _______________________________________________ > > regext mailing list > > [email protected] > > 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 protected] > Phone: +39.0503153497 > Web:http://www.iit.cnr.it/mario.loffredo > > _______________________________________________ > regext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
