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 [EMAIL PROTECTED]/resource does not mean it is > a > full JID (i.e., a connected resource of a registered account). Just > because a JID is [EMAIL PROTECTED] 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 [EMAIL PROTECTED]/resource or host/resource is a full JID.
I think Peter's explanation of full JID and bare JID confuses things for me. I have always assumed that a bare JID can have the forms <example.com> and <[EMAIL PROTECTED]>, and that a full JID is a bare JID with a resource. 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. 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. 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. 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 [EMAIL PROTECTED], or [EMAIL PROTECTED] -- Groetjes, ralphm
