Difference between revisions of "Sam Whited for Council 2020"

Jump to navigation Jump to search
m
Add note on password hashing I-D
(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)
183

edits

Navigation menu