[Standards-JIG] Re: What happened to the ACK proposal?

Tijl Houtbeckers thoutbeckers at splendo.com
Tue Aug 16 23:36:43 UTC 2005

On Tue, 16 Aug 2005 23:59:58 +0200, Peter Saint-Andre <stpeter at jabber.org>  

> Tijl Houtbeckers wrote:
>>> Assuming this is true, then the case for XMPP ACK is very compelling
>>> (the problem won't go away even if people upgrade their TCP stacks).  
>>> Why
>>> didn't this point carry the argument last time?
>> Well, it was mentioned both before and after JEP-ACK was rejected.
> The stanza acknowledgements proposal was not rejected -- it was never
> even accepted as a JEP ("rejected" has a particular meaning in the JSF's
> standards process, see JEP-0001).

Excuse me for using the wrong term there then. Before and after JEP-ACK  
was.. uhm..  not accepted.

> The sense of the Council at that time
> was that if stanza acknowledgements are added to XMPP, they should be
> defined in the specification that defines XML stanzas, namely RFC 3920
> or its replacement (and RFC 3920 *will* be superseded by rfc3920bis when
> we pursue advancement of the XMPP RFCs from Proposed to Draft).

As you can see I already pointed the author that started this thread to  
the XMPP WG mailinglist. Ian (perhaps inspired by the great "optimism' in  
the log of the council meeting about taking the XMPP WG route ;) seems to  
suggest however that doing this in JEP form would allow us to move ahead a  
little faster. However I doubt he wants to do that himself (he might not  
even be convinced yet), since other people have been pushing harder for  
this (Justin Karneges, me, and others who keep bringing it back like  
Stephen Marquard now).

I believe JEP-1 calls upon the author(s) to "confer with the JEP Editor or  
objecting Council member(s) regarding how to proceed." (well maybe that  
happened offlist at the time?). Author in this case being anyone who wants  
to pick it up I suppose. And that of course depends on in what form it can  
be picked up as well..

As a general question: is there anything that would prevent a JEP from  
being "folded" into the RFC process? (Server Based Privacy comes to mind  
(what was that.. 0016?))

Perhaps we're getting ahead of ourselves with procedural questions though..

Just how closely is the relationship between XMPP and it's transport layer  
defined? Ian had some comments on this but I'm having trouble finding  
those defined in rfc3920. If it's currently undefined, then should it even  
expected, let alone required, that there is 100% realiability? How "niche"  
is the use case for it?

More information about the Standards mailing list