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