Re: [regext] RDAP jCard profile

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

On Mon, Jul 8, 2019 at 3:31 PM Cameron Hall
<chall@staff.synergywholesale.com> 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 <tomh@apnic.net> 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
>> regext@ietf.org
>> https://www.ietf.org/mailman/listinfo/regext
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext