On Thu, 2011-09-08 at 11:59 +0200, Alexander Holler wrote: > [..] > As said before, I'm pretty sure I've read somewhere that an owner is > subscribed by default too. It's just that I didn't found that again with > a quick search, so I've only posted the statement about publishers.
Yes, this is mentioned in section 12.11 "Auto-Subscribing Owners and Publishers": A service MUST allow owners and publishers to subscribe to a node, and to retrieve items from a node even if they are not subscribed. A service MAY auto-subscribe owners and publishers if they are not already subscribed, in which case it SHOULD generate a subscription ID if necessary for the subscription and SHOULD send a notification of successful subscription as described in the Notification of Subscription State Changes section of this document. The 'MAY' allows application-specific implementations to have this feature, while generic implementations don't need to make such assumptions (resulting in less additional logic). That is good enough for me. > A statment if bare JIDs and full JIDs are distinct or not in regard to > subscriptions (when they both have the same user/domain pair) would help > too. 6.1.6 only talks about subscriptions from several full JIDs of the > same bare JID, but not about the mix of a bar JID and several full JIDs. > I don't know how it is implemented in existing implementations, so I > can't suggest what to use. I would prefer that if multiple subscriptions > are not supported than a bare JID should exclude any subscription for a > full JID with the same user/domain pair (means 6.1.3.7 Subscription > Pending) and vice versa. XEP-0060 was written with XMPP Core as the basis, not requiring or assuming XMPP IM. This means that it is not required for a Publish-Subscribe service to require knowledge about how bare JIDs and full JIDs interact in certain environments. Client JIDs are just one subset of possible JIDs, others include MUC rooms, servers, other components. Even then, I can see use cases for having subscriptions to both the bare JID and full JIDs of the same user account. Especially if the receiving server distributes messages to the bare JID to all available resources (this is implementation specific). I suppose section 6.1.6 could be more clear that subscriptions with the bare JID itself are treated similarly to other full JIDs and MUST therefore also be treated as a separate subscriptions. If this is really undesirable for a particular application, the application should not make such conflicting requests. I am not very much in favor of adding additional logic to service implementations for this. -- ralphm
