I agree. JCard is very flexible but the massive use of jagged arrays requires implementers to customize serialization and deserialization. It would be better to have a JSON representation which could be marshalled/unmarshalled by the usual toJson/fromJson methods.
mario Inviato da iPhone > Il giorno 14 feb 2019, alle ore 17:15, Andrew Newton <[email protected]> ha scritto: > > That makes sense to me. > > -andy > >> On Thu, Feb 14, 2019 at 11:11 AM Hollenbeck, Scott >> <[email protected]> wrote: >> Andy, should we get in on the DISPATCH discussion to note that we have >> similar concerns with jCard and RDAP? If there’s talk of a new WG it may >> make sense to add our requirements to the list. >> >> >> >> Scott >> >> >> >> From: regext <[email protected]> On Behalf Of Andrew Newton >> Sent: Thursday, February 14, 2019 11:09 AM >> To: Registration Protocols Extensions <[email protected]> >> Subject: [EXTERNAL] [regext] Fwd: [dispatch] Requesting DISPATCH of JSContact >> >> >> >> As an FYI, we're not the only ones less than in love with jCard. >> >> >> >> -andy >> >> >> >> ---------- Forwarded message --------- >> From: Bron Gondwana <[email protected]> >> Date: Tue, Feb 12, 2019 at 4:22 AM >> Subject: [dispatch] Requesting DISPATCH of JSContact >> To: <[email protected]> >> >> >> >> Hi All, >> >> >> >> As work concludes on >> https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11 there is >> interest in doing the same thing with a format for contacts.. >> >> >> >> The JSCalendar work grew out of the JMAP specification at >> https://jmap.io/spec-calendars.html - there was interest in producing a >> standalone format which was JSON-native rather the RFC7265's quite >> mechanical translation of iCalendar, which is confusing and unfamiliar to >> programmers used to working with JSON data. >> >> >> >> Likewise, JMAP Contacts contains an early attempt at translating VCARD into >> an easily understood JSON format. The shape of it is defined at >> https://jmap.io/spec-contacts.html - though I expect it would undergo >> significant revision before submission for publication. We are aware of >> both RFC6350 and RFC7095 and would both use them as a guideline and define >> mappings between them and a new JSON-first format. >> >> >> >> I have already spoken to the ART ADs about this, and they agree that >> dispatch is the correct venue to discuss this proposal. The JMAP working >> group could take it on, but has been mostly focused on the protocols around >> the formats rather than that formats itself (other than mail). The CALEXT >> working group has would be a potential place, if it was to recharter and >> increase scope to both contacts and calendars (since they seem to travel >> together in many places due to the use of DAV for both). Or maybe something >> else.. >> >> >> >> I'm also aware of work within ISO to define address formats and structured >> name formats which are less western-centric than the existing VCARD 'N' and >> 'ADR' structured fields. This format would try to remain backwards >> compatible with those fields while having a defined way to express the new >> formats.. >> >> >> >> I have asked that the existing JMAP work be put into an initial draft so we >> have a baseline in IETF style, knowing full well that it is likely to change >> significantly. >> >> >> >> Cheers, >> >> >> Bron. >> >> >> >> -- >> >> Bron Gondwana, CEO, FastMail Pty Ltd >> >> [email protected] >> >> >> >> >> >> _______________________________________________ >> dispatch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > regext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
