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

[Robert Stepanek <[e-mail]>]

On Thu, Feb 29, 2024, at 4:02 AM, Neil Jenkins wrote:
> 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.

So we have two different understandings of RFC 8984's definition for "reserved" properties, and that's despite us being co-authors of that I-D! This shows that its phrasing leaves too much room for interpretation.

I'd like to get that sorted out now for both JSCalendar and JSContact.

JSCalendar RFC 8984, section 8.2 <https://datatracker.ietf.org/doc/html/rfc8984#name-creation-of-the-jscalendar-> defines:

"If the Intended Usage field is `common`, sufficient documentation is required to enable interoperability. [...]
A `reserved` registration reserves a property name without assigning semantics to avoid name collisions with future extensions or protocol use."

JSContact, draft version 16, section 3.3 <https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-16.html#name-registry-policy-and-change-> defines:

"A `common` usage denotes an item with shared semantics and syntax across systems. Up-to-date systems MUST expect such items to occur in JSContact data.
A `reserved` usage reserves an item in the registry without assigning semantics to avoid name collisions with future extensions or protocol use."

First, both definitions leave it unclear if reserved properties may show up in JSCalendar/JSContact data. If they can, then one must expect implementations to also store them. This suggests the answer to be no. Implementations MUST NOT expect or add properties with reserved names, and any such JSCalendar/JSContact data is invalid outside the protocol that uses them. A major version change might change a reserved property name to a common usage one, though.

Secondly, this suggests that registering the property type of a reserved property name does not make any sense. The IANA Considerations should make clear that for a reserved property the type MUST be omitted, and the property context and reference or description MAY be omitted.  Currently, it states that the reference/description is omitted, but that doesn't make sense either: one would want to know why it's reserved and the JSContact I-D does exactly that for the "extra" property at the end of section 8.2.6 <https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-16.html#name-initial-contents-for-the-jsc>.

Lastly, I so far understood we would want to encourage registering properties with "common" usage in favor of vendor-specific properties. I did not understand this to apply also for reserved properties which I rather have seen as a rare edge case.