[Standards-JIG] Re: pubsub: affiliations and subscriptions

Ralph Meijer jabber.org at ralphm.ik.nu
Tue Apr 11 09:42:28 UTC 2006


On Thu, Apr 06, 2006 at 01:25:03PM -0600, Peter Saint-Andre wrote:
> [..]
>
> The issue here is non-IM applications, where the concept of barejid does
> not apply. So something like this seems better:
> 
> <iq type='set'
>     from='francisco at denmark.lit/barracks'
>     to='pubsub.shakespeare.lit'
>     id='sub1'>
>   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
>     <subscribe
>         node='blogs/princely_musings'
>         jid='francisco at denmark.lit/PDA'
>         barejid='true'/>
>   </pubsub>
> </iq>
> 
> In other words, consider the bare JID to be the "owner" for subscription
> tracking purposes. This attribute would default to "true" for backwards
> compatibility.

I'm still wondering about this. In my imagination, the bare JID always
represents a single client account or service. In those cases where two
entities have a JID that only differs in the resource, the problem lies
at the owner of that bare JID. Why wouldn't this hold for non-IM
applications?

In the IM space I can think of only one current use of JIDs that differ
only in resource but really represent other entities. MUC uses a
room at service JID for a room, and adds a resource part for each
participant. Using current semantics, any room occupant could subscribe
other occupants to a pubsub node. The traffic always goes through the
MUC service, though, so you might consider it to be an open relay.

I suppose MUC in combination with pubsub needs to be addressed more
carefully anyway, but that is topic for another discussion.

-- 
Groetjes,

ralphm



More information about the Standards mailing list