ietf-wg-mimi's People
ietf-wg-mimi's Issues
Identifier vs. identity
Ensure consistent use of "identifier" vs. "identity" throughout the charter text.
Where is other informational RFC or Standard RFC md files for contributions?
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?
Add all relevant Internet-Drafts to charter
ITNOA
I think it is good to add relevant all Internet-Drafts to charter for better organization of works.
OAuth is being superceded by GNAP
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?
Extensibility of messaging features
@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.
Scoping future A/V work
@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?
Requires recharter vs. out of scope
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.
Goals for security and privacy
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..."
Application vs Service
HTA raised that we use Service and Application and we should probably just use Service.
Need to specify that presence is (in scope / out of scope)
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.
Introduction problem text in charter can be read too broadly
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.
Terms "service" and "application" seem to be used interchangeably
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.
Why XMPP does not meet requirements for interoperability?
ITNOA
regardless of transport layer and secure layer (such as MLS or ...) my question is, Why XMPP does not meet requirements for interoperability?
thanks
Why Matrix Message Transport RFC does not relate to this document?
ITNOA
Why some RFC like Matrix Message Transport does not added to related documents in BoF?
clarity and importance of mitigations against spam, harassment and abuse
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.