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

Thomas Muldowney temas at box5.net
Tue Oct 21 17:51:58 CDT 2003


+1

--temas

On Tuesday, October 21, 2003, at 04:07 PM, Peter Saint-Andre wrote:

> 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
>
> _______________________________________________
> Council mailing list
> Council at jabber.org
> http://mailman.jabber.org/listinfo/council




More information about the Council mailing list