MIMI WG, IETF 116 Yokohama, 2023-03-30
Pete Resnick and Ben Campbell scribing
https://datatracker.ietf.org/meeting/116/materials/agenda-116-mimi-03
The Note Well was noted well.
The agenda was bashed (with much silence)
Chairs present a view of "building blocks" of the work being done.
Roadmap with prioritization proposed ( not strict ordering)
Room is silently OK with the plan
https://www.ietf.org/archive/id/draft-mahy-mimi-content-02.html
Issues that were on the list:
Jonathan Rosenberg [JDR]: Prefer to have them in the message because
the information is going to be used elsewhere. Better to have it
self-contained. No harm to have it there.
Daniel Gillmore [DKG]: I'm concerned about having them. But having
them optional is worse. Need to make sure that the information is
consistent between layers.
Eric Rescola [EKR] (pretending to be DKG): There's no valid use for
these in the message, and I share the concern that there could be
conflicting data.
Rohan: Group ID is the thing that is integrity protected. What you store
might be something else that maps to the Group ID. E.g. Friend name or
other local thing.
Raphael Robert: Agree with EKR and DKG. The thing that you are using
must be in MLS.
Rohan: Sender might be pseudononymous for privacy reasons.
Harald Alverstrand: It is possible to store the MLS values, because
they're known to the sender beforehand.
Suhas Nandakumar: (Satisfied that the information is appropriately
protected.)
Martin Dürst: For forwarding and similar operations where you imbed a
message in another, you need this information.
Rohan: By value or reference?
Richard Barnes: MLS can authenticate multiple identifiers. In favor of
including info.
Cullen Jennings: I think this is too low level a detail to worry about
now. Data will probably be copied, for example in message history.
Request to address this on the list if there are concerns.
Eric Rescorla: I think this is a bad idea. Prefers to specify explicit
ordering. Would only do inReplyTo, not threads, let receiving system
figure out how to render.
Rohan: Prefers not to use inReplyTo for threads.
DKG: I haven't been following closely. Trying to understand the
semantics of threading. Is ancestor ID in thread? (yes). If a message in
thread becomes an ancestor to another thread, what happens. Confusing,
not sure how to render to user.
Travis Ralston: Agrees threads and replies are different. Need replies
in thread for larger conversations.
Jonathan Rosenberg: Threads and replies are different. Defying user
expectations is bad. Cross-system threads e.g.. Need to have both
concepts.
Bron Gondwana: This is different than the email model of InReplyTo.
Cullen Jennings: We should provide just enough semantics so that we can
map into the different clients, but not cause clients to provide
different experiences.
Rohan summarizes: A number of people agree that replies are different
from email and for threading. Threading is underspecced and needs more
work. Reasonable summary?
Some folks agree, some unsure.
Question on reports on multiple messages deferred to list.
Next steps: Is this a reasonable start for semantics?
Vittorio Bertola: Comment on earlier issue regarding message editing.
Think it's a mess. Rohan suggests taking it to the list.
DKG: No authorization control for editing messages. You just need to
know message ID. UA needs to decide how to authorize. Draft is
agnostic--this is fine, should not pretend to specificy authorization
here.
Chairs: Show of Hands for adoption. Lots of support, One objection, but
nobody wanting to speak to it. Will confirm on the list, but looks like
we will adopt.
Harald: Process? Email or Github? Rohan + chairs: Both are fine, but
please bring substantive changes to email.
https://datatracker.ietf.org/meeting/116/materials/slides-116-mimi-matrix-for-mimi
https://datatracker.ietf.org/doc/draft-ralston-mimi-matrix-framework/
https://datatracker.ietf.org/doc/draft-ralston-mimi-linearized-matrix/
Matthew describes Matrix and how it maps to MIMI.
No clariying questions. Will defer other discussion to later.
https://datatracker.ietf.org/meeting/116/materials/slides-116-mimi-mimi-transport-protocol-mtp
https://datatracker.ietf.org/doc/draft-rosenberg-mimi-protocol
Jonathan explains that the draft makes a series of strawman design
decisions
DKG: Is this message id the same as Rohan's? JDR: This one has to be
different. DKG: Please use a different term.
EKR: Not desirable to have both timestamps and message ids for
synchronization. A hash would give you uniqueness. Get rid of timestamps
and use hash. JDR: Good point. Just needs to be unique and increasing.
EKR: Sync might still be tricky.
Rohan: Cooperative validating is hard with encryption. Client needs to
check consistency between inner thing and outer thing.
DKG: [missed comment. Seemed to be related to differentiating the inner
and outer thing?]
https://datatracker.ietf.org/meeting/116/materials/slides-116-mimi-mimi-delivery-service
https://datatracker.ietf.org/doc/draft-robert-mimi-delivery-service
Raphael describes the minimal/simplest delivery service
Mallory Knodel: Owner of delivery service locks in users. Migration
ability is needed for consumer services. Raphael: The only requirement
is that the service decide in real-time. You could migrate so long as
there is agreement in real-time. All that would be needed is an
extension for moving to a new service. Mallory: May need to allow one of
them to move. Raphael: Need to look at edge cases, but yes, sounds like
this can be done.
https://datatracker.ietf.org/meeting/116/materials/slides-116-mimi-mimi-transport-requirements
EKR is not trying to prescribe outcome. Just discussion points.
EKR time travels to last November.
Q1: How much are we defining? Is client <-> server in scope?
Raphael: I don't disagree with no client-server per se, but it's more
nuanced. The open question is how does the delivery service fit it? We
might need to have protocol from client to target service.
Vittoria: I think we might want a standard protocol client-server, but
not require it.
DKG: This WG is more than what you're asking here. Just scoping this
talk.
JDR: Disagree with Raphael. I think this is strictly server-server; the
entirety defines the delivery service.
Travis Ralson: Client-server out of scope.
Martin: Chat consistency might not be necessary. Ekr: encrypted content
would break.
Suhas: This should be s2s only. Timeliness of deliverables, and should
put e2e in the right place.
Rohan: Most people still don't understand that delivery service is
abstract, and some of those pieces are going to be on the client and
have client implications. We need to be clear about how we describe this
to avoid bad implementation assumptions.
Britta Hale: there are distributed settings where pure s2s management
will not work. EKR: I think that's out of scope. Britta: Disagree. There
might be temporary situations where you don't have access to servers.
Joel (AWS): Ability to have client connect directly to the owning server
has advantages. I think we should consider that. EKR: All of the
proposals I've seen have been federated, so if we want to do that, we
probably need a proposal.
Matthew: +1 to others. Also, need to remember the user semantics and
consider the presentation layer.
Chairs: If there are non s2s proposals, please take concepts to list.
Q2: Do we need to support discovery?
Matthew: I (unfortunately) think it's going to be important to provide
discovery.
EKR: I really want to do that work, but I think it's hard and maybe for
round 2.
JDR: If we only support SSIs, the outcome is going to be probably
unusable.
Joris Baum: is feature discovery in scope? Ekr: For this work but not
this layer.
Jon Peterson: I think the discovery problem is interesting: Just knowing
an SSI still might not get you everything you need. These might be
decoupleable, but we're going to need discovery to make this workable.
Chair: Sense that we landed on "Solve for SSI and plan on doing
discovery eventually."
Q3: Is consent required? What modes do we support?
Raphael: MLS can do immediate. But we need consent mechanism. Not clear
whether we want it to be a policy thing or an actual delivery thing.
Cullen: Current systems sometimes tie this to something "a little
expensive". I think to have a viable solution we're going to have to dig
into the requirements.
JDR: I was originally on consent only, but Alissa changed my mind: If
it's unacceptable to the gatekeepers, we're done. We therefore should
allow the protocol to allow variablity.
Rohan: If we implement the full consent model, can we change later? EKR:
I think we can.
Travis: The quarantine mode is probably the one we want to shoot for.
EKR: Any mechanism that allows immediate messages possibly leaks info,
so that might tie in privacy.
DKG: This is going to need to be negotiated; just one model won't work.
Also, consent could be revoked.
Jon: This is probably going to need a design document to sort this.
Harald: The question is at the wrong level. The receiver needs to
evaluate the local rules, and might need to ask the network for help to
block. Policy is not part of transport protocol.
Pete Resnick: Depending on scale of some providers, they might want to
help before the receiver asks for help, and block before consent occurs.
Need to put something in at provider level to require certain consent.
Chairs: Out of time, more issues. External deadlines Need to start
discussion threads on list. Kickstart series of virtual interims on
regular cadence, starting in a couple of weeks. Doodle on list for
timeslot.
Ekr: Not a big fan of bi-weekly. Maybe interims less often?
Chairs: Need process for agreeing on semi-stable draft versions as
interop targets. Maybe regular deadlines for PRs. Asks for input.
Discussion of whether we use github issues for discussion. Easier to
have discussions on list in pre-doc phase.