Re: [Standards] 2017-09-20 XSF Council Minutes
Hi, my missing votes are inline. On Wed, Sep 20, 2017 at 5:46 PM, JC Brand wrote: > 2017-09-20 XSF Council Minutes > == > > Present: Tobias, Link Mauve, SamWhited, jonasw, daniel > Minute taker: jcbrand > > 1) Vote on accepting "Consistent Color Generation" as Experimental XEP > > Tobias will vote on the mailing list > +1 from daniel, SamWhited and Link Mauve > +1 > 2) Vote on accepting "Jingle Encrypted Transports" as Experimental XEP > > +1 > Tobias will vote on the mailing list > > SamWhited wonders if the TODO currently at the bottom of the XEP means that > it's going to be split into separate XEPs, or just separate sections in the > existing XEP. And whether it makes sense to accept it if it'll be split up. > > According to jonasw, vanitasvitae said he’d add more XEPs specifying how to > use the JET framework with OMEMO etc. > > SamWhited will ask for clarification on the mailing list or double check > the discussion. > > Link Mauve and daniel will vote on the mailng list. > > 3) Discuss removal of Groupchat 1.0 protocol from XEP-0045 > > jonasw mentions that the original request is from a discussion in the XSF > chat > room. > > According to jonasw the origin of the discussion was that currently > there’s no > reasonable way for a client to know whether it’s still joined. > > Simply sending a presence to ensure that one is still joined could be > interpretedd as a "Groupchat 1.0 join", which is not desired and therefore > the > suggestion was made to remove the "Groupchat 1.0" protocol entirely. > > Clients are then also safe against accidental Groupchat 1.0 joins when they > desync. > > Tobias asks about the impact of not incrementing the namespace on clients > that > support Groupchat 1.0 and SamWhited says he's ok with breaking > compatibility > with those clients. > > Kev says that this approach is a hack and that rather than sending a > presence, > an IQ could be made to the room to determine whether you're still in it and > that XEP-0045 should be updated for that instead. > > Discussion will continue on the standards mailing list. > > 4) Consider advancing XEP-0387: XMPP Compliance Suites 2017 to Draft > > According to daniel, the suite requires the bookmarks XEP which can't be > implemented right now due to it depending on PEP functionality which > doesn't > exist yet. > > Link Mauve says it can depend on XEP-0049 (Private XML storage) instead of > PubSub/PEP and SamWhited says that PubSub is stated as RECOMMENDED and not > REQUIRED. > > Consensus appears to be that it's not a blocker. > > A Last Call will be issued for it. > > 5). Issue a new LC for XEP-0352: Client State Indication, > based on https://github.com/xsf/xeps/pull/427 > > +1 from SamWhited, Link Mauve, Tobias and daniel > > --- > > Date of next meeting is Wednesday 27 September 15:00 UTC. > > Link Mauve is having holiday, so won't be able to make it. Enjoy! > > Cheers, Tobi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] 2017-09-20 XSF Council Minutes
On Wed, Sep 20, 2017, at 10:46, JC Brand wrote: > 2) Vote on accepting "Jingle Encrypted Transports" as Experimental XEP +1 —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] 2017-09-20 XSF Council Minutes
2017-09-20 XSF Council Minutes == Present: Tobias, Link Mauve, SamWhited, jonasw, daniel Minute taker: jcbrand 1) Vote on accepting "Consistent Color Generation" as Experimental XEP Tobias will vote on the mailing list +1 from daniel, SamWhited and Link Mauve 2) Vote on accepting "Jingle Encrypted Transports" as Experimental XEP Tobias will vote on the mailing list SamWhited wonders if the TODO currently at the bottom of the XEP means that it's going to be split into separate XEPs, or just separate sections in the existing XEP. And whether it makes sense to accept it if it'll be split up. According to jonasw, vanitasvitae said he’d add more XEPs specifying how to use the JET framework with OMEMO etc. SamWhited will ask for clarification on the mailing list or double check the discussion. Link Mauve and daniel will vote on the mailng list. 3) Discuss removal of Groupchat 1.0 protocol from XEP-0045 jonasw mentions that the original request is from a discussion in the XSF chat room. According to jonasw the origin of the discussion was that currently there’s no reasonable way for a client to know whether it’s still joined. Simply sending a presence to ensure that one is still joined could be interpretedd as a "Groupchat 1.0 join", which is not desired and therefore the suggestion was made to remove the "Groupchat 1.0" protocol entirely. Clients are then also safe against accidental Groupchat 1.0 joins when they desync. Tobias asks about the impact of not incrementing the namespace on clients that support Groupchat 1.0 and SamWhited says he's ok with breaking compatibility with those clients. Kev says that this approach is a hack and that rather than sending a presence, an IQ could be made to the room to determine whether you're still in it and that XEP-0045 should be updated for that instead. Discussion will continue on the standards mailing list. 4) Consider advancing XEP-0387: XMPP Compliance Suites 2017 to Draft According to daniel, the suite requires the bookmarks XEP which can't be implemented right now due to it depending on PEP functionality which doesn't exist yet. Link Mauve says it can depend on XEP-0049 (Private XML storage) instead of PubSub/PEP and SamWhited says that PubSub is stated as RECOMMENDED and not REQUIRED. Consensus appears to be that it's not a blocker. A Last Call will be issued for it. 5). Issue a new LC for XEP-0352: Client State Indication, based on https://github.com/xsf/xeps/pull/427 +1 from SamWhited, Link Mauve, Tobias and daniel --- Date of next meeting is Wednesday 27 September 15:00 UTC. Link Mauve is having holiday, so won't be able to make it. Enjoy! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
