SML @ IETF 116

Tuesday, March 28th, 2023
09:30 JST/00:30 UTC
2 hours

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

Chairs: Barry Leiba and Alexey Melnikov

Note takers: Jim Fenton

Non-working group-forming BOF
Mailing list: sml@ietf.org

Admin

Note well, etc. presented by Barry

Background and Problem Statement

Hans-Joerg Happel

• Technology:
  ** Semantic web - machine readable data
  ** RDF - W3C standard
  ** schema.org - shared vocabulary

• Applications:
  ** Search - snippets for search engines
  ** Sharing and embedding - e.g., Facebook Open Graph, Twitter
  Cards
  ** Wikidata - machine-readable Wikipedia

• Structured email: content not for human consumption, for for semi-
  or fully-automated interaction

• Email more as a "personal API", bridging private and public
  informaiton space
• Examples already exist: calendar invites, mailing list management,
  etc
• GMail has been adding schema.org annotations since 2013, e.g.,
  flight itineraries
• Current adoption
  ** Sender side: Some ESPs like Google Play
  ** Receiver side: Large freemail vendors, some open source tools
  like KDE itinerary
• Current issues
  ** One-way only (sender to consumer)
  ** Interoperability
  ** Complex onboarding
  ** Sender confidence in client-side usage
• MIME types?
  ** to be discussed later
• Why this BOF
  ** Relevant extension to email
  ** Work required to go beyond big senders and providers

Barry: Clearifying that extensions to email aren't to SMTP but to the
content

Ted Hardie: Is this needed when ML is currently widely used for this
sort of thing? Also have concerns that people may "lie" and make
inconsistencies with visible data.
HJ: AI methods should be complemented with structured data. Re "lying",
already have potential for inconsistency between representation in
different MIME types.
Ted: Concerned about when machine-readable info is inconsistent with
what is shown to user.
Alexey: Already have that problem with multipart/ alternative
Bron: Same with calendar events.

ISP experiences with schema.org in email

Conny Junghans

• Status Quo
  ** more and more B2C communication, mostly machine-generated
  ** Mix of ML and schema.org. Strustured data eliminates
  uncertainty of ML, gives control of interpretation to senders
• Adoption hurdles
  ** Senders need to know about structured data and need incentive
  ** Documentation and testing
  ** Mail security - needs not to be exploitable by spammers

Barry: original plan of HTML in browser was to allow the email client to
display, but senders wanted more control over that.
Conny: Sometimes user has different preferences than sender.
Wes Hardaker: Looks useful, but there's a tussle between content
creators and display over how things are presented, e.g. non-use of
basic auth.
Q Misell: Explicit allowlist of senders won't scale adequately. Spam
classification is problematic.
Mike Bishop: re sender control of display, this couldvallow sender to
control the preview better.
Bron Gondwana: Non-use of basic auth isn't because of branding, it's a
bad user experience. Could use address book to determine if structured
data is used.

pEp use cases

Hernani Marques

• Background
  ** pEp is trying to support use of encryption
  ** Most users are unable to use, e.g., GnuPG
  ** Need automation to fix this

• Attached public key
  ** Confusion about attachments that can't be opened if client
  isn't OpenPGP-aware

• pEp KeySync
  ** See draft-pep-keysync
  ** Multiple devices per user, need to sync private keys

• pEp KeyReset
  ** See draft-pep-keyreset
  ** relevant for Zero Trust

• Summary: Need to instruct MUAs
  ** not to render certain parts
  ** Not to render certain mails

Mike Bishop: These are good problems to solve but seem disjoint from
what was discussed before
Joris Baum: Keys optimization protocol: can this address the trust
problem mentioned earlier?
Hernani: (describes process for verified public keys)
HJ: Many things share these problems, e.g., calendars
Hernani: Also want to synchronize contact information as well as private
keys.

Issues for standardization

Hans-Joerg Happel

• Suggested standardization work
  ** Focus on "schema.org for email"
  ** Compatibility with existing implentations
  ** Later: Sending structured email by users, discovery, dynamic
  email

• Schema.org for mail standardization issues

• Partial vs full representation
• Structured data formats
• Structured data vocabulary
• Relating structured data to message content
• Allowing clients to hide emails and body parts
• Addressing multiple MUAs
• Message updates
  ** More general problem, not just for structured messages
• Responding to actions
• Data extraction

Wes Hardaker: Lots of things to standardize. If we were to form a WG,
how do we prioritize things for the charter?
dkg: What's the testing process for new proposals? We will need to do a
lot of interop testing with a bunch of different MUAs.
HJ: Might also need to consider rendering in different regions. Start
with different open source implementations, e.g., KDE. Remember IETF is
not mainly focused on user experience.
dkg: It may not be what IETF does traditionally, but need to consider
testing.
Vittorio Bertola: I'm an MUA vendor, and this is interesting. Maybe work
through M3AAWG and similar organizations.
HG: There's also a WG in M3AAWG on dynamic email content.

Barry: Is everyone clear on this?

Klensin: Some things stated as fact were in fact controversial. I'm not
"clear".
Alexey: More generic question: Is there something that people want to
work on?
Christopher Inacio: List of problems was huge, what we would work on
seems like boiling the ocean.
dkg: Most interesting pieces include preferred format,
meta-consideration. Charter should focus on that and one particular use
case initially.
Alexey: Might start by writing some drafts to have more concrete
examples to discuss.
dkg: Multiple formats are a problem. We should specify "one good way" to
do things to maximize interoperability.
dkg: Would like to see a concrete charter for a new working group,
before the next IETF.
Ted Hardie: Somewhat agree with DKG, because we need to define a scope.

Barry: So working-group forming BOF in San Francisco
Klensin: Need that charter 6 weeks out from SF
Wes: All WG forming BOFs need a proposed charter. Longer timeslot to
discuss charter in SF.
Q Misell: A good problem has been identified.