[Council] Council Meeting Minutes for 2017-03-08

Dave Cridland dave at cridland.net
Thu Mar 16 12:31:17 UTC 2017


On 8 March 2017 at 17:50, Daniel Gultsch <daniel at gultsch.de> wrote:
> 2. Entity Caps 2
> ================
> Vote on accepting Entity Caps 2
> (https://xmpp.org/extensions/inbox/ecaps2.html) as experimental.
>
> Daniel +1
>

+1 to this.

> 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 don't think it does, actually.

More specifically, I think that specifications ought to be talking in
terms of XEP-0030 features, and this spec (and '115) are simply
mechanisms for caching the features, and irrelevant to the
specifications that use the underlying features.

> 4. Vote on advancing XEP-0233
> =============================
> Sam Whited +1
> Link Mauve +1
> Daniel +1
>
> Others to vote on list
>

+1 to this for Draft.

> 5. Several PRs relating to CSI/Carbons
> ======================================
>
> XEP-0280: Clarify the Carbons state after SM resumption.
> https://github.com/xsf/xeps/pull/428
>
> XEP-0352: Clarify the CSI state after SM resumption.
> https://github.com/xsf/xeps/pull/427
>
> XEP-0198: Clarify state after SM resumption.
> https://github.com/xsf/xeps/pull/429
>
> 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.
>
> 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.
>

-1, similarly.

It's not clear to me that the state post-resumption was sufficiently
unclear that it was causing interop concerns.

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

(Voted on another set of minutes as +0).

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


More information about the Council mailing list