SML Agenda

IETF 121 [hybrid] Bangkok

Friday, March 21st, 2025
06:00 (UTC) / 13:00 (Bangkok)
1.5 hours

Meetecho:
https://meetings.conf.meetecho.com/ietf122/?group=sml&short=&item=1
Notes: https://notes.ietf.org/notes-ietf-122-sml

Chairs: Alexey Melnikov & Arnt Gulbrandsen (absent)

Notes Taker: Robert Stepanek

draft-ietf-sml-structured-vacation-notices

Presentation

Scope: “Vacation notices” aka “Out-of-office replies”
Updates since IETF 121

• Draft adopted by WG 🎉
• Minor changes to the document

Goal of today is decide if to keep initial proposal simple with only a
few use cases, or add more use cases to support.

Assume that implementation complexity is directly related to willingness
of industry to adopt the proposed standard -> e.g. supporting multiple
periods of absence is something that would make things complicated,
suggest to not add them to the spec.

Proposal: use schema.org types (e.g. in "replacement" field), allow for
optional "opening hours" field (for which also a schema.org definition
exists).

Need to refine terminology and naming of draft, is "vacation notice"
appropriate for cases where a doctor auto-replies with email pointing to
their replacement.

Michael Richardson: Does opening hours allow to define time zone?

Hans-Jörg: Likely that schema.org openingHours currently does not, as
it is used with physical locations for which time zone is part of the
location?

Ben Bucksch: Need to take care of avoiding feature creep. The typical
vacation notice use case is multi-days, no need for opening hours. Makes
it less complex and probably also what people expect.

Hans-Jörg: Initial proposed model was for just days, but at IETF 121
someone noticed that Microsoft Exchange does support hours. That's why
it currently is in the draft.
Ben: And I disagreed with that already at IETF 121.

Looking at the common uses of vacation notice, all of these could
benefit from structured information, rather than just free-text. Suggest
to allow state the kind of unavailability, e.g. is it temporary,
permanent, no reply address, etc? Think that extending the initial scope
with that is worthwhile.

(Alexey and Ben both agree).

Might need to provide a registry of these predefined values. Not sure if
IANA registry is overkill.

Everyone is excited about Friday.

ACTION: Hans-Jörg to raise question on mailing list if to extend
schema with "unavailabilityType" field. If so, how/where to maintain
list of allowed values.

Hans-Jörg: Do we also need a "no reply" header field?

Aside, "noreply@example.com" seems to be international standard, haven't
ever seen localized versions of that address.

draft-ietf-sml-structured-email

Presentation

Main spec for structured email. Reference implementation by Audriga.

Looked into how popular clients deal with emails containing SML. Got
test account at one German mail provider to test this in more detail.

Suggest to create IANA registry for RDF vocabularies used in SML,
schema.org is good basis but not enough. Was also thought to be a good
idea in the SML interim before IETF 122.

Charter allows to define email-specific templates/schemas, but where to
put that actually (outside the RFC document)? Am talking to IANA right
now if IANA registries would allow to contain definitions like
schema.org?

Discussion

Andy Newton: Are these namespaces (being https URLs) meant to be
actually retrievable?

Hans-Jörg: AFAIK, they can but don't need to be.

Andy: If not meant to be retrievable, could use URNs instead of https
URIs.

Ben: Could set up a site that works like schema.org but for IANA. Could
also optionally import types from schema.org that are relevant for
email.

Alexey: An IANA registry is some path at iana.org, not a subdomain. Need
to ask IANA if they are happy to create a subdomain and manage it
differently.

Pete: Don't underestimate what IANA can provide, it might mean much
work, probably too much. But first figure out what you need, then
approach them and they might make it work!

Alexey: I concur. That being said, IANA might ask for more money for
hefty new work.

Wes Hardaker: I just had similar experience with IANA. Their advice was:
be super specific what you want us to be doing. That helps a lot to get
what you want.

Ben: schema.org just is a JSON LD file, so it could just be a simple
table at IANA.

Hans-Jörg: I think it'd be good to render schema in a form that people
are familiar with from schema.org.

Murray: You should also look into IANABIS WG that just got presented
this week for new IANA processes.

Presentation (continued)

Insight: multipart/* can occur multiple times in emails, making
arbitrarily complex structures in MIME and contain multiple structured
email parts in one message. Will need to take this into account in
spec to guide implementors how to deal with that.

Alexey: Sounds good, fix it.

Tested a number of popular email clients how they deal with
multipart/alternative containing various "text" media types for json-ld.
All dealt with it fine in the sense that they presented either the plain
text or html parts of the alternative, but some of them showed the
json-ld parts as attachment which might confuse users (see slides).
Tweaking Content-Disposition header also didn't help.

Alexey: multipart/related needs a main node to render, which one did you
choose, "html"?

Hans-Jörg: Can't tell from the top of my head.

Alexey: To be clear, json-ld as part of multipart/related makes perfect
sense to me.

Michael Richardson: could we write an additional RFC that encourages
"content-disposition: inline" / as clients need to hide the attachment?
(second bullet on slide titled 4.1)

Should we allow top-level message to contain "application/ld+json" for
cases where no users needs to directly view that email?

Alexey: it's not prohibited now. But if you want it, better state
explicitly in spec that this is recommended to do in specific use cases.

Also allow signed/encrypted structured data, e.g. not only rely on
S/MIME but also allow the SML data self-sufficiently be able to show if
its untampered? Might need to introduce a new media type if we want to
do that.

We might want to think of using SML for email signatures. Do we need
some markup tags to indicate that something is an email signature.

Alexey: In our organization, we use S/MIME for signature.

Hans-Jörg: To clarify, this is not confidentiality, it's what people
nowadays put in their email footers.

Alexey: Best to ask the mailing list.

Might be neat if we could make HTML body parts refer to structured email
body parts. Currently, such HTML bodies typically load that data from a
https: URL when rendering that email. Suggest to use HTML "data-id"
property.

Alexey: what is the problem with content-id again?

Hans-Jörg: the issue with content-id is that we could only refer to
all of the json-ld body part, we can't make the HTML body part refer
into a fragment of the json-ld data.

Alexey: AFAIK, the syntax for fragments is specific media types, so you
maybe could define what you need to json-ld.

John Levine: The syntax for fragments is defined in the URI, the
semantics how to locate that fragment in the data is specific to the
media type.

Alexey: looks like we need to experiment more.

Ben: Is there an actual need for this? This would make it harder for
client implementors.

Alexey: Various email clients do not display/strip external links
anyway, so something like cid: makes it actually simpler to render the
content.

Ben: Making that information specific to a MIME part is what concerns
me, clients might not render it. It should not look like a URL, because
clients might just not display any URL, irrespective if the resolve to a
resource inside that same email.

Hans-Jörg: I understand that it might be more complex than cid:.

Pete Resnick: You may be overestimating how email clients are written.
Some of that stripping out content is done pretty crudely, just not
displaying any external input/URL. Content ids seem to be well
understood by now.

Hans-Jörg: But then we could just refer to the json-ld data in total,
not subparts.

Ben: I always find https URL that aren't actually hosted on some HTTP
server very confusing.

Hans-Jörg: Issue is that json-ld expects https/http URI schemes.

Alexey: That definitely needs more discussion.

Hans-Jörg: Last point, imagine flight reservation structured email.
Airline might inform you about flight changes or other updates. Do we
need error/status codes in SML to communicate issues/changes between
user and e.g. airline?

Michael Richardson: I am in favor of this, I delete email rather than
keeping it. This would help getting that structured email data again,
should I need it again.

Alexey: Make a proposal.

Arnt suggested to use already defined SUPERSEDES header field to
indicate that formerly sent structured data is outdated. Currently only
focused on recipient, should also take sender use cases into account.
How to delete structured data? Expires header field?

Alexey: Sounds good, but need to consider security constraints (e.g. the
message is signed and sent by the same sender, etc).

Ben: I think it's good and necessary. Use case I can think of is parcel
delivery where this would be useful. Would be careful with the reasons
stated for the data changes.

Alexey: let's see what happens on the mailing list.