KevI'm having a somewhat distracted day. I'm not intending going anywhere, but in case I fail to notice the time later, could someone please send me a message when the time comes.
Tobiassure
KevThanks.
stpeterhas joined
stpeterhas left
stpeterhas joined
linuxwolfgoes looking for his graphite-powered legacy input device
KevYees.
stpeterdents and tweets
Michaelhas joined
linuxwolfthis is going to bug me all day
KevOn a yoghurt I'm about to eat (although it's a "0% fat" one, which seems to mean "tastes icky"): "suitable for vegetarians".
Hirotaka Satohas joined
KevOne assumes this is contrary to the usual bacon yoghurts, which aren't.
linuxwolfwell, there's vegetarians and there's Vegerians
linuxwolfor vegans
linuxwolfwhich wouldn't eat yogurt if any part came from an animal is some form … such as milk
stpeterdon't forget the fruitarians!
linuxwolfvegitarivores and meatarians
Kevlinuxwolf: It doesn't claim to be suitable for vegans (which, given it's made from milk, would probably be difficult).
linuxwolfvery true
linuxwolfI wonder if they removed all the bacteria … which wouldn't make it yogurt
KevThey certainly removed all the nice.
KevI'm sure that when I was (much) younger, fruit yoghurts used to taste of fruit. Sometimes even the one advertised on the packaging.
linuxwolf0% fat is almost never a good idea
KevI didn't notice any fruit yoghurts that weren't fun-free :/
linuxwolfwhen we were younger, fruit yogurts actually contained fruit
linuxwolfnow they have "natural and artificial flavors"
KevI *like* cherries.
KevI'm sure I do.
KevThey taste fruity and nice.
linuxwolfyou're best bet is to get plain yogurt, add fruit, and blend
guusdkhas joined
stpeterprefers plain, high-fat yoghurt
linuxwolfmaybe some honey too
stpeterand how did we get on this topic? ;-)
KevAlso: Bacon.
Kevstpeter: I'm whining about eating a fun-free yoghurt.
linuxwolfnow I'm hugry
guusdkhungry within a minute joining the xmpp council muc.
linuxwolflet's get this over with so I can address that hunger thing
KevYeah, I was until I tasted this yoghurt, too!
linuxwolfI think I'll have a ham-and-cheese panini
stpeterhave we pinged Ralph and Matthew?
KevI have (just)
ralphmhas joined
linuxwolfjust pinged Ralph
linuxwolfhehe
stpeteroh shoot, gotta join the IETF Tools Team call
Tobiaspinged matt
KevRighty.
MattJhas joined
Kev1) Roll call
KevI'm here!
ralphmAOL
linuxwolfpresente
MattJHere!
Tobiashere
KevAmazing.
Kev2) Spec length
KevWhat to do about -45 and -60?
MattJToo long.
KevXEP-0312: TL;DR
linuxwolfI doubt anyone will argue too short
MattJWell there are obviously only two things we can do: split or remove
ralphmheh
KevRight, so, I don't argue with splitting MUC into essentially two - Administration and Usage or something.
MattJMakes sense
KevAlthough I'm not sure what it buys us, really, other than two shorter specs.
KevWe want servers to implement all of it, regardless.
KevI suppose clients could just implement the non-admin bits (as Swift did for a while).
linuxwolfI think we'd end up with some duplication, with regards to join/create
MattJWell splitting MUC makes less sense for others, I think
MattJ*less sense than for others
ralphmI haven't really considered splitting MUC
MattJOTOH I have a growing list of things I'd like to see removed from XEP-0060
ralphmFor XEP-0060 there are a lot of optional features
ralphmthat could be moved to their own spec
linuxwolfyeah, XEP-0060 could benefit from breakup
linuxwolfnot sure about MUC right now
KevOk, so is it fair to say that rough consensus is that -45 should be left alone, wrt. splitting it?
MattJI'm convinced there are a whole bunch of features in XEP-0060 that *nobody* is using
ralphmthere you have some very basic use cases that you can build upon
KevSplitting -60 seems fine to me, although I don't know it in enough depth to suggest where.
MattJI think MUC isn't too bad
stpeterfor MUC, I do think we could fairly easily split the dumb-client parts from the moderator/admin/owner use cases -- and *most* clients don't support any of the latter
MattJWe just need to be sure not to add to it
Tobiasdo you think the duplication would be much when splitting basic chat features and complex admin stuff for MUC?
MattJI wouldn't be opposed to an admin/user split of the spec
KevTobias: Well, you've got room creation, kicking and things.
linuxwolfstpeter: probably, although some discussion in the "dumb-client" spec would need to talk about create in some referential manner
stpeterlinuxwolf: for sure
KevSo a dumb client may not be able to kick, but should still know what being kicked looks like.
stpeterright
linuxwolfyeah
TobiasKev, but these would only be added by the admin spec, wouldn't they...basic clients would still understand normal errors and such
ralphmsure, you need to discuss roles etc in the core spec
stpeterralphm: true
KevSo, my rough stance on this is that I'm not opposed to a sensible split for -45 into dumb client and admin, but that I think getting such a split would be hard work that I'm not looking forward to having to review, and very much want to not have to do.
MattJIn fact the main advantage I see of splitting 45 as it stands is that we can experiment with e.g. defining other protocols for admin of a room/service
stpeterso I think it might be useful to take a look at 45 and see what it would look like with the moderator/admin/owner stuff moved to a separate spec
ralphmnod
linuxwolfsure
stpeterMattJ: yes, ad-hoc commands in MUC is on my list :)
MattJMine too
MattJBelow MAM :)
stpeterheh
linuxwolfchanges 0.25USD to hildjj
stpetermy workflow is slowing down with the impending end of my IESG term, so I'll have more time soon
KevOk, so, pubsub everyone's happy with being split.
linuxwolfs/changes/charges
linuxwolfKev: definitely
KevI don't think we need to discuss this further then, do we?
linuxwolfnot presently
stpeterKev: I can take a quick/rough pass at 45
KevI'll take -45 changes as they come, but I have assorted reservations that I'm happy to have removed by seeing something that works.
stpeterKev: I think it would be worth discussing 60
stpeterclearly there's a lot in 60
Kevstpeter: Now, or when we have some sort of split pencilled up so we can discuss it?
stpeterwell, have people looked at 60 and thought about how we might split it up?
stpetersame kind of thing?
linuxwolfhow about we start with everyone's list of "please remove"
ralphma bit
ralphmmost of the configuration bits could be moved out
MattJI'm still in the process of XEP-0060 review
stpeteri.e., admin/owner/etc. vs mere publish and subscribe?
linuxwolfI've thought about it, but haven't gone into much detail
KevI haven't, I think everyone else here has a better grasp of pubsub than I do.
ralphmfor nodes, subscriptions and pre-conditions
stpeterI think that pub and sub are pretty simple, really
MattJso I'll probably have a better list when I submit my feedback to the list
ralphmstpeter: yeah
stpeterok
stpeterso it sounds like we can circle back on this topic in a few weeks
linuxwolf/nod
stpeterand perhaps start a thread on the pubsub@ list?
linuxwolf+1
stpeterI can start a thread on muc@ when I take a rough pass at the split
Kev3) Last call on XEP-0267
MattJeven for subscriptions... I think things like "multiple subscriptions" should be (re)moved (or at least fixed)
ralphmI'd very much like to see XEP-0060 be a very stripped down spec that explains the core use case, with references to other specs for enhanced behaviour
MattJ+100
Tobias+1
ralphmI'll have a pass at XEP-0060 and make a list
stpeterralphm: super
KevDo we have implementations of 267 deployed/used now?
linuxwolfgarzie
linuxwolfgrazie even
linuxwolfgah
linuxwolfKev: I don't know
stpeterKev: there's an implementation in Prosody (experimental) but I've not yet had time to deploy it at xmpp.net
stpeterI'd be happy to wait
KevI'm not opposed to Last Calling it I guess, but I'm unlikely to want to push it to Draft.
MattJand I haven't looked at it or tested it yet
stpeterright
ralphmtwo would be nice
stpeterhow about I test it out at xmpp.net first
MattJwfm
linuxwolf+1
Tobiassounds like a plan
stpeternotes that we might need to think about this non-requirement requirement for multiple implementations and deployment experience before pushing something to Draft
KevOk. I may even have comments about it, I think.
ralphmstpeter: I think multiple implementations is still a great thing to have
KevI treat Experimental as "Not obivously broken" and Draft as "The way we have consensus on solving this", mostly (and Final as "done deal").
stpeterralphm: always, the question is: is that a requirement for advancement? XEP-0001 doesn't say that
KevI think the current state of 267 is that we don't know that this is the right way to do this as we've not tried it.
stpeterbut that's a topic for a future meeting
stpeterKev: probably
KevOr, to phrase it slightly better, it can't stop being Experimental until there's been an experiment.
linuxwolfthought experiments can go far, but maybe not far enough
ralphmright, so the non-requirement kinda makes it easier to assert if it is the right way to do a thing
stpeteranyway
stpeterI think we have a path for 267
KevWe've explicitly made the bar to Experimental very low in recentish meetings.
stpetermore experimentation on the way :)
linuxwolfthe bar as been lower (-:
MattJKev, *ahem* :)
ralphmKev: I've never lowered the bar, I don't think it should be very high at all
ralphmbut draft should be
linuxwolfI'm with ralphm
KevRight, that's what I said, isn't it?
KevWe've discussed this recently and agreed that the bar to Experimental should be very low.
ralphmright
KevIt doesn't imply that Draft should be that low.
linuxwolfyes, but some of us started very low, and others needed to move (-:
Astrohas joined
ralphmso I am again arguing for actual implementations (plural) to move forward
linuxwolfanyway, we're in general agreement, so let's move on (-:
KevI don't need multiple implementations to persuade me it's Draft ready - but it's the easiest way to persuade me.
Kevlinuxwolf: right.
Kev4) Last call on XEP-0297
MattJ+1
linuxwolfare there multiple implementations?
stpeter(BTW, a quick visual comparison of http://xmpp.org/extensions/xep-0045.html#moderator and http://xmpp.org/extensions/xep-0045.html#statuscodes indicates that we'd cut about 40% of XEP-0045 by moving the moderator/admin/owner use cases)
Tobiasi don't know of a single implementation
Kevlinuxwolf: I think there are, actually, aren't there?
stpeter(but I'll post to muc@ about that....)
linuxwolfMattJ has one for Prosody
linuxwolfright?
MattJand a client one in Verse
Tobiasah...ok
KevAs the BC guys are using MAM, which uses it.
MattJZash wrote both
linuxwolf/-:
Tobiasnice
MattJand yes, BuddyCloud
linuxwolfok then
linuxwolf+1 for last call
stpeternotes that we'll need 297 for Carbons
KevRight.
linuxwolfI'll make my comments during LC
KevI'm ok with Last Calling this.
stpeterthat's why I'm interested in seeing this done