SML Agenda

IETF 121 [hybrid] Madrid

Wednesday 23 July 2025
07:30 (UTC)/9:30 (Madrid)
1.5 hours

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

Chairs: Alexey Melnikov & Arnt Gulbrandsen

Notes Taker: Daniel Kahn Gillmor and John Levine

Administrivia

Note well noted

Structured Email (-03) (Hans-Joerg Happel)

https://datatracker.ietf.org/doc/draft-ietf-sml-structured-email/

The current list of open issues:
https://github.com/hhappel/draft-happel-structured-email/issues/

• call for help with IANA registration section

• John Levine recommends talking with IANA desk in Madrid (H-J Happel
  did that in Bangkok (IETF 122))

• Alexey: why different registries?

• Happel: schema.org is a good baseline, sml.iana.org is a narrower
  range of things explicitly intended for use with e-mail

• Phillip Tao: i'm walking back the application/sml wrapper idea -- it
  seemed good for extensibility, but i'm not sure we need that.

• Daniel Kahn Gillmor (dkg): please don't build a wrapper and expect
  it to be extensible. We have extensibility at the content-type. Use
  that.

• dkg: please don't sign/encrypt the subpart separately from the
  message itself. draft-ietf-lamps-e2e-mail-guidance makes pretty
  clear that the message itself should have a single cryptographic
  status

• Happel: the SML part might be signed by a different party than the
  message itself. consider a hotel and a hotel booking system

• Arnt Gulbrandsen: if we get signing/encryption from jose
  automatically, why do we need to cover that here? can we just let
  jose handle it? a header could indicate whether a message can be
  automatically archived without display after processing the
  structured data, or whether display is still meaningful/required
  even after doing automatic processing.

• Happel: we deal with json-ld in mail, but that shouldn't havee a
  reason for extra signatures.

• Phillip Tao: legal footer is challenging because of the
  full-representation claim -- which part is going to be the full
  representation, given that there could be multiple structured e-mail
  parts. It would be simpler if full-representation is handled by a
  top-level multipart/alternative. If you have multiple structured
  parts, you can have a top-level m/a, and then within that a
  multipart/mixed that contains all your structured parts.

• It would be weird if you had a human-readable part but then you were
  stripping the structured sub-part during forwarding or replying.

• Happel: another approach could be for a different structure where
  each part itself has a multipart/alternative with a machine-readable
  part

• dkg: I'd be wary about trusting a signal other than the MIME
  structure itself to indicate full-representation. What if the signal
  doesn't match the MIME structure?

• Arnt: strongly in favor of splitting reply work to separate draft on
  top of the core draft. Let's get the core draft moving.

• Alexey: i think i disagree with Arnt.

• Arnt: error replies section needs to talk about who the replies go
  to: envelope sender or Reply-To address?

• Alexey: flags like hasAttachment are in documents at work in
  MAILMAINT

• Alexey: a flag for "fullRepresentation" in addition to
  "hasStructuredData" seems like overkill

• Happel: sure, consider an MUA like a sieve script

• Phillip: the second flag might be useful depending on whether the
  MUA can handle it automatically or not. Some messages might want to
  be displayed to the user. Rich links, for example, compared to
  authorization codes.

• Happel: i think you're saying that there's a distinction between
  machine-readable and automated-handling.

• Phillip: full vs. partial needs to be distinguishable by the mime
  structure. The other header/flag should tell you whether the message
  is handlable by the client and doesn't need to be displayed to the
  user at all.

• Daniel Eggert: hasAttachment flag is for web UI so that they can
  show the paper clip icon. Since structured data is more for those, i
  don't think the flag helps anyone. I don't think we (apple mail)
  would use it.

• Arnt: flag is only for managing what mobiles might need. email
  transfer isn't that expensive these days. Re: webUI, i've seen webUI
  that handles structured mail quite well. in the list of inbound
  messages, you can see status of the parcels along with the list of
  messages. It is useful.

• Bron: i don't know whether there's any value in being able to
  display whether there is structured data. but it might be useful if
  you want to fetch all messages that have structured data (for
  example, to prioritize such processing). Even if your MTA is
  adversarial and can't tell the flag, you could have a MUA that
  fetches the message and sets the flag directly.

Trust and security considerations (-04) (Arnt Gulbrandsen)

https://datatracker.ietf.org/doc/draft-happel-structured-email-trust/

• Alexey: if this draft ends up being different from Gmail structured
  data, then this draft needs to describe what we do, not what gmail
  does.

• Arnt: i want the draft to describe what different operators do, if
  they have running code. If there are differences between what folks
  are doing and what we encourage people to do, i want to describe the
  running code overall.

• dkg: uncomfortable with the consolidation effects of relying on some
  pre-built list of payment processors.
  if you're depending on transaction IDs, the property you want is
  "high-entropy", not "long". it must be unpredictable.
  I'm also quite uncomfortable with the boolean nature of what you're
  calling "trust" here. In particular, i might buy a ticket and be
  fine with entering a simple calendar entry for the event. but that
  doesn't mean that i want that ticketing vendor to add a repeating
  event to my calendar that sets off an alarm at 2am every Tuesday
  morning.

• Alexey: i get lots of fake messages about paypal; this needs to
  grapple with anti-spam/phishing, etc. I think we might also want to
  bind these kinds of authorizations to some narrow time window. (a
  message about a transaction is only acceptable if it matches the
  transaction ID and happens to have a timestamp "near" the payment
  processor's timestamp)

• Happel: this seems related to the agent-to-agent side meeting that
  happened recently.

Structured vacation notices (-01) (Hans-Joerg Happel)

https://datatracker.ietf.org/doc/draft-ietf-sml-structured-vacation-notices/

(ran out of time, didn't get to this)

AOB