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

[Peter Saint-Andre]

Peter just submitted, and I have just published, Version 0.14 of this 
JEP. Let us know if it addresses your concerns! :-)

http://www.jabber.org/jeps/jep-0060.html

/psa

On Tue, Oct 21, 2003 at 01:49:22PM -0600, Matthew A. Miller wrote:
> 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 
> specified
>        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.
> 
> >pgm.
> >
> >_______________________________________________
> >Council mailing list
> >Council at jabber.org
> >http://mailman.jabber.org/listinfo/council
> > 
> >
> 
> _______________________________________________
> Council mailing list
> Council at jabber.org
> http://mailman.jabber.org/listinfo/council
> 

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php