moparisthebestFYI for https://github.com/xsf/xeps/pull/1158 I intend to vote +0 and unless everyone else thinks it should go through as-is change it up to not Obsolete it, just remove DNS method (and mention it in security considerations for posterity) and change it to only add urn:xmpp:alt-connections:xbosh, I'd appreciate a indication whether you all think this is the right way forward or not
ncahuillahas joined
ncahuillahas left
danieli literally just now walked into my hotel room and got connected to the internet...
danielthe lady at the check in desk asked me to give a sales pitch for Conversations. that was unexpected and slowed me down...
jonas’present
moparisthebesthaha awesome
danieldo we have a larma?
larmaSomewhat
Ge0rGdaniel: did you arrive with a huge poster?
danieli did not unfortunatly. but i was registered as a business travel to not pay tourism tax
daniel2) Agenda bashing
danielnone
daniel3) Editors update
danieljonas’, published the xep4 and 60 changes we voted on last week
danieland a new proto xep that we are going to vote on later
jonas’do we need to add ownership changes for muji to the agenda, larma?
jonas’i.e. did you get a reply from the authors in that regard?
danieli have not seen public emails? did i miss them?
larmaI haven't had time to write a mail to ML yet, which we agreed to do first.
jonas’ack, I was confused then. carry on.
daniel4) Items for voting
daniela) Obsolete XEP-0156 and add warnings
https://github.com/xsf/xeps/pull/1158
jonas’I can live with that. +1
Wojtekhas joined
Ge0rGWe are removing DNS but also HTTP Lookup Method, right?
danieljust to be clear. this essentially makes bosh obsolete?
moparisthebestso http lookup is already defined in the RFC
jonas’no, HTTPS is delegated to RFC 7395
danielbecause you can’t discover bosh any more?
moparisthebestbut this removes bosh, so my alternate proposal is remove everything else but adding bosh
jonas’ah
moparisthebesthence my +0 vote
jonas’I did not realize this removes BOSH, I thought that was also covered by RFC 7395
moparisthebest(see my comment right before the meeting)
jonas’in that case, -1, because we should keep BOSH discoverable
moparisthebestI didn't either until it was pointed out
Ge0rGyeah, -1 because of BOSH
danieli'm on board with getting rid of dns and getting rid of http
moparisthebestcool, I'll rework the PR for next week
danielbut i do think we need to keep bosh
daniel-1
jonas’moparisthebest, thank you :)
danieldo you want to vote on this as well larma ?
Ge0rGmaybe we can get rid of 0156 if we put BOSH into some other adequate place?
larmaI don't think we need to keep BOSH forever, but probably still need it today, so -1
danielthank you
danielwrt BOSH i think it's interesting that w3c eventsource is still around too (even though websocket exist)
danielbut that's a discussion for another day probably
danielb) Obsolete and update Security Considerations for XEP-0138 and XEP-0229
https://github.com/xsf/xeps/pull/1159
moparisthebestI think I'll remove httppoll too unless people think it's useful..
moparisthebest+1 on this one
larma+1 on b)
jonas’(I would like to point out that writing a MUST NOT in an obsolete document seems kinda pointless :))
Ge0rGI agree with obsoleting, but "this method is deemed insecure and MUST NOT be used" is a normative change and we MUST NOT enforce policy with protocol
danielironcially we just deployed compression on a big project last week
SamI'm torn on this; I get the reasoning, but I also have deployed it on large projects and found it *extremely* beneficial
larmaGe0rG: if you implement it, you must not use it ;)
moparisthebestlots of insecure things are useful
jonas’moparisthebest, I think I would be happier if, instead of changing the normative text, we add a huge security notice to the top of the document and the place where you'd change the normative text instead
jonas’otherwise, it seems that the "MUST NOT" thing is, in fact, obsolete.
moparisthebestthe rationale behind putting the "MUST NOT" in regard to the *method* specifically is because I expect a new compression method to come along and resurrect the negotiation
jonas’right, but at the same time, you're obsoleting that standard, including the MUST NOT
jonas’that seems off
Ge0rG-1 because of the MUST NOT
moparisthebestI'm not married to it, happy to change as you all see fit
Ge0rGI'd be okay with just obsoleting and adding a fat red warning in the security considerations
jonas’what Ge0rG says.
danielyeah i think i'm -1 too. either just obsolete it (and put exi or zstd or whatever in a new xep). or just add a security warning
jonas’-1 to b: what Ge0rG says :).
Sam*thinks outloud* maybe it would be good to have an "editorial notes" section at the top of the XEP that's non-normative and doesn't require any update to the version because it's not actually part of the xep.
jonas’Sam, unrelated to this, because stuff like that should definitely be versioned (thinking attic)
moparisthebestI'll update this one too for next week :)
SamNah, it would be versioned in Git and would be something the editor or council or whomever could update. Maybe call it "Editor Notes" and "Council Notes" or something. We don't version every website page in the attic
SamBut anyways, not a discussion fo rhere
ncahuillahas joined
SamJust throwing the idea out while a relevant thing is being discussed.
jonas’moparisthebest, thank you very much
danielc) XEP-0045: Remove some more mentions of GC 1.0
https://github.com/xsf/xeps/pull/1163
danielon list
danielit'll probably be fine. just want to double check later
Ge0rGI think that "[citation needed]" is not appropriate in a XEP
Ge0rGalso on-list
larmaSame as daniel
jonas’on list, also what Ge0rG says, I'll leave an editorial note
danield) Obsolete some deferred XEP (0008, 0038, 0051)
https://github.com/xsf/xeps/pull/727/
moparisthebestyea I'd be +1 if not for [citation needed]
jonas’daniel, can we split that vote?
danielyes we can
jonas’I'd like to vote +1 on obsoleting 0008, but I don't have an immediate opinion on the other two
Ge0rGon-list
danielright. let me call them seperatly
Ge0rGbut I agree we should vote per-XEP
danielyour votes on obsoleting 0008
danielon list
larmaI'm +1 on all of them
Ge0rG+1
moparisthebest+1 on obsoleting 0008
jonas’+1 on obsoleting 0008
jonas’(using the silence: I also have an AOB)
danielyes give me a second. i'm live editing the spreadsheet on a notebook screen :-)
jonas’shall I take over?
jonas’(for editing, that is)
jonas’(well, I just filled in a few blanks)
danielok. your votes on obsoleting 0038 now please
jonas’on-list
daniellarma's vote has been recorded already
moparisthebest+1 on obsoleting 0038
Ge0rG+1, but I'd like to have a XEP for mapping ASCII smiley to Unicode
danieli'm on list
jonas’Ge0rG, that sounds more like a thing for modernxmpp / client UI
pep.Ge0rG, jabber:x:data
danielnext vote: obsolete 0051
moparisthebestI'm +1 with prejudice on obsoleting 0051 because it needs major security considerations and just has "To follow" yikes.... fyi the very important security considerations are covered by https://datatracker.ietf.org/doc/html/rfc6120#section-4.9.3.19
Ge0rGit's been deferred for over a decade, but is there anybody using it?
jonas’+1, I think this is best addressed with <see-other-host/> stream error in RFC 6120, which also talks about the corresponding security considerations.
jonas’(which I've actually seen in the wild)
danieli'm on list for this one too
Ge0rGalright, given <see-other-host> I'm +1 on obsoleting
moparisthebestI sure hope no one is using it, or if they are, I hope they are using it in a secure way... :/
daniellast time there was a huge debate about them. but i dont recall the outcome
pep.Yes
danielpep where?
jonas’the outcome is that some people whose XML library can't deal with them don't like them
pep.103? Referenced in the stickers thing
SamFWIW, I have seen multiple implementations (not just my own) that this will break even though technically I'm using an XML parser with namespace read support
jonas’on-list for the protoxep
larmaI'm +1 on this
Ge0rGcan't we put a child element into the <x/>?
moparisthebestI'm on-list, my gut reaction is to run from attribute namespaces
pep.I'm not sure why that would be a blocker for experimental anyway
Ge0rGon-list as well
danielattribute namespaces aside i'm thinking that we might want to think this bigger and version presences/roles as well
jonas’pep., I agree, it shouldn't be a blocker for experimental
danieland not just affiliations?
Ge0rGdaniel: fully agree
pep.daniel, there's already two XEPs for presence, doing about the same thing
larmadaniel, for presences there are 311 and 436
Ge0rGit'd be awesome to get a differential membership update mechanism for huge MUCs
danielbut yes personal opinions aside I agree that those aren’t blockers for experimental
danieli'm +1
Ge0rGon-list
jonas’I still need to read it, so I'll stay with on list
danielok. thank you everyone
daniel5) Pending votes
daniela) Georg on 'Proposed XMPP Extension: PubSub Type Filtering'
Ge0rG+1
daniel6) Date of Next
daniel+1w wfm
moparisthebest+1w wfm
jonas’+1w wfm
daniel7) AOB
larma+1w wfm
danieljonas’, mentioned one but we are out of time
danielis everyone fine with extending by 10mins?
moparisthebestYes
jonas’we can also move it to next week, it's not urgent
Ge0rGI'm still semi-here, so ok
jonas’ok, really quick
danielok jonas’ go ahead
jonas’the past two years with pandemic and so on have advanced the A/V technology and probably increase most of ours exposure to that.
jonas’I was thinking whether we should or want to migrate this meeting to an audio-by-default, video-if-desired, chat-as-fallback format
jonas’you can think on that in the week until the next meeting and maybe we can have a discussion then
jonas’infrastructure won't be a problem (I have a Jitsi to spare)
Ge0rGI'm very much -1, not only for auditability reasons
danieljonas’, i was actually considering proposing the same. although maybe on a monthly basis
daniellike every first meeting in a month or something
ZashTry Dino? 😉
larmaI wouldn't be entirely against, but I kinda don't like the idea of using not-standardized XMPP for this and I also don't think everyone wants to use Dino
SamThe minutes would have to be written as the meeting goes on unless it's being recorded for auditability; that seems desirable though. Stuff gets missed when people do them afterwards.
jonas’I'd volunteer to write proper online minutes for auditability
jonas’(I've been doing that for various work meetings in the past two years and it's not a problem for me)
KevDidn't want to derail the meeting, but for 'editorial notes', I think they're a fine idea, but I also think there's no reason not to version them - numbers are cheap and we already have an editorial numbering scheme (the last number).
pep.Judging by what minutes looked like in board (at the time) I'd hope that'd be worth it :/
moparisthebestI also prefer text format as a standard, but I'm fine with audio if everyone else wanted it, or on a monthly basis or whatever
danielok Ge0rG seems to be a hard no. but thank you for the suggestion. maybe something to think about or reconsider at a later date
SamI guess that's fine; versioning them as part of the XEP just means we have to bump a 10 year old final xep just because the editor wanted to add the note "by the way, this typo is incorrect in the example, please ignore it" or something
jonas’I'd like to have a proper discussion including Ge0rG next week when we are not running out of time :)
danielok
danielClose
danielthank you everyone
jonas’thanks daniel!
moparisthebestThanks!
pep.Not in council but that'd be a -1 from the floor. Maybe there can be trials to see how that'd go :x
Kevre: Video/Voice/Text - High bandwidth is useful for Council themselves, if it's the only thing they're doing at the time and not e.g. on trains etc., while text is really useful for people following along, or reading up later. Maybe a poll of non-Council to see how many people actually take advantage of being able to read the raw logs would reveal that I'm the only person who does it, and there wouldn't be much value in keeping that if video was better for Council.
SamFWIW re video calls: I also thought about proposing something like this a few times when I was on the council. Having a face to face chat once a month or more would probably make things go smoother the rest of the time.
danieltwo years into the pandemic i figured out that i can hook up my full frame mirror less camera over usb and use it as a webcam (i had always assumed i needed a hdmi->usb capture device). but with gphoto it just works
jonas’out
moparisthebestAlso Zash some badxmpp that sends https://datatracker.ietf.org/doc/html/rfc6120#section-4.9.3.19 or 0051 before auth or where the target has a bad certificate would be interesting
Zashmoparisthebest, topic for somewhere else, probably jdev@ tho
Kev> I guess that's fine; versioning them as part of the XEP just means we have to bump a 10 year old final xep just because the editor wanted to add the note "by the way, this typo is incorrect in the example, please ignore it" or something
That's true, but it's a bump where we already encode in the version number that the change was meaningless :)
moparisthebestJust brought it up re: our vote here :)
SamDoes bumping the version mean council has to weigh in for final XEPs? That seems to defeat the purpose
moparisthebestI used to be strictly against audio and especially video in preference to text chat, but the last 2 years have shown me they can add some value when used periodically
pep.« Kev> [..] how many people actually take advantage of being able to read the raw logs » I also do that often. Many things that get missed in minutes
moparisthebestSam: editorial changes don't need council, even if versions get bumped I think...
danielyes if anything we should probably start doing 1 in 4 meetings with A/V or something. see how people like it
daniel(instead of every week)
Zash(and do a Summit, so we remember there are actual humans attached to these nicknames/avatars)
Kev> Sam: editorial changes don't need council, even if versions get bumped I think...
This.
SamHmm, I thought final couldn't be bumped at all and draft required council.
SamAnyways, the whole point in my mind is that it's *not* part of the XEP, it could just as easily be a separate wiki page it's just included at the top for convenience, but I don't really care either way.
KevAnd, I realise this might be a pointless idea, but I wonder if there are services where people will transcribe video meetings for you, and if the XSF might be willing to pay for such a service for Council meetings if they went video - that way those of us who like to read up would be no worse off than now, and Council could enjoy the extra bandwidth.
SamThere are; I forget what the one I used in the past was called but it cost <a lot> (I forget that too, just that it was expensive)
ncahuillahas left
pep.A/V for crappy links isn't exactly great either fwiw. It'd be the case for me (if I were in council) but how many times have we heard Ge0r.G complain about his link :)
SamAlthough that was live transcription actually, so maybe it would be cheaper after the fact
larmahttps://cloud.google.com/speech-to-text/pricing first 60 minutes free per month 😀
pep.yay another google service
SamSeems reasonable
SamI forget this can be automated now.
moparisthebestHow do those do with accents I wonder?
moparisthebestThere are some even British accents that are completely incomprehensible to me
SamThe robots are probably better at this than you, they have a larger training set :)
Sam(that's a serious statement, not a joke)
marc0shas left
marc0shas joined
moparisthebestVery possible, I never know if that's the case or whether 100% of their training data were people with California accents
marc0shas left
marc0shas joined
mdoschhas left
mdoschhas joined
Ge0rGmoparisthebest: I think the problem won't be the accents but rather the slang.
Ge0rGtranslation services are horrible at technical slang
moparisthebestProbably true
pep.Too Many TLAs
jonas’I'll see if I can get a demo of a minutes file I created from an A/V meeting