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