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

• 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

• 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

• 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

• 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

• 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

• 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

• 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