[Foundation] Council Questions - Jer

Shawn Wilton shawn at black9.net
Wed Aug 7 23:15:59 CDT 2002


Yeah, could get that done when everyone agrees on x:forms.



----- Original Message -----
From: "Jeremie" <jeremie at jabber.org>
To: <members at jabber.org>
Sent: Wednesday, August 07, 2002 8:12 PM
Subject: Re: [Foundation] Council Questions - Jer


> > 1. What do you think is working and not working with regard to the JEP
> > process? What suggestions do you have for improvement?
>
> How about a jabber interface for voting? :)
>
> My only general comment about the process has to do with the timing of the
> participation by council members. We've been back and forth, and it still
> seems vague between pre-participation (before it goes to vote) or
> post-participation (discussion of issues during voting process w/
> revisions).  I'd prefer the pre-participation approach, where the voting
> is just a matter of checks and balances.  Then fact that the council votes
> just ensures that those individuals on the council are the ones
> responsible to offer major comments before the last call.
>
> Otherwise, the whole process is still young yet, we really need to crank a
> few more JEPs through the entire lifetime. I've always believed it's ok to
> make mistakes in how the process works now and learn from them, it's
> faster and easier to fix them than trying to ensure you get it right the
> first time
>
> > 2. From a purely technical standpoint, what differentiates Jabber from
> > SIP, SIMPLE, and related technologies? Why (or why not) is XMPP a better
> > choice for many applications than transporting XML/MIME payloads via
SIP?
>
> Jabber *works*?
>
> To be honest, I don't care that much.  To each their own, and if others
> find value in utilizing SIP/SIMPLE (something which hasn't been
> demonstrated to me yet) beyond what we already provide (maybe because you
> already have SIP rolled out), then we can very easily adopt those
> protocols into our architecture and support them, either directly in the
> server, c2s, and s2s, or as a gateway/transport.  Due to the way we work,
> it's just another feature of the platform as a whole, it doesn't detract
> from anything existing and adds value to others that are already
> interoperable using Jabber.
>
> As soon as there are some SIMPLE implementations based on a solid spec
> that are actually being used "in the wild" then I'll be the first to
> prototype support for it, in fact I already have a name, the
> difficult-transport, *g*.
>
> > 3. Why do you think it is necessary to develop a pub/sub protocol for
> > Jabber? Please provide specific examples. In particular, it seems that
> > there should be some useful synergy among pub/sub, message queueing, and
> > presence. How do you see this fleshing out in specific applications?
>
> There is no doubt pub/sub is necessary.  The existing presence mechanism
> was designed for distributing entity/jid state, not abstract data event
> subscription/notification, and although the functionality of it is
> enticing to build on, it becomes difficult to do cleanly.
>
> A generic pub/sub mechanism is ultimately going to take more work even if
> the concept is easy and seems like it's already been done with presence.
> Multiple flavors might also not be a bad thing, it's possible that any
> argument of code reuse isn't as relevant when taking into account the size
> of the app built on it, such as a conferencing client or music stream
> notifier.  Maybe we end up with a robust pub/sub model for distributed
> client/service applications, and a rudimentary protocol for entities doing
> lightweight notification between each other.
>
> > 4. How do you think ownership of the trademark on the Jabber term should
> > be handled?
>
> More to come on this in a few minutes in another message...
>
> > 5. How do we establish trust between servers on an Internet scale?
>
> We already have trust based on DNS, dialback is the best you can get with
> the currently deployed capabilities on the Internet.  It's not as if it's
> "insecure" either, it's ultimately as safe as your DNS, and you can use
> DNSSEC if your paranoid, maybe this is a good killer app to encourage
> wider deployment of those protocols which others have worked hard to
> develop the security for.
>
> Secondarily, there is always a model based on specific trust relationships
> using SSL/TLS and privately exchanging keys, or relying on trusted third
> parties.  This will be done anyway, and only enhances the existing
> security/trust available.
>
> > 6. Do you think we should build a mechanism for in-band transport of
large
> > payloads within Jabber? If not and you think an out-of-band transport is
> > sufficent, how do you see that as different from SIP?
>
> I used to be decidedly against this, but I've softened up and am now on
> the fence, it could go both ways. Using in-band is incredibly convenient
> for us, but it also seems like we're working around many of the mechanisms
> that help make the Internet work and duplicating a lot of effort.  Maybe
> there should simply be a process of determination between the sender and
> recipient and in-band is the last resort?
>
> The definition of "large" will also always be growing, and already means
> many different things.  Right now sending large payloads within Jabber
> isn't optimal (but it's capable of being at least as good or better than
> email), and I have no doubt that JNG will absolutely be an improvement and
> in-band might then be the first/best option.
>
> > 7. How can the growing complexity and functionality of the Jabber
protocol
> > be balanced with simplicity and developer-friendliness?
>
> Easier said than done: with vigilance, dedication, and a readiness to put
> off the 20% of functionality that causes the 80% of complexity.
>
> > 8. How can the JSF and the Jabber technical community best work with
other
> > standards organizations, specifically the IETF and any possible Working
> > Group the IETF forms to to pursue standardization of the core Jabber
> > protocol?
>
> All of these are individual based, *we* make up one or all of these
> communities.  It's the time we put in, coding, reading, doc'ing, chatting,
> answering questions, thinking, and dreaming, that makes possible any
> collaboration between such efforts and groups.
>
> Thanks, and looking forward to the next year of Jabber :)
>
> Jer
>
>
>
>
> _______________________________________________
> Members mailing list
> Members at jabber.org
> http://mailman.jabber.org/listinfo/members
>




More information about the Members mailing list