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
Note well noted
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/
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.
https://datatracker.ietf.org/doc/draft-happel-structured-email-trust/
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.
https://datatracker.ietf.org/doc/draft-ietf-sml-structured-vacation-notices/
(ran out of time, didn't get to this)