[Council] Council Meeting Minutes for 2017-03-08
tmarkmann at googlemail.com
Thu Mar 9 11:58:59 UTC 2017
On Wed, Mar 8, 2017 at 6:50 PM, Daniel Gultsch <daniel at gultsch.de> wrote:
> 0. Roll call
> -Sam (chairing)
> -Link Mauve
Thanks to Sam for chairing.
> 1. Minute Taker
> Daniel volunteers as a minute taker
> 2. Entity Caps 2
> Vote on accepting Entity Caps 2
> (https://xmpp.org/extensions/inbox/ecaps2.html) as experimental.
> Daniel +1
> Other to vote on list
> Council agrees that this needs more list discussion on list on whether
> this should be an inplace upgrade to XEP-0115. If it becomes a new XEP
> depending XEPs should be updated to a more generalized wording like
> "use XEP-0030 or any caching mechanism like ecaps2"
I really welcome someone improving our current feature caching method in
XMPP. Although I'm not sure if it were better trying to fix things in
XEP-0115, as it aims solving the exact same thing.
Regarding the XEP itself, it's strange that sorting is fist mentioned in
examples section, where I'd expected it to be mentioned as part of the Hash
Function Input section.
> 3. LC for XEP-0333 Chat Markers
> Current author (Daniel) says it should go back to experimantel because
> he needs more time to finish it.
> 4. Vote on advancing XEP-0233
> Sam Whited +1
> Link Mauve +1
> Daniel +1
> Others to vote on list
+1 on advancing XEP-0233.
> 5. Several PRs relating to CSI/Carbons
> XEP-0280: Clarify the Carbons state after SM resumption.
> XEP-0352: Clarify the CSI state after SM resumption.
> XEP-0198: Clarify state after SM resumption.
> Daniel notes that by delegating responsibly to the individual XEP’s
> you are forcing those XEP’s to do a Namespace bump to clarify that
> behaviour while he believes that the behaviour wasn’t necessarily
> unclear before.
If the behaviour currently isn't unclear, I don't see why rewording or more
clearly describe the current behaviour would cause a namespace bump.
> Sam thinks the 0198 change is unessary.
> Vote on #429
> Sam -1
> Link Mauve -1
> Daniel -1
> The carbon state (carbons being enabled for the *stream* and carbons
> are enabled via IQ) is actually well defined as being in the same
> state after a resumption. This makes #428 unecessary.
Might not hurt to clarify this in the Carbons XEP though, as it just
clarifies the current behaviour and makes it more obvious to new readers.
> 6. Add <x/> tag to MUC-PMs
> PR is here: https://github.com/xsf/xeps/pull/436
> Everyone is going to vote on list. Daniel considers blocking this
+1 for the MAY version.
> 7. Migration plan for SHA-1
> Link Mauve is going to work out a list of every SHA-1 usage we have.
> 8. IEEE IoT email
> Sam will send out an email to council discussing specific plans
> regarding IoT SIG / IEEE interaction.
> 9. Date of next
> 2017-03-15 1600Z
> 10. AOB
> Sam reminds Link Mauve to vote on SASL2 and IBR2 and Daniel to vote on IBR2
> Sam bangs the gavel.
Thanks for the minutes Daniel.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Council