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
