[Standards-JIG] Re: proto-JEP: Stream Acking
sneakin at semanticgap.com
Fri Oct 29 04:09:28 UTC 2004
Well, if the prefix must be included in the <stream> it would be possible to
completely forgo feature negotiation. The client (or server for s2s) would
specify the prefix for JEP-Ack's namespace. The server would notice it, and
send back a <stream> w/ the prefix specified too. Both parties would know
that they're going to be acking from the start. The initiating party would
only send acks if and only if the receiving party specified a prefix for
There are also a couple of suggestions that come to mind. The first is
probably a business rule dealing the typical prefix, which for bandwidth
savings SHOULD be a single character preferably an 'a'. I assume most XML
parsers used for Jabber are intelligent enough to use prefixes. If not,
then it might be wise to make it a MUST.
The second is the process flow for determining why an ack wasn't sent back.
A reason for the second one is what do you do if an ack is not received,
send again, wait, or ping? This is presumably why pinging is included, but
the use of pings is not explicit in the proto-JEP. That would also explain
why pings get responded to even if the server is refusing to accept
anything from the sender due to karma or what not.
The flow would probably be:
Wait for ack
If timeout expires
Wait for pong
If a timeout expires then the connection
is dead and the stanza wasn't received
Else the server must be mad at us; keep waiting
Else the stanza was received
That, or something more accurate, should probably be noted some where in the
JEP. Most likely in the implementation notes.
Peter Saint-Andre wrote:
> In article <82777bea04102809344d9878d2 at mail.gmail.com>,
> Joe Hildebrand <hildjj at gmail.com> wrote:
>> <a:a/> would work ok, if you negotiated a stream feature first, and
>> restarted the stream with the a: prefix defined in stream:stream.
> Yes, if. :-)
More information about the Standards