[Standards] RFC 3921bis Managing Presence Subscriptions based on full JIDs serious issue

Peter Saint-Andre stpeter at stpeter.im
Thu Feb 7 18:37:36 UTC 2008

Ralph Meijer wrote:
> On Wed, 2008-02-06 at 16:45 -0700, Peter Saint-Andre wrote:
>> Tomasz Sterna wrote:
>>> Dnia 2008-02-01, Pt o godzinie 00:17 +0100, Tomasz Sterna pisze:
>> [..]
>>> So I actually need full JID based subscriptions.
>> Right.
>> The problem is that we can't tell what an entity is just by looking at
>> its JID. Just because a JID is node at host/resource does not mean it is a
>> full JID (i.e., a connected resource of a registered account). Just
>> because a JID is node at host does not mean it is a bare JID (i.e., a
>> registered account). This is why we have service discovery. :)
>> So in general I think it makes sense to counsel client developers that
>> adding full JIDs is a bad idea, but you can't assume that a JID of the
>> form node at host/resource or host/resource is a full JID.
> I think Peter's explanation of full JID and bare JID confuses things for
> me. 

Sorry about that.

> I have always assumed that a bare JID can have the forms
> <example.com> and <node at example.com>, and that a full JID is a bare JID
> with a resource. 

Aha. In the past we have used the term "bare JID" to refer to a
registered account:

   localpart at domain.tld

And we have used the term "full JID" to refer to a resource thereof:

   localpart at domain.tld/resource

But I think your usage may make more sense. I'll have to try it on for

> The fact that we call the part in front of the '@' sign
> a node, but also have nodes that hang of an entity (like pubsub and
> disco) is fairly confusing, too, by the way.

Yes, as mentioned I think we may want to call that a localpart.

> That said, I think that a number of specifications assume that resources
> are just that, resources of some thing. I.e. all of the resources that
> share the same bare JID, are under common control of whatever owns the
> bare JID. 

I think that is an accurate assumption in many contexts, but I'm not yet
sure if it is accurate in all contexts, thus my reluctance to generalize
it too far.

> E.g. in XEP-0060 (Publish-Subscribe), all affiliations and
> subscription authorization are based on the bare JID.
> Some people have suggested that you shouldn't (be able to) rely on a
> particular resource identifier being stable, among others, for security
> reasons. In that case, it doesn't make sense to me to subscribe to just
> one resource's presence or have that resource in your roster.

Right. Especially if resource IDs are server-assigned as is recommended
in rfc3920bis.

> If your particular use case desires that you can subscribe to the
> presence of two different things (and not two facets of the same thing),
> why not make two different bare JIDs for them? Why not have
> echo at chrome.pl, or webstatus at chrome.pl?

Agreed, I think it is good to think of resources as facets of the same
thing. And then a node is a kind of sub-facet or something. :)

OK, now I'm finished working my way through the Ralph flood. :) Speaking
of which, Ralph, don't forget to vote on XEP-0115. :P


Peter Saint-Andre

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

More information about the Standards mailing list