[Standards] more obsolete specs

Fabio Forno fabio.forno at gmail.com
Sat May 30 09:35:26 UTC 2009

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).


Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

More information about the Standards mailing list