Re: [Standards] LAST CALL: XEP-0345 (Form of Membership Applications)
On 2019/01/12, Jonas Schäfer wrote: > This message constitutes notice of a Last Call for comments on > XEP-0345. > > Note: Since this is a Procedural XEP under control of Board, the Last Call > mail goes to both standards@ and members@ (only for XSF members) mailing > lists. This may lead to fragmentation of feedback. The archives of the lists > are at [1] and [2] respectively. > > Title: Form of Membership Applications > Abstract: > This specification outlines the form and mandatory content of > membership applications. > > URL: https://xmpp.org/extensions/xep-0345.html > > This Last Call begins today and shall end at the close of business on > 2018-01-27. > > Please consider the following questions during Last Call and send your > feedback to either or both of the members or the standards discussion list. > > 1. Is this document needed to fill gaps in the XMPP Standards Foundation's > policies and procedures, or to clarify an existing XSF policy or procedure? Yes. I just reread the bylaws, and there does not seem to be any indication of what information is required to apply for membership. > 2. Does the document address the problem stated in the introduction and > requirements? Yes. > 3. Should the XSF adopt this document as part of its policies and procedures? Unsure. See concerns / questions below. > 4. Do you have any concerns about the effects of this policy? §2 of the XEP -- "Who May Apply" -- specifies that it is not normative, but it states: > only "natural persons" The bylaws directly conflict with this in §2.1 "Admission of Members": > [..] to be eligible for membership, a person, corporation, organization, > or other entity [..] This is confusing to say the least. Another concern that has surfaced not so long ago, and which is the reason of this LC, is about requiring a Legal Name, §6 "Mandatory Information". Would it be possible to know if there is actually any legal requirement for this? Board members are not actually required to be members to apply. As for council, do they have any legal authority? It was also mentioned on xsf@ that using a pseudonym might be used to apply for membership multiple times, and thus influence votes. When in reality, I could just as well use a Real-looking name, since I don't think there is any verification in place. If legal name becomes a requirement, will we have to do verifications? I am personally not for enforcing the legal name if there is no legal requirement. > 5. Is the document accurate and clearly written? Not entirely sure what "accurate" is supposed to mean, but the document is clearly written. Cheers, -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] LAST CALL: XEP-0345 (Form of Membership Applications)
This message constitutes notice of a Last Call for comments on XEP-0345. Note: Since this is a Procedural XEP under control of Board, the Last Call mail goes to both standards@ and members@ (only for XSF members) mailing lists. This may lead to fragmentation of feedback. The archives of the lists are at [1] and [2] respectively. Title: Form of Membership Applications Abstract: This specification outlines the form and mandatory content of membership applications. URL: https://xmpp.org/extensions/xep-0345.html This Last Call begins today and shall end at the close of business on 2018-01-27. Please consider the following questions during Last Call and send your feedback to either or both of the members or the standards discussion list. 1. Is this document needed to fill gaps in the XMPP Standards Foundation's policies and procedures, or to clarify an existing XSF policy or procedure? 2. Does the document address the problem stated in the introduction and requirements? 3. Should the XSF adopt this document as part of its policies and procedures? 4. Do you have any concerns about the effects of this policy? 5. Is the document accurate and clearly written? Your feedback is appreciated! [1]: https://mail.jabber.org/pipermail/standards/ [2]: https://mail.jabber.org/pipermail/members/ signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0345 (Form of Membership Applications)
>> 4. Do you have any security concerns related to this specification? > I am concerned about the implication that an applicant could lie, > although I am not sure what actions ought to be undertaken. I do think > it is worth spelling out that it is possible for an applicant to lie, > and that members SHOULD be aware of this in evaluating applications. Things like that someone might claim to still be on Council when they're not? /K
Re: [Standards] LAST CALL: XEP-0345 (Form of Membership Applications)
On 23 July 2014 21:35, Matthew A. Miller wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Let's see how pedantic this really gets ... > > On 7/10/14, 8:25 PM, XMPP Extensions Editor wrote: > > This message constitutes notice of a Last Call for comments on XEP-0345 > (Form of Membership Applications). > > > > Abstract: > > This specification outlines the form and mandatory content > > of membership applications. > > > > > > URL: http://xmpp.org/extensions/xep-0345.html > > > > This Last Call begins today and shall end at the close of business on > 2014-07-24. > > > > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > > > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? > I do think this specification fills gaps in the XMPP protocol (of > membership). > > > > 2. Does the specification solve the problem stated in the introduction > and requirements? > I believe it mostly does, but have a nit (see below). > > > > 3. Do you plan to implement this specification in your code? If not, > why not? > I do plan to implement this specification in my code (of conduct). > > 4. Do you have any security concerns related to this specification? > I am concerned about the implication that an applicant could lie, > although I am not sure what actions ought to be undertaken. I do think > it is worth spelling out that it is possible for an applicant to lie, > and that members SHOULD be aware of this in evaluating applications. > > Actually, the specification does suggest that if members believe that the information is incomplete or inaccurate, they can challenge it formally. Outright lying is not included explicitly, but omission is. Happy to make "missing" into "missing or inaccurate" to make it more explicit. > > > > 5. Is the specification accurate and clearly written? > > > > > This document does describe code (of conduct) with defined success cases > and error handling. As such, I find it a little odd that it does not > use normative MUST/SHOULD/SHALL/MAY/SHOULD NOT/MUST NOTs. I think that > if we wish to hold our code (of conduct) to a high level of > interoperability, we ought to be more explicit about that. > > Those keywords are defined only for standards track documents; this is procedural. Whilst we stretch the definition of "Standards Track" in RFC 2119 to include our own Standards Track XEPs rather than the RFCs it was intended for, I suspect that to apply them here would be too great a distortion of their intent. As an aside, your use of it here - "members SHOULD be aware" - illustrates a common pitfall of the terms - using the ordinary word "should" and reflexively capitalizing it to add normative force - and a problem with applying it to non-computational issues. The normative force here would be that members "MUST" take into account potential subterfuge - there's no reasonable case where they might choose not to take subterfuge into account without first evaluating the possibility of subterfuge; in which case they're still within the normative force of MUST in this instance. Moreover, it's impossible to distinguish between cases where members did consider subterfuge with cases where members did not - as such it actually has no effect on "interoperability", which can itself be served simply by voting arbitrarily. So in answer to your original thought - very much more pedantic. And I've every hope it'll get worse. On the plus side, I am getting some useful feedback out of this. Dave.
Re: [Standards] LAST CALL: XEP-0345 (Form of Membership Applications)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Let's see how pedantic this really gets ... On 7/10/14, 8:25 PM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0345 (Form > of Membership Applications). > > Abstract: > This specification outlines the form and mandatory content > of membership applications. > > > URL: http://xmpp.org/extensions/xep-0345.html > > This Last Call begins today and shall end at the close of business on 2014-07-24. > > Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? I do think this specification fills gaps in the XMPP protocol (of membership). > > 2. Does the specification solve the problem stated in the introduction and requirements? I believe it mostly does, but have a nit (see below). > > 3. Do you plan to implement this specification in your code? If not, why not? I do plan to implement this specification in my code (of conduct). > 4. Do you have any security concerns related to this specification? I am concerned about the implication that an applicant could lie, although I am not sure what actions ought to be undertaken. I do think it is worth spelling out that it is possible for an applicant to lie, and that members SHOULD be aware of this in evaluating applications. > > 5. Is the specification accurate and clearly written? > > This document does describe code (of conduct) with defined success cases and error handling. As such, I find it a little odd that it does not use normative MUST/SHOULD/SHALL/MAY/SHOULD NOT/MUST NOTs. I think that if we wish to hold our code (of conduct) to a high level of interoperability, we ought to be more explicit about that. - -- - - m&m Matthew A. Miller < http://goo.gl/LK55L > -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJT0ByhAAoJEOz0ck4QngW7s+AIAKxL4nO35pUhpiOez5uWXT/P UQgyl8TbmtFLkyC5WMFi9Opruja8xD048pQoMgPFCvHZ1t0/domWaDBRxbuAGzUb +hCuBRqlG5WBegCWMZqk6rRk8TjP6S7xUnpMz3ipD3vVhOUf68F1GIbS+7eIQom3 SyMoLnUuR/su1aTSEPH6VEMQuo0+/QrTkfXzBQXBxCkkvJN/yGLoZjGLaHsXrwPq teT6GbT/AuhJOFr9JeNdXfHv7DKH/nFPWLaKzZo1/zK2NlvDDXIVnwaKBsy8As09 xVi9nto5C+CfOxKQ9ROJ5+wxJ5DWIZaFb0YUdn55ags/fAintc0mYXldOtedQEA= =orJC -END PGP SIGNATURE-
[Standards] LAST CALL: XEP-0345 (Form of Membership Applications)
This message constitutes notice of a Last Call for comments on XEP-0345 (Form of Membership Applications). Abstract: This specification outlines the form and mandatory content of membership applications. URL: http://xmpp.org/extensions/xep-0345.html This Last Call begins today and shall end at the close of business on 2014-07-24. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
