XMPP Council - 2011-02-24

00:07:43 mlundblad has left
03:29:53 Tobias has left
09:05:52 Tobias has joined
11:38:05 Kev has left
11:38:33 Kev has joined
13:20:24 Tobias has left
13:20:41 Tobias has joined
13:23:59 Tobias has left
14:04:43 Kooda has left
14:04:50 Kooda has joined
14:05:53 Tobias has joined
15:34:17 stpeter has joined
15:44:15 linuxwolf has joined
15:44:41 linuxwolf quick caffeine run, brb
15:44:52 Kev You've got 16 minutes. Go go go.
15:46:05 stpeter howdy
15:46:10 stpeter replies to Kev's message
15:46:14 Kev Evening.
15:46:17 Kev What was my message?
15:46:23 Kev I've got another agenda item I'm adding now.
15:46:36 linuxwolf oh noes
15:47:58 stpeter your email message about agenda
15:48:15 stpeter sorry, on a conference call at the moment, but multitasking as best as I can :)
15:48:39 Kev Asking Council to review a version published 12 minutes in advance of the meeting seems excessive :p
15:49:02 Fritzy has joined
15:50:35 stpeter heh
15:50:45 stpeter you mean 0047?
15:51:15 Kev Yeah.
15:51:35 stpeter it was discussed on the list, and I assume that Council members are paying attention to the list :P
15:51:38 stpeter http://xmpp.org/extensions/diff/api/xep/0047/diff/1.3rc2/vs/1.3rc3
15:51:50 stpeter I think Council members can read one sentence in 10 minutes
15:52:22 stpeter but hey XEP-0047 has been sitting around for almost a year, what's another week?
15:52:34 Kev I've reviewed the change :p
15:52:51 linuxwolf ditto
15:53:01 linuxwolf found a typo or two
15:54:02 linuxwolf somewhat patiently waits for gavel
15:55:57 Kev As Florian just posted this: http://florianjensen.com/wp-content/uploads/2009/05/meetings.jpg
15:56:48 Fritzy hurray
15:57:51 stpeter :)
15:58:50 Kev Both Ralph and Matt poked.
15:58:54 stpeter k
15:59:08 MattJ has joined
15:59:19 stpeter yay
15:59:24 MattJ Heh, I was waiting in council@c.j.o :)
15:59:32 stpeter heh
15:59:37 linuxwolf heh…newb (-:
15:59:38 ralphm has joined
15:59:45 MattJ I'm in the habit of "/join council" which uses the current server - I guess I was in the wrong room when I typed it
15:59:48 linuxwolf made that mistake a few weeks ago
16:00:23 Kev 4pm!
16:00:33 Kev And a full Council, the fates are smiling upon us.
16:00:39 ralphm 1700
16:00:45 MattJ :)
16:00:49 linuxwolf or it's the Apocalypse
16:00:52 Kev 1) Roll call.
16:00:54 Kev All here!
16:00:57 linuxwolf either would be fine
16:00:57 ralphm yay
16:00:59 Kev 2) Agenda bashing.
16:01:06 Kev (Beyond the extensive on-list bashing)
16:01:06 ralphm I'm gone in 15 min.
16:01:13 stpeter k
16:01:20 stpeter no bashing here
16:01:26 Fritzy plenty on list. :)
16:01:27 Kev A shame this'll be the longest Council for a while :)
16:01:35 Kev 3) XEP-0047 1.3rc3. http://xmpp.org/extensions/diff/api/xep/0047/diff/1.2/vs/1.3rc3 Accept new version?
16:01:43 MattJ +1
16:01:49 linuxwolf found at least one typo, +1 otherwise
16:01:56 linuxwolf "Upon receiving an error related to delivery of a or stanza, the sender"
16:02:08 ralphm +1
16:02:15 stpeter note that I added a sentence the other day but didn't check in the file -- it was discussed on list, however
16:02:18 stpeter linuxwolf: noted
16:02:21 Kev I had a couple of comments about this. As an aside, SHOULD wait for a reply to the iq seems wrong (unrelated to the diff). Is 'wait' the right error? I didn't check bis. And suggesting we continue sending iqs when we start receiving errors sounds wrong.
16:02:28 Kev +1 though.
16:02:51 Fritzy +1 myself, although maybe an example of a wait error would be nice.
16:03:18 Kev 4) XEP-0184, version 1.2rc: http://xmpp.org/extensions/tmp/xep-0184-1.2.html http://xmpp.org/extensions/diff/api/xep/0184/diff/1.1/vs/1.2rc2 Accept new version? See http://mail.jabber.org/pipermail/standards/2011-February/024133.html http://mail.jabber.org/pipermail/standards/2011-February/024160.html
16:03:51 Kev I'm +1 on this. Now that it's been clarified that these aren't read receipts, I'm happy if the bit about not sending replies is modified to say that a client doesn't need the user's configuration to return a receipt to a contact that has a presence sub. I believe that was added at my behest.
16:04:23 stpeter Kev: it was added at your behest, as I recall
16:04:24 linuxwolf +1 also
16:04:28 Fritzy +1, but what about messages from archives. Are we watching for delay?
16:04:30 ralphm +1
16:04:51 Dave Cridland has joined
16:05:11 stpeter Fritzy: I think we have some text about that now, don't we?
16:05:12 stpeter checks
16:05:13 Kev Fritzy: It explicitly says not to send from archive.
16:05:20 Fritzy No, I see that.
16:05:37 Fritzy I meant, it doesn't specify how you know that (yes, I realize that is in another spec)
16:05:48 stpeter ah
16:05:53 Kev I don't think it needs to.
16:05:55 Kev Does it?
16:06:03 Kev Well, it's a simple tweak to say "As in e.g. ..."
16:06:07 stpeter is off his conference call so can concentrate more fully now
16:06:16 Kev stpeter: Are you happy to make the tweak?
16:06:18 Fritzy right, I think it could be a simple reference
16:06:19 linuxwolf well, it does mention XEP-0136...
16:06:24 Kev linuxwolf: Ah, it does?
16:06:32 Kev I reviewed it earlier, forgotten it all now.
16:06:40 Kev In that case, I think we're set.
16:06:43 linuxwolf "An entity MUST NOT send an ack message when a user views messages that have been archived or stored on the client or the server (e.g., viaMessage Archiving <http://xmpp.org/extensions/xep-0136.html> [8 <http://xmpp.org/extensions/tmp/xep-0184-1.2.html#nt-id36424>]), only when first receiving the message."
16:06:46 stpeter we added: 5.5 Archived Messages An entity MUST NOT send an ack message when a user views messages that have been archived or stored on the client or the server (e.g., via Message Archiving [8]), only when first receiving the message.
16:06:55 Kev I think we're set then.
16:06:58 Kev Fritzy?
16:06:59 Fritzy oh, why didn't I see that?!
16:07:01 Fritzy ok
16:07:03 linuxwolf not sure what more can be said
16:07:11 Fritzy (must have been looking at the wrong version or something)
16:07:17 MattJ OT, but I like "[...] this protocol does not enable the sender to know that the intended recipient has read the message or understood the message (if the intended recipient is a human being)" :)
16:07:19 Kev I don't see a MattJ: note.
16:07:26 MattJ I'm +1
16:07:27 Kev note? vote.
16:07:28 Kev Ta.
16:07:31 Fritzy still +1
16:07:36 Kev 5) http://www.xmpp.org/extensions/inbox/realtimetext.html Accept as XEP?
16:07:41 Fritzy -1
16:07:41 linuxwolf ugh
16:07:44 linuxwolf -0
16:08:00 MattJ It struck me that *this* spec would have more interesting interaction with archiving :)
16:08:02 Kev I'm usually +1 on Experimental stuff, and seeing what happens, but this feels so completely non-XMPPish, I'm -1.
16:08:03 linuxwolf just because there's precedence, doesn't mean it's GOOD precedence
16:08:08 MattJ Instant realtime replay of conversations!
16:08:25 Kev I've actually implemented this before, for someone who needed it, using a far far simpler model.
16:08:31 Hirotaka Sato has joined
16:08:43 MattJ Kev, how exactly?
16:08:49 MattJ (and... should we spec it?)
16:08:52 linuxwolf Kev: ditto
16:08:54 Fritzy probably
16:08:56 MattJ This comes up every so often
16:08:57 Kev MattJ: <fragment>I'm half-way through typ</fragment>
16:08:58 ralphm So even if most of us think it is a bad idea, do we really want to discourage specs being made for the use case?
16:09:14 Kev ralphm: No, I think we want to discourage specs that don't seem right.
16:09:21 Fritzy the use case is fine
16:09:22 Kev I'm not -1 because I don't care about the feature.
16:09:44 MattJ If we reject this then we need some clear feedback for the author on why
16:09:45 Kev This is 11,600 words (excluding boilerplate) if my copy/paste/wc skills are ok.
16:09:58 Kev MattJ: I'd like a thread on this on standards@
16:10:06 Kev I'm happy to revote after seeing some community feedback.
16:10:20 Kev I'll weight in on such a discussion (I'm happy to start it)
16:10:22 stpeter +1 to a discussion thread on standards@
16:10:30 ralphm nod
16:10:38 linuxwolf I'll be sure to provide my $0.02USD
16:10:39 Kev I think this is the requirement we currently have set for Council. You can -1, but must post to standards@ with a justification.
16:10:40 stpeter finds two AOB items
16:10:48 ralphm :-)
16:10:56 Fritzy Sure, I'll -1 and post
16:11:12 MattJ Ok, then I'm +1 to the -1 if we discuss it
16:11:22 Kev MattJ: You mean you're +0?
16:11:24 Dave Cridland I
16:11:25 Kev Or you're -1?
16:11:25 Dave Cridland d
16:11:25 Dave Cridland o
16:11:26 Dave Cridland n
16:11:28 Dave Cridland '
16:11:29 Dave Cridland t
16:11:32 Kev Dave Cridland: Stop.
16:11:36 linuxwolf Kev: I was −0 (-:
16:11:38 Dave Cridland ... much like it either. :-)
16:11:51 Fritzy >_<
16:11:52 Kev linuxwolf: yes, I saw that. It'l ralphm's and MattJ's I missed :)
16:11:55 MattJ Kev, put me as +0
16:12:08 stpeter ralphm: the AOB that applies to you is that we need votes from all Council members on http://xmpp.org/extensions/diff/api/xep/0198/diff/1.1/vs/1.2rc2
16:12:09 coolidge25789 has joined
16:12:26 Kev stpeter: That's not AOB, that's last week's meeting :)
16:12:36 ralphm I don't think it is a required to have everyone's +1,-1,0 for moving to experimental
16:12:40 stpeter Kev: it's other business as far as this meeting is concerned :)
16:12:45 Kev ralphm: do you have a stance on rtt before we move on?
16:12:59 Kev No, you can fail to express an opinion, but I want to know if you have one.
16:13:01 ralphm Kev: I agree with the list action
16:13:06 Kev Ok.
16:13:19 ralphm so that appears to be -1 then
16:13:23 Kev :)
16:13:24 Kev 6) http://dave.cridland.net/xeps/google-queue.html This is documentation of a Google protocol. What track should it be? None seem to fit - author doesn't think it's suitable for standards track (should use stream features), Historical is only for pre-XSF documents, and Informational is for BCP. Should the XEP types be tweaked?
16:13:40 stpeter shouldn't it be up to Google folks to document Google extensions?
16:13:48 linuxwolf that's what I was about to ask....
16:13:49 Kev So, Dave poked me about this pre-Council, and I said it should be standards track.
16:13:57 Fritzy Do they care to?
16:13:58 stpeter (however, note that I wrote the documentation for linklocal...)
16:14:09 stpeter (and that was an Apple protocol)
16:14:13 Fritzy We'll make a new track called "Google"
16:14:16 stpeter haha
16:14:19 linuxwolf grr
16:14:24 MattJ :D
16:14:33 Kev I don't see that we gain sufficient interoperability to make this worth documenting but not ST.
16:14:37 MattJ I think standards track is fine
16:14:43 coolidge25789 has left
16:14:43 ralphm I think this was discussed with some Google people
16:14:52 linuxwolf yeah, but if it's our standard, some things will need to change
16:14:53 stpeter Jonas is on the author list
16:15:02 ralphm stpeter: right
16:15:09 Kev Dave Cridland can express his opinion on it being ST, but I understand he doesn't think this is the right way to do it.
16:15:13 ralphm so it's ours and theirs
16:15:21 stpeter but yeah we'd at least change the namespace to urn:xmpp:*
16:15:29 Kev I think we should ST it, and do whatever the community thinks is the right thing to do.
16:15:36 Dave Cridland stpeter, But that makes it a different protocol.
16:15:39 Kev As it does seem simple and useful.
16:15:42 Fritzy Do we need this simplification when we have other solutions?
16:15:42 stpeter indeed it does
16:15:55 Dave Cridland stpeter, THe point of documenting it is to say "this exists", nothign more.
16:15:59 stpeter I think we need to take this to the standards@ list
16:15:59 Kev Fritzy: from my limited understanding, this is actually simple and useful.
16:16:05 stpeter Dave Cridland: in that case, Informational is right
16:16:10 Fritzy Dave Cridland: then it's informational
16:16:15 Kev stpeter: No, because it's not a BCP.
16:16:24 Dave Cridland stpeter, Informational is described as "typically" for BCP, so there is wiggle-room.
16:16:29 Kev Thus the question about whether we should update the XEP-0001 descriptions.
16:16:38 linuxwolf we've used informational for other "not-quite-standard" protocols in the past
16:16:40 ralphm I would say it is historical, but hey
16:16:50 Kev ralphm: Historical means it was written before the JSF existed :)
16:17:03 linuxwolf I would be good with Informational, FWIW
16:17:07 Dave Cridland I originally thought Historical, hence its designation.
16:17:14 Dave Cridland But Informational suits me fine.
16:17:34 stpeter those categories need to be clarified
16:17:44 stpeter now that the XSF has been around for almost 10 years
16:17:50 linuxwolf or reambiguated (-:
16:17:51 MattJ Good point :)
16:17:59 Kev If we do put this as Informational, I think we should also create an ST version, and obsolete this one.
16:18:11 Fritzy hmm..
16:18:23 MattJ FWIW Telepathy does or is planning to implement this
16:18:26 linuxwolf how about we see what the list discussion is first
16:18:27 MattJ I think
16:18:28 Kev Publishing it as Informational means we think it's important enough to be worth publishing. If we don't believe it's the right solution, we should document the right solution.
16:18:30 Fritzy I think this requires some more thought
16:18:31 Dave Cridland Kev, I'm fine with that (and this was my original plan), but the original is deployed in at least one large implementation.
16:18:32 stpeter I think informational documentation of protocols out there in the wild can be helpful
16:18:44 ralphm so, what is the value of redoing it in a new namespace?
16:18:47 Dave Cridland MattJ, Does implement as specified here.
16:18:53 ralphm I don't think I want more/less features
16:18:58 MattJ ralphm, that we can advance the protocol
16:18:58 Kev ralphm: We wouldn't for Informational.
16:19:02 Kev But for ST we need to.
16:19:19 stpeter ralphm: aside from the fact that "google:" is not a legitimate identifier on any planet I know about?
16:19:27 MattJ Heh
16:19:30 ralphm that seems bureaucratic
16:19:32 Kev Good point, it's an illegal namespace :D
16:19:35 ralphm stpeter's argument is sane
16:19:35 stpeter I mean we dropped "jabber:" 8+ years ago?
16:19:35 Kev Anyway.
16:19:43 MattJ Wait, so is jabber:iq:... :)
16:19:45 stpeter it's an illegal namespace, why encourage those?
16:19:45 Kev Anyway.
16:19:49 linuxwolf has left
16:19:51 stpeter MattJ: legacy
16:19:57 linuxwolf has joined
16:20:03 Kev Who is volunteering to start a list discussion?
16:20:08 stpeter we were idiots back then, why encourage more idiocy?
16:20:09 MattJ Dave
16:20:12 linuxwolf Dave
16:20:12 Kev Or are we not bothering and going ahead as Informational?
16:20:12 ralphm stpeter: must namespaces be uris?
16:20:21 MattJ I vote Informational
16:20:26 MattJ and keep the existing namespace
16:20:33 MattJ and then ST it if we want to make our own
16:20:38 MattJ but that's for the list
16:20:40 Kev I do want a discussion about whether this is the optimal approach.
16:20:46 linuxwolf /agreed w/ MattJ
16:20:52 stpeter [Definition: An XML namespace is identified by a URI reference [RFC3986]; element and attribute names may be placed in an XML namespace using the mechanisms described in this specification. ]
16:20:53 Dave Cridland Oh, if you guys are happy with Informational, I see no need to bother the list with it. I'll just submit to the XEP Editor as Informational.
16:20:56 stpeter http://www.w3.org/TR/xml-names/#concepts
16:21:03 Fritzy I don't think it is /the/ optimal approach, but it is very simple, and that sometimes is all a spec needs to be popular
16:21:13 ralphm stpeter: thanks
16:21:14 stpeter +1 to simplicity
16:21:14 Kev So someone has to agree to start the list discussion to see what the best way of doing it is.
16:21:20 Kev If this is sufficiently different, we should ST it.
16:21:24 MattJ Dave Cridland, the list discussion would be on whether we want to make a standards track version of this
16:21:32 Kev Or, rather, create an ST spec to obsolete the informational.
16:21:32 stpeter MattJ: agreed
16:21:39 Dave Cridland MattJ, I think that'll come naturally from submitting this one.
16:21:41 ralphm I think it would be good to rename the namespace only for this reason
16:21:46 Fritzy yeah, let's see what the community thinks
16:21:53 Kev So who's starting the discussion
16:21:58 linuxwolf Dave
16:22:04 Kev Someone volunteer, I volunteered for rtt :)
16:22:12 stpeter Dave has been volunteered
16:22:14 Fritzy haha
16:22:18 Kev Dave Cridland: Happy?
16:22:21 ralphm i.e. if google would have chosen a valid namespace name, I would excuse them from the namespace changing stuff we regularly do
16:22:23 Fritzy Dave is fine with informational, remember?
16:22:33 MattJ I'd volunteer except I know I'll not get around to it right now
16:22:41 Kev Fritzy: Yes, I'm not happy with Informational without a discussion :)
16:22:44 Dave Cridland There's a political problem with renaming the namespace, of course, which is that given the inertia of Google's implementation, there's little hope of seeing deployment there.
16:22:45 ralphm I'm +1 on accepting this on standards track in that case.
16:23:00 Kev I have no objection to this going on ST.
16:23:23 Fritzy sure, plus a little service discovery and away we go
16:23:24 ralphm Dave Cridland: that's an assumption we should verify
16:23:46 Dave Cridland ralphm, I can ask Jonas, of course.
16:24:11 Kev We're 7 minutes away from meeting-tolerance.
16:24:13 ralphm Dave Cridland: I think it would be good of us to make Google aware that their namespaces are illegally named. You could even suggest they use http://google.com/something
16:24:26 ralphm Dave Cridland: please do
16:24:37 ralphm Kev: next?
16:24:50 Kev What are people's current positions? Mine is that I either want list discussion if we want to Informational it, or to do it ST.
16:25:00 taylor26215 has joined
16:25:01 Hirotaka Sato has left
16:25:08 stpeter Kev: same here
16:25:11 linuxwolf ditto
16:25:20 Fritzy +1
16:25:22 Kev Dave Cridland: Are you willing to start the discussion?
16:25:25 Dave Cridland My opinion is that it shouldn't be done this way, or with this namespace, in ST, and the original needs documenting irregardless of whether we persue this as ST.
16:25:44 Fritzy namespace changes can happen during experimental on standards track
16:25:50 Kev I'm happy to publish this Informational and obsoleted by an ST document.
16:25:57 Fritzy hm
16:25:58 linuxwolf Dave: sounds like you can kick off the list discussion… (-:
16:26:08 Fritzy that way we could at least refer to the old version, I suppose
16:26:13 Dave Cridland Righty, I'll do so - shall I formally submit this before or after?
16:26:23 Kev Dave Cridland: Both at the same time would make me happiest.
16:26:31 Fritzy It's all about you, isn't it?
16:26:39 Fritzy ;)
16:26:41 Kev Fritzy: About me? Yes.
16:26:53 ralphm I'm +1 on 0198
16:26:56 ralphm gotta go
16:26:58 Dave Cridland Kev, K. I shall submit now, then, and then kick off the discussion once it's announced.
16:26:59 Kev Bye Ralph.
16:27:03 stpeter is this extension already documented on google.com somewhere?
16:27:08 Kev Dave Cridland: You have the ST version ready?
16:27:21 stpeter needs to transfer the voting tally pages to WordPress
16:27:40 Kev I was saying I didn't want the Informational submitted before the ST one.
16:27:43 Dave Cridland stpeter, Erm. I can't actually recall - I know that Jonas wrote an email describing it to jdev@ at one point.
16:27:52 MattJ Kev, why not?
16:28:11 Dave Cridland Kev, Ah, you want an ST one? Well, that's another issue entirely... I can easily enough write out a proposal, of course.
16:28:23 Kev MattJ: Because if we're Informationalising it without an ST equivalent, I think there should be a discussion on standards@ to see what the community thinks.
16:28:30 MattJ about what?
16:28:36 Kev The right way of doing it.
16:28:49 linuxwolf I think we should allow this informational one first, start the list discussion, and see where it goes
16:28:53 MattJ Informationalising it isn't about the right way of doing it
16:29:00 MattJ It's about how Google have it implemented *now*
16:29:22 MattJ which can be used as the basis of an ST document if we decide we want one
16:29:24 Kev I basically feel unhappy about us documenting this non-ST, given that it's basically one deployment.
16:29:28 Dave Cridland MattJ, Right - at least three implementations of this exist now.
16:29:36 MattJ Kev, one significant deployment
16:29:39 Dave Cridland Kev, It's not one implementation. If it were...
16:29:46 Kev MattJ: Yes.
16:29:59 Kev Dave Cridland: Yes, and I think we should see if it's the right way before we encourage more implementations.
16:30:06 Kev By claiming that this is a BCP.
16:30:16 MattJ I don't see we should claim it as a BCP
16:30:23 Kev MattJ: That's what Informational means.
16:30:32 MattJ The current definition of "informational" is another matter
16:30:36 linuxwolf fine, then let's redefine informational
16:30:40 linuxwolf then publish
16:30:41 MattJ We've already decided it's too limited
16:30:43 Kev linuxwolf: I'm fine with that.
16:31:03 Kev Although that's Board, rather than Council :)
16:31:03 linuxwolf it used to have a broader definition anyway
16:31:08 MattJ So fix XEP-0001, publish queue as informational, debate forming an ST doc from it
16:31:10 stpeter Kev: right :)
16:31:15 stpeter but documentation is good
16:31:37 Dave Cridland (FWIW, I'd be more comfortable with Historical in the XEP framework - ie, "this is how it's been done, we don't say this is a good idea".)
16:31:47 Kev So'd I.
16:31:52 stpeter fine by me
16:32:03 Kev Assuming we modify historical to mean "Implemented outside the standards track"
16:32:09 linuxwolf I'm fine with Historical too
16:32:11 Kev +wordsmithing.
16:32:14 linuxwolf do we also want to clarify what the definition of "is" is (-:
16:32:16 Dave Cridland But that means redefining Historical to encompass things developed outside the XSF but after it was instigated.
16:32:19 stpeter "Documentation is like sex. When it's good, it's very good. When it's bad, it's better than nothing." -- Jeremie Miller
16:32:34 stpeter ok my other call is starting
16:32:38 Dave Cridland stpeter, Is that Jer's quote? I never knew it was him.
16:32:38 Kev Ok, we've passed tolerance.
16:32:45 linuxwolf oh, +1 on 198
16:32:45 stpeter meeting city this morning!
16:32:51 stpeter linuxwolf: noted
16:32:57 stpeter and ralphm's vote on 198 is noted
16:32:58 Kev I'm happy to vote on this next week as Historical, and someone should ask Board to modify -0001.
16:33:13 Kev 7) Date of next meeting
16:33:16 Kev Next Wednesday?
16:33:22 linuxwolf wfm
16:33:23 MattJ +1
16:33:36 Kev Fritzy: ?
16:33:48 Fritzy that's fine.
16:33:53 Kev 8) AOB?
16:33:53 Fritzy +1
16:34:00 stpeter I'll update the calendar for next Wed
16:34:04 Kev Ta.
16:34:09 Fritzy Nope.
16:34:10 stpeter some folks need to vote on 198
16:34:15 stpeter and the vcard inbox item
16:34:16 Kev stpeter: We know.
16:34:18 Fritzy yup, I'll do that on list today
16:34:18 stpeter just a reminder :)
16:34:28 Fritzy plays catchup.
16:34:31 Kev Anything else?
16:34:46 stpeter nope
16:34:50 linuxwolf nay
16:34:51 Kev Ok.
16:34:57 Fritzy nodda
16:34:59 MattJ Just to confirm... my votes for 198 and vcard4 are in, yes? I got no reply
16:35:24 Kev MattJ: I've not seen them on-list. If they're in the buffer, I'll see them when I do the minutes :)
16:35:28 stpeter MattJ: didn't see those
16:35:34 MattJ Hmph
16:35:38 stpeter MattJ: scrolling up
16:35:41 MattJ I'll try from my other account again
16:35:50 Kev Ok.
16:35:50 stpeter MattJ: probably just my fault
16:35:51 MattJ erm, I sent to the list, sorry
16:35:55 stpeter ah ok
16:35:57 stpeter that works
16:35:58 Kev bangs the gavel
16:36:00 Kev Thanks all.
16:36:02 stpeter thanks
16:36:03 Fritzy ciao
16:36:05 linuxwolf adios
16:36:07 MattJ Thanks
16:36:10 stpeter turns his attention to the IESG telechat
16:36:17 MattJ Enjoy :)
16:36:20 stpeter oh yeah
16:36:20 linuxwolf preps for next meeting
16:36:29 MattJ Just can't get enough telechats
16:36:35 linuxwolf hi ho, hi by
16:36:37 stpeter this is a fun one -- the meeting schedule for IETF 80
16:36:45 MattJ Is that Prague?
16:37:08 stpeter yes
16:37:10 linuxwolf Some say that's Kev's favorite city to visit
16:37:14 stpeter haha
16:37:23 stpeter it's a beautiful city
16:37:42 MattJ Kev, ok... I don't see my email in the archives... +1s anyway
16:38:02 MattJ Kev, I also asked where vcard4 puts User Profile
16:42:22 linuxwolf has left
16:42:34 Steffen Larsen has joined
17:03:57 taylor26215 has left
18:04:38 Steffen Larsen has left
18:10:02 Dave Cridland has left
18:31:59 Tobias has left
19:19:02 ralphm has left
19:26:40 bear has left
19:26:41 bear has joined
19:54:54 ralphm has joined
20:00:27 julm has joined
20:25:10 Tobias has joined
21:37:10 ralphm has left
23:03:11 stpeter has left