[Standards-JIG] Re: proto-JEP: Stream Acking

Nolan Eakins 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:
   Send stanza
   Wait for ack
   If timeout expires
      Send ping
      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.

- Nolan

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. :-)
> /psa


More information about the Standards mailing list