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 [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.
Sorry about that. > 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. Aha. In the past we have used the term "bare JID" to refer to a registered account: [EMAIL PROTECTED] And we have used the term "full JID" to refer to a resource thereof: [EMAIL PROTECTED]/resource But I think your usage may make more sense. I'll have to try it on for size... > 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 > [EMAIL PROTECTED], or [EMAIL PROTECTED] 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 -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
