[15:15:44] --- sayrer has become available
[15:25:17] <ken> ping
[15:26:23] <sayrer> ping
[15:31:58] --- danbri has become available
[15:32:06] <danbri> hi
[15:32:39] * danbri re-enters the futuristic world of jabber
[15:33:03] * ken wonders if XChat does jabber...
[15:33:12] <danbri> not afaik, sadly
[15:33:39] <danbri> I assume I18n stuff just works, by contrast with the horrors of charsets in irc...
[15:33:57] <danbri> (have been wondering about migrating the #rdfig IRC channel to Jabber... or bridging, at least)
[15:34:57] <ken> one would hope i18n works, but xmpp does have an odd sense of what constitutes an "XML instance" ;)
[15:35:13] <danbri> uhoh
[15:35:37] <ken> it's a "stream of xml" delineated by top-level elements... only.
[15:36:34] --- danjay has become available
[15:37:35] <danbri> mini i18n test: Alef أ Baa' ب Taa’ت の日本語訳集
[15:37:41] <danjay> ping!
[15:37:53] <danbri> hmm not clear that gaim liked having fancy characters pasted in
[15:37:54] <danbri> hi
[15:38:01] <danjay> how do you do a C cedilla?
[15:38:21] <danbri> no idea. i was pasting chars from web pages in mozilla. offtopically.
[15:39:18] <ken> looks pretty good from here
[15:39:23] <sayrer> Content-Type: application/xml;charset=iso-8859-1 <Björn/>
[15:39:29] <danbri> you saw arabic + japanese ?
[15:39:34] <ken> haven't crashed Gaim... yet
[15:39:37] <ken> yes
[15:39:55] <sayrer> I see the arabic
[15:39:57] <danjay> xchat looks irc-only
[15:40:00] * danbri checks terminal log, sees the raw XML in unicode terminal, looks fine.
[15:40:07] <sayrer> get squares for the japanese
[15:40:08] <danbri> odd that gaim can't display it.
[15:40:18] <ken> I'm not sure the arabic looks complete, but some characters for sure came through
[15:40:20] <danbri> prolly just missing fonts
[15:40:23] <sayrer> yeah
[15:40:30] <danbri> it was only 3 chars of arabic
[15:40:33] <ken> I got japanese characters. must be fonts
[15:40:46] <ken> ah, yes I got three arabic characters.
[15:40:58] <danbri> from http://faizateachesyouarabic.blogspot.com/ btw
[15:41:11] <danbri> so this encourages me towards Jabber again
[15:41:25] <ken> jabber's a little easier to bot with, too
[15:41:47] <danjay> Çelik,
[15:42:34] <danjay> need bigger monitor
[15:44:00] <sayrer> gotta tryout a pubsub.com jabber feed, too
[15:44:45] <danbri> are jabber channels bound tightly to one server? no notion of a network a la IRC?
[15:45:09] * danbri always assumed so, and vaguely uncomfortable with that... but i guess i live with mailing lists being hosted on a single server...
[15:48:34] <ken> yes, bound to a server. basically, we're all "messaging" one Jabber endpoint and it's echoing it back to the rest.
[15:49:12] --- rubys has become available
[15:49:17] <ken> thar we go!
[15:50:35] <danbri> hi sam
[15:51:06] <rubys> Iñtërnâtiônàlizætiøn
[15:51:14] <danbri> :)
[15:51:17] <rubys> cool. seems to work.
[15:51:40] <danbri> <message from='atompub@ietf.xmpp.org/danbri' to='danbri@jabber.org/Gabber' type='groupchat'><body>mini i18n test: Alef أ Baa' ب Taa’ت の日本語訳集</body></message>
[15:51:51] <danbri> I like that I can see the protocol guts in my terminal window
[15:52:10] <rubys> danbri: what client?
[15:52:16] <danbri> gaim
[15:52:29] <danbri> i think it was a preference i switched on somewhere
[15:53:15] <ken> not only that, but you can paste protocol guts and have it work too!
[15:53:42] <sayrer> right clicking the input textbox gives you some interesting i18n features
[15:54:05] <danbri> not in mine
[15:54:22] <rubys> I like the option "Thai(broken)"
[15:54:29] <danbri> is this room logged yet? vaguely recall all the ietf channels being logged
[15:55:19] <rubys> http://www.xmpp.org/ietf-logs/atompub@ietf.xmpp.org
[15:55:37] <danbri> great
[15:55:39] <rubys> logs aren't utf8
[15:56:21] <ken> ouch ;)
[15:56:37] <danbri> HTTP server claims Content-Type: text/html; charset=iso-8859-1
[15:56:38] <rubys> More precisely: logs appear to be utf-8, but the encoding is not declared such, so the default is iso-8859-1
[15:56:43] <danbri> but they look better in utf-8 ;)
[15:56:50] <danbri> yeah, what sam said.
[15:57:15] <rubys> view -> character coding -> utf-8
[16:01:04] <danbri> chatting w/ stpeter
[16:01:10] <danbri> he's going to fix the httpd.conf
[16:01:38] --- sayrer has left
[16:02:13] <rubys> rubys cheers
[16:02:26] <rubys> arg. font information doesn't seem to survive.
[16:02:37] <rubys> Is there any way to "emote" using gaim?
[16:04:10] * danbri just types /me
[16:04:25] * ken found that intuitive
[16:04:35] <danbri> "<body>/me just types /me</body>" suggests the protocol doesn't care
[16:04:58] <ken> ah, Gaim then. that's funny.
[16:05:16] <ken> probably explains why it works in Y! too and me wife always thinks it odd
[16:05:39] <ken> it *seems* to work in Y!, that is
[16:05:55] * rubys test
[16:05:58] <rubys> weird
[16:06:13] <rubys> the underlying protocol for emoting is really weird in IRC
[16:06:15] <danbri> I do it in ichat/aim anyway. people i talk to have mental irc parsers :/
[16:07:50] <danbri> I talked a bit with qmacro about strategies for migrating IRC-based hangouts across into the shiny Jabber future... http://esw.w3.org/topic/JabberChickenEgg
[16:08:30] <danbri> would be easier if everyone on freenode used the nickserv system, esp if we wanted full 2-way proxying...
[16:08:49] <danbri> but it gave me too much of a headache :(
[16:11:14] <ken> the nice thing about jabber seems to be that you can create a lighter-weight server. you can distribute channels more easily, rather than trying to scale both channels and users.
[16:11:45] <danbri> yes
[16:12:00] <ken> now that there's a jabberd with a reasonable install...
[16:12:34] <danbri> I'd like to see W3C move over from IRC to Jabber... but nobody seems motivated enough yet. I often think that FreeNode is the key. If those channels could be gated across somehow, ...
[16:15:22] <ken> and think, we might even see how we can do resource-update notifications ;)
[16:16:40] <danjay> early night - night all O:-)
[16:16:57] --- danjay has left
[16:24:33] <danbri> encoding problem fixed (thanks to stpeter and co)
[16:39:01] --- rubys has left: Disconnected
[16:46:03] --- stpeter has become available
[16:46:36] <stpeter> BTW, we have gateways from Jabber to IRC but I'm not aware of any from IRC to Jabber -- will look into that
[16:48:27] <stpeter> brb
[16:48:28] --- stpeter has left
[16:48:42] --- stpeter has become available
[16:49:34] <ken> I wonder how difficult a two-way gateway would be. iirc, IRC server <-> server seems to be all channels, not just select channels.
[16:49:35] --- bobwyman has become available
[16:49:45] * stpeter nods
[16:49:49] <stpeter> hey bob
[16:50:03] <ken> if one could gateway just one IRC channel with the IRC server-server protocol, that would do the trick
[16:50:27] <bobwyman> greetings peter...
[16:50:45] <stpeter> ah
[16:50:58] <stpeter> we've looked at setting up an IRC node on irc.jabber.org
[17:01:09] --- sayrer has become available
[17:01:32] <bobwyman> Is that Robert Sayer?
[17:02:14] <sayrer> yes it is
[17:02:31] <bobwyman> Good afternoon and congratulations on your new post at the IETF!
[17:03:07] <sayrer> good afternoon and thanks!
[17:05:02] --- rubys has become available
[17:06:44] <bobwyman> Good evening Sam...
[17:06:50] <rubys> hi bob!
[17:09:20] <bobwyman> Sam, you might be interested to know that we've been making pretty good progress on figuring out how to do Atom syndication via the Jabber/XMPP pubsub support. We've got most of it running on our site now and are just waiting on getting some protocol issues resolved in the Jabber JIG... And, we've got some Jabber client developers who've promised to build support for it. This is going to be interesting...
[17:09:45] <rubys> EXCELLENT!
[17:10:30] <rubys> are there any security considerations that are worth mentioning?
[17:10:41] <bobwyman> It would, however, be *really* nice if we didn't have to put a <feed> wrapper around the entries we're sending. In this context the <feed> thing doesn't really add much value...
[17:11:11] <rubys> "it's the entries, stupid"
[17:12:16] <bobwyman> Security: Just logging into the server. At this point, for a "public" service, I think we're ok. The nice thing is that in the future, we'll be able to arbitrarily complex authentication/authorization stuff. But, to start, if you can log in, you can access the feed.
[17:15:19] <rubys> where "feed" is a stream of entries.
[17:16:34] <rubys> BTW, I am in no way emotionally attached to the outer "feed" element.
[17:17:15] <bobwyman> Hmmm... I hope others agree with you/me on this...
[17:17:47] <rubys> do you have anything written up outlining what a jabber solution would look like from a topology point of view?
[17:20:09] <bobwyman> No. There are some issues with the Jabber protocol at present (or, it's implementation) that make things hard to do right. The problem is that jabber servers typically are fairly strict in controlling the data rate between network components. All servers are currently "tuned" for chat traffic -- but atom feeds are much fatter... So, we'd get kicked off any existing Jabber network in a moment.
[17:20:40] <bobwyman> The result is that we're currently pure hub-and-spoke. You have to use client-to-server to connect directly to xmpp.pubsub.com.
[17:20:50] <rubys> even when scaled back to an entry level?
[17:21:05] <bobwyman> In the future, we should be able to use the full Jabber network to handle fan-in and fan-out...
[17:21:32] <bobwyman> "scaled back" is still pretty fat. I'll send a sample message in a moment and you'll see what I mean...
[17:23:01] <rubys> has the XMPP protocol working group disbanded?
[17:23:56] <bobwyman> Sample message with one entry:
<message to='sample_at_pubsub_dot_com@xmpp.pubsub.com'
from='pubsub-delivery@xmpp.pubsub.com' >
<event xmlns='http://www.jabber.org/protocol/pubsub#event'>
<items node='66271d2e70372c1b4dc5b46e79a6f001'>
<item id='6802'>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='subid'>pubsub/subs/1111111111</header>
</headers>
<pubsub-message xmlns="http://www.pubsub.com/xmlns">
<feed xmlns="http://purl.org/atom/ns#"
xmlns:ps="http://pubsub.com/xmlns" version="0.3" xml:lang="en-us">
<title>PubSub Weblogs</title>
<modified>20040507T00:09:46-0500</modified>
<entry>
<ps:source-feed xmlns="http://pubsub.com/xmlns#sourcefeed">
<title>A Sample Blog</title>
<link rel="alternate" type="text/html"
href="http://example.com/index.html"/>
<link rel="alternate" type="text/xml"
href="http://example.com/atom.xml"/>
<modified>2003-12-13T18:30:02Z</modified>
<author>
<name>Bob Wyman</name>
</author>
</ps:source-feed>
<title>The title of the entry</title>
<link rel="alternate" type="text/html"
href="http://example.org/2003/12/13/atom03"/>
<id>tag:example.org,2003:3.2397</id>
<issued>2003-12-13T08:29:29-04:00</issued>
<modified>2003-12-13T18:30:02Z</modified>
<content type="text/html" mode="escaped" xml:space="preserve">
This is the text of the entry. This is <b>bold</b>.
</content>
</entry>
</feed>
</pubsub-message>
</item>
</items>
</event>
</message>
[17:24:07] <bobwyman> It's kind of fat....
[17:25:52] * rubysssage/event/items/pubsub-message/feed/entry
[17:26:17] <rubys> message and entry are clearly required... what about the rest?
[17:26:26] * bobwymanssage/event/items/item/pubsub-message/feed/entry (You forgot "item")
[17:26:50] <rubys> ah, I misread the indentation.
[17:27:33] <bobwyman> items and item are required by JEP-0060. They are there to allow multiple items to be sent in one message.
[17:28:14] <bobwyman> The silly thing is that we've got a multi-item feed being reduced to a single entry so that it can be published over a channel that supports multiple items....
[17:34:42] --- sayrer has left: Disconnected
[17:35:57] * stpeter returns and scrolls up
[17:38:27] <bobwyman> Both Jabber Messages and Atom Feeds are mechanisms for transferring/packaging multiple items. It's too bad they are so different when the are doing much the same thing...
[17:39:18] <bobwyman> "when they are doing much the same thing..."
[17:39:59] * stpeter surfs to http://www.xmpp.org/ietf-logs/atompub@ietf.xmpp.org/2004-06-17.html for reading purposes
[17:40:03] <rubys> atom isn't cast in stone yet...
[17:41:57] <bobwyman> I would like to believe that it might be possible for Jabber and Atom to agree on what the "multi-item" wrapper looks like... It would, I think, serve both communities very well...
[17:42:24] <stpeter> rubys: the XMPP WG has completed its charter items and we need to figure out whether to (1) recharter or (2) just keep working on extensions in the Jabber Software Foundation's standards process
[17:42:48] <rubys> in any case, the people are still around, right?
[17:43:09] <stpeter> oh yeah, we're working in the JSF, which is the organization that created these protocols in the first place
[17:43:37] <stpeter> http://www.jabber.org/jeps/ describes our standards process
[17:43:51] <bobwyman> What about Marshall Rose, Lisa, etc.? Do they participate in JSF stuff or where they IETF only?
[17:43:58] <stpeter> we may just keep working there to (1) lessen the load on the IETF and (2) keep cranking out extensions
[17:44:11] <rubys> stpeter: have you looked at the xml message bob posted above?
[17:45:00] * ken also sees no problem using distinct Atom document types, like standalone <entry>s. that's what the API does, after all
[17:45:03] * stpeter scrolls up
[17:46:28] <bobwyman> ken: Of course, to have standalone entries, we'd have to resolve the "feed-meta-data" issue. i.e. What parts of the feed-level data need to be copied into an entry if it is stand alone?
[17:46:32] <stpeter> rubys: yes, we've been having some active discussions about how to send ATOM feeds over Jabber/XMPP via the pubsub mechanism bob referred to
[17:48:05] <stpeter> but i've been out sick and then dealing with some other stuff so i have some catching up to do
[17:48:59] <ken> I've been mulling that over still. I think I'm leaning towards all resources being independent. this would make <entry>s similar in scope to email/usenet messages in which "source information" they carry with them, like from (feed/author), copyright, organization (feed/title).
[17:49:27] <stpeter> ken: "that" = many vs. one entry?
[17:50:28] <ken> that = how to select an entry from some feed and copy it to another feed, while still having the entry have its own metadata
[17:50:41] <stpeter> ah
[17:52:17] <ken> I'm not too fond of "feed of feeds" or inverting the feed data into the entry. I babbled about this in IRC yesterday, but no one was there to chat about it ;)
[17:52:21] <ken> http://www.ilrt.bris.ac.uk/discovery/chatlogs/atom/2004-06-16.html#T16-01-26
[17:52:30] <bobwyman> stpeter: This is a continuation of a discussion on the list. The problem arises when you build synthetic feeds (constructed from entries taken from multiple feeds) or when you want to distribute Atom entries over something like Jabber/XMPP. The question is how much, if any, *feed specific* context is needed to maintain the semantic meaning of the entry...
[17:53:08] <stpeter> hmm, the atompub list is not on Gmane
[17:53:22] <stpeter> i'm transitioning all my list subs to Gmane and a newsreader
[17:53:24] <stpeter> email is a slum
[17:53:37] * stpeter contacts the good people at gmane.org
[17:55:15] <bobwyman> Ken(bitsko) wrote on ICQ yesterday: "would it be better if the synthesized feed were to take a limited amount of information from the original feed (author, copyright), copy it *into* the entry, then let the consumer process the entry "as is". then, a link back to the origin is just information, not necessary for immediate processing."
[17:55:36] <bobwyman> I think the answer is *YES*...
[17:55:40] <ken> if we were to keep things pretty much "as-is", then I might lean towards taking specific inherited feed elements and copying them into their corresponding entry element
[17:57:39] <ken> what might be better than just "as-is" is promoting the concept of standalone entries altogether. that's a pretty big switch from current practice, tho
[17:59:19] <bobwyman> At the meeting at Sun, the sixapart guy said that they would like a way to handle entries in isolation since they often insert a single entry into multiple feeds: (i.e. various category feeds, the "current" feed, an archive feed, etc.) Even though the entry appears in many places it is still just "the entry." He was suggesting very *little* inheriting from the source feed...
[18:03:10] --- timbray has become available
[18:03:26] <stpeter> ok, atom-syntax has been added to gmane
[18:03:32] <timbray> I'm a space-age jabber kid
[18:03:36] <stpeter> hehe
[18:04:30] <stpeter> personally i'm working to transition away from email :-)
[18:05:00] <timbray> will any of my IRC reflexes work here or am I back in total noob territory?
[18:05:20] <stpeter> oh yeah some IRC stuff works, but not all
[18:05:29] <stpeter> mainly /me and /nick
[18:05:37] <stpeter> some clients do /help
[18:05:51] <timbray> no /msg?
[18:05:59] <stpeter> i'm working to encourage support for more IRC commands
[18:06:21] <stpeter> timbray: usually in your client interface you have a "room roster" and you can double-click or right-click people there for side conversations
[18:06:24] <ken> depends on the client. apparently /me is sent literally, and the client renders it as emoting
[18:06:33] <ken> /msg timbray ping
[18:06:34] --- paulehoffman has become available
[18:06:38] <ken> heh, no /msg ;)
[18:06:57] <paulehoffman> Wow, Tim said some people were here.
[18:08:09] <ken> /msg doesn't work, but selecting the person from the sidebar and IM'ing them seems to do the trick ;)
[18:08:21] <timbray> and this is better than IRC why?
[18:08:36] <stpeter> paulehoffman: i just requested gmane to add atom-syntax to its list
[18:08:46] <timbray> what's gmane?
[18:08:48] <stpeter> timbray: we have SASL, TLS, presence, etc.
[18:08:59] <stpeter> gmane is an email list to NNTP service
[18:09:05] <stpeter> http://www.gmane.org/
[18:09:14] <paulehoffman> Gmane is a big collection of mailing list archives. It's cool with me.
[18:09:33] <stpeter> i'm trying to wean myself from mutt
[18:10:05] <stpeter> timbray: plus we have logical addressing, so you don't expose your IP address as you do on IRC
[18:10:11] * timbray peruses the menus trying to figure out a way to remember this server/room
[18:11:02] <stpeter> timbray: plus it's all XML :-)
[18:11:14] <timbray> well it must be good then
[18:11:19] <stpeter> streaming XML, which may not be what you intended....
[18:11:51] <stpeter> Jeremie Miller (inventor of this technology) was a bit creative when he thought up streaming XML
[18:11:56] --- carlb has become available
[18:12:14] <timbray> yeah, I know what they do. Yeah, nobody anticipated that. Hey, it seems to work.
[18:12:29] * stpeter nods
[18:12:31] * ken has to leave just as everyone is showing up. bummer
[18:12:33] <timbray> I would have done it as a sequence of microdocuments as opposed to one big long one, but hey, I didn't do it
[18:12:36] <ken> tty'all later!
[18:12:39] <stpeter> ciao
[18:13:03] --- ken has left
[18:13:04] <stpeter> it turns out there are nice efficiencies from not having to instantiate an XML parser every time
[18:13:05] <paulehoffman> <gotta learn how to do those action things like nodding>
[18:13:13] <stpeter> paulehoffman: /me nods
[18:13:16] <stpeter> like IRC
[18:13:22] * paulehoffman laughs
[18:13:43] * paulehoffman pulls that knowlege from about 20 years ago
[18:14:03] <bobwyman> Framing is a bit of a challenge with streaming XML... Some folk still like BEEP... It's like XMPP but it had counted frames so parsing was easier...
[18:14:08] <paulehoffman> Gotta run as well. See y'all on the mailing list.
[18:14:19] * paulehoffman disappears in a puff of smoke
[18:14:27] --- paulehoffman has left: Disconnected
[18:15:19] <bobwyman> Other than history, why aren't email messages, nntp messages, atom entries, and Jabber/XMPP event messages all the same format?
[18:15:34] <stpeter> ooh, i could change the leave message so it says "user disappears in a puff of smoke"
[18:17:41] * stpeter changes the room config
[18:19:22] <stpeter> brb
[18:19:24] --- stpeter disappears in a puff of smoke
[18:19:31] --- stpeter materializes out of thin air
[18:19:50] <stpeter> heehee
[18:20:34] <stpeter> it's the little things in life...
[18:39:47] --- stpeter disappears in a puff of smoke
[18:39:57] --- timbray disappears in a puff of smoke
[19:02:36] --- sayrer materializes out of thin air
[20:57:41] --- sayrer disappears in a puff of smoke: Disconnected
[21:55:52] --- rubys disappears in a puff of smoke
[23:28:10] --- carlb disappears in a puff of smoke