183
edits
Difference between revisions of "Sam Whited for Council 2020"
Jump to navigation
Jump to search
m
Sam Whited for Council 2020 (view source)
Revision as of 14:27, 5 November 2020
, 14:27, 5 November 2020Add I-Ds and minor changes.
(Initial council statement) |
m (Add I-Ds and minor changes.) |
||
| Line 40: | Line 40: | ||
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 | 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 60: | Line 60: | ||
- [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] | |||