Re: [regext] RDAP jCard profile

[Mario Loffredo <[e-mail]>]

Hi George,

Il 11/07/2019 05:38, George Michaelson ha scritto:
> 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 always believed like you that a JSON contact representation as an 
alternative to jCard should take into account non-ASCII full texts to 
describe some information.

This is why, the first JSContact proposal has been updated to represent 
unstructured data as well as the languages associated to full names.

Obviously, the current version is still not comprehensive but, at the 
same time, I think it isn't very distant from your perspective.

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

Yes, so did I. But there are other issues due to the jCard structure 
beyond the customization of serialization/deserialization methods.

I have implemented an RDAP validator and the JSON schema representation 
of jCard has been very hard.

I have used a JSON transformation library to provide different views of 
the RDAP response according to the user profile and I have found similar 
problems because the trasformer meta-language couldn't be easily applied 
to jCard jagged arrays.

Definitively, jCard doesn't make its processing easy.

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

If the WG will decide that JSContact shall be provided by RDAP providers 
only as an optional capability, both the documents will be useful.

IMHO, the RDAP jCard profile should contain also the "url" element to 
represent the link to a web page in general (e.g. a registrar web page). 
The "contact-uri" element has an ad-hoc meaning described by the ICANN 
RDAP profile.


Best,

mario


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