Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[Holger Weiß]

* Georg Lukas  [2021-09-07 17:22]:
Furthermore, I'm not sure if messages received by a client from 
offline history are supposed to contain the respective MAM-ID, so 
deduplicating here might be very adventurous, as the same message 
might arrive from offline history without a MAM ID and from MAM with 
a MAM ID, and the @id attribute might not be unique.


I'm not sure how implementations other than prosody handle this, but I'd
love to see MAM servers to also inject MAM-IDs into offline messages,
and have that explicitly written in 0313.


I would've assumed offline messages to be already covered by the 
following guarantee, just like regular live messages:


When a message is archived, the server MUST add an  element 
as defined in Unique and Stable Stanza IDs (XEP-0359) to the message, 
which informs the recipient of where and under what ID the message is 
stored.


[ https://xmpp.org/extensions/xep-0313.html#archives_id ]

Holger
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[Kevin Smith]

On 7 Sep 2021, at 16:22, Georg Lukas  wrote:
>> §6.1.1: the business rules for user archives are inadequate:
>> 
>> MUC messages in user archive: I think that implementation practice has
>> clearly shown that storing MUC messages in the user archive is a Bad
>> Idea, and nobody is doing it anyway. Also the server is probably not in
>> a position to track a user's MUC activity and query all MUCs for whether
>> they implement some sort of message storage. This part should be
>> converted into "SHOULD NOT" or "MUST NOT".
> 
> After some discussion it was suggested to change the scope of this from
> "should not store" to "should not return by default", which is also fine
> with me.

At the risk of repeating myself, I think that storing groupchat messages in the 
user archives is helpful, and people do this in the wild.

So if there *was* somehow agreement for forbidding it, it would need a 
namespace bump, because it used to be allowed (and, indeed, recommended).

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Stable is the new Draft

[Peter Saint-Andre]

On 8/31/21 9:41 AM, Jonas Schäfer wrote:

> The term "Draft" for our non-Final but also non-Experimental standards has 
> been adopted from our "mother" organization, the Internet Engineering Task 
> Force. The IETF has since abandoned that term.

In fact, the IETF moved from a three-stage track to a two-stage track:

https://datatracker.ietf.org/doc/rfc6410/

This would be the equivalent of removing the "Stable" state entirely.

That said, I'm in favor of the renaming.

Peter

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[Georg Lukas]

Hello everyone,

given that XEP-0313 is up for recall in tomorrow's Council meeting, I'd
like to sort my long list of issues into blocking and non-blocking.
Fixing the blocking ones is a requirement for me to change my vote to
something different than -1.

Two blocking (non-Editorial) issues:

* Georg Lukas  [2021-03-31 18:50]:
> Time and again, specifications that use Message Forwarding have
> fallen victim to impersonation attacks (there is a number of CVEs
> around, like CVE-2017-5589, CVE-2019-16235, and CVE-2020-26547).
> 
> The XEP urgently needs a respective section in the Security
> Considerations, and ideally also a negative example like
> https://xmpp.org/extensions/xep-0280.html#example-11

I'd also copy a bunch of  elements from XEP-0280, in
addition to the above text.

> §6.1.1: the business rules for user archives are inadequate:
> 
> MUC messages in user archive: I think that implementation practice has
> clearly shown that storing MUC messages in the user archive is a Bad
> Idea, and nobody is doing it anyway. Also the server is probably not in
> a position to track a user's MUC activity and query all MUCs for whether
> they implement some sort of message storage. This part should be
> converted into "SHOULD NOT" or "MUST NOT".

After some discussion it was suggested to change the scope of this from
"should not store" to "should not return by default", which is also fine
with me.


One probably-non-blocking can-of-worms issue:
> Furthermore, I'm not sure if messages received by a client from offline
> history are supposed to contain the respective MAM-ID, so deduplicating
> here might be very adventurous, as the same message might arrive from
> offline history without a MAM ID and from MAM with a MAM ID, and the @id
> attribute might not be unique.

I'm not sure how implementations other than prosody handle this, but I'd
love to see MAM servers to also inject MAM-IDs into offline messages,
and have that explicitly written in 0313.


Non-blocking issues:
> Storage rules: those look very much like the original ones from the
> initial specification, and I think we have learned much since then.
> 
> Prosody will store "normal" messages with a body, or "chat"
> messages that are not empty after stripped. By default, it will strip
> chat states, but it will count origin-id or  as elements that are
> worth of storing.
> 
> Part of the problem is an implementation issue with storing the stripped
> message and not the original  but the
> general problem of clearly defined storage rules remains.
> 
> This XEP needs something like the 0280 Recommended Rules
>  but it
> should be part of the XEP and not a later addition guarded by a separate
> namespace. Maybe.
> 
> Also it would be great to persist message errors for sent messages. But
> this is a separate can of worms.
> 
> 
> My comment from the last 0313 LC about letting the client know if the
> MAM preferences are "undefined" yet, so that the client can ask the user
> once, now applies to XEP-0441, so I hope I'll think of bringing it up in
> the respective Last Call again.
> 
> 
> The Business Rules section needs clear guidance to client
> implementations that want to do "full sync", i.e. obtain all messages
> received by the account since the client was last online, without too
> many duplicates.
> 
> This is a complex problem because offline messages might contain
> everything that is also in MAM, or might have been drained by another
> client in the meantime, so that offline messages will only give you the
> end of chat history.
> 
> 
> There is a separate standards@ thread regarding how to treat offline
> history for MAM-enabled clients, but it only solves part of the above
> problem.
> 
> 
> There is no "atomic" switch between fetching messages from MAM and
> receiving live traffic, so a client needs to either remember the last
> locally known MAM ID before sending initial presence, then request MAM
> after that last-known-MAM-ID until it catches up with offline history,
> or until it depletes the MAM archive, duplicating messages between
> offline history and MAM fetching.
> 
> The naive approach of first fetching MAM, then sending initial presence
> causes a subtle race condition for messages that are delivered to your
> account in the brief moment after you completed fetching from MAM.
> 
> There is also a problem if a client crashes during this catch-up phase
> (this is more common on mobile systems than you'd hope), as it needs to
> either persist the last-known-MAM-ID or keep the incoming MAM fetch in
> memory until everything is processed, as otherwise it would populate the
> message database with new MAM-IDs that would be incorrectly considered
> as the new last-known-MAM-ID after a client restart.
> 
> 
> We are still missing a "MAM subscription" mechanism, where a client
> would automatically receive the MAM-ID of all messages it sends, so 

[Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)

[XSF Editor]

This message constitutes notice of a Last Call for comments on
XEP-0459.

Title: XMPP Compliance Suites 2022
Abstract:
This document defines XMPP application categories for different use
cases (Core, Web, IM, and Mobile), and specifies the required XEPs
that client and server software needs to implement for compliance with
the use cases.

URL: https://xmpp.org/extensions/xep-0459.html

This Last Call begins today and shall end at the close of business on
2021-09-21.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?

2. Does the specification solve the problem stated in the introduction
and requirements?

3. Do you plan to implement this specification in your code? If not,
why not?

4. Do you have any security concerns related to this specification?

5. Is the specification accurate and clearly written?

Your feedback is appreciated!
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] UPDATED: XEP-0060 (Publish-Subscribe)

[XSF Editor]

Version 1.22.0 of XEP-0060 (Publish-Subscribe) has been released.

Abstract:
This specification defines an XMPP protocol extension for generic
publish-subscribe functionality. The protocol enables XMPP entities to
create nodes (topics) at a pubsub service and publish information at
those nodes; an event notification (with or without payload) is then
broadcasted to all entities that have subscribed to the node. Pubsub
therefore adheres to the classic Observer design pattern and can serve
as the foundation for a wide variety of applications, including news
feeds, content syndication, rich presence, geolocation, workflow
systems, network management systems, and any other application that
requires event notifications.

Changelog:
Remove exception for last item when purging a node: all items must be
removed. (jp)

URL: https://xmpp.org/extensions/xep-0060.html

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XMPP Council Agenda 2021-09-08

[Jonas Schäfer]

Hi everyone,

The next XMPP Council Meeting will take place on 2021-09-08 at 15:00Z in 
xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and add to the 
discussions.

This agenda is composed from:

- Editor notifications to standards@
- xsf/xeps GitHub PRs marked as Needs Council
- xsf/xeps GitLab MRs marked as Needs Council
- Suggestions directly sent to me (see below)

Agenda as follows:

1) Roll Call

2) Agenda Bashing

* Feel free to pre-bash on-list or directly to me if you think something is 
missing.

3) Editor’s Update

- Last Call for XEP-0459, Compliance Suites 2022

4) Items for voting

4a) PR#1064:  XEP-0227: New revision 1.1
URL: https://github.com/xsf/xeps/pull/1064
List-Archive: https://mail.jabber.org/pipermail/standards/2021-July/
038422.html
We had that one in the past a few times, list discussion has settled down in 
the meantime.

4b) Advance XEP-0313 to Stable as-is
List-Archive: https://mail.jabber.org/pipermail/standards/2021-March/
038252.html
List-Archive: https://mail.jabber.org/pipermail/standards/2021-April/
038292.html

As threatened last week. 

The Last Call had mainly editorial feedback (actual clarifications) and what 
Georg said. I propose we:

- Instruct the Editor to apply the editorial feedback
- Then advance XEP-0313 to Stable.

It is de-facto stable and having the Experimental tag on it doesn't help 
anyone.

5) Pending Votes

None.

6) Date of Next

7) AOB

8) Close

End of Agenda.

Note that I am aiming for 30 minutes, but meetings may be extended as 
necessary if all council members agree.

Meetings are normally held every Wednesday at 15:00 UTC in the
xmpp:coun...@muc.xmpp.org?join chatroom.
Meetings are open, and anyone (XSF Member or not) may attend, though 
only XMPP 
Council members may vote. Relevant comments from the floor are 
welcomed.

Using your web browser, you can join anonymously via
https://xmpp.org/chat?council

Note that conversations in the room are logged publicly at
https://logs.xmpp.org/council/

If you have suggestions for an agenda item, you can message me via XMPP 
or email at this address or at jo...@zombofant.net.

I aim to publish the Agenda on the day before the Council meeting before 
19:00Z.

Stay safe, smart & healthy,
Jonas


signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___