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 <[email protected]>
À : [email protected]

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]

> * § 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).

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

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to