-
m&m
T - 10
-
Kev
Thanks.
-
stpeter
T - 0 ? ;-)
-
MattJ
T+1
-
Kev
Yep.
-
stpeter
:)
-
Kev
1) Roll call.
-
m&m
presente
-
Kev
Ralph sends apologies.
-
Tobias
present
-
Kev
(about 2 minutes ago)
-
Kev
MattJ: .
-
m&m
he indicated last week it was likely he'd miss
-
stpeter
Matthew is around, I think
-
m&m
he == Ralph
-
Kev
m&m: Ta.
-
MattJ
Present
-
Kev
2) LC http://xmpp.org/extensions/xep-0186.html ?
-
Kev
I've just noticed a somwhat major problem with this.
-
MattJ
Oh?
-
Kev
Which is that if a user goes invisible, joins some MUCs and then goes visible those MUCs will never receive an unavailable.
-
Kev
"When the client becomes visible, the server MUST treat that state as equivalent to an active session before receiving initial presence from the client."
-
stpeter
hmm
-
Kev
So it's a trivial fix, I think, just that sentence needs a reword.
-
m&m
/nod
-
stpeter
if an invisible man enters a room, is he present? ;-)
-
MattJ
Yes and no
-
m&m
Schrodinger's occupant?
-
stpeter
heh
-
Tobias
hehe
-
Kev
So, I don't know if Peter wants to fix that up a bit before we issue Last Call, or after.
-
Kev
I'm easy.
-
stpeter
Kev: won't the MUC room receive unavailable if the now-visible man goes offline?
-
Kev
No, because the server's forgotten about the directed presence.
-
stpeter
oh, I see
-
stpeter
right
-
m&m
active != available
-
stpeter
same is true for all directed presence sent while invisible
-
stpeter
ok
-
Kev
Right. The MUC was an illustration because it's the most likely use of directed presence while invisible (he asserts, boldly).
-
stpeter
yeah, I will clean that up -- I assume we'd prefer to say that the server needs to add any directed presence JIDs to its list of entities it'll send unavail to
-
Kev
Right.
-
stpeter
prepopulate that list -- whatever we call it in RFC 6921
-
Kev
Want to do that pre-or-post-LC?
-
stpeter
er, 6121 ;-)
-
stpeter
no preference
-
stpeter
might as well do it right now
-
m&m
(-:
-
stpeter
or after this meeting :)
-
Kev
I'll +1 the LC in any case.
-
Kev
Everyone else?
-
Tobias
+1
-
m&m
also +1
-
m&m
it's far enough from IETF (-:
-
Kev
MattJ: ?
-
MattJ
Did anyone read my points about probes on the list?
-
Kev
MattJ: I haven't.
-
MattJ
As in, mainly I want them optional
-
Kev
Or, at least, I didn't notice it enough for it to stay in my inbox.
-
MattJ
and an optional flag in the protocol to enable/disable them
-
m&m
I don't recall either
-
MattJ
I can provide text for it, but do we want it pre-draft/LC?
-
Kev
MattJ: I don't think the XEP prohibits probes, does it?
-
MattJ
There are pros/cons each way regarding the sending of probes
-
MattJ
It depends how paranoid you are, and your reasons for invisibility
-
stpeter
I thought we concluded that the flag would make this little extension less simple than desired
-
MattJ
Fair enough if that really is the consensus
-
MattJ
Let's LC it, and I'll post my thoughts to the list
-
stpeter
well, feel free to raise the issue again
-
stpeter
ok
-
Kev
MattJ: I'm not sure it makes a great deal of sense to add that to the XEP, although I'm not dead-set against it.
-
Kev
I note, though, that a server can allow the client to change whether it happens as part of the per-user ad-hoc configuration.
-
Kev
Assuming it has such a thing.
-
MattJ
Kev, if we don't add it, should the server default to sending or not sending probes?
-
Kev
(And the XEP gives leeway either way)
-
Kev
Implementation issue? :)
-
m&m
this sounds like a great discussion for the list, post LC
-
MattJ
Kev, not exactly :)
-
Kev
In any case, that's everyone present +1 on LC.
-
MattJ
Or two differing implementations will give invisible users very different behaviour
-
MattJ
But yes, +1 to LC and we'll discuss on-list
-
Kev
3) http://xmpp.org/extensions/inbox/xml-media-element.html Accept?
-
MattJ
I need to read it through, and I'll post to the list
-
m&m
I have further objections to publishing
-
m&m
er
-
m&m
no futhre
-
m&m
gah
-
m&m
no further
-
Kev
I've got assorted issues with it, but not enough to prevent it going on the vine.
-
m&m
exactly
-
Kev
Tobias: ?
-
Tobias
+1 for publishing as experimental and fixing remaining issues then
-
Kev
4) Date of next meeting?
-
Kev
It'd be easier for me for it to not be next week, but I can possibly manage if we need it.
-
m&m
-1 to next week
-
MattJ
+0 to next week
-
Kev
Week after?
-
m&m
Us 'Murricans have a holiday
-
MattJ
Oh good
-
m&m
7/11 works for me
-
m&m
and not just for Slurpees
-
Kev
Ah, yes, when we good British folks gave the Merkins a kind and thoughtful present of independence.
-
Tobias
that'd work for me
-
stpeter
Kev: When the client becomes visible, the server MUST treat that state as equivalent to an active session before receiving initial presence from the client, with one exception: if the client sent directed presence to any entities while in the invisible state, the server MUST treat those entities as under point 2 of Section 4.6.3 of RFC 6121 (i.e., the server MUST ensure that it sends unavailable presence to those entities if the client subsequently goes offline after becoming visible).
-
Kev
stpeter: +1 on that text.
-
Kev
(Thanks)
-
stpeter
good catch
-
Kev
OK, so we've on for a fortnight ~now.
-
stpeter
I'll 0.11 shortly and then issue the LC
-
Kev
5) AOB?
-
m&m
none from me
-
Tobias
no AOB from me either
-
Kev
Cool, all done then.
-
Kev
Thanks all
- Kev bangs the gavel.
-
m&m
with plenty of time before my next meeting!
-
Tobias
thanks
- m&m goes back to upsetting various working groups
-
m&m
oh wow … fippo actually posed to a list!