Logs for jdev
[00:28:11] * julm left the chat.
[00:28:19] * julm joined the chat.
[00:34:58] * Neustradamus joined the chat.
[01:15:41] * MattJ left the chat.
[01:54:43] * scippio_netbook left the chat.
[02:03:50] * Florob left the chat.
[02:26:39] * bear left the chat.
[05:35:10] * teo1 joined the chat.
[06:00:20] * julm left the chat.
[06:00:21] * julm joined the chat.
[07:09:34] * julm left the chat.
[07:09:39] * julm joined the chat.
[07:53:57] * abhinavsingh joined the chat.
[08:07:45] * ermine joined the chat.
[08:51:56] * Tobias joined the chat.
[09:48:01] * dwd left the chat.
[09:52:14] * Sebastian joined the chat.
[10:01:54] * smoku joined the chat.
[10:04:35] * Treebilou joined the chat.
[11:02:17] * Tobias left the chat.
[11:03:24] * Tobias joined the chat.
[11:34:35] * Zash joined the chat.
[11:41:00] * holberg joined the chat.
[11:41:21] * holberg left the chat.
[13:12:37] * Kev left the chat.
[13:12:58] * Kev joined the chat.
[13:25:08] * Asterix left the chat.
[13:25:17] * Asterix joined the chat.
[13:43:23] * mlundblad joined the chat.
[15:24:12] * Zash left the chat.
[15:24:15] * Zash joined the chat.
[15:46:50] * Zash left the chat.
[15:46:53] * Zash joined the chat.
[15:50:44] * Zash left the chat.
[15:50:49] * Zash joined the chat.
[16:07:51] * Zash left the chat.
[16:44:14] * Florob joined the chat.
[17:16:29] * luna left the chat.
[17:17:09] * jonas joined the chat.
[17:24:45] * Tobias left the chat.
[17:27:41] * luna joined the chat.
[17:28:26] * s@y joined the chat.
[17:30:06] * Tobias joined the chat.
[17:31:41] * luna left the chat.
[17:36:00] * luna joined the chat.
[17:37:39] <luna> hi. i'm experimenting with service discovery and it's relationship to dns.
[17:39:26] <luna> when my client is connected to server a, and from within the client, i do a service discovery against server b (or domain
b) - does the client do all the the work without involving server a, or does server a do the work on behalf of the client?
[17:40:10] <Kev> Your client only has a connection to your server.
[17:40:17] <luna> it would appear to me, from my testing, that the client asks server a to do the work.
[17:41:19] <luna> so that would corroborate my test results.
[17:50:49] <luna> i'm using openfire, and see that there are a handful of various items that appear in my discovery browser. (broadcast, pubsub,
search, manager, updater, conference, so on…). these are clearly references to dns labels (e.g. _pres._xmpp.broadcast.example.com),
as i see the dns queries for them occurring. some of them appear to not be configurable - for example, manager and updater.
is this a deficiency in the server software i'm using?
[17:51:57] <luna> should i be able to configure these dns labels? they're generic enough that i think it would be quite possible there could
be a conflict with existing dns data.
[17:52:47] <Kev> There shouldn't be a conflict, because a service of e.g. pubsub.server.com should have a DNS SRV record of _xmpp-server._tcp.pubsub.server.com
[17:54:05] <luna> ah, whereas an existing dns entry (say, for example, there might exist pubsub.server.com - just by chance) would almost certainly
be an a record, not an srv rcord?
[17:55:15] <luna> *record
[17:55:50] <Kev> Correct.
[17:55:56] <jonas> it would have a _xmpp-server._tcp SRV-record, if it wouldnt be an XMPP server
[17:56:02] <Kev> XMPP will fall back to A records, but that's not how it should be.
[17:56:15] <Kev> jonas: "wouldn't"?
[17:57:13] <jonas> ah, heh, yes wouldnt
[17:59:23] <Link Mauve> Kev, so for a component, I shouldn’t have an A record, but only a SRV record?
[17:59:38] <Link Mauve> _xmpp-server too for a component?
[18:00:05] <luna> i see references to _pres._xmpp srv records appearing in dns lookups for quite a few of these services, but it looks like
their use is discouraged, as per section 8.2 of 3921bis. am i understanding this right?
[18:02:36] * s@y left the chat.
[18:02:56] * Tobias left the chat.
[18:03:18] <Kev> Link Mauve: You can have A too if you want, but you should have SRV.
[18:03:22] <Kev> And yes, _xmpp-server.
[18:04:25] <Link Mauve> Ok, I change my A to SRV.
[18:04:29] <Link Mauve> Thanks, Kev. :)
[18:04:41] <Kev> A will work, as I say, XMPP servers will use it as a fallback
[18:04:59] <Kev> But yes, SRV is 'right' :)
[18:05:07] <Kev> luna: Right, _pres isn't used.
[18:06:25] * Tobias joined the chat.
[18:06:45] <Link Mauve> Kev, what port should be used in the SRV record?
[18:07:01] <Kev> The port your server is listening on.
[18:07:05] <Kev> 5269 is the default.
[18:07:21] <Link Mauve> Yes, but the component won’t be accessed directly, right?
[18:07:45] <Kev> A component looks to the outside world exactly like another XMPP server.
[18:07:56] <Link Mauve> Yes.
[18:08:01] <jonas> it will be accessed by the server the user is connected to
[18:08:24] <Kev> So if jabber.org wants to talk to pubsub.you.com, it'll connect to the pubsub.you.com server directly.
[18:08:36] <Kev> Whether you.com exists or not as an XMPP server will be irrelevant to jabber.org.
[18:12:53] * teo1 left the chat.
[18:12:55] * teo1 joined the chat.
[18:13:12] <luna> Kev: if it's not used, then why do i see it being used? :)
[18:13:23] <Kev> OpenFire?
[18:13:45] <luna> am i using openfire? yes.
[18:13:54] <Kev> OpenFire does some strange (and some scary) things with DNS.
[18:14:01] <luna> oh, so that's openfire
[18:14:03] <luna> bah
[18:14:07] <luna> so that's openfire's fault?
[18:14:15] <Kev> I don't know.
[18:14:19] <luna> hmm
[18:14:27] <Kev> I am aware that openfire does bad things with DNS.
[18:14:32] <luna> ok
[18:14:37] <Kev> And I wasn't aware of anyone using _pres in the wild.
[18:14:45] <Kev> I don't claim that these two things are related :)
[18:15:38] <luna> right now, my client is connected with my jabber.org account, so i'm connected to hermes.jabber.org. i'm doing a service
discover against my domain, which is running openfire. i'm seeing _pres lookups coming from hermes.
[18:16:31] <luna> is your sense that hermes is doing those lookups because openfire told it to?
[18:17:08] <Kev> No.
[18:17:12] <luna> oh.
[18:17:19] <Kev> That's odd, I had no idea we did those lookups.
[18:17:22] <Kev> But there you go.
[18:17:31] <Kev> I wonder if 3920 (non-bis) mandated them.
[18:17:38] <luna> what causes hermes to do those lookups?
[18:17:45] <luna> is it something my client causes?
[18:17:46] <Kev> The software it's running.
[18:17:52] <Kev> Which, embarrasingly, I work on.
[18:17:57] <Kev> And I didn't know.
[18:17:58] <luna> oh, just internally?
[18:18:06] <luna> heh :)
[18:18:23] <luna> i wouldn't be to embarrassed.
[18:18:25] <luna> *too
[18:18:36] <luna> it seems to be a daily thing for me, lately.
[18:18:43] <Kev> Not that it's incorrect behaviour, I just had no idea that anyone used _pres, let alone us.
[18:19:06] <luna> if you're interested - http://dpaste.com/263166/
[18:19:23] <Kev> No, indeed, rfc3921 does say you should be resolving _pres.
[18:19:36] <Kev> So we're doing the right thing and I never knew.
[18:19:52] <Kev> I guess you don't have SRV set up?
[18:19:52] <luna> err - but then there's a bit of a contradiction, isn't there?
[18:20:08] <luna> http://www.ietf.org/mail-archive/web/xmpp/current/msg01453.html
[18:20:28] <Kev> That's not rfc3921, that's 3921bis.
[18:20:43] <Kev> i.e. 'The thing that is being worked on at the moment to replace 3921'
[18:20:50] <luna> oh, i see.
[18:21:12] <luna> so perhaps they will be formally deprecated at some point in the future - but as of right now, they aren not ?
[18:21:21] <Kev> Depends what you consider formal.
[18:21:23] <luna> *are not
[18:21:40] <Kev> Everyone* considers 392bis to be the correct thing to develop against.
[18:21:48] <luna> hmm.
[18:22:07] <Kev> 3920/3921 were 2004, we've got a lot of deployment experience since then.
[18:22:19] <luna> sure.
[18:23:08] <Kev> and bis is up for IETF last call, so it's clearly where the effort is being put.
[18:24:05] * abhinavsingh left the chat.
[18:24:46] <luna> so overlaying these considerations onto existing, active servers (from a sysadmin perspective) - the sensible approach would
be to publish and support these records, keeping in mind that in the future they may become unneeded?
[18:25:31] <Kev> No, the sensible thing is to do the Right SRV records (_xmpp-(server|client)._tcp.your.server.tld), and then no other resolution
[18:25:50] <luna> oohhhh…. now i'm following, i think.
[18:26:02] <luna> but… i do have those records.
[18:26:09] <Kev> Are you sure?
[18:26:13] <Kev> What server?
[18:26:15] <luna> pretty sure.
[18:26:18] <luna> dipswitch.net
[18:26:37] <luna> oh - wait a moment.
[18:27:07] <Kev> ; <<>> DiG 9.6.0-APPLE-P2 <<>> -t srv _xmpp-server._tcp.conference.dipswitch.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44081
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;_xmpp-server._tcp.conference.dipswitch.net. IN SRV
;; ANSWER SECTION:
_xmpp-server._tcp.conference.dipswitch.net. 300 IN SRV 10 0 5269 im.dipswitch.net.
;; Query time: 174 msec
;; SERVER: 192.168.1.11#53(192.168.1.11)
;; WHEN: Sun Oct 24 19:26:53 2010
;; MSG SIZE rcvd: 96
[18:27:11] <Kev> Nope, no record there.
[18:27:21] <Kev> ;)
[18:27:24] <Kev> So yes, maybe you do :)
[18:27:47] <Kev> Ah
[18:27:53] <Kev> But not for the other services.
[18:28:12] <Kev> updater, for example, is advertised but not in DNS.
[18:28:23] <luna> right. i've added only conference so far.
[18:28:29] <luna> ok, i believe i follow now.
[18:28:41] <Kev> (Not that there's any reason for that to be in DNS at all, or even to exist :))
[18:28:49] * MattJ joined the chat.
[18:28:50] <luna> well - that was another question.
[18:28:59] <luna> why do you say that?
[18:29:23] <Kev> It's some service used for autoupdating Smack clients isn't it?
[18:29:26] <Kev> Spark, rather.
[18:29:50] <luna> to be quite honest - i don't know with certainty, but i think so, yes.
[18:30:14] <Kev> Are you doing Spark autoupdates?
[18:30:18] <luna> i've got no use for spark, really, at the moment, so i don't know much about it.
[18:30:27] <luna> no, i'm not.
[18:30:33] <Kev> So that'd be my argument for why you don't need it :)
[18:30:45] <luna> sounds god to me, definitely.
[18:30:47] <luna> *good
[18:30:55] <luna> i wonder how i can make it go away :)
[18:31:07] <luna> i'll poke around more in the admin interface.
[18:32:09] * Hermitifier left the chat.
[18:34:01] * abhinavsingh joined the chat.
[18:34:51] <luna> so - if i'm understanding correctly - my goal would be to "not advertise the spark updater service"?
[18:35:34] <Kev> Well, it's not a terribly exciting goal, but if you're of the "Don't run services you don't use" school of sysadminning, yep.
[18:35:59] <luna> yeah, that's about right. anal, pedantic, and boring :)
[18:36:33] <Kev> Given the history, that sounds sensible.
[18:39:47] * Hermitifier joined the chat.
[18:45:23] <luna> i'm having a hard time finding out how i can turn off the spark updater service for openfire.
[18:45:42] <Kev> I don't remember having it when I ran openfire (a very long time ago), but maybe you can't.
[18:46:11] <luna> you may be right. i think i'll set it aside for now and move on to less unexciting things.
[18:48:10] <luna> it also advertises a "logger" service, and a "manager" service. do you happen to know what those might be for? my searching
so far hasn't revealed much.
[18:49:01] <Kev> I do not.
[18:49:08] <Kev> I suspect 'manager' is again something Spark-specific.
[18:50:25] <luna> oh, maybe you're right. i thought perhaps something to do with connection managers, in the context of bosh, but i've currently
got http binding off, so if that were the case, it surprised me to see it there.
[18:51:48] * ermine left the chat.
[18:56:35] * abhinavsingh left the chat.
[19:17:07] * Sebastian left the chat.
[19:28:59] * Tobias left the chat.
[19:29:04] * Tobias joined the chat.
[19:39:25] * johnny left the chat.
[19:39:32] * johnny joined the chat.
[19:46:23] * Zash joined the chat.
[20:07:04] * Tobias left the chat.
[20:07:26] * Tobias joined the chat.
[20:07:57] * Tobias left the chat.
[20:08:29] * Tobias joined the chat.
[20:08:33] * Tobias left the chat.
[20:16:38] <luna> aha. the logger and sipark services as part of the openfire sip phone plugin.
[20:18:17] * luna left the chat.
[20:18:53] * luna joined the chat.
[20:20:33] * Tobias joined the chat.
[20:22:33] * Lance joined the chat.
[20:22:43] * teo1 left the chat.
[20:22:44] * teo1 joined the chat.
[20:23:14] * Lance left the chat.
[20:27:30] <MattJ> luna, what does that plugin do, do you know?
[20:27:52] <MattJ> I have a SIP phone set up since this weekend, and am pondering how best it could be integrated with XMPP :)
[20:31:11] <Zash> Make it talk Jingle instead ;9
[20:31:56] <MattJ> Don't think I haven't thought about it :)
[20:32:15] <MattJ> But I think other people are more into audio stuff than I, and could probably do a better job of it
[20:32:25] <luna> MattJ: i'd installed it ages ago out of curiosity, but haven't yet used it, so i can't offer any firsthand insight - but the
readme says "The SIP phone plugin lets you configure SIP phone support in Spark from the server. Spark clients will read the
SIP configuration from the server. Once configured Spark will let users make and receive phone calls. From the admin console
you can monitor the phone calls."
[20:32:42] <MattJ> Ah, ok, SIP for Spark
[20:32:44] <MattJ> Boring then :)
[20:33:18] <MattJ> I'm thinking more of having Prosody update my PEP/status to "On the phone" automatically, etc.
[20:33:19] <luna> looks that way, yeah.
[20:33:29] <luna> aha! finally figured out the last two services being advertised - updater and manager. they appear to be a function of the
"client control" plugin.
[20:34:02] <MattJ> also redirecting calls to voicemail automatically when my XMPP status is DND
[20:34:13] <luna> so this leaves conference and pubsub.
[20:34:40] <luna> pep… i just noticed that string in my service discovery browser.
[20:34:57] <luna> personal eventing protocol?
[20:35:09] <MattJ> Yes
[20:35:20] <MattJ> Kind of out-of-bound presence
[20:35:36] <luna> out of bound? or out of band?
[20:35:38] <Kev> Well, in-band presence.
[20:35:42] <MattJ> er, band, yes :)
[20:35:46] <Kev> Just not overloading presence stanzas.
[20:35:54] <Kev> User metadata, basically.
[20:36:27] <MattJ> Well everyone took what they used to put in presence and put it in PEP instead :)
[20:36:45] <Kev> Which is right.
[20:37:04] <luna> i can't keep up with all of this. :)
[20:38:07] <luna> so pep is a "subset" of pubsub?
[20:38:14] <Zash> yes
[20:38:23] <luna> (i'm reading xep 163)
[20:38:33] <Zash> :D
[20:38:56] <Kev> PEP was originally not a subset of pubsub.
[20:39:06] <Kev> But thebit that wasn't a subset got rolled into 60
[20:39:16] <Kev> So now it's a subset.
[20:39:29] <Kev> But it's still used to mean the basic concept that was different from -60, which is that it's pubsub-on-a-jid.
[20:46:43] <luna> hmm, ok - so rather than sending a person's "status" (or whatever you want to call it) to all of their various contacts via
"normal" xmpp messages, it instead makes it available via a sort of simplified pubsub model?
[20:47:10] <johnny> isn't there an XEP for that?
[20:47:23] <luna> yeah, xep 163.
[20:47:29] <johnny> oh hah :)
[20:48:23] <luna> meaning instead of sending my status directly to all jids that i exchange presence with, instead i just publish once, to my
server, and then the jids get the presence update form my server, instead of my client, so to speak?
[20:48:51] <Zash> luna: instead of putting it in <presence/>
[20:49:13] <Zash> which is broadcast to all your contacts by your server
[20:49:19] <luna> i see.
[20:49:42] <Zash> pep is jus broadcast to those who has advertised interest in that type of event
[20:50:01] <Zash> like [xep user tune] and all the other user somethings
[20:50:02] <Kanchil> Zash: XEP-0118: User Tune is Standards Track (Draft, 2008-01-30) See: http://xmpp.org/extensions/xep-0118.html
[20:50:28] <luna> it sort of reminds me a bit of unicast vs. multicast.
[20:50:45] <Zash> s/uni/broad/ rather :)
[20:51:05] <luna> ah - there you go.
[20:51:16] <Zash> but not exactly ..
[20:51:21] <luna> sure, of course.
[20:52:45] <luna> it's kind of surprising to see a specification targeted to something so specific (and maybe trivial, in a sense) as what song
someone's listening to.
[20:52:56] <Zash> !xep user
[20:52:56] <Kanchil> Zash: Multiple matches: XEP-0045: Multi-User Chat, XEP-0154: User Profile, XEP-0196: User Gaming, XEP-0112: User Physical
Location, XEP-0281: DMUC1: Distributed Multi-User Chat, XEP-0080: User Location, XEP-0195: User Browsing, XEP-0084: User Avatar,
XEP-0172: User Nickname, XEP-0197: User Viewing, XEP-0107: User Mood, XEP-0118: User Tune, XEP-0108: User Activity, XEP-0058:
Multi-User Text Editing, XEP-0194: User Chatting
[20:53:06] <Zash> Yeah, there's a bunch ;)
[20:53:16] <luna> heh, i see.
[20:53:46] <luna> the web page i'm looking at… :)
[20:53:47] <luna> funny
[20:56:14] <Zash> !xep 80
[20:56:14] <Kanchil> Zash: XEP-0080: User Location is Standards Track (Draft, 2009-09-15) See: http://xmpp.org/extensions/xep-0080.html
[20:56:20] <Zash> !xep 112
[20:56:20] <Kanchil> Zash: XEP-0112: User Physical Location is Standards Track (Obsolete, 2004-10-12) See: http://xmpp.org/extensions/xep-0112.html
[20:56:49] <Zash> Ah, obsolete
[20:57:09] <luna> i still see queries for _pres._xmpp.pubsub.dipswitch.net coming from hermes. given the earlier conversation, shouldn't i
be seeing queries for _xmpp-server._tcp.pubsub first? or am i still not understanding things properly?
[20:57:24] <Kev> You should. Are you sure that you are not?
[20:57:41] <luna> i don't currently have an srv record for _xmpp-server._tcp.pubsub, but was still expecting to see the queries.
[20:57:41] <Kev> Well, you wouldn't know, I guess.
[20:57:47] <luna> no, i'm certain.
[20:57:51] <Kev> Depends what DNS resolves along the route are caching.
[20:58:02] <Kev> *resolvers
[20:58:11] <johnny> _pres._xmpp is really a thing now? :)
[20:58:12] <luna> oh, of course. perhaps it was looked up earlier by hermes.
[20:58:26] <Kev> johnny: No, explicitly not in bis, but it was in the originals.
[20:59:49] <luna> aha - here we go : 24-Oct-2010 15:43:41.345 queries: info: client 126.96.36.199#51922: view external: query: _xmpp-server._tcp.pubsub.dipswitch.net
IN SRV -ED (188.8.131.52)
[21:00:05] <luna> hermes has cached my nxdomain :)
[21:01:37] <luna> although that was over an hour ago, and my nxdomain ttl is 1 hour.
[21:05:47] * luna left the chat.
[21:06:21] * luna joined the chat.
[21:12:53] * darco joined the chat.
[21:14:47] * luna left the chat.
[21:16:17] * luna joined the chat.
[21:28:02] * test joined the chat.
[21:28:26] * test left the chat.
[21:36:48] * Neustradamus left the chat.
[21:38:21] * Neustradamus joined the chat.
[21:45:48] * mlundblad left the chat.
[21:50:52] * jonas left the chat.
[22:06:00] * johnny left the chat.
[22:12:24] * Tobias left the chat.
[22:16:11] * Zash left the chat.
[22:18:41] * bear joined the chat.
[22:19:29] * luna left the chat.
[22:21:10] * luna joined the chat.
[22:25:48] * luna left the chat.
[22:27:37] * abhinavsingh joined the chat.
[22:31:31] * luna joined the chat.
[22:32:55] * louiz’ left the chat.
[22:33:23] * louiz’ joined the chat.
[22:33:28] * louiz’ left the chat.
[22:33:33] * louiz’ joined the chat.
[22:33:36] * louiz’ left the chat.
[22:36:09] * louiz’ joined the chat.
[22:44:45] * MattJ left the chat.
[23:02:48] * Treebilou left the chat.
[23:25:01] * johnny joined the chat.
[23:25:29] <luna> when experimenting with a server that supports bosh (in my case, openfire). how does one typically figure out the url at which
the service can be found? is this something the admin would typically specify when setting things up? there doesn't appear
to be a place to do this in openfire.
[23:29:15] <darco> I believe the default is something like http://example.com:7070/
[23:36:09] <luna> specifically for openfire, you mean? i can configure the ports used, in the admin interface, and it does use 7070 and 7443
by default, but it appears there is more to it than that, as there seems to be nothing found at that url alone.
[23:37:08] <luna> i've read some indications that i need to use http://example.com:7070/http-bind/ and there does seem to be "something there"
- but i'm wondering how i would have known that?
[23:37:45] <luna> (aside from simply prior knowledge in some way)
[23:39:16] * smoku left the chat.
[23:46:53] <darco> oh yea
[23:47:08] <darco> yes, you need to add some extra stuff
[23:47:11] <darco> one sec and I'll look it up
[23:47:58] <darco> yes, you need to add /http-bind/ to the end
[23:48:19] <darco> I can't remember where I found that
[23:48:21] <darco> >_>
[23:48:54] <darco> I just pulled that out of my domain zone file....
[23:49:04] <darco> _xmppconnect IN TXT "_xmpp-client-xbosh=http://xmpp.deepdarc.com/http-bind/"