[Standards] LAST CALL: XEP-0345 (Form of Membership Applications)
dave at cridland.net
Wed Jul 23 21:28:03 UTC 2014
On 23 July 2014 21:35, Matthew A. Miller <linuxwolf at outer-planes.net> 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
> > Please consider the following questions during this Last Call and send
> your feedback to the standards at 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
> > 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards