[Standards-JIG] JEP-0060: 1.8pre18

[Peter Saint-Andre]

-----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>