XMPP Council - 2011-02-24

quick caffeine run, brb

You've got 16 minutes. Go go go.

howdy

Evening.

What was my message?

I've got another agenda item I'm adding now.

oh noes

your email message about agenda

sorry, on a conference call at the moment, but multitasking as best as I can :)

Asking Council to review a version published 12 minutes in advance of the meeting seems excessive :p

heh

you mean 0047?

Yeah.

it was discussed on the list, and I assume that Council members are paying attention to the list :P

http://xmpp.org/extensions/diff/api/xep/0047/diff/1.3rc2/vs/1.3rc3

I think Council members can read one sentence in 10 minutes

but hey XEP-0047 has been sitting around for almost a year, what's another week?

I've reviewed the change :p

ditto

found a typo or two

As Florian just posted this: http://florianjensen.com/wp-content/uploads/2009/05/meetings.jpg

hurray

:)

Both Ralph and Matt poked.

k

yay

Heh, I was waiting in council@c.j.o :)

heh

heh…newb (-:

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

4pm!

And a full Council, the fates are smiling upon us.

1700

:)

or it's the Apocalypse

1) Roll call.

All here!

either would be fine

yay

2) Agenda bashing.

(Beyond the extensive on-list bashing)

I'm gone in 15 min.

k

no bashing here

plenty on list. :)

A shame this'll be the longest Council for a while :)

3) XEP-0047 1.3rc3. http://xmpp.org/extensions/diff/api/xep/0047/diff/1.2/vs/1.3rc3 Accept new version?

+1

found at least one typo, +1 otherwise

"Upon receiving an error related to delivery of a or stanza, the sender"

+1

note that I added a sentence the other day but didn't check in the file -- it was discussed on list, however

linuxwolf: noted

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.

+1 though.

+1 myself, although maybe an example of a wait error would be nice.

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

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.

Kev: it was added at your behest, as I recall

+1 also

+1, but what about messages from archives. Are we watching for delay?

+1

Fritzy: I think we have some text about that now, don't we?

Fritzy: It explicitly says not to send from archive.

No, I see that.

I meant, it doesn't specify how you know that (yes, I realize that is in another spec)

ah

I don't think it needs to.

Does it?

Well, it's a simple tweak to say "As in e.g. ..."

stpeter: Are you happy to make the tweak?

right, I think it could be a simple reference

well, it does mention XEP-0136...

linuxwolf: Ah, it does?

I reviewed it earlier, forgotten it all now.

In that case, I think we're set.

"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."

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.

I think we're set then.

Fritzy?

oh, why didn't I see that?!

ok

not sure what more can be said

(must have been looking at the wrong version or something)

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)" :)

I don't see a MattJ: note.

I'm +1

note? vote.

Ta.

still +1

5) http://www.xmpp.org/extensions/inbox/realtimetext.html Accept as XEP?

-1

ugh

-0

It struck me that *this* spec would have more interesting interaction with archiving :)

I'm usually +1 on Experimental stuff, and seeing what happens, but this feels so completely non-XMPPish, I'm -1.

just because there's precedence, doesn't mean it's GOOD precedence

Instant realtime replay of conversations!

I've actually implemented this before, for someone who needed it, using a far far simpler model.

Kev, how exactly?

(and... should we spec it?)

Kev: ditto

probably

This comes up every so often

MattJ: <fragment>I'm half-way through typ</fragment>

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?

ralphm: No, I think we want to discourage specs that don't seem right.

the use case is fine

I'm not -1 because I don't care about the feature.

If we reject this then we need some clear feedback for the author on why

This is 11,600 words (excluding boilerplate) if my copy/paste/wc skills are ok.

MattJ: I'd like a thread on this on standards@

I'm happy to revote after seeing some community feedback.

I'll weight in on such a discussion (I'm happy to start it)

+1 to a discussion thread on standards@

nod

I'll be sure to provide my $0.02USD

I think this is the requirement we currently have set for Council. You can -1, but must post to standards@ with a justification.

:-)

Sure, I'll -1 and post

Ok, then I'm +1 to the -1 if we discuss it

MattJ: You mean you're +0?

I

Or you're -1?

d

o

n

'

t

Dave Cridland: Stop.

Kev: I was −0 (-:

... much like it either. :-)

>_<

linuxwolf: yes, I saw that. It'l ralphm's and MattJ's I missed :)

Kev, put me as +0

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

stpeter: That's not AOB, that's last week's meeting :)

I don't think it is a required to have everyone's +1,-1,0 for moving to experimental

Kev: it's other business as far as this meeting is concerned :)

ralphm: do you have a stance on rtt before we move on?

No, you can fail to express an opinion, but I want to know if you have one.

Kev: I agree with the list action

Ok.

so that appears to be -1 then

:)

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?

shouldn't it be up to Google folks to document Google extensions?

that's what I was about to ask....

So, Dave poked me about this pre-Council, and I said it should be standards track.

Do they care to?

(however, note that I wrote the documentation for linklocal...)

(and that was an Apple protocol)

We'll make a new track called "Google"

haha

grr

:D

I don't see that we gain sufficient interoperability to make this worth documenting but not ST.

I think standards track is fine

I think this was discussed with some Google people

yeah, but if it's our standard, some things will need to change

Jonas is on the author list

stpeter: right

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.

so it's ours and theirs

but yeah we'd at least change the namespace to urn:xmpp:*

I think we should ST it, and do whatever the community thinks is the right thing to do.

stpeter, But that makes it a different protocol.

As it does seem simple and useful.

Do we need this simplification when we have other solutions?

indeed it does

stpeter, THe point of documenting it is to say "this exists", nothign more.

I think we need to take this to the standards@ list

Fritzy: from my limited understanding, this is actually simple and useful.

Dave Cridland: in that case, Informational is right

Dave Cridland: then it's informational

stpeter: No, because it's not a BCP.

stpeter, Informational is described as "typically" for BCP, so there is wiggle-room.

Thus the question about whether we should update the XEP-0001 descriptions.

we've used informational for other "not-quite-standard" protocols in the past

I would say it is historical, but hey

ralphm: Historical means it was written before the JSF existed :)

I would be good with Informational, FWIW

I originally thought Historical, hence its designation.

But Informational suits me fine.

those categories need to be clarified

now that the XSF has been around for almost 10 years

or reambiguated (-:

Good point :)

If we do put this as Informational, I think we should also create an ST version, and obsolete this one.

hmm..

FWIW Telepathy does or is planning to implement this

how about we see what the list discussion is first

I think

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.

I think this requires some more thought

Kev, I'm fine with that (and this was my original plan), but the original is deployed in at least one large implementation.

I think informational documentation of protocols out there in the wild can be helpful

so, what is the value of redoing it in a new namespace?

MattJ, Does implement as specified here.

I don't think I want more/less features

ralphm, that we can advance the protocol

ralphm: We wouldn't for Informational.

But for ST we need to.

ralphm: aside from the fact that "google:" is not a legitimate identifier on any planet I know about?

Heh

that seems bureaucratic

Good point, it's an illegal namespace :D

stpeter's argument is sane

I mean we dropped "jabber:" 8+ years ago?

Anyway.

Wait, so is jabber:iq:... :)

it's an illegal namespace, why encourage those?

Anyway.

MattJ: legacy

Who is volunteering to start a list discussion?

we were idiots back then, why encourage more idiocy?

Dave

Dave

Or are we not bothering and going ahead as Informational?

stpeter: must namespaces be uris?

I vote Informational

and keep the existing namespace

and then ST it if we want to make our own

but that's for the list

I do want a discussion about whether this is the optimal approach.

/agreed w/ MattJ

[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. ]

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.

http://www.w3.org/TR/xml-names/#concepts

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

stpeter: thanks

+1 to simplicity

So someone has to agree to start the list discussion to see what the best way of doing it is.

If this is sufficiently different, we should ST it.

Dave Cridland, the list discussion would be on whether we want to make a standards track version of this

Or, rather, create an ST spec to obsolete the informational.

MattJ: agreed

MattJ, I think that'll come naturally from submitting this one.

I think it would be good to rename the namespace only for this reason

yeah, let's see what the community thinks

So who's starting the discussion

Dave

Someone volunteer, I volunteered for rtt :)

Dave has been volunteered

haha

Dave Cridland: Happy?

i.e. if google would have chosen a valid namespace name, I would excuse them from the namespace changing stuff we regularly do

Dave is fine with informational, remember?

I'd volunteer except I know I'll not get around to it right now

Fritzy: Yes, I'm not happy with Informational without a discussion :)

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.

I'm +1 on accepting this on standards track in that case.

I have no objection to this going on ST.

sure, plus a little service discovery and away we go

Dave Cridland: that's an assumption we should verify

ralphm, I can ask Jonas, of course.

We're 7 minutes away from meeting-tolerance.

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

Dave Cridland: please do

Kev: next?

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.

Kev: same here

ditto

+1

Dave Cridland: Are you willing to start the discussion?

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.

namespace changes can happen during experimental on standards track

I'm happy to publish this Informational and obsoleted by an ST document.

hm

Dave: sounds like you can kick off the list discussion… (-:

that way we could at least refer to the old version, I suppose

Righty, I'll do so - shall I formally submit this before or after?

Dave Cridland: Both at the same time would make me happiest.

It's all about you, isn't it?

;)

Fritzy: About me? Yes.

I'm +1 on 0198

gotta go

Kev, K. I shall submit now, then, and then kick off the discussion once it's announced.

Bye Ralph.

is this extension already documented on google.com somewhere?

Dave Cridland: You have the ST version ready?

I was saying I didn't want the Informational submitted before the ST one.

stpeter, Erm. I can't actually recall - I know that Jonas wrote an email describing it to jdev@ at one point.

Kev, why not?

Kev, Ah, you want an ST one? Well, that's another issue entirely... I can easily enough write out a proposal, of course.

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.

about what?

The right way of doing it.

I think we should allow this informational one first, start the list discussion, and see where it goes

Informationalising it isn't about the right way of doing it

It's about how Google have it implemented *now*

which can be used as the basis of an ST document if we decide we want one

I basically feel unhappy about us documenting this non-ST, given that it's basically one deployment.

MattJ, Right - at least three implementations of this exist now.

Kev, one significant deployment

Kev, It's not one implementation. If it were...

MattJ: Yes.

Dave Cridland: Yes, and I think we should see if it's the right way before we encourage more implementations.

By claiming that this is a BCP.

I don't see we should claim it as a BCP

MattJ: That's what Informational means.

The current definition of "informational" is another matter

fine, then let's redefine informational

then publish

We've already decided it's too limited

linuxwolf: I'm fine with that.

Although that's Board, rather than Council :)

it used to have a broader definition anyway

So fix XEP-0001, publish queue as informational, debate forming an ST doc from it

Kev: right :)

but documentation is good

(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".)

So'd I.

fine by me

Assuming we modify historical to mean "Implemented outside the standards track"

I'm fine with Historical too

+wordsmithing.

do we also want to clarify what the definition of "is" is (-:

But that means redefining Historical to encompass things developed outside the XSF but after it was instigated.

"Documentation is like sex. When it's good, it's very good. When it's bad, it's better than nothing." -- Jeremie Miller

ok my other call is starting

stpeter, Is that Jer's quote? I never knew it was him.

Ok, we've passed tolerance.

oh, +1 on 198

meeting city this morning!

linuxwolf: noted

and ralphm's vote on 198 is noted

I'm happy to vote on this next week as Historical, and someone should ask Board to modify -0001.

7) Date of next meeting

Next Wednesday?

wfm

+1

Fritzy: ?

that's fine.

8) AOB?

+1

I'll update the calendar for next Wed

Ta.

Nope.

some folks need to vote on 198

and the vcard inbox item

stpeter: We know.

yup, I'll do that on list today

just a reminder :)

Anything else?

nope

nay

Ok.

nodda

Just to confirm... my votes for 198 and vcard4 are in, yes? I got no reply

MattJ: I've not seen them on-list. If they're in the buffer, I'll see them when I do the minutes :)

MattJ: didn't see those

Hmph

MattJ: scrolling up

I'll try from my other account again

Ok.

MattJ: probably just my fault

erm, I sent to the list, sorry

ah ok

that works

Thanks all.

thanks

ciao

adios

Thanks

Enjoy :)

oh yeah

Just can't get enough telechats

hi ho, hi by

this is a fun one -- the meeting schedule for IETF 80

Is that Prague?

yes

Some say that's Kev's favorite city to visit

haha

it's a beautiful city

Kev, ok... I don't see my email in the archives... +1s anyway

Kev, I also asked where vcard4 puts User Profile