[Standards] XEP-0198: Stream Management - Clarifications

Alexander Holler holler at ahsoftware.de
Sat Sep 17 17:44:28 UTC 2011

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



More information about the Standards mailing list