[Standards] more obsolete specs

Peter Saint-Andre stpeter at stpeter.im
Tue Jun 2 20:20:42 UTC 2009

Hash: SHA1

On 5/30/09 3:35 AM, Fabio Forno wrote:
> On Sat, May 30, 2009 at 3:17 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> Yes, I agree. Is XEP-0144 good enough, or do we need to (1) improve it
>> or (2) define yet another approach to solving the problem?
> Basically improvements,  trying to solve the few situations leading to
> an undetermined behavior. For example in "iq semantics" it is written:
> "If the receiving entity successfully processes the suggested
> action(s) (which may include ignoring certain suggestions), the
> receiving entity MUST return an empty IQ result to the sending
> entity". This approach presents some issues:
> - if the sender of the items is a different entity from the one which
> will process subscriptions it is impossible to know which
> modifications have been accepted or rejected
> - even if the two entities are the same it is not possible to know why
> some subscriptions haven't been processed. For example if we don't
> receive a subscribe we can't distinguish an explicit reject from
> client side issues (network problems, client crash, users forgetting
> to take actions before ending their session) and this is bad, since we
> don't know whether to resend them or not
> Imho an <iq/>, with the accepted modifications, sent back to the
> sender after the user has processed the additions would solve the
> problem (we just need a session-id for linking the this notification
> to the triggering first request).

OK. Feel free to work on the spec. I can give you SVN access. :)


- --
Peter Saint-Andre

Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Standards mailing list