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

[Neil Jenkins <[e-mail]>]

On Wed, 28 Feb 2024, at 19:41, Robert Stepanek wrote:
> 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.

My understanding was that this was more to do with avoiding name collisions by making it fairly easy to reserve a name on a first-come-first-serve basis, so people didn't start accidentally building extensions with conflicting names.

>  • "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?

I would say unlikely, because even if you wanted something similar, you would be more like to reference a UID outside of the protocol context, so need a property like `addressBookUids` instead.

>  • Or do we reserve it now to never use it outside the protocol-specific contexts?

I think that's fine.

>  • "blobId" doesn't score for the "future extension" criteria. But is one protocol enough to score for the "protocol use" criteria?

I don't really see why not.

Cheers,
Neil.