Hello Brian and thanks for your feedback. The idea behind presence permission was only to know when somebody is on/ offline, thinking in the point of view of an external PEP service (for presence access model).
I'm not against the idea of using XEP-0297 here, but I'm a bit worring about the traffic overhead: business rules §7.2 try to limit it by recommanding to send presence only once. If you want to check the initial destinee, you would need to send every presence received instead of one per sending entity (i.e. if romeo is in the roster of 1000 people, the privileged entity will received 1000 stanzas instead of one). So I'm not sure it really worth it, do you have a concrete use case for this? regards Goffi Le lundi 29 août 2016, 10:12:11 CEST Brian Cully a écrit : > When dealing with presence information from the standpoint of the > privileged entity, we lose information about to whom the original > (non-forwarded) presence was sent. This wouldn’t affect the semantics when > the privilege is of type “managed_entity”, but when it’s “roster” it’s > important to know when using directed presence. > > I propose that, like <message/> stanzas, <presence/> stanzas also use > XEP-0297, so the privileged entity can extract the original ‘to’ attribute > when necessary. I also like that it gives parity to both incoming stanzas > cases, but that’s a fairly small concern. > > -bjc > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
