[Standards] more obsolete specs

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


-----BEGIN PGP SIGNED MESSAGE-----
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

- --
Peter Saint-Andre
https://stpeter.im/

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

iEYEARECAAYFAkoliZoACgkQNL8k5A2w/vz4AACeKd0fz6ICFMYFPE2IFIfmATuU
3EcAnAx6D+Hnw9OU01rjgWj6Q9C/z8Gg
=Q0kB
-----END PGP SIGNATURE-----


More information about the Standards mailing list