[JDEV] Proposals (file transfers and info/query)

Tue Aug 10 16:32:15 CDT 1999

Interleaved response.

Scott.

* Jeremie translated into ASCII [Tue, Aug 10, 1999 at 01:28:33PM -0500][<Pine.LNX.4.10.9908101302340.22307-100000 at lor.jeremie.com>]
> > Are you impling that instead of encoding our messages in MIME, that we
> > encode them with some HTTP headers on the top? I'm going to assume not.
> 
> No no, not at all... I think we are talking about two different issues :)
> 

Probably. In this e-mail I'm going to make clear what I'm talking about in
reference to MIME. Allen Short has suggested that I rename my CTCP arguments
to "feature negotiation" and presense announcement. This will be covered in
a seperate e-mail.

> I'm speaking strictly of file transfers ala the file transfer proposal and
> HTTP, and I think you are talking about the <message></message> packet
> within the Jabber protocol.
> 

Correct.

> Honestly, I'm quite against adding any sort of MIME layer onto the Jabber
> protocol or <message/> packet itself for lots of reasons.  First, instant
> messaging is all about simple instant text messages, not a one-to-one web
> page delivery service.  Second, Jabber is all about talking transparently
> to other IM systems, many/most of which do not and could not support MIME
> messages.  Third, everything that a client needs to do with MIME can be
> done via file transfers, and in this way be more widely supported even
> across other IM systems.  Finally, it would increase the complexity
> significantly of the Jabber protocol.
> 

I'll address your problems in order.

1) It's all about the ASCII baby.
Jabber is about talking to other IM systems. However, in your short absense
I assume, Jabber has also become about talking to each other. What you want
is a system where you can communicate usably with many IM systems but do it
all in ASCII. You can't have both. Not unless you've decided Jabber is to be
only for hackers, coders, and unix users. As an easy example, AIM uses a
text formatting language similar to HTML and rich text. When an AIM user
comes to Jabber seeking the ability to use all the messaging systems,
they're going to be immediately asking "where are my bolds, italics, and
underlines?" We cannot place those extensions within the current <say> tag.
We cannot place those extensions within the client specific <ext> tag. We
have to place them within a retooled <message><say/><message> tree. Through
long arguments on this list, it's been generally agreed upon MIME is the way
to go about this.

2) What about those that can't support MIME messages?
We don't send "MIME messages" to another system. The transport that receives
a message parses it like any other client would and relays it to the other
IM network. (That is an over-simplification, but it works for this example.)
Whether that message is <message><say>Blah.</say></message> or it's <message
encoding="utf-16"><say type="text/html" encoding="utf-8" length=39><html><bold>Treat me
bad.</bold></html></say></message>, the "client" will still have to parse
it. I see a MIME-workalike actually decreasing our work rather than
increasing it with the extensions that will be made later.

3) It can all be handled by FTP
You're right. It can. You can also "surf" the web through e-mail gateways. I
really hope my two line message saying "Hey Jer!" encoded in plain/html
doesn't require a client to learn HTTP to receive it. In short, it's
overkill and in some situations, the wrong solution.

> IMHO, messages should be just simple text messages.  Jabber is an
> expression of the base and common elements of ALL instant messaging
> systems, not a radically advanced new next generation IM system.
> 

In the MIME-workalike I have ready to post, simple text messages are still
alive and well. However, the MIME system is still simple. It also helps us
when we come to future work. I would rather have MIME implemented now and
supported from the beginning than later when you don't have such tight
control over the protocol.

> I *DO* think I see what you are getting at (finally) and where you are
> coming from, that you want to create that "radically advanced new next
> generation IM system", and you're in luck, so do I, but it's not
> what Jabber has been about :)  With further discussion on this topic
> though, Jabber might be able to fit the bill... if not, I don't have a
> problem creating another team to explore creating a new IM system with
> it's own server and clients, and a Jabber transport to that system.
> 

No, I do not want to create a "radically advanced new next generation IM
system." What I want in Jabber is a simple transport for all IM systems to
interoperate. I hope later in Jabber's evolution there will be a transport
for the "radically advanced new next generation IM system" that you and I
will build; however, I can't see Jabber allowing support for our system or
even currently existing systems without a few bare minimum extensions on our
currently OVER-simplified protocol.

> > I don't see how LDAP mapped to our XML system would in anyway limit the
> > usefulness of the info/query protocol. The examples you have given are
> > wrapped into the LDAP idea almost the same way they're wrapped into the
> > current Info/Query protocol.
> > 
> > I'm not suggesting USING LDAP, but instead wrapping its spec into our XML
> > stream ala MIME in Jabber.
> 
> Ok, just using the textual LDAP query structure but passing it via XML,
> right?  Not sure what you would gain from that since all of the tools and
> libraries in the sources are geared towards handling XML and the rest of
> the functionality in the protocol is normal XML...  then again, I don't
> have experience with LDAP at that level yet.
> 

And the Scott-a-beast, once awake, realizes the folly of its ways. Quickly
attempting to maintain the pack's respect it trys to divert their attention
to where he is making sense. (a few paragraphs up everyone!)

Jer, I was on crack. Ignore all LDAP in XML posts I've made.

> Jer
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev