[Standards] Fwd: XEP-0376 (Pubsub Account Management): some feedbacks

Hello, I'm forwarding this old message, as it has never been answered, and the author (namely Dwd) is more active these days. PAM is very useful in Pubsub toolbox, and I would like to see this specification in a better state :). Thanks! Goffi ---------- Message transmis ---------- Objet : [Standards] XEP-0376 (Pubsub Account Management): some feedbacks Date : vendredi 15 avril 2022, 10:41:49 heure d’été d’Europe centrale De : Goffi <goffi(a)goffi.org> À : standards(a)xmpp.org Hi, I'm currently implementing XEP-0376 both client and service side, and here are my feedbacks. # Form: - a small typo in example 1, it's "xmlns" ("s" is missing) - § 3.3 Unsubscribing: even if it's obvious, an explicit example would be welcome for unsubscribe too - there are a lot of questions on this XEP, I'm not sure if it's the best location for that, IMHO discussing this on standard@ would be more appropriate. - § 5 XMPP Registrar Considerations: even if it made me smile a bit, I don't think that XEP (beside humourous ones) is a location for this kind of jokes. It's not a big deal for experimental XEPs though. # Substance: * § 3.5 auto-subscriptions and § 3.6 Filtering I don't really understand the sentence "this implies that servers would gradually acrue any node type which the user has had a capable client at any time.". Could you formulate it more clearly or at least explain it? Regarding auto-subscription, XEP-0060 is not great itself about it as it's mentioning "root collections" and "subsciption_depth" which are notions of XEP-0248 (and I don't think that there are many complete implementations of it, if any). But that's a topic which should be discussed on a different thread. That put aside, I'm not sure that XEP-0376 should take care at all of auto- subscription regarding that we have already the filtering with +notify. This is done on a per-client basis, and if client wants to get says OMEMO public keys or user mood because it supports those features, I don't see the need to keep track of it at the server level. Sure it's broadcast. To my experience this is not a problem: I use +notify to auto-subscribe when I want update from all users to which I'm presence subscribed, and if I want only events for a specific user/node, I use an explicit subscription (in which case PAM is useful). Thus I would remove entirely § 3.5 and § 3.6, or replace them by a text indicating that PAM service ignores them and they work as usual with XEP-0060/ XEP-0163 auto-subscription and filtering. This would make the whole thing simpler, but please explain me with a clear use-case if I'm missing something. * § 3.7 interaction with MAM I guess events should be archived normally by MAM (at least to be sure that all clients receive them correctly), and I really don't see the need to filter them out (that's only events about explicit (un)subscription to nodes, the traffic should not be high). [this par below is forwarded from a follow-up email] all clients receive them correctly), and I really don't see the need to filter them out (that's only events about explicit (un)subscription to nodes, the traffic should not be high). Second thought: are you talking about the (un)subscribe notification as explained at § 3.2, or XEP-0060 items events? In the later case yes, filtering is probably desirable: if my client doesn't handle blogging, it probably doesn't want all the XEP-0277 items notifications. That's it for now. It's a useful addition to pubsub in XMPP, and I hope to see more implementation in close future. Cheers Goffi