Re: [regext] RDAP jCard profile

[George Michaelson <[e-mail]>]

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
<[e-mail]> 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
> > <[e-mail]>  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<[e-mail]>  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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/regext
> >> _______________________________________________
> >> regext mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/regext
> > _______________________________________________
> > regext mailing list
> > [e-mail]
> > 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:[e-mail]
> Phone: [phone]
> Web:http://www.iit.cnr.it/mario.loffredo
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext