[Standards-JIG] JEP-0060: 1.8pre18
Peter Saint-Andre
stpeter at jabber.org
Thu Jun 8 20:51:09 UTC 2006
-----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
provisional?
> What we'd really
> like is some sort of "subscription_options_required" error message we
> could send back, with an options form included in the same stanza.
So something like this:
<iq type='set'
from='francisco at denmark.lit/barracks'
to='pubsub.shakespeare.lit'
id='sub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe
node='princely_musings'
jid='francisco at denmark.lit'/>
</pubsub>
</iq>
<iq type='error'
from='pubsub.shakespeare.lit'
to='francisco at denmark.lit/barracks'
id='sub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe
node='princely_musings'
jid='francisco at denmark.lit'/>
<options node='princely_musings' jid='francisco at denmark.lit'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#subscribe_options</value>
</field>
<field var='pubsub#deliver'><value>1</value></field>
<field var='pubsub#digest'><value>0</value></field>
<field var='pubsub#include_body'><value>false</value></field>
<field var='pubsub#show-values'>
<value>chat</value>
<value>online</value>
<value>away</value>
</field>
</x>
</options>
</pubsub>
<error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<subscription-options-required
xmlns='http://jabber.org/protocol/pubsub#errors'/>
</error>
</iq>
I don't particularly like:
(1) two different ways to tell the requesting entity that subscription
options are required (the server could return an error or it could
return the "success-but-please-configure" stanza that is currently defined)
(2) including the configuration form in the error
But IMHO (1) is worse than (2).
> 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.
Peter
- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEiI28NF1RSzyt3NURAm7jAKC8SSI0FU7mGUhO9itPX2P82oLxvwCcDslt
i7NitZWYIZPQBX6orXVSc+4=
=urR+
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060608/881e2534/attachment.bin>
More information about the Standards
mailing list