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

Peter Saint-Andre stpeter at jabber.org
Tue Apr 11 20:13:47 UTC 2006

Hash: SHA1

OK, Ralph and I chatted about this via IM. Response below...

Ralph Meijer wrote:
> 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?

You're right, it would hold for non-IM applications. The relevant
concept is client-server, not IM. So any client (IM or not) that
connects to an XMPP server will specify a resource, and its "affiliated
JID" can always be truncated to a bare JID.

I see two cases when an address that looks like node at domain.tld/resource
is not a client connection:

1. MUC Occupant -- occupant at chat.domain.tld/RoomNick

2. Pubsub Node -- PubSubService at domain.tld/NodeID

Let's look at these separately.

1. MUC Occupant

In this case, I think the occupant would subscribe to outside feeds not
as an occupant but as an XMPP account. So the subscriber to a pubsub
node would not be <occupant at chat.domain.tld/RoomNick>, instead it would
be <node at domain.tld/resource>. And this XMPP address can be reliably
truncated to a bare JID, so we are fine.

There is the possibility of "internal nodes" -- that is, the room itself
hosts pubsub nodes for use within a room. But IMHO this functionality
requires a special profile of JEP-0060 and we can work out the issue of
subscriber address truncation (or not) in that profile.

2. Pubsub Node

In this case, the pubsub service is <PubSubService at domain.tld> and nodes
hosted there are <PubSubService at domain.tld/NodeID>. This brings up the
issue of "pubsub chaining" -- i.e., do we allow pubsub nodes to
subscribe to other pubsub nodes? The scenario would be something like this:

- - a node "NewsFeed" at pubsub.example.com
- - a node pubsub at example.net/NewsReader
- - NewsReader wants to subscribe to NewsFeed
- - so it would send:

<iq type='set'
    from='pubsub at example.net/NewsReader'
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
        jid='pubsub at example.net/NewsReader'/>

But there is no need to chain the nodes in this way. Better, I think,
for the pubsub service to subscribe on behalf of the node, and it can
distribute the information how it pleases (maybe multiple local nodes
want to use that information). So the subscription request would be:

<iq type='set'
    from='pubsub at example.net'
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
        jid='pubsub at example.net'/>

If so, then both cases (MUC occupant and pubsub node) are handled in
special ways, and we don't need the 'barejid' attribute.

> 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.

Agreed, see above.


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060411/11096795/attachment.bin>

More information about the Standards mailing list