SML Agenda

IETF 121 [hybrid] Dublin

Wednesday, November 6th, 2024
15:00 (UTC)
1.5 hours

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

Chair: Alexey Melnikov & Arnt Gulbrandsen

Notes Taker: dkg

Vacation Notices (HaJo)

• include time zones?

  • Neil Jenkins: why not just force UTC?
  • Ben Bucksch: just do date, don't bother with times at all. it's
    a vacation notice. If you include times, just use UTC, time
    zones are too complicated.
  • dkg: please include the timezones, it is a disaster if you leave
    it up to the users (recipients) to guess it.
  • John Klensin: if it's just dates, fine. but if you're going to
    do time, do it right: use timezones.

• Replacement person

  • Joris Baum: most people want the JSON-LD format. make vCard
    optional?
  • Ben: agree with Joris; and, replacement with a team (and not an
    individual) is a real thing

• Multiple periods of absence

  • room offered a collective "meh" (lack of interest)

• Vacation notices for services

  • dkg: if we're talking about proactive vacation notices as a
    note, then we need to re-address the previous topic
  • Alexey: DKG, you convinced me that we need multiple periods of
    absence. The draft already proposes how to do this (a JSON array
    instead of a single object)
  • Jim: are we imagining a dedicated e-mail address like
    hours@restaurant.com that would send you information about
    opening time?
  • Pete: as Klensin says: if you open this up to proactive notices,
    you're basically in a calendaring system.
  • dkg: you'll also want a replacement mechanism, if you have
    proactive notices
    • Hans-Jörg: replacement is covered by the main draft

Structured Email (HaJo)

• Full representation: where in the MIME tree should the other part
  live?

  • dkg: we need data to answer whether this (inclusion of JSON-LD
    body part as the last part of multipart/alternative) is
    dangerous for legacy clients. How can we get that data in a
    stable way?
  • Ben: we need to test in the existing clients, but it's very
    expensive to test that in an automated way. Manual testing might
    be what we need.
  • Steve Atkins: there are services that will give you those
    screenshots
  • Pete Resnick: we need to do regular testing in Gmail and
    Outlook, and other major MUAs that might affect large numbers of
    users, even if they don't show up in the room.
  • Alexey: even if the clients are broken in handling of
    multipart/alternative as specified, we should encourage fixing
    them, not just change what we do.
  • (some discussion from the chat about what the broken MUAs were)
  • Arnt Gulbrandsen: I need that infrastructure in my day job. If
    the infrastructure is there, i'd be happy to use it. I'll see
    whether i can allocate resources toward that.
  • Ben: Even if some clients are broken, I am in favor of sticking
    to the strictly defined multipart/alternative spec.

• Partial representation: is multipart/related OK?

  • Pete: If we're dealing with a JSON-LD part that is replacing
    something like an image in multipart/related, "logically" the
    right way to do that is multipart/related, with one part that is
    multipart/alternative, with the JSON-LD in it.
    and then from the multipart/related part, point to the CID that
    you care about.
    But if you want it to work, just use multipart/related, throw in
    the JSON-LD as a part, and depend on some other code to find the
    right part.
  • Joris: The simply case is the HTML part actually pointing to the
    JSON-LD part directly.
  • Pete: Then normal multipart/related is fine; legacy clients will
    just show the JSON-LD part as an attachment.
    You can use Content-Disposition: inline if you want, but it
    might not have an effect on legacy clients.
    • Arnt: if the MUAs didn't break on (some historic google
      change), then we're not going to break them further

• Non-representation case: can we use multipart/related, or should we
  use multipart/mixed

  • Phillip Tao: do we really need the non-representation case?
    For full representation case: is it possible that clients won't
    render it at all?
    • Hans-Jörg: this is a good question about what people can or
      can't do.
    • Ben: if i'm updating a previous vacation notice that I sent,
      I don't want to spam you with those updates
      let's try to avoid multipart/mixed because recipients are
      confused by attachments that they don't expect or care
      about.
    • Alexey: yes, you can hide messages. Some clients already
      hide DSNs and MDNs, and display that information elsewhere
      in their UIs

• Referencing structured data in text/html: backward or forward
  references?

  • Arnt: where did you get the example from?

    • HaJo: from an e-mail where this was a link to the web.

  • dkg: why not just use a content-id?

    • HaJo: there might be more than one element in the JSON-LD
      part

  • John Levine: use a content-id with a fragment to identify the
    sub-element in the JSON-LD part.

  • This seems to satisfy anyone, with details to be worked out on
    the list.

Use Cases (Ben)

• any other use cases inspired by this discussion?

• any questions?

  • dkg: these are very different from each other, and there are
    security concerns with a bunch of the use cases. inspiring, but
    challenging to get the whole distributed ecosystem to move in
    this direction.

    • Ben: we're going to need to coordinate the semantics.

  • John Klensin: security concerns++. is the current model of
    e-mail on the internet the appropriate transport for this? how
    can we validate message originator, for example? Just saying
    "user has to agree" sounds like we could make it easy for a user
    to make a dangerous mistake.

    • Ben: the WG document on trust/security considerations is
      intended to address this.