**Session Date/Time:** 18 Feb 2025 17:00

# [SML](../wg/sml.html)

## Summary

The SML Working Group meeting focused on current issues with the base specification, primarily around the definition of vocabularies and the embedding of JSON-LD in emails. Key discussions revolved around the feasibility of an IANA registry for vocabularies, client compatibility when embedding structured data, and the nuances of MIME part handling. Initial client compatibility tests showed promising results regarding breakage but highlighted inconsistencies in how structured data is presented, sometimes as an attachment. The need for further discussion on specific MIME structures and potential future requirements for signing structured data was also noted.

## Key Discussion Points

*   **Vocabulary Registry (Section 3.2)**
    *   The current specification recommends `schema.org` but allows any valid JSON-LD vocabulary.
    *   A discussion was held on the utility of an IANA registry for vocabularies that are not `schema.org`, particularly for RFC-defined types like the Structured Location Notice. This would allow clients to discover and document vocabularies.
    *   A question was raised if IANA could host API-like documentation for these RFC-defined vocabularies, similar to `schema.org`'s website.
    *   Alexey noted that IANA traditionally prefers simple, table-like registrations and may resist hosting more complex HTML/API documentation. Registrations often involve TXT templates.
    *   The relationship with `schema.org` was debated: should IETF RFCs encourage registration there, or should the IETF create its own approved vocabulary mechanism? Concern was raised about `schema.org`'s separate governance and timelines potentially conflicting with RFC publication.
    *   Ben suggested an IETF-approved vocabulary system, possibly with a faster iteration cycle than RFCs, to ensure interoperability for specific use cases.
    *   Michael pointed to Appendix B of the ASDF document (draft-ietf-asdf-asdf), which provides a JSON schema.org rendition of ASDF syntax, as a potential reference for minimal standardization.
    *   A sense of those present indicated that a general registry for other vocabularies beyond `schema.org` makes sense.

*   **Embedding JSON-LD in Emails (Base Spec Issues)**
    *   The working group reviewed the approach of clearly separating machine-readable JSON-LD parts within a `multipart/alternative` email structure.
    *   A question was raised regarding the permissibility and client handling of multiple `multipart/alternative` elements within a single email. It was confirmed that MIME standards allow this, and clients should theoretically be able to handle it.
    *   The discussion moved to how clients *would* deal with multiple machine-readable parts if present, or if different `multipart/alternative` branches contained different types of machine-readable data.
    *   Ben emphasized the distinction between MIME specifications (where "attachment" is a `Content-Disposition`) and client UI (which presents an "attachment" concept). He recommended sticking to simple, common MIME structures that are known to work with existing clients.
    *   Art suggested describing a single, recommended configuration (e.g., SML as the last part in `multipart/alternative`) and providing no guidance for more complex or unusual structures to avoid unnecessary complexity and debate.
    *   A concern was raised that overly rigid structures might prevent future extensibility inherent in MIME.

*   **Client Compatibility Testing for `multipart/alternative` and `multipart/related`**
    *   Initial tests were conducted on various email clients and webmailers regarding the rendering of emails containing JSON-LD in `multipart/alternative` and `multipart/related` structures.
    *   The "good news" is that none of the tested clients "totally broke" (i.e., failed to display the HTML part or render the email unusable).
    *   The "bad news" is that some clients (e.g., Gmail) displayed the JSON-LD part as an attachment (with a paperclip icon), which was deemed inconsistent and potentially confusing for users.
    *   Ben expressed strong concern that showing machine-readable data as an attachment is a "fail" for user experience, drawing parallels to past issues with vCards, which led to user complaints and confusion.
    *   Art and Alexey acknowledged Ben's point about potential user confusion but emphasized that the primary goal of these tests was to confirm that the structured data didn't severely break the email's display, which was met.
    *   Notably, Apple Mail and Outlook, which have historically shown loose MIME handling, rendered the test emails without issues. This was seen as a positive outcome given their market share.
    *   It was noted that some `multipart/related` tests might have missed setting `Content-Disposition: inline`, which could affect attachment display. This needs to be re-tested.
    *   A general sense was that the current approach for embedding is "okayish" with legacy clients, but the attachment display issue for some clients needs further attention, potentially through engagement with vendors.

*   **Signing Structured Data**
    *   A brief discussion was held on a potential future need to sign structured data at the content level, independent of the overall message signature (e.g., S/MIME, PGP/MIME).
    *   This might involve using mechanisms like JWS/JOSE and imply the use of different MIME types (e.g., `application/jose+json` instead of `application/ld+json`).
    *   This was noted as a topic for future consideration regarding the extensibility of the specification.

## Decisions and Action Items

*   **Decision:** No immediate decision on the IANA vocabulary registry, but the concept is deemed useful for other vocabularies.
    *   **Action Item:** Create a GitHub ticket for continued discussion on an IANA vocabulary registry and its relationship with `schema.org`. (Alexey)
*   **Action Item:** Art to provide real-world examples of emails with complex or nested `multipart` structures to inform discussion on encouraging/discouraging certain configurations.
*   **Action Item:** Re-test `multipart/related` embedding with `Content-Disposition: inline` to observe its effect on attachment rendering. (H. Yorck and testing team)
*   **Decision:** The embedding approach of having SML as the last part in `multipart/alternative` is considered "okayish" for existing clients based on current tests, despite some showing it as an attachment. Further engagement with vendors (e.g., Gmail) may be needed.
*   **Action Item:** Create a GitHub ticket to track the discussion around signing structured data at the content level and its implications for MIME types and specification extensibility, if one does not already exist.

## Next Steps

*   Update the draft specification based on discussions, prior to the upcoming IETF meeting in Bangkok.
*   Continue discussions on specific issues on the mailing list, particularly regarding MIME structures and client handling of embedded JSON-LD.
*   The chairs will start an adoption call for the Trust draft (action item from previous interim).
*   Phillip (not present) is working on a separate draft for structured reply, expected in a few months (action item from previous interim).
*   The SML WG has a meeting tentatively scheduled for Friday at the Bangkok IETF.