[standards-jig] JEPs and Jabber Adoption
jan at gondor.com
Sun Jun 29 23:02:36 UTC 2003
On Sun, Jun 29, 2003 at 05:23:16PM -0400, Paul Curtis wrote:
> The four JEPs (47, 65, 95, & 96) have all the functionality we need to
> begin with to have file transfer between two clients, either with
> streams or by using XMPP packets as the transport. Let's start there.
> Get all the clients we can to support these. THEN, let's take up other
> more advanced streams and use cases.
IMHO, this is a much better approach than discussing these JEPs over and
over again. Let's select one set of JEPs from all the various proposals
and implement it.
While people have good points why none of the JEPs filetransfer could be
based on is perfect, they can probably all be the base for working
reference implementations. When we have these implementations, we can
see if the issues are real or just theoretical.
Of course, we should avoid wasting too much time on implementations of
inferior JEPs. But at some point, when discussions are getting stuck,
just implementing some of the JEPs is the best way to proceed.
So my suggestion is that all the authors read their JEPs again, do some
last-minute cleanups if they want, and then the client authors (and
server authors, if server changes are necessary) try to agree on some
JEPs to implement. At that point, further changes to the JEPs (or even
new filetransfer JEPs) should be avoided unless real major flaws get
If we can shortcut this and people just agree on JEPs (47, 65, 95, &
96), as you suggested: Even better!
> And, finally, the discussions about how JEPs are handled is extremely
> important to the community. This needs to be worked out, and the process
> made to meet the needs of the community at large, without sacrificing
> the roles that all of the members play.
Perhaps it should be easier to get a protocol to Draft status? JEP 1
states that 'a Draft standard may still require additional field
experience and may be subject to change based on such experience', so
it's clear that there may still be issues to be resolved.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards