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

Matthew A. Miller linuxwolf at outer-planes.net
Tue Oct 21 14:49:22 CDT 2003

Replies are inline.  Enjoy!

-  LW

Peter Millard wrote:

>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.
I was not clear enough.  What I am trying to say is "is there any reason 
the pub/sub service cannot be a 'user at domain'?".  It appears that this 
is a case where the specification is not clear enough.  I propose the 
wording be something like the following:

        If nodes are addressable by JIDs, the node-id MUST be specified 
by the resource
        (e.g. "domain/node-id" or "user at domain/node-id", and MUST NOT be 
        by the "user" (e.g. "node-id at domain").

>>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?
The vast majority of user interfaces that require a "yes" or "no" 
present a "yes/no/cancel" unless there's a very good reason for why the 
request must be handled immediately.  For most other uses of 
"jabber:x:data", this would be interepreted as "I didn't mean to do this 
now".  In this instance, it changes that to "I deny this request".  It 
assumes the users or user-agents will properly understand this, which my 
experiences have proven to not be a safe assumption.

To address your question "what happens when the user sends back a 
cancel?"  If the user sends a type='cancel', the subscription request 
SHOULD (MUST?) go into (or remain in) some "subscription pending" queue 
for that node.  I find this especially appropriate since there is a 
discussion on processing such pending requests.

>>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.
I am only proposing that the "get-pending" be done in this manner, not 
the entire process.  It doesn't make sense to force clients to implement 
commands' "responder" behavior for something that <message/>-based forms 
already handle.

>Council mailing list
>Council at jabber.org

More information about the Council mailing list