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

Joe Hildebrand hildjj at gmail.com
Fri Oct 5 16:35:47 CDT 2007


On Oct 3, 2007, at 5:45 PM, Justin Karneges wrote:

> To clarify, the updates are:
>   1) the stream feature element now has an 'id' attribute, and this  
> is the id
> that is used when recovering a session, rather than using the  
> stream id
> (hildjj really wanted this, not sure why, but no one objected).
> additionally, the id is used to indicate recovery support by the  
> server.

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.

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.

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

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.

Should section 2.1 have a reconnect overview?

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

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)

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?

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

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

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


Thanks for doing the update.  I like the way this is going.





More information about the Standards mailing list