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

Thomas Muldowney temas at box5.net
Tue Oct 21 15:58:12 CDT 2003


+1

--temas


On Tuesday, October 21, 2003, at 02:49 PM, 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




More information about the Council mailing list