coopdanger / ietf-wg-mimi Goto Github PK

Ensure consistent use of "identifier" vs. "identity" throughout the charter text.

ITNOA

As you know in https://datatracker.ietf.org/doc/bofreq-cooper-more-instant-messaging-interoperability/ you can see some relevant Internet-Drafts for example

Relevant drafts:

• Problem outline:
  https://www.ietf.org/archive/id/draft-mahy-mimi-problem-outline-00.html
• Identity concepts:
  https://www.ietf.org/archive/id/draft-mahy-mimi-identity-00.html
• Content profile:
  https://www.ietf.org/archive/id/draft-mahy-mimi-content-00.html
• Framework for identity mapping:
  https://www.ietf.org/archive/id/draft-rosenberg-dispatch-spin-00.html
• Content negotiation for MLS:
  https://www.ietf.org/archive/id/draft-mahy-mls-content-neg-00.html

My question is where is the md files of these Internet-Drafts?

ITNOA

I think it is good to add relevant all Internet-Drafts to charter for better organization of works.

MIMI will communicate with related working groups as needed, including MLS, STIR, OAUTH, and the W3C Verifiable Credentials WG.
Technology Overlap: MLS, OAUTH, all of ART
Key Participant Conflict: MLS, OAUTH, TLS, OHAI, PPM, SECDISPATCH, PRIVACYPASS, QUIC, ADD, DPRIVE, IABOPEN, RSWG

Why not GNAP?

@larseggert said:

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.

@zaheduzzaman said:

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?

Several ADs commented that there should be no distinction between the list of items that require recharter versus those that are out of scope. I propose that we reduce these down to a single list.

From @beurdouche --

"When reading the proposed charter, I realized that there is currently
very little about security and no mention of privacy at all.

Unfortunately, I won’t be able to join the BOF tomorrow, but I’d be happy
if the WG could consider adding a sentence in the charter stating that
strong security and privacy are an important part of the effort of the WG.

As I mentioned in a previous email, from the design and proof perspectives,
it is much easier to aim at the strongest properties and relax security and
privacy when needed for a certain functionality than to add them in an ad-hoc
manner when missing.

Maybe something like this?
“The working group will aim to achieve the strongest security and privacy
properties possible for each targeted functional requirement”.

Defining these expected security and privacy properties might even be
a good milestone..."

HTA raised that we use Service and Application and we should probably just use Service.

Presence - the idea that some user can have a continuously updated view of the status of another user - is prevalent in messaging systems. Examples include green dots on rosters, "read points" in conversations, "I am typing a response" indications, and "this user has been inactive for X days".

A common feature here is that the user does not need to send a message to the group to maintain the status; it is derived in some other way (such as being driven by the service provider's view of the user's status).

This should be either in scope, out of scope, or carefully circumscribed.

The current text sounds as if the introduction problem is a broad scale, possibly separable problem. It needs to be narrowed to clarify that the scale of the problem to be tackled is only across conforming services.

It is not clear from the charter what is meant by the terms "service" and "application". Some sentences read like they are two names for the same thing, other sentences read like the application is something the end user uses to access the service - meaning that they are different.

Those terms should be defined in the charter before being used, and the text checked to make sure usage is consistent.

ITNOA

regardless of transport layer and secure layer (such as MLS or ...) my question is, Why XMPP does not meet requirements for interoperability?

thanks

ITNOA

Why some RFC like Matrix Message Transport does not added to related documents in BoF?

Hooks to enable mitigations by services and users for spam, harassment and other kinds of abuse are prerequisite to any successful interoperable work here. However, the charter explicitly mentions spam, abuse and moderation only in suggesting that it would require rechartering ("metadata processing to manage spam and abuse" "moderation across systems") or that it's out of scope (development of anti-spam algorithms, which, fine). I'm not sure what "metadata processing" means in this context, but I don't want the group to have to immediately recharter to address one of the largest challenging problems for interoperable federated messaging. Interoperable sending of abuse reports, message franking, blocking and blocklists, etc. seem essential to me and I don't know if they're in scope.

The BoF discussion seemed to make it clear that most expected that spam and abuse would at least be considered, but I don't think the charter needs to introduce more confusion or limits on being able to work on it. These aren't features to postpone.