More Instant Messaging Interoperability
charter-ietf-mimi-01

[Ballot comment]
A very much needed interoperation between IM systems! So, I can only applaud the effort. The charter is really easy to read, may I add some comments below:

"assuming the use of MLS for key establishment." is a little ambiguous, is it in all individual participating IMs or only between IMs ?

Perhaps due to the Belgian sensitivity about "federation" ("fédération" in French means that there is still an overarching authority), and I appreciate that the terms "federated identities" are commonly used, is there any better term ? ("conglomerate" sounds negative ;-) ). Feel free to ignore this Belgian/French comment.

Again my French is probably hitting, should "Express and implied user preferences" be replaced by "Expressed/explicit and implied user preferences" ?

I am afraid that in 2023, there are more than "plain text" (suggest to add media) in "including plain and rich text"

I like the concept of "extensible baseline" (is it an oxymoron? ;-) ), but let's keep it: this is a moving target and every human being starts by crawling before walking and running.

Should there be a "1:n" between "both 1:1 and multiparty messaging" ?

[Ballot comment]
# GEN AD review of charter-ietf-mimi-00-02

CC @larseggert

## Comments

### Chair

Will there be a second chair?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Added charter milestone "WG adoption of requirements document for messaging interoperability (decision about whether to forward to IESG for publication to be made later, by WG consensus)", due March 2023

[Ballot comment]
Balloting yes because I would really like this WG to succeed :-)

Some other minor comments/questions:

I didn't quite follow "Express and implied user preferences ... ".  Possibly clearer as "Explicit and implied user preferences ...", if that is what is meant?

Given the WG has to recharter to work on audio/video then is " The working group will not standardize new audio/video signaling or media protocols but may recommend the use of existing protocols and suites such as SIP and WebRTC." needed in the current charter text at all?

"Oracle or look-up services that reveal the list of messaging services associated with a given user identity without the user's permission.".  It wasn't entirely clear to me whether oracle/look-up services that reveal services only with explicit user consent are in scope, or no oracle services are in scope.

Thanks,
Rob

[Ballot comment]
I have two comments/questions -

1. it says -
          In a future phase, the working group may recharter to
work on audio and video. The working group will not standardize new audio/video
signaling or media protocols but may recommend the use of existing protocols
and suites such as SIP and WebRTC.

  If a rechartering is needed to work with AV then why in this charter we are scoping the future work?

2. why do we have two different way to express when the group needed to be rechartered? actually what is the intended separation between rechartering needed vs out of scope?

[Ballot comment]
Thanks for a very readable and instructive charter.

Like Lars, I wonder why there are both a 'out of scope' and a 'need to recharter' lists.

The unusual length of the charter makes me wonder whether there is really a core of interested MIMI participants to work on something real; i.e., the charter looks more like a diplomatic compromise among opposing parties, so not a good sign for a team work. But, I am trusting the shepherding AD on this topic.

Regards

[Ballot comment]
Note that I am still unsure if the existing messenger solutions _want_ to interop. The lesson from XMPP was that at first, entities wanted to interop to gain market share. But upon reaching this, XMPP/interoperability would get dropped.

[Ballot comment]
# GEN AD review of charter-ietf-mimi-00-01

CC @larseggert

## Comments

### Paragraph 5
```
  Modern messaging services commonly support numerous features including plain
  and rich text, delivery notifications, read receipts, replies, reactions,
  presence, and many more. The working group will identify a baseline set of
  messaging features and specify a content format to allow this feature set to be
  implemented interoperably. This format must be usable in the presence of E2EE.
  In defining the format, the working group will seek to reuse existing
  primitives (especially existing semantics) including previously defined message
  headers, MIME types, and URIs where practical.
```
Is this baseline set supposed to be extended over time? If yes, it
would be good to say so here, so that the mechanisms the group will
develop can easily support extensions.

### "A", paragraph 3
```
  A recharter would be required should the working group decide to work on:

  * Metadata processing to manage spam and abuse

  * Interoperable mechanisms for group administration or moderation across systems

  The following are out of scope for the working group:
```
I don't understand why these two items are specifically called out
as "a recharter would be required" rather than simply listing them
into the "out of sopee list", the items in which can also become work
items after a recharter.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Paragraph 0
```
- both consumer and enterprise to interoperate without undermining the security
+ both consumers and enterprises to interoperate without undermining the security
+              +              +
```

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool