# SML @ IETF 116 {#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 {#admin} Note well, etc. presented by Barry ## Background and Problem Statement {#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 {#isp-experiences-with-schemaorg-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 {#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 {#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.