[Standards-JIG] JEP-0060: 1.8pre18
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:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
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
- 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