stpeterI think Council members can read one sentence in 10 minutes
stpeterbut hey XEP-0047 has been sitting around for almost a year, what's another week?
KevI've reviewed the change :p
linuxwolfditto
linuxwolffound a typo or two
linuxwolfsomewhat patiently waits for gavel
KevAs Florian just posted this: http://florianjensen.com/wp-content/uploads/2009/05/meetings.jpg
Fritzyhurray
stpeter:)
KevBoth Ralph and Matt poked.
stpeterk
MattJhas joined
stpeteryay
MattJHeh, I was waiting in council@c.j.o :)
stpeterheh
linuxwolfheh…newb (-:
ralphmhas joined
MattJI'm in the habit of "/join council" which uses the current server - I guess I was in the wrong room when I typed it
linuxwolfmade that mistake a few weeks ago
Kev4pm!
KevAnd a full Council, the fates are smiling upon us.
ralphm1700
MattJ:)
linuxwolfor it's the Apocalypse
Kev1) Roll call.
KevAll here!
linuxwolfeither would be fine
ralphmyay
Kev2) Agenda bashing.
Kev(Beyond the extensive on-list bashing)
ralphmI'm gone in 15 min.
stpeterk
stpeterno bashing here
Fritzyplenty on list. :)
KevA shame this'll be the longest Council for a while :)
Kev3) XEP-0047 1.3rc3.
http://xmpp.org/extensions/diff/api/xep/0047/diff/1.2/vs/1.3rc3
Accept new version?
MattJ+1
linuxwolffound at least one typo, +1 otherwise
linuxwolf"Upon receiving an error related to delivery of a or stanza, the sender"
ralphm+1
stpeternote that I added a sentence the other day but didn't check in the file -- it was discussed on list, however
stpeterlinuxwolf: noted
KevI 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.
Kev+1 though.
Fritzy+1 myself, although maybe an example of a wait error would be nice.
Kev4) 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
KevI'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.
stpeterKev: it was added at your behest, as I recall
linuxwolf+1 also
Fritzy+1, but what about messages from archives. Are we watching for delay?
ralphm+1
Dave Cridlandhas joined
stpeterFritzy: I think we have some text about that now, don't we?
stpeterchecks
KevFritzy: It explicitly says not to send from archive.
FritzyNo, I see that.
FritzyI meant, it doesn't specify how you know that (yes, I realize that is in another spec)
stpeterah
KevI don't think it needs to.
KevDoes it?
KevWell, it's a simple tweak to say "As in e.g. ..."
stpeteris off his conference call so can concentrate more fully now
Kevstpeter: Are you happy to make the tweak?
Fritzyright, I think it could be a simple reference
linuxwolfwell, it does mention XEP-0136...
Kevlinuxwolf: Ah, it does?
KevI reviewed it earlier, forgotten it all now.
KevIn that case, I think we're set.
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."
stpeterwe 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.
KevI think we're set then.
KevFritzy?
Fritzyoh, why didn't I see that?!
Fritzyok
linuxwolfnot sure what more can be said
Fritzy(must have been looking at the wrong version or something)
MattJOT, 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)" :)
KevI don't see a MattJ: note.
MattJI'm +1
Kevnote? vote.
KevTa.
Fritzystill +1
Kev5) http://www.xmpp.org/extensions/inbox/realtimetext.html
Accept as XEP?
Fritzy-1
linuxwolfugh
linuxwolf-0
MattJIt struck me that *this* spec would have more interesting interaction with archiving :)
KevI'm usually +1 on Experimental stuff, and seeing what happens, but this feels so completely non-XMPPish, I'm -1.
linuxwolfjust because there's precedence, doesn't mean it's GOOD precedence
MattJInstant realtime replay of conversations!
KevI've actually implemented this before, for someone who needed it, using a far far simpler model.
Hirotaka Satohas joined
MattJKev, how exactly?
MattJ(and... should we spec it?)
linuxwolfKev: ditto
Fritzyprobably
MattJThis comes up every so often
KevMattJ: <fragment>I'm half-way through typ</fragment>
ralphmSo even if most of us think it is a bad idea, do we really want to discourage specs being made for the use case?
Kevralphm: No, I think we want to discourage specs that don't seem right.
Fritzythe use case is fine
KevI'm not -1 because I don't care about the feature.
MattJIf we reject this then we need some clear feedback for the author on why
KevThis is 11,600 words (excluding boilerplate) if my copy/paste/wc skills are ok.
KevMattJ: I'd like a thread on this on standards@
KevI'm happy to revote after seeing some community feedback.
KevI'll weight in on such a discussion (I'm happy to start it)
stpeter+1 to a discussion thread on standards@
ralphmnod
linuxwolfI'll be sure to provide my $0.02USD
KevI think this is the requirement we currently have set for Council. You can -1, but must post to standards@ with a justification.
stpeterfinds two AOB items
ralphm:-)
FritzySure, I'll -1 and post
MattJOk, then I'm +1 to the -1 if we discuss it
KevMattJ: You mean you're +0?
Dave CridlandI
KevOr you're -1?
Dave Cridlandd
Dave Cridlando
Dave Cridlandn
Dave Cridland'
Dave Cridlandt
KevDave Cridland: Stop.
linuxwolfKev: I was −0 (-:
Dave Cridland... much like it either. :-)
Fritzy>_<
Kevlinuxwolf: yes, I saw that. It'l ralphm's and MattJ's I missed :)
MattJKev, put me as +0
stpeterralphm: 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
coolidge25789has joined
Kevstpeter: That's not AOB, that's last week's meeting :)
ralphmI don't think it is a required to have everyone's +1,-1,0 for moving to experimental
stpeterKev: it's other business as far as this meeting is concerned :)
Kevralphm: do you have a stance on rtt before we move on?
KevNo, you can fail to express an opinion, but I want to know if you have one.
ralphmKev: I agree with the list action
KevOk.
ralphmso that appears to be -1 then
Kev:)
Kev6) 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?
stpetershouldn't it be up to Google folks to document Google extensions?
linuxwolfthat's what I was about to ask....
KevSo, Dave poked me about this pre-Council, and I said it should be standards track.
FritzyDo they care to?
stpeter(however, note that I wrote the documentation for linklocal...)
stpeter(and that was an Apple protocol)
FritzyWe'll make a new track called "Google"
stpeterhaha
linuxwolfgrr
MattJ:D
KevI don't see that we gain sufficient interoperability to make this worth documenting but not ST.
MattJI think standards track is fine
coolidge25789has left
ralphmI think this was discussed with some Google people
linuxwolfyeah, but if it's our standard, some things will need to change
stpeterJonas is on the author list
ralphmstpeter: right
KevDave Cridland can express his opinion on it being ST, but I understand he doesn't think this is the right way to do it.
ralphmso it's ours and theirs
stpeterbut yeah we'd at least change the namespace to urn:xmpp:*
KevI think we should ST it, and do whatever the community thinks is the right thing to do.
Dave Cridlandstpeter, But that makes it a different protocol.
KevAs it does seem simple and useful.
FritzyDo we need this simplification when we have other solutions?
stpeterindeed it does
Dave Cridlandstpeter, THe point of documenting it is to say "this exists", nothign more.
stpeterI think we need to take this to the standards@ list
KevFritzy: from my limited understanding, this is actually simple and useful.
stpeterDave Cridland: in that case, Informational is right
FritzyDave Cridland: then it's informational
Kevstpeter: No, because it's not a BCP.
Dave Cridlandstpeter, Informational is described as "typically" for BCP, so there is wiggle-room.
KevThus the question about whether we should update the XEP-0001 descriptions.
linuxwolfwe've used informational for other "not-quite-standard" protocols in the past
ralphmI would say it is historical, but hey
Kevralphm: Historical means it was written before the JSF existed :)
linuxwolfI would be good with Informational, FWIW
Dave CridlandI originally thought Historical, hence its designation.
Dave CridlandBut Informational suits me fine.
stpeterthose categories need to be clarified
stpeternow that the XSF has been around for almost 10 years
linuxwolfor reambiguated (-:
MattJGood point :)
KevIf we do put this as Informational, I think we should also create an ST version, and obsolete this one.
Fritzyhmm..
MattJFWIW Telepathy does or is planning to implement this
linuxwolfhow about we see what the list discussion is first
MattJI think
KevPublishing 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.
FritzyI think this requires some more thought
Dave CridlandKev, I'm fine with that (and this was my original plan), but the original is deployed in at least one large implementation.
stpeterI think informational documentation of protocols out there in the wild can be helpful
ralphmso, what is the value of redoing it in a new namespace?
Dave CridlandMattJ, Does implement as specified here.
ralphmI don't think I want more/less features
MattJralphm, that we can advance the protocol
Kevralphm: We wouldn't for Informational.
KevBut for ST we need to.
stpeterralphm: aside from the fact that "google:" is not a legitimate identifier on any planet I know about?
MattJHeh
ralphmthat seems bureaucratic
KevGood point, it's an illegal namespace :D
ralphmstpeter's argument is sane
stpeterI mean we dropped "jabber:" 8+ years ago?
KevAnyway.
MattJWait, so is jabber:iq:... :)
stpeterit's an illegal namespace, why encourage those?
KevAnyway.
linuxwolfhas left
stpeterMattJ: legacy
linuxwolfhas joined
KevWho is volunteering to start a list discussion?
stpeterwe were idiots back then, why encourage more idiocy?
MattJDave
linuxwolfDave
KevOr are we not bothering and going ahead as Informational?
ralphmstpeter: must namespaces be uris?
MattJI vote Informational
MattJand keep the existing namespace
MattJand then ST it if we want to make our own
MattJbut that's for the list
KevI do want a discussion about whether this is the optimal approach.
linuxwolf/agreed w/ MattJ
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. ]
Dave CridlandOh, 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.
stpeterhttp://www.w3.org/TR/xml-names/#concepts
FritzyI don't think it is /the/ optimal approach, but it is very simple, and that sometimes is all a spec needs to be popular
ralphmstpeter: thanks
stpeter+1 to simplicity
KevSo someone has to agree to start the list discussion to see what the best way of doing it is.
KevIf this is sufficiently different, we should ST it.
MattJDave Cridland, the list discussion would be on whether we want to make a standards track version of this
KevOr, rather, create an ST spec to obsolete the informational.
stpeterMattJ: agreed
Dave CridlandMattJ, I think that'll come naturally from submitting this one.
ralphmI think it would be good to rename the namespace only for this reason
Fritzyyeah, let's see what the community thinks
KevSo who's starting the discussion
linuxwolfDave
KevSomeone volunteer, I volunteered for rtt :)
stpeterDave has been volunteered
Fritzyhaha
KevDave Cridland: Happy?
ralphmi.e. if google would have chosen a valid namespace name, I would excuse them from the namespace changing stuff we regularly do
FritzyDave is fine with informational, remember?
MattJI'd volunteer except I know I'll not get around to it right now
KevFritzy: Yes, I'm not happy with Informational without a discussion :)
Dave CridlandThere'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.
ralphmI'm +1 on accepting this on standards track in that case.
KevI have no objection to this going on ST.
Fritzysure, plus a little service discovery and away we go
ralphmDave Cridland: that's an assumption we should verify
Dave Cridlandralphm, I can ask Jonas, of course.
KevWe're 7 minutes away from meeting-tolerance.
ralphmDave 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
ralphmDave Cridland: please do
ralphmKev: next?
KevWhat are people's current positions? Mine is that I either want list discussion if we want to Informational it, or to do it ST.
taylor26215has joined
Hirotaka Satohas left
stpeterKev: same here
linuxwolfditto
Fritzy+1
KevDave Cridland: Are you willing to start the discussion?
Dave CridlandMy 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.
Fritzynamespace changes can happen during experimental on standards track
KevI'm happy to publish this Informational and obsoleted by an ST document.
Fritzyhm
linuxwolfDave: sounds like you can kick off the list discussion… (-:
Fritzythat way we could at least refer to the old version, I suppose
Dave CridlandRighty, I'll do so - shall I formally submit this before or after?
KevDave Cridland: Both at the same time would make me happiest.
FritzyIt's all about you, isn't it?
Fritzy;)
KevFritzy: About me? Yes.
ralphmI'm +1 on 0198
ralphmgotta go
Dave CridlandKev, K. I shall submit now, then, and then kick off the discussion once it's announced.
KevBye Ralph.
stpeteris this extension already documented on google.com somewhere?
KevDave Cridland: You have the ST version ready?
stpeterneeds to transfer the voting tally pages to WordPress
KevI was saying I didn't want the Informational submitted before the ST one.
Dave Cridlandstpeter, Erm. I can't actually recall - I know that Jonas wrote an email describing it to jdev@ at one point.
MattJKev, why not?
Dave CridlandKev, Ah, you want an ST one? Well, that's another issue entirely... I can easily enough write out a proposal, of course.
KevMattJ: 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.
MattJabout what?
KevThe right way of doing it.
linuxwolfI think we should allow this informational one first, start the list discussion, and see where it goes
MattJInformationalising it isn't about the right way of doing it
MattJIt's about how Google have it implemented *now*
MattJwhich can be used as the basis of an ST document if we decide we want one
KevI basically feel unhappy about us documenting this non-ST, given that it's basically one deployment.
Dave CridlandMattJ, Right - at least three implementations of this exist now.
MattJKev, one significant deployment
Dave CridlandKev, It's not one implementation. If it were...
KevMattJ: Yes.
KevDave Cridland: Yes, and I think we should see if it's the right way before we encourage more implementations.
KevBy claiming that this is a BCP.
MattJI don't see we should claim it as a BCP
KevMattJ: That's what Informational means.
MattJThe current definition of "informational" is another matter
linuxwolffine, then let's redefine informational
linuxwolfthen publish
MattJWe've already decided it's too limited
Kevlinuxwolf: I'm fine with that.
KevAlthough that's Board, rather than Council :)
linuxwolfit used to have a broader definition anyway
MattJSo fix XEP-0001, publish queue as informational, debate forming an ST doc from it
stpeterKev: right :)
stpeterbut documentation is good
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".)
KevSo'd I.
stpeterfine by me
KevAssuming we modify historical to mean "Implemented outside the standards track"
linuxwolfI'm fine with Historical too
Kev+wordsmithing.
linuxwolfdo we also want to clarify what the definition of "is" is (-:
Dave CridlandBut that means redefining Historical to encompass things developed outside the XSF but after it was instigated.
stpeter"Documentation is like sex. When it's good, it's very good. When it's bad, it's better than nothing." -- Jeremie Miller
stpeterok my other call is starting
Dave Cridlandstpeter, Is that Jer's quote? I never knew it was him.
KevOk, we've passed tolerance.
linuxwolfoh, +1 on 198
stpetermeeting city this morning!
stpeterlinuxwolf: noted
stpeterand ralphm's vote on 198 is noted
KevI'm happy to vote on this next week as Historical, and someone should ask Board to modify -0001.
Kev7) Date of next meeting
KevNext Wednesday?
linuxwolfwfm
MattJ+1
KevFritzy: ?
Fritzythat's fine.
Kev8) AOB?
Fritzy+1
stpeterI'll update the calendar for next Wed
KevTa.
FritzyNope.
stpetersome folks need to vote on 198
stpeterand the vcard inbox item
Kevstpeter: We know.
Fritzyyup, I'll do that on list today
stpeterjust a reminder :)
Fritzyplays catchup.
KevAnything else?
stpeternope
linuxwolfnay
KevOk.
Fritzynodda
MattJJust to confirm... my votes for 198 and vcard4 are in, yes? I got no reply
KevMattJ: I've not seen them on-list. If they're in the buffer, I'll see them when I do the minutes :)
stpeterMattJ: didn't see those
MattJHmph
stpeterMattJ: scrolling up
MattJI'll try from my other account again
KevOk.
stpeterMattJ: probably just my fault
MattJerm, I sent to the list, sorry
stpeterah ok
stpeterthat works
Kevbangs the gavel
KevThanks all.
stpeterthanks
Fritzyciao
linuxwolfadios
MattJThanks
stpeterturns his attention to the IESG telechat
MattJEnjoy :)
stpeteroh yeah
linuxwolfpreps for next meeting
MattJJust can't get enough telechats
linuxwolfhi ho, hi by
stpeterthis is a fun one -- the meeting schedule for IETF 80
MattJIs that Prague?
stpeteryes
linuxwolfSome say that's Kev's favorite city to visit
stpeterhaha
stpeterit's a beautiful city
MattJKev, ok... I don't see my email in the archives... +1s anyway
MattJKev, I also asked where vcard4 puts User Profile