[Foundation] Council Questions

Joe Hildebrand hildjj at cursive.net
Wed Aug 7 10:48:26 CDT 2002


(This got a little long.  Sorry.)

> 1. What do you think is working and not working with regard to the JEP
> process? What suggestions do you have for improvement?

As I've stated in standards-jig, I think that there needs to be a
difference between 0 and +1.  A simple majority of +1 over 0 should be
needed to move on to the next step.

Timely responses from the council are crucial.  Even if the response is
a short "I'm worried about X, and am taking a while to think about it
before voting" is better than no response.

I am glad to see that there are starting to be more JEPs.  I know of
several companies that are not yet involved in the JEP process that need
to be, companies that are extending the protocol in ways that the rest
of the community could benefit from.  We have gotten good feedback from
the process, and I hope that other companies can now see the value in
participation in the JSF.
 
> 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?

I have to deal with this one too much in real life.  There are many
voice carriers who think that SIP is the best protocol ever for enabling
VoIP (Voice over IP) calls.  In particular they really like having a
different protocol for signaling and for data transmission.  For those
of you unfamiliar with the protocols, RTP (Real-Time Transport Protocol,
RFC 3267) is used to actually transport VoIP calls, which SIP is used to
find the endpoints, ring the phones, and get everything set up for an
RTP session.  It makes sense for RTP to be a point-to-point solution,
like our current file transfer approaches, for the same sorts of
reasons.  Particularly when compared with H.323, the separation of
signaling from content may be a big win for carriers.

SIMPLE takes the idea that SIP can be good, and says "if SIP is good,
then SIP must be used for everything, including IM and presence."  There
are some potential wins with this approach, particularly with respect to
enhancing presence with phone on-hook/off-hook/voice-mail status.
However, the SIMPLE group initially decided to use SIP not only as a
signaling protocol, but also as a transport protocol.  Yes, this makes
programmability better. But, since SIP can be transported across UDP,
and since any hop can decide to transmute a SIP/TCP link into a SIP/UDP
link for the next hop, I've lost the ability to send large-ish packets,
and I have no congestion control.  (Yes, there is a proposal to get
around this, but these approaches remind me of the last gasps of the
pre-Kepler astronomers with their epicyclics.)  One obvious approach is
to use another protocol (point-to-point) for the transmission of IM and
presence information.  They are still arguing over what that protocol
should be.  Yes, it could be a bastardization of our protocol, but I
really don't see what value SIP would be adding at that point.  Imagine
XMPP sessions going point-to-point.  You would have all of our file
transfer firewall problems for every single chat.  What this all boils
down to is that SIP turns out to be a lousy, complicated way to
encapsulate IM and presence.

Now, assume that SIP is the one true VoIP protocol.  I've seen enough
evidence in the last year that some carriers are going to be deploying
SIP as a core piece of their architectures.  Let us examine the SIMPLE
argument: "if you are deploying SIP anyway, you should also use it for
IM."  I take issue with both clauses of that argument.  

"SIP"
Even if carriers deploy SIP, I don't think that small and medium
enterprises will be doing so in the near future.  Certainly not to the
level where they can make use of any sort of VoIP/IM integration.  Given
this, why should I deploy SIP, just to solve a problem that is
fundamentally simple?

"SIP -> SIMPLE" 
Just because you have deployed DHCP, should you use that as the basis
for your IM protocol?  It could be done, but it would sure be
complicated to get it right. 

People also say "SIMPLE is the only standards-track IM protocol.  I'm
not going to deploy something that hasn't been blessed by the IETF."
This is the key reason why we need to have the IETF involved in our
protocol, if we want wide-spread deployment.  If we decline to become
involved in the IETF, SIMPLE wins by default, no matter what its
technical problems.

Now, the last point that people make with regard to SIMPLE is that it is
built in to Windows Messenger.  If I recall correctly, there isn't any
SIMPLE support in the version of Windows Messenger that ships with XP.
Yes, there is some SIP for VoIP-y things, but no SIMPLE.  The latest
downloads of Windows Messenger have something they are calling SIMPLE,
but since there are no RFC's yet, and the SIMPLE group has not decided
on a roster management approach, much less an actual transport protocol,
"SIMPLE" in this respect is more of a marketing ploy than an actual
standards adherence on the part of MS.

It is interesting for us to be the ones who have proved that our
protocol scales.  We can sit back and point to hard data that shows
hundreds of thousands of concurrent connections to single server
implementations, and millions of connected users in network.  Until a
real SIMPLE solution has been deployed on an Internet scale, I have
reservations about the real-world scalability of SIMPLE, due to the
complex presence polling and the end-to-end connectivity required.  I
also have concerns about whether IT administrators will be able to
adequately control the flow of traffic between their users and the
outside world.  Jabber provides all of these things, today.

> 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?

A lot of the implementation details in a server can boil down to pub/sub
operations.  Examples:

- Sessions
- Presence
- Text Conferencing
- Profile information
- Calendaring

I think a sufficiently generic pub/sub protocol could be used to
implement these higher-level services, but still be used for news feeds
and the like that are direct consumers of pub/sub.

Queuing systems usually do some form of guaranteed delivery.  A more
end-to-end delivery guarantee mechanism could be built on top of the
current protocol.  Queuing systems are also usually pull-based, rather
than push.  This allows automatic load balancing and fail-over, since
consumers only request the next message when they are finished with the
previous one.  A similar system could be built on XMPP using an IQ/get
to request a packet, and an IQ/result when/if a packet is available on a
given queue.

For both pub/sub and queuing, sending the actual message contents in the
notification leads to less race conditions.  Once we have better
filtering at the server (ala JEP-0016), this won't be as much of an
issue, spam-wise.

One reason why queuing and pub/sub get mentioned a lot together is that
since they have similar semantics, Sun put both into JMS
(http://java.sun.com/products/jms/).  Yes, it would be cool to have a
JMS binding for Jabber that did both guaranteed delivery queues and
pub/sub.

> 4. How do you think ownership of the trademark on the Jabber term
should
> be handled?

I see this as a business question, and NOT a technical question.  The
Council exists to make technical decisions.  The Board should deal with
questions like this.
 
> 5. How do we establish trust between servers on an Internet scale?

This is really hard.  It's not bad on a per-peering-agreement basis,
where we can just exchange secrets or certificates.  But establishing a
priori trust with a domain you know nothing about?  I'm not sure if that
even makes any mathematical sense.  Trust and anonymity are really hard
to do simultaneously.  That being said, deciding on a set of root
Certificate Authorities, and requiring servers to have a valid,
CA-signed certificate would help some.

Perhaps PingID (http://www.pingid.com), Andre's new company, will come
out with something that does domain-level identity management, rather
than personal identity.  Something that answers the question "Is this
connection from an organization that has the reputation associated with
this domain name."
 
> 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 think there needs to be an in-band large payload protocol.  It should
be used as a fall-back in times when no other transfer mechanism will
work.  I also think there needs to be a well-defined JEP-0020 feature
negotiation for deciding which transport mechanism will be used.
 
> 7. How can the growing complexity and functionality of the Jabber
protocol
> be balanced with simplicity and developer-friendliness?

By continuing to strive for protocols that are generic and flexible.
Purpose-built, single-use protocols are contrary to simplicity, and if
not to developer-friendliness, at least to
library-developer-friendliness.  I think the protocols that will be used
the most are the ones that can be used in ways the protocol writer
didn't even imagine.

> 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?

If the IETF forms a working group, the technical members of the JSF
community will really need to participate in that group, to ensure that
we continue to control the protocol.

I strongly believe that the IETF is a really good mechanism for us to
push for the further adoption of our protocol.  I also believe that
we'll get some good feedback from the new participants in the process,
particularly with respect to security.  Yes, we are opening up our
"closed" community to more scrutiny, and we'll have to work a little
harder to make our voices heard, but the JSF is currently the repository
of world-wide XMPP expertise.  If we remember that, and work within the
IETF process, we'll end up with a better overall protocol than if we
keep to ourselves.

(I've said XMPP here a few times, but I'd like to point out that the
choice of name for the protocol is a business/political one, and NOT a
technical one.  Frankly, I continue to not feel strongly one way or the
other about the name of the protocol.  Note that I'm not running for the
Board.)



More information about the Members mailing list