**Session Date/Time:** 27 Jul 2022 17:30

# calext

## Summary

The calext session covered updates and open discussion points for the JS Contact and JS Calendar specifications, including their mappings to vCard and iCalendar, respectively. Key topics included the definition and mapping of the `label` property in JS Contact, the handling of `replyTo` and `sentTo` properties in JS Calendar for scheduling, proposed vendor extension naming schemes, and a potential correction to a `VTODO` duration constraint in RFC 5545.

## Key Discussion Points

*   **JS Contact Status and Publications:**
    *   JS Contact (o3) and JS Contact vCard Mapping (o2) RFCs are in progress.
    *   A new draft, "vCard Extensions for JS Contact," defines vCard properties and parameters needed for mapping.
    *   All three drafts are planned for co-publication.

*   **JS Contact Main Changes:**
    *   Clarified that `id` values in options objects must be persisted to facilitate patching.
    *   Introduced a `resources` property, combining various URI-based vCard properties, with a specialization for `onlineServices` to specify canonical service names.
    *   New vCard properties and parameters are being defined, some with shared semantics with iCalendar properties.

*   **JS Contact Label Property Discussion:**
    *   The `label` property in JS Contact is intended for human-readable, non-semantic text, motivated by Apple Address Books' `x-ab-label`.
    *   In vCard, a `LABEL` parameter exists for `ADDRESS` (delivery address) in RFC 6350 but is not in IANA. An older `LABEL` property in vCard 3 was obsoleted.
    *   Apple Address Books use `x-ab-label` with property groupings, seemingly for very short identifiers (e.g., "home," "work").
    *   **Question:** Is the current JS Contact `label` definition (free-form text) aligned with common use cases like `x-ab-label` (short identifiers)? Is arbitrary node tagging needed?
    *   **Opinion:** The `label` property should be at least as powerful as `x-ab-label`. A clear mapping from existing data (e.g., `x-ab-label`) to JS Contact is important. If JS Contact `label` is clarified to be for short identifiers, using `x-ab-label` directly might be appropriate for mapping.

*   **JS Contact Property Groups Discussion:**
    *   vCard allows grouping properties (e.g., `item1.email`, `item1.tel`) using opaque identifiers, but RFC 6350 specifies no further semantic meaning.
    *   The mapping RFC preserves these groups using JSON pointers.
    *   **Question:** Should property groups be a first-class feature in JS Contact?
    *   **Opinion:** Apple Address Books are the only known system widely using them. While preservation in mapping is necessary, there's no strong demand for them as a first-class JS Contact feature currently.

*   **JS Contact Properties Not Intended for Standard Mapping:**
    *   `PID` and `CLIENTPID` (vCard for synchronization): Not intended for standard JS Contact properties, though values can be preserved. Their utility for synchronization was questioned.
    *   vCard temporal values:
        *   `date-time` and `date` types (partial values): Not intended for support in standard JS Contact properties due to lack of use cases.
        *   `date-and-or-time` for anniversaries: Supported, including partial dates, but not time-only.
        *   **Proposal:** Support time components for birthdays (e.g., exact time of birth).

*   **JS Calendar Status and Publications:**
    *   Similar to JS Contact, three RFCs are in progress, including an extensions draft for new iCalendar properties.
    *   Some definitions (e.g., `propId` parameter) will be shared between vCard and iCalendar extensions.
    *   A standard mapping for unknown properties to an extension property mechanism using URNs (in the IETF namespace) is defined.

*   **JS Calendar `replyTo` and `sentTo` Discussion:**
    *   JS Calendar's `replyTo` (multivalued) allows different scheduling methods (IMIP, Web, Other) for RSVPs/invites.
    *   `participant.sentTo` defines where to send invites (without a Web method).
    *   **Problem:** iCalendar's `ORGANIZER` or `ATTENDEE` properties typically allow only one calendar address (URI, often mailto), creating ambiguity when mapping from multivalued JS Calendar properties. The `Web` method has no iCalendar mapping.
    *   **Options Discussed:**
        1.  Keep JS Calendar multivalued and define a heuristic for iCalendar mapping (e.g., prioritize IMIP). (Concerns: rule complexity, potential data loss/overwrite).
        2.  Merge `Other` and `IMIP` methods into a single `ITIP` method. (Aims for clarity).
        3.  Use separate properties for each scheduling method.
        4.  Maintain current design, explicitly rename `Other`. The multi-value property provides a namespace for extensibility, allowing servers to introduce new scheduling methods without clients needing explicit knowledge.
        5.  Simplify the approach, focusing on existing ITIP mechanisms and separating organizer from reply-to addresses.
        6.  Separate identification from scheduling mechanism. A canonical identifier (the single URI) could serve for ITIP if mailto and no other mechanisms are present, with an array of alternative, preferential reply mechanisms.

*   **JS Calendar `sendBy` Property:**
    *   JS Calendar `sendBy` is the email address from the `From` header of the email containing calendar data.
    *   iCalendar `SENT-BY` parameter on `ATTENDEE` is defined differently.
    *   **Proposal:** Rename JS Calendar `sendBy` to `sendFrom` to avoid confusion, and preserve the iCalendar `SENT-BY` parameter during mapping.

*   **JS Calendar Vendor Extension Naming Scheme:**
    *   Current scheme uses a domain and property name, but no IETF-authorized domain exists.
    *   **Proposal:** Allow `https` URIs (pointing to property definitions) or URNs in the IETF namespace for extensions. This makes properties self-documenting.

*   **JS Calendar Unknown Properties and Vendor Extensions:**
    *   Previous consensus suggested unknown properties should be ignored but stored.
    *   **Option 1:** Validate known properties, ignore/store others. Risk of name squatting if future standard properties clash with existing unknown properties.
    *   **Option 2 (Proposal):** Only properties without a prefix are standard JS Calendar. All other properties *must* be prefixed with an `https` URI or a URN referencing the defining RFC. This aims to prevent name clashes and ensure self-documentation.
    *   **Concerns:** This might bloat the payload, introduce quoting complexities for patching with slashes in URIs, and potentially cause implementations to reject perfectly valid objects if they don't know about a specific extension.

*   **Tasks Update: `VTODO` Duration Constraint in RFC 5545:**
    *   RFC 5545 explicitly disallows `DURATION` on a `VTODO` without a `DTSTART`. This restriction was not present in RFC 2445.
    *   **Problem:** This constraint hinders compatibility with project management tools (where tasks may have durations but no fixed start time if dependent on other tasks) and standalone "floating" tasks with only a duration.
    *   **Opinion:** This constraint appears to have been added by mistake during the rewrite of RFC 2445 to 5545, as the author does not recall the reasoning, and it's not mentioned in the appendix of RFC 5545 as a change. Libraries like `libical` do not enforce it.
    *   **Proposal:** Drop the constraint to allow `DURATION` on its own for `VTODO`.

## Decisions and Action Items

*   **JS Contact Label Property:** No immediate decision; Mario and the presenter will further investigate `x-ab-label` usage and propose a way forward.
*   **JS Contact Property Groups:** Agreed to preserve property groups during mapping but not to introduce them as a first-class feature in JS Contact.
*   **JS Contact Temporal Values:** Agreed to support time components in birthday definitions.
*   **JS Calendar `sendBy` Property:** Agreed to rename JS Calendar `sendBy` to `sendFrom` and to preserve the iCalendar `SENT-BY` parameter on participants.
*   **JS Calendar Vendor Extension Naming Scheme:** Agreed to allow `https` URIs or URNs in the IETF namespace for extensions.
*   **Tasks `VTODO` Duration:** Agreed that the constraint in RFC 5545 is likely an error and should be removed.

## Next Steps

*   **JS Contact Label Property:** Mario and the presenter will continue work on this, including mailing list discussions to gather more input and clarify `x-ab-label` semantics.
*   **JS Calendar `replyTo` and `sentTo`:** Further discussion is required on the mailing list to reach consensus. Rick S. will draft a proposal for this.
*   **JS Calendar Unknown Properties and Vendor Extensions:** No consensus was reached on the proposal for prefixing all non-standard properties. This topic requires further discussion.
*   **Tasks `VTODO` Duration:** Ken M. (or the presenter) will consult with the Area Director (Murray, acting for Francesca) to determine the appropriate mechanism (errata vs. update) for removing the `DTSTART` constraint on `VTODO` durations.