Hi,
I forward here this post by Robert Stepanek from CalExt.
Any feedback is appreciated. Please provide it on calsify mailing list.
Best,
Mario
-------- Messaggio Inoltrato --------
Oggetto: [calsify] Proposal: jscontact-profiles
Data: Wed, 06 Nov 2024 11:35:24 +0000
Mittente: Robert Stepanek <rsto=40fastmailteam....@dmarc.ietf.org>
A: cals...@ietf.org
We ran out of time in yesterday's calext WG meeting, so I could not
present my proposal for new JSContact work. I would like to introduce a
registry of protocol-specific profiles for JSContact ("jscontact-profiles").
I will ask the working group for adoption when I have a draft ready, but
in this email I would like to outline the motivation and goals:
Motivation
* JSContact not only covers the features available in all current
vCard extensions, but also provides a richer model for international
names, addresses, phonetics, and more.
* This is useful for sophisticated address book and contacts
applications, but other use cases not necessarily require all of that.
* For example, the regext WG works on using JSContact in RDAP, but
only a subset of JSContact elements is useful to them (see
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/).
Goal
* The goal of jscontact-profiles is to define an IANA registry for
defining profiles of JSContact data.
* A profile declares which properties of a Card object it supports, it
must be a strict subset of IANA-registered JSContact properties (but
as always, new I-Ds can register new standard or reserved properties).
* Profile names are registered at IANA and their registry entry refers
to the internet draft that defines it.
* A new optional property "@profile" in the Card object defines that
Card's profile, the value is the profile name. The default null
profile stands for the regular JSContact profile.
Benefits
* A machine-readable central IANA registry is simpler to process than
if protocols define their JSContact profiles in an ad-hoc
specification. This for example benefits implementors of general-use
JSContact libraries.
* Protocol designers might be encouraged to use JSContact rather than
coming up with their own contacts format, when they can use a
standard approach how to restrict JSContact features to the ones
they are interested in.
* JSContact being the basis allows for sharing a subset of contacts
data across protocols and applications.
In parallel to this draft, an I-D for the "rdap" profile for JSContact
data will be worked on, so that we can validate our approach during design.
Should anyone be interested to collaborate, please me know! I will post
to the mailing list again once I have a document ready to ask for adoption.
Regards,
Robert
_______________________________________________
calsify mailing list -- cals...@ietf.org
To unsubscribe send an email to calsify-le...@ietf.org
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
