**Session Date/Time:** 07 Nov 2025 16:30

# SML

## Summary

The SML working group discussed the progress of its core documents: the Trust document, the Structured Unavailability Information (formerly Vacation Notices) draft, and the Core SML document. A presentation on compelling SML use cases was also given. Key discussions revolved around simplifying the "trust" model for displaying structured data, handling automatic actions with appropriate safeguards, and streamlining the Core SML specification by removing complex parts (like SML replies) for future development. Decisions were made to proceed with Working Group Last Call for the Trust and Core SML drafts, with a dependency on both being ready before IESG submission.

## Key Discussion Points

*   **Trust Document**
    *   The document has been significantly shortened to align strictly with the SML charter, thanks to a prior review.
    *   A question was raised regarding the inclusion of a threat landscape review, as it is not explicitly in the charter. The editor (Arnt) mildly favors its inclusion.
    *   **Formal Display**: A proposed change to simplify the recommendation for displaying structured data, aligning it with calendar invitations. This would move away from a complicated "three-part test" (trusted sender, trusted thread, third-party data structure connection) to a more uniform user experience.
    *   **Trusted Sender vs. Trusted Message**: Discussion highlighted the haziness of the term "trusted sender" and the potential for a message to be trusted (e.g., related to a calendar event) even if the sender is not explicitly known. Hans-Yerg brought up the concept of trust in the structured data itself (e.g., digitally signed by a known entity like an airline), separate from sender trust. The document editor prefers to avoid taking a strong stance on this complexity.
    *   **Jason LD Signatures**: Clarification on terminology was requested, differentiating between "signed JSON-LD" and W3C's "Data Integrity Proofs" (formerly JSON-LD Signatures).
    *   **Automatic Processing**: Performing actions at message receipt time (e.g., notifications, data changes without user awareness) requires a stricter test than mere display.
        *   The editor suggested matching current Mail User Agent (MUA) notification logic, but questioned if this is sufficient.
        *   Daniel GKG raised concerns about writing generic normative guidance for diverse automatic actions (e.g., event description updates vs. cancellations, rate limits to prevent DoS). He emphasized that semantics are data-type specific.
        *   Hans-Yerg suggested an initial explicit user acknowledgment (like for remote images) for automatic actions, or approval for a specific sender/use case.
        *   Ben Weishad outlined three cases for warranted automatic processing: explicit user approval, user setting/preference, or a trusted sender with a non-dramatic action (e.g., data extraction).
    *   **Sender Predictability**: Arnt noted the desire for senders to predict receiver-side actions, which implies harmony across receivers. This is not currently in the document.
    *   **Use Cases Text**: Text in the draft related to use cases was deemed too vague ("Some use cases have higher risks than others") and will be removed unless more concrete input is provided.

*   **Structured Unavailability Information Draft (formerly Vacation Notices)**
    *   This draft provides a specific use case for structured email, skipped at the previous meeting.
    *   **Distinction between Individuals and Role Accounts**: The `replacement` property was updated from a custom type to `schema.org/Person` or `schema.org/Organization` to allow for replacements by individuals or services.
    *   **Complex Absence Patterns**: Incorporated `schema.org/OpeningHours` to allow for granular unavailability (e.g., part-day, recurring business hours), which is often not supported by current MUAs. This can apply to both services and individuals (e.g., part-time home office).
    *   **Unavailability Type**: A new `unavailabilityType` property was introduced to categorize absence as `temporaryUnavailability` (standard vacation), `permanentUnavailability` (left company), `noReply` (automated message with no human response expected), or `moved` (new address).
    *   **Draft Renaming**: The draft was renamed from "Vacation Notice" to "Unavailability Information" to reflect its broader scope.
    *   **Status**: The draft is deemed coherent and implementable, with example implementations already working. It needs to align with the Core SML draft.

*   **SML Use Cases (Presented by Ben Weishad from Parula)**
    *   Mock-ups were presented for several compelling SML use cases, with a focus on consistent user experience across chat (WhatsApp-like) and email.
    *   **Polls**: For group decisions, including specific integration for meeting time coordination with calendar views (e.g., "view in my calendar" option to check conflicts).
    *   **"Book Me"**: Offering multiple time alternatives for recipients to choose from (e.g., doctor appointments), automatically updating calendars.
    *   **To-Do Lists/Task Management**: Hierarchical lists with checkboxes, allowing team collaboration, integration with external task management systems, and pinning lists to a user's task manager/calendar.
    *   **Location Sharing**: Real-time location sharing (e.g., for an hour, day, week) with map integration, showing multiple participants' locations, and routing/ETA for meeting points.
    *   **Concerns**: Alexey and DKG raised privacy concerns for location sharing and the interaction with other systems (e.g., calendar). It was clarified that location sharing would be user-initiated.
    *   **Comparison to WebExDC**: DKG noted that many described features are already possible with WebExDC via email. Ben acknowledged overlap but highlighted SML's aim for deeper calendar integration.
    *   **Data Distribution**: Initial data in email, with updates pulled via HTTP from a sender-chosen server (URL in SML) to avoid frequent emails. For XMPP, updates would be sent over XMPP. Arnt noted that HTTP updates are preferred over frequent email updates for "reactions" based on current experience.

*   **Core SML Draft**
    *   **Simplification**: The draft was simplified by removing the sections dealing with "SML replies" to streamline the core specification and expedite publication. This content is intended for a separate, future document.
    *   **Machine Readable Message (MRM)**: A new concept was introduced: a "machine readable message" is defined as a message entirely composed of "full representation" body parts. This allows MUAs to act on the entire message as machine-readable.
        *   Jim raised a concern that even with MRMs, users still need human-readable context for changes, e.g., in recurring calendar invitations.
    *   **Partial Representation**: For cases where structured data annotates human-readable content (e.g., recipes in a newsletter), the draft proposes referencing JSON-LD `@id` properties within the HTML to link structured data to specific parts of the displayed text. This simplifies a previous controversial proposal for an explicit "core part" property.
    *   **Message Flags**: Radically simplified to two proposed flags that a trusted MUA or MTA can set:
        *   `has-structured-data`: Indicates the presence of any structured data.
        *   `is-machine-readable`: Reflects the "machine readable message" conclusion.
        *   These flags could aid MUA rendering and future SIF filters.
    *   **IANA Considerations**: Sections for IANA registration of the two message flags and the `Content-Purpose` MIME header field were added. Two new registries are proposed:
        *   `SML Vocabularies Registry`: For general structured data vocabularies (e.g., schema.org, SML email vocabularies).
        *   `SML Email Vocabulary Registry`: For email-specific concepts defined within the SML working group (e.g., structured unavailability notice).
    *   **Review Needs**: Further reviews are sought, especially for clarity to readers unfamiliar with the working group's history, typo correction, and refinement of IANA boilerplate text.
    *   **Status**: The document is considered a building block and is stable for implementation.

## Decisions and Action Items

*   **Decision**: The Trust document and the Core SML document will both proceed to Working Group Last Call (WGLC).
*   **Decision**: Submission of both the Trust document and the Core SML document to the IESG will be held until both are completed and their consistency is verified.
*   **Decision**: The "SML Replies" section has been removed from the Core SML draft for simplification and to expedite publication. It will be developed as a separate document or a future BIS.
*   **Action Item (Arnt)**: Add an informative section to the Trust document discussing sender predictability of actions based on structured data.
*   **Action Item (Arnt)**: Remove the vague "Some use cases have higher risks than others" text from the Trust document unless more concrete text is provided by the working group.
*   **Action Item (Hans-Yerg)**: Incorporate discussions around explicit user acknowledgment and Ben's three cases for automatic processing into the Trust document.
*   **Action Item (Hans-Yerg)**: Refine the IANA sections, particularly the boilerplate for the registries, in the Core SML draft.
*   **Action Item (Ben Weishad)**: Provide suggested text for further refinement or simplification of the "partial/full/MRM" characteristics in the Core SML draft.

## Next Steps

*   **Working Group Last Call (WGLC)** for the Trust and Core SML drafts.
*   **Community Review**: The working group is encouraged to provide detailed reviews of the current text for clarity, typos, and consistency, especially for those new to the working group's progress.
*   **FOSDEM 2024 Modern Email DevRoom**: Members are invited to submit proposals for talks related to modern email at the FOSDEM conference in Brussels (late January 2024) by December 1st.