[standards-jig] JEP-0060 comments

Greg Hewgill greg at hewgill.com
Tue Jan 7 04:16:13 UTC 2003

On Mon, Jan 06, 2003 at 04:08:42PM -0700, Peter Millard wrote:
> I will try to rework this section again to help make it more clear.. I
> presume you're talking about the implementation notes (Section 7.1).

I just want to make sure this JID management is astoundingly clear in the
specification. It's obviously a pretty important piece of the puzzle, so it
would do us well to make sure it's not open to misinterpretation.

I think a reasonable approach to take would be to allow subscription from
either a full jid or a base jid. (If the jid= attribute is not specified in the
subscription request, use the full jid in the from= iq attribute.) Store the
full jid in the affiliation list, but use the resource part (if any) *only* for
notification delivery. All other operations where the from= jid must be
compared to a jid in the affiliation list would be done using just the base

One area that needs consideration is whether the same entity (base jid) is
permitted to subscribe under two different resources (full jids). If so, should
an unsubscribe request unsubscribe only the specified full jid? Or if the
unsubscribe request contains a base jid only, should all resources associated
with that entity be unsubscribed?

> Yes. As you pointed out unique + required is too strict for simple
> applications. I would think that if an implementation chooses to NOT
> implement persistent item storage, then id's would never be necessary.

Would item id's *ever* be necessary, though? You say that they would never be
necessary if the pubsub component did not support persistent storage, but is
there any situation where they would be necesary? I think your intent is that
there would not be, but I'm seeing some conflicting signals. :)

Out of curiousity, did you have a particular kind of implementation in mind
with regard to these item ids? Or at least a convenient metaphor? For example,
the idea might be to handle ids (if present) like filenames in a directory.
That would imply that there could only be one item with a given id at any one
time. (The metaphor is incomplete because it does not consider the id-less
case, but it's a start.) The implementation I had in mind when reading the
specification for the first time was a relational database back end, where such
uniqueness is not necessarily assumed.

> Will you be making this code available for use on jabberstudio, or some other
> project repository??

Yes, I just requested a jabberstudio project for "pubsub" (ok, it's not a very
creative name). I'll hopefully have that set up in a day or two.

Greg Hewgill
jid: ghewgill at slacker.com

More information about the Standards mailing list