Re: [Standards] XMPP Council Minutes 2018-04-11
Thu, 12 Apr 2018 23:47:09 + Tedd Sterr wrote: > Isn't this the point of the CFE - to find out? > There is always the *possibility* that somebody somewhere could > possibly maybe have implemented a given feature, but if nobody knows > about it, do we just assume it does anyway? In which case, we can > always assume there are enough implementations because there *might* > be. That's why back in the days I suggested to keep track of XEP implementations. However, I was told the information there would be inaccurate. But I fail to see how polling a few users in rare meetings is going to be more accurate. Another objection is that XSF needs a lot of efforts to keep this table up to date. And this might be true, of course. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2018-04-11
On 4/12/18 5:47 PM, Tedd Sterr wrote: >> But we might never know if someone is building an application or service >> on top of a library... > > Isn't this the point of the CFE - to find out? > There is always the **possibility** that somebody somewhere could > possibly maybe have implemented a given feature, but if nobody knows > about it, do we just assume it does anyway? In which case, we can always > assume there are enough implementations because there **might** be. > > A CFE asks whether anyone has implemented the feature and what their > experiences were (was it straightforward, well documented, any issues, > etc.) While a library implementation could answer /_those_/ questions, > questions of whether the feature is good in practice or what issues > arise from its use can only really be answered by somebody using the > library's implementation of said feature. Sometimes the library developers know these things because of feature requests they've received or questions they've answered, so it's worth asking them. But you can't necessarily find this out first-hand from those who are using the library. I'm just saying don't discount entirely the fact that there are multiple library implementations. Peter ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2018-04-11
> But we might never know if someone is building an application or service > on top of a library... Isn't this the point of the CFE - to find out? There is always the *possibility* that somebody somewhere could possibly maybe have implemented a given feature, but if nobody knows about it, do we just assume it does anyway? In which case, we can always assume there are enough implementations because there *might* be. A CFE asks whether anyone has implemented the feature and what their experiences were (was it straightforward, well documented, any issues, etc.) While a library implementation could answer _those_ questions, questions of whether the feature is good in practice or what issues arise from its use can only really be answered by somebody using the library's implementation of said feature. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2018-04-11
On 12 April 2018 at 22:58, Sam Whited wrote: > On Thu, Apr 12, 2018, at 16:41, Christian Schudt wrote: > > here some implementation for XEP 131 and 141 because you said „doesn’t > > have enough implementation“. > > In general I think "implementations" is meant to read "clients or > applications", here. If something is implemented in a library (or several > libraries), but then never used in a real client or application then we > still can't really claim to have any experience with the protocol in a > "real-world" scenario. I'm not sure there's anything official saying this > has to be the case, but that's my take on what "implementations" means. > Indeed true. I know of one non-public one based on top of Smack; I'll see about getting documentation for it. And, embarrassingly, I realised the project I've been working on also implements XEP-0141: https:github.com/surevine/web-chat/ implements XEP-0141 for forms found in XEP-0346. So there are two, and one is open source. Hoorah? > > —Sam > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2018-04-11
On 4/12/18 3:58 PM, Sam Whited wrote: > On Thu, Apr 12, 2018, at 16:41, Christian Schudt wrote: >> here some implementation for XEP 131 and 141 because you said „doesn’t >> have enough implementation“. > > In general I think "implementations" is meant to read "clients or > applications", here. If something is implemented in a library (or several > libraries), but then never used in a real client or application then we still > can't really claim to have any experience with the protocol in a "real-world" > scenario. I'm not sure there's anything official saying this has to be the > case, but that's my take on what "implementations" means. But we might never know if someone is building an application or service on top of a library... Peter ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2018-04-11
On Thu, Apr 12, 2018, at 16:41, Christian Schudt wrote: > here some implementation for XEP 131 and 141 because you said „doesn’t > have enough implementation“. In general I think "implementations" is meant to read "clients or applications", here. If something is implemented in a library (or several libraries), but then never used in a real client or application then we still can't really claim to have any experience with the protocol in a "real-world" scenario. I'm not sure there's anything official saying this has to be the case, but that's my take on what "implementations" means. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2018-04-11
Hi, here some implementation for XEP 131 and 141 because you said „doesn’t have enough implementation“. => XEP-0001 requirement (at least two implementations) is fulfilled. — Christian > 4) Advance to Final XEP-0131: Stanza Headers and Internet Metadata - > https://xmpp.org/extensions/xep-0131.html > > Kev: -1 (doesn't have the implementations, and other reasons) Stanza.io: https://github.com/legastero/stanza.io/blob/master/docs/Supported_XEPs.md Smack: https://download.igniterealtime.org/smack/docs/latest/javadoc/org/jivesoftware/smackx/shim/packet/Header.html Babbler: https://sco0ter.bitbucket.io/babbler/apidocs/rocks/xmpp/extensions/shim/model/Header.html Gloox: https://camaya.net/gloox/features/ SleekXMPP: https://github.com/fritzy/SleekXMPP/tree/develop/sleekxmpp/plugins/xep_0131 > 5) Advance to Final XEP-0141: Data Forms Layout - > https://xmpp.org/extensions/xep-0141.html > > Kev: -1 (would like to advance, but doesn't have the implementations) Stanza.io: https://github.com/legastero/stanza.io/blob/master/docs/Supported_XEPs.md Smack: https://download.igniterealtime.org/smack/docs/latest/javadoc/org/jivesoftware/smackx/xdatalayout/packet/DataLayout.html Babbler: https://sco0ter.bitbucket.io/babbler/apidocs/rocks/xmpp/extensions/data/layout/model/Page.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Minutes 2018-04-11
http://logs.xmpp.org/council/2018-04-11/#15:01:53 1) Roll Call Present: Kev, Dave, Daniel, Georg, Sam 2) Agenda Bashing Dave apologises for not managing to do an agenda this week, and quickly makes something up: two CFEs, Kev's IM-NG protoXEP, and... Jonas mentions the GC-1.0 abolishment vote (referencing Georg's email: https://mail.jabber.org/pipermail/standards/2018-April/034760.html) Georg adds that he also has a proposal for MUC self-ping. Daniel wants to register the MUC config option for MAM, or least clarify the process for doing this. Dave decides that should be plenty for one meeting. 3) Minute Taker Either Tedd Sterr will do it or else Dave will. Goerg mentions that the abolition of Pidgin is a Board agendum now. Dave tries to figure out which CFEs have completed; Jonas says 0131, 0141, and 0229. 4) Advance to Final XEP-0131: Stanza Headers and Internet Metadata - https://xmpp.org/extensions/xep-0131.html Kev: -1 (doesn't have the implementations, and other reasons) Sam: -1 (doesn't feel like it fits a need, and doesn't have the implementations; we should kill it instead) Dave: [on-list] (would like to ditch it, but it's referred to by other XEPs - 0060 and 0149) Daniel: -1 (actually implemented this once, but it's too niche) Georg: -1 (had a tough fight against generic headers in 0363) 5) Advance to Final XEP-0141: Data Forms Layout - https://xmpp.org/extensions/xep-0141.html Kev: -1 (would like to advance, but doesn't have the implementations) Daniel: -1 Georg: -0 Sam: -1 (same reason as Kev; also forms is too complex already and we shouldn't shoehorn layout into document structure) Dave: [on-list] 5') Advance to Final XEP-0229: Stream Compression with LZW - https://xmpp.org/extensions/xep-0229.html Dave: -1 (implementations, and don't see a driving need for it) Sam: -1 (have used this and have implementations, but it's underspecified) Kev: -1 Daniel: 0 Georg: -1 (security issues of mixing different data classes into a compressed stream) Daniel asks whether the security issues apply to compression in general, not specifically 0229; Georg confirms it applies to compression and thus 0229 by extension. Sam recommends figuring out what to do with 0138 (Stream Compression) and then 0229 could follow suit. Daniel feels it's not right to 'punish' 0229, rather than 0138; Georg agrees and suggests adding 0138 to next week's agenda. 6) Adopt ProtoXEP: IM Routing-NG - https://xmpp.org/extensions/inbox/im-ng.html Kev recognises it will need to adapt with future decisions, but would like to get it under XSF control. Georg is incredulous that he missed this submission. Georg: [on-list] Kev: +1 Dave: 0 (worry this might end up the bike shed of bike sheds, but not going to veto) Daniel: +1 (to get it under XSF control; not sure I like it in its current form) Sam: +1 7) Kill GC-1.0 (removal from XEP-0045) Kev is OK with this in principle, as long as it results in an improvement. Daniel requests a link to the PR; Kev & Georg clarify that it's a vote on the principle of the removal; Georg promises to prepare a PR should the vote be accepted (but not when that will be submitted.) Kev is fine to see a PR, and would be OK with one that doesn't break anything, but isn't sure it's possible. Dave is fine with removing bare presence as a mechanism for joining a chatroom, but worries that after losing sync existing clients may inadvertently join using GC-1.0, which would then perform a different action. Georg asserts that two weeks of stats from prosody.im and yax.im show that only one client didn't support MUC protocol; Dave says that's a different problem to the one he outlined. Georg explains his preference is to make the user explicitly aware they're gone, rather than silently re-joining and possibly missing part of history. Dave counters that this presumes a client will gracefully handle an unexpected join rejection to a presence stanza they didn't think was a join in the first place. Georg hopes sane clients will handle a MUC presence error as no longer joined; Dave thinks this might be optimistic. Georg attempts to clarify whether Kev is against this, and feels unable to meet Kev's exacting requirements without the ability to fix MUCs getting out of sync, which is what GC-1.0 covers up; Kev doesn't want to stop Georg from trying, but does want to ensure changes to a Draft XEP don't break anything (and expects it inevitably will.) Georg wonders whether sending an error to non-joined clients is considered breaking; Kev says it depends whether clients react sensibly. Georg: +1 Sam: +1 (tentatively, on the general idea; can't hurt to see a PR) Dave: +1 (keen to see what this would do in practice) Daniel: +1 Kev: +1 8) AOB Daniel queries the process for registering a new MUC config option, and the possibility of voting its addition to the registry; Dave is unsure but will look into it, and expects it's simply a matter of documenting it. Georg wants a vote-on-principl
