Am 08.09.2011 13:35, schrieb Ralph Meijer:
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.
That (and maybe a reference to that in 6.1.3.7) would clarify the stuff.
Than the only thing what should be clarified is that automatic
subscriptions (owner and publisher) are with the bare JID (everything
else is imho senseless) and if subscriptions will get removed if the
affiliation is changed.
To keep it easy I think not removing any subscribtions if not required
by the new affiliation (e.g. outcast or not member in closed rooms) is a
good solution.
That would mean when a owner gives another JID the affiliation publisher
or owner and sets the affiliation afterwards to 'none' the JID will
still have a (automatic generated) subscription. But I think that is
fine if it described so in XEP.
Regards,
Alexander
