Difference between revisions of "Sam Whited for Council 2020"

From XMPP WIKI
Jump to navigation Jump to search
(Initial council statement)
 
m (Add note on password hashing I-D)
 
(3 intermediate revisions by the same user not shown)
Line 34: Line 34:


I would like to use my position on the XSF council to further this discussion. I see the councils role in this discussion as being a purely advisory one. We would facilitate discussion in the community, try to come to consensus among ourselves, and then make a recommendation to the board who would make any final decisions.
I would like to use my position on the XSF council to further this discussion. I see the councils role in this discussion as being a purely advisory one. We would facilitate discussion in the community, try to come to consensus among ourselves, and then make a recommendation to the board who would make any final decisions.
=== The Document Lifecycle ===
One of the big problems with the XEP series of documents is that, as previously  mentioned, new documents often aren't implementable and older documents often sit in experimental long after they are widely used and deployed. Draft documents are also somewhat confusing: I have heard a number of times "I can't implement that, it's just a draft".
I would like to begin a discussion about how we can fix this.
I suspect the answer is some mix of modifying the name of the document statuses, creating policies around what documents are allowed to go into each status, and/or simple fixes to the document template to make the intent more obvious.




Line 40: Line 47:
When voting to advance, I am somewhat liberal. If we move a spec to draft and major problems are found, a migration strategy to a new spec that fixes the problem can always be written. Currently too many specs languish in "Experimental" long after they are widely used and understood. My strategy can be primarily summed up as "is this of substantial value to the public Jabber network, or do a significant number of XMPP based services (public or private) already implement it? If so, and if there are no known major security issues, advance it."
When voting to advance, I am somewhat liberal. If we move a spec to draft and major problems are found, a migration strategy to a new spec that fixes the problem can always be written. Currently too many specs languish in "Experimental" long after they are widely used and understood. My strategy can be primarily summed up as "is this of substantial value to the public Jabber network, or do a significant number of XMPP based services (public or private) already implement it? If so, and if there are no known major security issues, advance it."


However, view on accepting XEPs is somewhat more conservative than others "just get the text under XSF control as quickly as possible". I believe we should be very cautious about accepting XEPs where a competing standard already exists: competition is good, but our current process leads to confusion and incompatibilities among clients. Similarly I do not believe we should accept any XEP that still contains TODOs (though I often abstain from these votes when other council members feel strongly that an XEP should be brought under XSF control). XEPs, even in their initial form, should be something a developer can read and implement without having to skip over deliberate omissions and missing sections.
However, view on accepting XEPs is somewhat more conservative than others "just get the text under XSF control as quickly as possible". While I like the idea of getting text under XSF control quickly, I believe we should be very cautious about accepting XEPs where a competing standard already exists. Competition is good, but our current process leads to confusion and incompatibilities among clients. Similarly I do not believe we should accept any XEP that still contains TODOs (though I often abstain from these votes when other council members feel strongly that an XEP should be brought under XSF control). XEPs, even in their initial form, should be something a developer can read and implement without having to skip over deliberate omissions and missing sections.


That being said, for initial acceptance and advancing I think it's important to take community members expectations and opinions into consideration, and this would be my guiding principal when making voting decisions.
That being said, for initial acceptance and advancing I think it's important to take community members expectations and opinions into consideration, and this would be my guiding principal when making voting decisions.
Line 48: Line 55:
I am currently an author or co-author on the following XEPs:
I am currently an author or co-author on the following XEPs:


- [https://xmpp.org/extensions/xep-0386.html XEP-0386: Mobile Considerations on LTE Networks]
* [https://xmpp.org/extensions/xep-0386.html XEP-0386: Mobile Considerations on LTE Networks]
- [https://xmpp.org/extensions/xep-0364.html XEP-0364: Current Off-the-Record Messaging Usage]
* [https://xmpp.org/extensions/xep-0364.html XEP-0364: Current Off-the-Record Messaging Usage]
- [https://xmpp.org/extensions/xep-0366.html XEP-0366: Entity Versioning]
* [https://xmpp.org/extensions/xep-0366.html XEP-0366: Entity Versioning]
- [https://xmpp.org/extensions/xep-0367.html XEP-0367: Message Attaching]
* [https://xmpp.org/extensions/xep-0367.html XEP-0367: Message Attaching]
- [https://xmpp.org/extensions/xep-0375.html XEP-0375: XMPP Compliance Suites 2016]
* [https://xmpp.org/extensions/xep-0375.html XEP-0375: XMPP Compliance Suites 2016]
- [https://xmpp.org/extensions/xep-0377.html XEP-0377: Spam Reporting]
* [https://xmpp.org/extensions/xep-0377.html XEP-0377: Spam Reporting]
- [https://xmpp.org/extensions/xep-0378.html XEP-0378: OTR Discovery]
* [https://xmpp.org/extensions/xep-0378.html XEP-0378: OTR Discovery]
- [https://xmpp.org/extensions/xep-0383.html XEP-0383: Burner JIDs]
* [https://xmpp.org/extensions/xep-0383.html XEP-0383: Burner JIDs]
- [https://xmpp.org/extensions/xep-0387.html XEP-0387: XMPP Compliance Suites 2018]
* [https://xmpp.org/extensions/xep-0387.html XEP-0387: XMPP Compliance Suites 2018]
- [https://xmpp.org/extensions/xep-0389.html XEP-0389: Extensible In-Band Registration]
* [https://xmpp.org/extensions/xep-0389.html XEP-0389: Extensible In-Band Registration]
- [https://xmpp.org/extensions/xep-0393.html XEP-0393: Message Styling]
* [https://xmpp.org/extensions/xep-0393.html XEP-0393: Message Styling]
- [https://xmpp.org/extensions/xep-0438.html XEP-0438: Best practices for password hashing and storage]
* [https://xmpp.org/extensions/xep-0438.html XEP-0438: Best practices for password hashing and storage]
 
And a few tangentially XMPP related I-Ds:
 
* [https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/ Channel Bindings for SCRAM over TLS 1.3]
* [https://datatracker.ietf.org/doc/draft-ietf-kitten-password-storage/ Best practices for password hashing and storage] (This would replace XEP-0438 if it is accepted as an RFC)

Latest revision as of 14:32, 5 November 2020

About

I am a former council member running again for 2020. This will be my third term on the council.


Overview

Though I haven't been involved very much over the past year I'd like to get back to my XMPP projects and start being more involved in the community again.

Aside from authoring XEPs, working on an XMPP client and server library, and participating in XSF discussions and other business, I have a few goals that I would like to specifically address while on the council. In the past my council work has involved cleaning up confusing duplicate XEPs and pushing for the advancement of XEPs which are widely used but still considered experimental, while that won't change this year, I think this work is largely done (with a few notable exceptions such as Carbons) so I'd also like to focus on the following areas:


Create Policies Around the Compliance Suites

I used to author the compliance suites, but stopped when I felt that our inability to publish suites for each year in a timely manner made the XSF and me as the author appear incompetent (and perhaps I was since I couldn't always convince the council to publish the suites in a timely manner).

To help solve this I would like to clarify the purpose of compliance suites, create a set of criteria for XEPs on the compliance suites, and create a process by which they can be advanced easily even if they're not absolutely perfect (since we'll have another shot at improving them next year), or by which previous compliance suites can be re-used if nothing has changed.

The exact mechanism by which this takes place, and the criteria for doing so are up for debate, but I'd love to get this discussion started and prod it along in my next council term.


The XSFs Role in the Public Jabber Network

There has been a great deal of discussion in the past about whether the XSF is purely a standards body or whether they should also guide the public XMPP network in terms of feature adoption, recommend XMPP related software, or otherwise act as a more general software foundation.

I would like to use my position on the XSF council to further this discussion. I see the councils role in this discussion as being a purely advisory one. We would facilitate discussion in the community, try to come to consensus among ourselves, and then make a recommendation to the board who would make any final decisions.

The Document Lifecycle

One of the big problems with the XEP series of documents is that, as previously mentioned, new documents often aren't implementable and older documents often sit in experimental long after they are widely used and deployed. Draft documents are also somewhat confusing: I have heard a number of times "I can't implement that, it's just a draft". I would like to begin a discussion about how we can fix this.

I suspect the answer is some mix of modifying the name of the document statuses, creating policies around what documents are allowed to go into each status, and/or simple fixes to the document template to make the intent more obvious.


How I Vote

When voting to advance, I am somewhat liberal. If we move a spec to draft and major problems are found, a migration strategy to a new spec that fixes the problem can always be written. Currently too many specs languish in "Experimental" long after they are widely used and understood. My strategy can be primarily summed up as "is this of substantial value to the public Jabber network, or do a significant number of XMPP based services (public or private) already implement it? If so, and if there are no known major security issues, advance it."

However, view on accepting XEPs is somewhat more conservative than others "just get the text under XSF control as quickly as possible". While I like the idea of getting text under XSF control quickly, I believe we should be very cautious about accepting XEPs where a competing standard already exists. Competition is good, but our current process leads to confusion and incompatibilities among clients. Similarly I do not believe we should accept any XEP that still contains TODOs (though I often abstain from these votes when other council members feel strongly that an XEP should be brought under XSF control). XEPs, even in their initial form, should be something a developer can read and implement without having to skip over deliberate omissions and missing sections.

That being said, for initial acceptance and advancing I think it's important to take community members expectations and opinions into consideration, and this would be my guiding principal when making voting decisions.

My XEPs

I am currently an author or co-author on the following XEPs:

And a few tangentially XMPP related I-Ds: