Am 16.09.2011 21:24, schrieb Dave Cridland:
On Fri Sep 16 17:58:17 2011, Kim Alvefur wrote:
I think it shouldn't hurt if <r/> meant "I'd really like you to send an
<a/> now, please", and the other party SHOULD reply with <a/>, but not
MUST.
No, that would be bad. I do not wish to second guess why I'm not getting
an <a/>, I just want to get one.
If an implementation for whatever reason sends a whole bunch of
<r/>s at the same time, then why reply with more than one <a/>.
I don't want to optimize the protocol for poorly written
implementations. If the other end is asking for lots of
acknowledgements, either send them or go talk to a different peer.
Send as many <a/> as you like, but at least one per <r/> received.
I don't see any reason why there should be an error defined for.
It's just like if you never get an return for an iq stanza. If the
sender for an <r/> doesn't get an <a/> in whatever time he wants one,
it's the sender of the <r/> decision what to do. It's extremly unlikely
that a receiver of an <r/> is interested in an error, if he doesn't send
an <a/> and through that clearly violates the MUST (send <a/>) in the XEP.
And defining some arbitrary (response) time doesn't make sense (imho).
Regards,
Alexander
