[Standards-JIG] JEP-0060: 1.8pre18

Ralph Meijer jabber.org at ralphm.ik.nu
Wed Jun 14 13:04:19 UTC 2006

On Thu, Jun 08, 2006 at 02:51:09PM -0600, Peter Saint-Andre wrote:
> Hash: SHA1
> Michael W. Zaharee wrote:
> > We would like to see several changes to cover a couple of issues we have.
> > 1) As we cannot represent a subscription without configuration options
> > being supplied, we would like to have an error response which clearly
> > indicates this requirement.  The "success, but come back with options"
> > response (example #42) can't work for us as we have no context to
> > represent what would be an intermediate state for us. 
> You don't have the ability to represent a subscription as pending or
> provisional?

If you do a subscription
request (!) using <subscribe/>, you get back a reply. Either you get an
error iq, or a result iq. In the latter case, you MUST examine the
result for the subscription attribute to determine if the request
succeeded. The attribute can have the following values:

 - subscribed: you have successfully subscribed.

 - pending: your request requires the action of an entity to approve the
   subscription request

 - unconfigured: your request was approved, but you need to configure
   the subscription before it becomes active.

 - none: your subscription was automatically denied in some way, without
   it being an error.

Having a error response represent either of the above states instead
doesn't really change the basic concepts. So, this seems like an
implementation detail to me.

> > 2) We would like to be able to retrieve information on all
> > subscriptions, with all configuration options, in a single
> > request-response exchange to avoid the overhead of round trip operations
> > for each subscription.  I notice in the schema that both subid and node
> > attributes are optional in the options element; can we use the absence
> > of _both_ of these in a request to indicate that option details are to
> > be returned for all subscriptions?
> What if someone has 500 subscriptions? You're going to return them all
> (with all configuration options) in one stanza? That seems problematic.

Right. Handle this out of band or using custom protocol. I cannot
imagine a valid use case to accomodate this.



More information about the Standards mailing list