[Standards] UPDATED: XEP-0198 (Stanza Acknowledgements)

[Justin Karneges]

On Friday 05 October 2007 2:35 pm, Joe Hildebrand wrote:
> I think the idea was that using the stream id was: a) a layer
> violation and b) might make XEP-78 digest authentication subject to a
> replay attack.

All we need is a reference to the previous stream, and the stream id seems to 
be designed for the purpose of identifying a stream. :)  The id would not be 
reused for the new stream, so there should not be a security concern.

Having our own ack session id can't hurt though, if we want to be that much 
more flexible.  It just means another id to juggle around in our pile of ids.

> I'm not sure I'd call this "Stanza Acknowledgments" any more; I'm
> thinking about <r/> and <a/> as stream checkpoints; they don't need
> to be sent after every stanza.  As a matter of fact, I might
> implement this with a timer, sending a <r/> N ms after the last
> stanza sent, or total of M ms after the last ack, where M > N.

The acking (and even the pinging) all seem to be revolving around stanzas, so 
I think that word is fine to keep.  "Stanza Checkpoints" ?

> I assume the namespace will go to urn:xmpp:ack or something when it
> gets approved.

Yes.

> Section 2.1, bullet 1: MUST -> SHOULD, or add "and wants to allow
> this client to enable acking".  I can imagine server implementations
> that make decisions about who is allowed to turn on acking on a per-
> user or per-device basis.

Are you sure this is needed?  The text follows the narration found in RFC 3920 
about the TLS and SASL stream features, and I think those are fine.

I should say that I also hate this format, though.  I only wrote the XEP this 
way because I wanted it included in the RFC.  I don't think I'll rewrite the 
XEP (too much work), but I guess we can deviate from the RFC format as 
appropriate.

> Should section 2.1 have a reconnect overview?

I may want to mention about <reconnect> at least, since the <ack> 
stream:feature element is mentioned.

> Should the id attribute be on the reconnect element, rather than the
> ack element in the stream features?

Yes, that would probably make more sense.

> 2.2.4, is a little confusing with respect to the b attribute.  Is it
> the last b that the initiating entity set in a <r/> or sent in a <a/>?
> Probably the latter.  (same in 2.2.5) 

I think you mean 2.2.5 and 2.2.6, respectively.

To answer the question: The 'b' value used in <enable> and <enabled> is set to 
the last 'c' value received from the peer.  Whether this last 'c' value came 
from <r/> or <a/> doesn't matter, either is fine.

> 2.2.6, I'm not clear on the difference between <r/> and <a/>.  Is it
> possible we could just use one or the other?

<r/> is just like <a/>, except that the receiver is required to reply to it.  
Because of that, the <r/> element must contain a 'c' value so that the 
receiver knows what value to ack.

> Section 3, there needs to be a set of reconnect examples, including
> the error cases.

Sure.

> Section 4 feels gratuitous/unrelated.  Why should this replace
> spaces?  Maybe this could be a separate XEP.

Spaces are used for two purposes:
  1) keeping connections open (NATs)
  2) probing for dead connections

For #2, the ack/timeout of the whitespace is handled by the TCP layer, and the 
default timeouts are generally considered too long in duration for XMPP IM 
connections.  It is annoying for users to see a guy online that has been 
disconnected for 10 minutes (or annoying for a user to see all of his friends 
online, when he himself has been disconnected for 10 minutes).  And of 
course, the longer it takes to notice a connection is gone, the more stanzas 
that pile up in an unacked send queue.  If we want to reduce the probe 
timeout, we need an application-level "ping".

There's just one problem: karma.  As you know, servers historically have had 
outrageous throughput penalties, sometimes on the order of minutes.  An IM 
client might want to have a 1 minute timeout.  How do we reconcile the 
problem of an ack being withheld for 3 minutes, but an IM client wants to 
ensure the channel didn't die in 1 minute?

Why would an ack be withheld for 3 minutes?  XEP-198 tries to address the 
notion of "stanza acceptance", which goes a slight step beyond just getting 
stanzas across the network.  Stanzas need to be received by the endpoint, 
and "accepted".  This is so we can use XEP-198 acking as a form of flow 
control with servers that impose karma penalties.  A server can withhold acks 
during the penalty period.

The pings may seem out of place, but they are intertwined in the overall 
picture.

Granted, I'm ignoring the fact that traditional jabberd karma is done by 
withholding TCP acks, which means not reading data from the TCP receive 
queue, which means never seeing a ping packet. :)  Hence the SHOULDs.  But I 
was trying to prepare for the future, where a server could impose throughput 
penalties without risking a connection timeout.

> Section 5, if you want to use a prefix, you should set it on the
> enable to check for support.  Server will either throw an error,
> return an un-prefixed ack, or return a prefixed ack to say "it's ok
> to use prefixes".

Interesting...

-Justin