Re: [calsify] jscontact - Inquiries about the "label" and "contexts" properties

[Robert Stepanek <[e-mail]>]

Hi,

thank you for your input.

On Fri, Jan 19, 2024, at 9:00 AM, skedastically wrote:
> Therefore, I would think it is more beneficial to combine them into one, with enumerated values of "work" and "private" being "special" values. This is similar to how the TYPE property parameter was implemented in VCard. Furthermore, I would think it would be better to name them as "tags" instead of contexts or label(s).

This is not how I understand the definition of the TYPE property. Section 5.6 of RFC 6350 states: "[...] Most of the time, its value is a comma-separated subset of a predefined enumeration".

The "most of the time" sentence part is ambiguous (does it refer to "comma-separated" or "predefined enumeration"?). But all properties making use of TYPE in RFC 6350 then enumerate all possible values. The complete list of allowed values per property is defined here: https://www.iana.org/assignments/vcard-elements/vcard-elements.xhtml#parameter-values

> - Is "contexts" intended to be used as a keyword system similar to the above idea?

The "contexts" property is meant to only contain predefined, enumerated values. New values can be registered following the procedures outlined in the "Registry Policy and Change Procedures" section of draft-ietf-calext-jscontact-16 <https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-16.html#name-registry-policy-and-change->, once this RFC is published.

> If so, what is the extra use of a single "label", given that tags are already assigned? Furthermore, would it be better to rename the parameter to "tags" or a similarly generic term instead?

The "label" property is meant to contain a user-defined free-text value. It is the result of the non-standard X-ABLabel property repeatedly showing up in vCard data generated by a couple of implementations, notably Apple's, and goes back to at least 2002 (see https://www.w3.org/2002/12/cal/vcard-notes.html). I don't want to change it to a multi-valued property value in JSContact as the semantics would then differ from vCard.

Instead, I would suggest you to start registering a new "keywords" property once JSContact is published. That would include defining how it converts with vCard. It would only require a minor version bump (say, "1.0" to "1.1") and might not even require a RFC draft to be written.

Does that sound good to you?

Thanks,
Robert