Skip to main content

Minutes IETF119: sml: Fri 03:00
minutes-119-sml-202403220300-00

Meeting Minutes Structured Email (sml) WG
Date and time 2024-03-22 03:00
Title Minutes IETF119: sml: Fri 03:00
State Active
Other versions markdown
Last updated 2024-04-08

minutes-119-sml-202403220300-00

SML Agenda

IETF 119 [hybrid] Brisbane

Friday, March 22nd, 2024
13:00 (Brisbane, UTC +10)/03:00 (UTC)
1.5 hours

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

Chair: Alexey Melnikov

Notes Taker: Pete Resnick

Agenda

  • Administrivia - Chair

    • Announcement that Arnt will be co-chairing
  • Structured vacation notices - Hans-Jörg Happel

    • Discussion

      • Pete Resnick: Adoption seems fine. Not clear about the
        layers, but: Seems like a vacation notice should look like
        (or be) a jcal/ical object and the "replacement person"
        should be a jcard/vcard. HJ: Understood, but be clear on
        distinction between structured data
      • Jim Fenton: Yes, adopt. FYI: Outlook has finer grain than
        date. Also has info about sensitivity (who gets it, maybe
        more info for domain internal receipients)
      • Vittorio Bertola: Yes, adopt. Privacy considerations on this
        (and all SML stuff). Maybe need to have privacy
        considerations across all of these.
      • Ken Murchison: Yes, adopt. Similar thoughts to Pete on
        jcal/ical
    • Chair checks support for adoption. 8 yes, 0 no, 1 no opinion.

Action: chairs to start adoption call for Structured Vacation Notices
draft.

  • Structured Email: Use cases - Hans-Jörg Happel

    • Discussion

      • Michael Richardson: Clarification point that Expires header
        needs to richer.
      • Pete Resnick: Security and privacy considerations very
        important in this document. Also, think about how to
        describe how we decide on semantics for these kinds of
        things (e.g., "copy to clipboard" or "confirmation code")
      • Daniel Kahn Gillmore: Should not have trust and security in
        a separate document. It belongs in (or close to) each
        scenario and/or as a part of the core spec.
  • Structured Email - Hans-Jörg Happel

    • The current list of open issues:
      https://github.com/hhappel/draft-happel-structured-email/issues/
    • Discussion

      • Jim Fenton: Tracking links are examples of where text is a
        subset of the structured data. Might need mechanisms for the
        receiver of the mail to accept or reject certain kinds of
        structured objects.
      • Alexey Melnikov: This is an orthogonal issue to what is on
        the slide, but you have a good point.
      • Alexey Melnikov: For the cross reference between HTML
        fragment and a structured data, can any URI type be used?
        I.e. not just https://, as they can be inadvertantly
        accessed by MUAs.
      • Pete Resnick: I don't think the "reference hint" is worth
        doing. If the user wants it inline, they'll do it and use
        the cid: method. If not, there are too many dangers for the
        implementation trying to "help"
      • Daniel Kahn Gillmore: I don't understand the use case of the
        reference hint. Don't think this will be useful.
      • Alexey Melnikov: Regarding forwarding, it's might be the
        case that we just need security/privacy considerations. In
        particular legacy MUAs will not know to strip some
        structured data.
      • Daniel Kahn Gillmore: We have this problem today with
        mailing lists; this is a generic problem. I don't think this
        is specific to SML. We should try to solve it generally (if
        we want to try to solve it)
      • Pete Resnick: Not something we should solve in this
        document. General approach is "forward if inline, don't if
        attachement", and beyond that it's going to be case by case.
      • Alexey Melnikov: MDN request handling is similar with regard
        to the reply status issue, i.e. we defined $MDNSent IMAP
        keyword that is set atomically, so that only one MUA
        performs MDN requested action. We can figure this out. (Also
        explains that the "$ flag is just an IMAP convention")
      • Daniel Kahn Gillmore: That we go into IMAP flags and the
        like, I'm worried about scope creep. Things like IMAP flags
        leaks data to the server.
      • Pete Resnick: Agree with DKG. Make sure to separate
        semantics of SML from other kinds of processing (e.g., Sieve
        scripts)
      • Alexey Melnikov: if we need to define a Sieve action, we can
        do this. If outside our charter, we can figure out where to
        do it.
  • Structured Email: Trust and security considerations - Hans-Jörg
    Happel

    Didn't get to this.

Chair announces that we are looking for editors and possible chairs.
Will do adoption calls on the list.