[Council] VOTE: JEP-0060 (Publish-Subscribe)

[Peter Millard]

Matthew A. Miller wrote:
> -1, for the following reasons:
>
> 1)  In section "3. Requirements", it specifies requirements for
> identifying a pub/sub node by JID, which specifies the JID must only be
> host and resource.  Is there a specific reason why the JID is not
> allowed to include a "user" (e.g. user at host/node-id")?

Yes, this is explicit. The reasons are that I want to explicitly disallow nodes
being treated like "contacts". I had a whole list of reasons when I talked about
this during the last council w/ hildjj... I need to find the archives.

> 2)  In section "7.1.4. Subscribe to a node", the use of the
> jabber:x:data form type='cancel' is not appropriate.  It changes the
> meaning of "cancel" from what is described in JEP-0004.  I believe it
> would be better to include an additional field to determine if the
> subscription is allowed or denied (either a boolean or a list-single
> {allow, deny, delay}):

This again was explicit since most clients will display an x-data form with an
OK & Cancel button. Clicking OK will send "submit", and clicking Cancel will
send "cancel". This works well w/ existing clients. If we include a boolean
field for allow/deny, then what happens when the user sends back a cancel?

> 3) Also in section "7.1.4. Subscribe to a node", when requesting pending
> subscription requests, I feel it would be more appropriate to use an
> <iq/> transaction.  Behavior similar to what I believe is being done
> here can also be accomplished via Ad-Hoc Commands (JEP-0050):

Are you proposing just to replace Example 32 with a "Commands" iq transaction,
or the entire "approval" process? I'm fine with the get-pending stuff being an
iq since it's the only place where action="foo" is being used.

pgm.