Re: [calsify] Request for preliminary review of JSContact property registrations

[Robert Stepanek <[e-mail]>]

On Wed, Feb 28, 2024, at 4:34 AM, Neil Jenkins wrote:
> On Wed, 28 Feb 2024, at 02:06, Robert Stepanek wrote:
>> The "addressBookIds" and "blobId" property names seem rather too specific for JMAP to reserve them in the standard namespace.
> 
> I disagree and would not like to change them. The whole point of having the registry was to avoid having the mess of ugly vendor-named (or similar) properties.

Agreed, and as many entries in there should have intended usage "common" to allow for interoperability. "Reserved" should in my understanding only be used sparingly, and as defined by both JSCalendar and JSContact "to avoid name collisions with future extensions or protocol use."

Since this is the first time that we might add "reserved" usage properties in the IANA JSCalender and JSContact registries (apart from "extra" in JSContact), let's put our own criteria to the test:
 • "to avoid name collisions with future extensions" means: reserve this name now because it's likely that a some time in the future there will be a "common" usage property for which this name is a very good choice.
 • "to avoid name collisions with protocol use" means: it's likely that contact exchange protocols will use a property named like this with protocol-specific semantics. No "common" usage property should ever exist having this name and it doesn't make sense for this property to occur outside the context of some specific protocol.

Now:
 • "id" scores highly for the "protocol use" criteria, so let's reserve that!
 • "addressBookIds" scores both for the "future extension" and "protocol use" criteria, but what is it? Do we think that's a good property name for some future extensions that going to add a "common" definition, potentially incompatible with how JMAP will be using it? Or do we reserve it now to never use it outside the protocol-specific contexts?
 • "blobId" doesn't score for the "future extension" criteria. But is one protocol enough to score for the "protocol use" criteria? Maybe, but I want to hear the working group first, because this sets a precedent.

> They would stick out like a sore thumb in JMAP Calendars and be inconsistent with everything else we've done.

I am sure you meant JMAP Contacts here, and yes, I am very much aware of that. Being active in both the jmap and calext working groups, I am just trying to look at JSContact and JSCalendar outside the context of JMAP.

>> I see that we haven't registered these properties for JSCalendar either, so whatever we now decide for JSContact should preferably be done for JSCalendar, too.
> 
> I'm not quite sure what you are looking at — the JMAP Calendars spec makes similar registrations <https://www.ietf.org/archive/id/draft-ietf-jmap-calendars-13.html#section-10.4> for JSCalendar.

My mistake, sorry. I just looked at the IANA registry, not at the JMAP Calendar spec. Again, I want to make sure we find the right solution for both JMAP Contacts and Calendars and accordingly for JSContact and JSCalendar.

In any case, I don't think it makes sense to specify a type for reserved properties, but that's just a minor thing to change.