[JDEV] IETF, Jabber, etc..

[Scott Robinson]

Interleaved response.

Scott.

* Thomas D. Charron translated into ASCII [Fri, Sep 10, 1999 at 11:46:17AM -0700][<EGAFCMJKKNBCHAAA at my-deja.com>]
[snap]
> 	The IMPP standard is geared at MORE then JUST IM, and IM is what we've been looking at, but there is MUCH more to it then I would have thought about BEFORE the meeting.  Presence notification is a whole different ball of wax then just simple IM, and giving the ability to IM accross networks, etc..
> 

I've mentioned it in previous posts, but I'll go further into it here. I'm
working on a "guise" transport which addresses this issue.

> 	Now, I'm not saying that IMPP and jabber don't mix.  I'm just saying we're currently working more on one particular layer of the cake.  A long time ago, in an archive far far away, someone said while we where discussing feature negotiation, that a client may respond to a file transfer with "Please Don't, I'm a TOASTER".  I still love that line, but here's my getcha.  What can jabber, as it stands now, or even in the near future, going to DO for a toaster?  My toaster certainly won't have a buddy list, so when I turn it on, it's isn't going to announce it's presence, nor would I want it to.  But how can I get data from it?  Do I want it on a buddy list?  Hell no.  May I want to get data to it or from it, hell YA!  Right now, we're not in that direction.
> 

toaster at appliances.scotthome.net will be set remotely by control software on
my workstation to begin browning my auto-buttered toast.
refrigerator at appliances.scotthome.net will reduce the temperature when I'm
gone, and when I'm in the house it will increase. My detector (of when I'm
in the house) will be frontdoor at appliances.scotthome.net.

In my view of the future, most of the IM traffic will not be between users
but instead between user clients.

> 	One of the things that came out of the pulver.com summit is that we're in a big, BIG world, and there's more to IM and presence then we seem to be looking at.  The Cisco, Worldnet, and even Erikson guys made some points that made me think.
> 

If people would just listen to my spews on #jabber. ;)

[sna]
> 	Let's say my Jabber id itself is tcharron at jabber.org.  Now, my Cell phone may me 6031234567 at cellphone.jabber.org.  My pager, 167289 at mobilecom.jabber.org.  My toaster toaster at appliances.tomshouse.net.  I know, that these seem silly, but bear with it and try to suspend reality.
> 
> 	Now, jabbertransport right now, is geared twards sending and recieving of IM.  Sure, we can do more with it, but that's what it's really geared for.  To, From, Subject, etc..  That's IM land.  It's NOT really presence geared.  What if we had a transport that was geared twards just that, presence.  This transport could actually serve as a metatransport to the others.  I can register lots of things, and all of them have different addresses, but my presence data would all be available and configurable via this one transport.  I could dynamically have it route messages how I wanted them routed.  We've geared this twards being inside of jabbertransport, but why?  Jabbertransport is an IM base, NOT a PRESENCE base.  With a presence base, you COULD connect to a server anonymously somewhere, send a message validating yourself to the presence transport, and bingo, anyone looking at your presence would be able to see your online, even though you aren't logged into jabbertransport, an!
d !
> perhaps not even be reachable by IM.
> 

The guise system is an anti-spam, unified account, and presense transport.
It takes all your jabber accounts and has two layers of message movement.
Net-side is has the guise system. It allows you to have UNLIMITED user-names
under a single user-hash. I can be
"scott at guise.jabber.org/674522e7efcda98898badaf810324c2103d2e19c" but I can
also be "superjoe at guise.jabber.com/<shasum>". With this I can enable and
disable various accounts and have a semi-single address.

User-side it filters and map these various accounts to proper rules.
scott at guise would check my online "user" accounts and relay the message the
appropriate one(s). superjoe at guise would probably route to abuse@<network>,
the network being the spammer's, resolved by one of my guise filters.
However, I'd also have my private srobinson at guise which my close friends
would have. No spam worries there. rcontrol at guise would route to my firewall
and allow me to send remote configuration information. This, and more, is
what I envision my guise transport to be used for.

[snap]
> 	Hypothetically, this COULD all be incorperated into jabbertransport as it stands now, but why?  IM is one thing, presence is totally different.
> 

Ahmen. Jabbertransport is only for JABBER protocol IM. We have to remember
that the transports are not only transient but also two-way. You hear
"transport" and most people think "that's how we send data to other
networks." What I see the transport system _really_ being used for is to
support hooks to various secondary abstraction protocols. (GSM/SMS, a
low-bandwidth pager system, even a web-based jabber system.)

[snap]