On Sat Sep 17 18:44:28 2011, Alexander Holler wrote:
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).
You don't appear to be disagreeing with me, but instead arguing about
something I've never mentioned.
I'm saying that receivers of an <r/> MUST send an <a/>. Receivers of
two <r/>'s MUST send one <a/> for each. If receivers of an <r/>
withhold an <a/>, that indicates some problem with the connection
(including application-level congestion).
If no </a> at all is sent, then the peer that's missing the <a/>
response might do all sorts of things to try to recover, up to and
including sending a timeout error, or simply dropping the connection
- and that seems entirely fine; either the connection or the other
peer is broken.
If a peer is sending lots of <r/>'s, then this is a poor
implementation, but you still MUST reply to each individually. Could
be there's been a period of congestion and you're actually seeing one
<r/> per minute coming through in a big bunch.
Introducing variance in whether or not to respond to an <r/> or not
simply breaks the protocol.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
