[Standards-JIG] JEP 60: Requesting Items for a Node

Peter Saint-Andre stpeter at jabber.org
Tue May 24 19:41:28 UTC 2005

On Mon, May 23, 2005 at 05:21:19PM -0600, Peter Millard wrote:
> On 5/20/05, Peter Saint-Andre <stpeter at jabber.org> wrote:
> > I think it would be reasonable for a pubsub service to consider owners
> > and publishers to have "super-user" status and to allow JIDs with those
> > affiliations to retrieve items.
> > 
> > If Peter and Ralph don't have any objections, I will add a note about
> > that.
> I think this is reasonable for owners, but not publishers (as has
> already been noted).

SHOULD for owners and MAY for publishers, or just remain silent about

> > Hmm. Currently, the SubID is used to differentiate between multiple
> > subscriptions from the same JID -- or, more precisely, it is used by
> > the pubsub service on any subscription to a node that allows multiple
> > subscriptions to the same node by the same JID (so if the node allows
> > multiple subscriptions, then the service MUST add the 'subid' attribute
> > if one is not provided by the subscriber). If we specify that the SubID
> > is required in all cases, then services will be generating SubIDs when
> > they're not really necessary or used. I don't know if that is a major
> > hardship or not -- perhaps some implementors could voice their opinions.
> > 
> > Furthermore, no guidelines are specified for the generation of SubIDs.
> > At the least, I think the JEP needs to say that a SubID MUST be unique
> > per node+jid combination.
> This is clearly too large of a change at this point IMO. There will be
> lots of implementations that do not support s10n options, therefore,
> don't need to support sub-ids. Making them mandatory after a JEP is
> already Draft should not be allowed. We'd be breaking exsting
> implementations :( Furthermore, we shouldn't be designing protocols w/
> just compliance checking in mind. Sure, it's something to consider,
> but it should not be something we optomize for.

I agree that making SubIDs mandatory for all subscriptions seems
unnecessary -- many deployments won't need them because they'll 
disallow multiple subscriptions per JID or, more generally, the 
whole concept of subscription options.


More information about the Standards mailing list