# SML @ IETF 118 {#sml--ietf-118} Monday, November 6th, 2023 15:30 (Prague, UTC+1)/14:30 (UTC) 1.5 hours Meetecho: https://meetings.conf.meetecho.com/ietf118/?group=sml&short=&item=1 Notes: https://notes.ietf.org/notes-ietf-118-sml Chairs: Alexey Melnikov Bernie Hoeneisen: Delegate/helping with running the session Note takers: Joris Baum ## 15:30 Administrivia {#1530---administrivia} * Alexey presents the Note Well and Note ReallyWell * Asked people to join meetecho * presents agenda * Reminds room to keep charter in mind * (Note taker will try to note things said but not in slides) ## 15:35 Structured vacation notices {#1535---structured-vacation-notices} * Hans-Jörg presenting * https://datatracker.ietf.org/doc/slides-118-sml-structured-vacation-notices/ * "machine-readable" version of e-mail * "Out of Office" (OOF) mail are typically hand-written * Auto-processing would be beneficial * Michael richardson: * There are very useful privacy-immune use cases. * Draft is really useful and a good example use case. * Phillip Tao: * Interesting use case for future SML use cases * Other use cases trigger fully automated use cases on responder side * Attaching the structured OOF information to an outgoing e-mail is unusual and debatable * Chair: This is good for a future dicussion on draft specifics * Pete Resnick: * Passing object to clients is useful * Ben Bucksch: * Good use case, especially for parsing a lot of OOF replies ## 15:48 Structured Email: Use cases {#1548---structured-email-use-cases} * Hans-Jörg presenting * https://datatracker.ietf.org/doc/slides-118-sml-structured-email-use-cases/ * Sharing is typically done by instant messaging nowadays - could be done by e-mail as well * Transactional use cases: Goal is to improve UX * E-mail specific use cases: ActivityPub already has "like" and "follow" * Phillip Tao: * Wonderes about which use case should be adopted as the "reference draft" * OOF might be more complex than simpler use-cases like reactions * John Levine: * It is OK. * It is a good idea to minimalize quantity of user interactions with e-mail. Make fewer, higher-quality interactions. * Jim Fenton: * Strongly agrees with John. * Concerned about security considerations. Will be discussed later in the session. * Chair: Ready for adoption (not asking about publication)? * Please voice objections * Neil: Having a document on use-cases might not be very useful in the end * Chair: Indeed, the WG is not obligated to publish this document as an RFC once it is adopted. * Chair: (After informal poll about document readiness for adoption) Let us start adoption call! ## 16:02 Structured Email {#1602---structured-email} * Chair: Let's have questions after each open issue * Hans-Jörg presenting * https://datatracker.ietf.org/doc/slides-118-sml-structured-email/ * Representation (JSON, XML, etc) - Having both representations might be beneficial for some software * Jakub Olexa: * Recommend using RDF-XML as some services might block JSON * Microdata is also much more complicated than JSON-LD * Vocabularies - * Neil Jenkins: Scope needs to be narrowed down to make it interoperable * Hans-Jörg: Use cases are not meant to be understood as instructive. Like MIME attachments * Michael Richardson: Do not understand Banking example. -> Automatically importing some Banking data into other systems might be a good use case. * Placement - How to represent and orthogonally how to convey data * Pete Resnick: * non-representation (e.g. including OOF data before going on vacation) is not part of the info on the slide * Neil Jenkins: * Existing usage might be difficult to change * Ben Bucksch: * Multipart/alternative is a good idea for full representation * For partial representation - it is important to associate which part of the e-mail is represented by the structured data - multipart/alternative is not a good solution for this as it is a problem for clients without auto-processing. * Bernie Hoeneisen: This is more of a case for non-representation * HTML "script" tag is associated with executable code -> try to avoid it * Identifiers - * Jakub Olexa: * machine-readable information with Personally Identifyable Information (PII) should be banned as it might violate GDPR and open the door for spammers etc. * Bron Gondwana: * Bad people already misuse PII with regular expressions * It is better to make its semantic - easier processing for all * Chair: Ready for adoption (not asking about publication)? * Chair: Let us start the adoption call! ## 16:27 Email Marker to Indicate Automatic Processing {#1627---email-marker-to-indicate-automatic-processing} * Bernie Hoeneisen presenting * https://datatracker.ietf.org/doc/slides-118-sml-auto-processing-markers/ * Phillip Tao: * Should it be included in the base draft instead of split out? * I would vote for having some kind of marker at the message level. * Chair: We can decide in the working group whether or not this is a part of the main document or separate * John Levine: * I would like to hear more from mail systems who like to implement this. So we know what is worth doing. * Bernie (presenting): * Yes, requirements could be more clear. ## 16:37 Structured Email: Trust and security considerations {#1637---structured-email-trust-and-security-considerations} * Hans-Jörg presenting: * https://datatracker.ietf.org/doc/slides-118-sml-structured-email-trust-and-security-considerations/ * Status Quo - clients will only process structured data for white-listed senders * Guidelines - Right now we are still building the scope of things * Jim Fenton * We do not want people to use DKIM for things that require higher level of trust other than "is this message likely from them?" * trust is also a personal thing. * Attribution needs to be done properly * Ben Buksch * It is important to frame trust discussion? * 1 - what do clients need to consider? * 2 - what do senders need to consider? * 3 - what do standards have to consider? * Proposes to make three sections of the document out of this. One for each target group * Hans-Jörg: * Good idea to structure it that way * It is unclear whether combining or splitting is better * Ben Buksch: * For clients, trusted senders are not useful * "Trusted senders" are typically for not sending out data/notifications * John Levine: * Agree with everybody * Decades of experience that it won't scale * Proposes to make big list of scenarios to pin down aspects of the trust problem * Phillip Tao: * It may be a good idea to reduce the scope as some use cases need more trust than others * Neil Jenkins: * Agrees with Phillip - it should be up to the service to determine trust * Simple use cases do not require extra trust * Hans-Jörg: * Already has one co-author * Chair: Ready for adoption? * Chair: Undecided (5 "yes" and 5 "no"). Take it to the mailing list! ## 17:00 Flextime {#1700----flextime} * Looking for co-chair! * Also looking for a new chair from March 2024! * Will discuss plans related to the online interim meeting on the mailing list