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

[Neil Jenkins <[e-mail]>]

On Fri, 1 Mar 2024, at 00:00, Robert Stepanek wrote:
> 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.

Agreed.

> A major version change might change a reserved property name to a common usage one, though.

Agreed (hopefully will never happen 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.

Sure, that's fine, I see your logic there.

> 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>.

Sounds reasonable.

> 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.

I see. I think we are broadly on the same page here, it's just a matter of degree. I think the default should be to accept reservation of an unused property name, unless there's a strong probability the name will be required for a common property in the near future. My understanding is you lean towards leaning towards default against, on the possibility it might be a preferred name for a future common property. Since the future is hard to predict, I am strongly in favour of using the cleanest names now, rather than forcing unusual namespaced names on the off chance of collisions later.

Cheers,
Neil.