On Sat, Oct 14, 2017, at 07:06, Jonas Wielicki wrote: > I am still not keen on obsoleting XHTML-IM before we have an actual > alternative ready. I don’t think that this will achieve anything good. > Instead, I think that one of two things will happen:
Someone suggested in the council meeting today that these specific points have not been addressed, so I'd like to make a few observations: > (a) Clients continue to implement XHTML-IM because it is the only actual > way to convey markup right now (this is what I’ll do until there’s a > replacement). With regards to (a), I think that is exactly what will happen, and I am okay with that. By not obsoleting it, clients will also continue to implement it, so this doesn't really change things either way. All we are doing by obsoleting it is saying that we, the XSF, do not recommend new implementations of this protocol because it has a history of security issues. Naturally people may still implement it for compatibility. At best we stop a few new implementations from running into the same security issues we've seen time and time again, at worst there is no effect, so this doesn't seem like a compelling argument for not obsoleting before a replacement is ready to me. > (b) The ecosystem will fracture in islands of different, underspecified, > plain-text markups put in <body/>. With (b) I think that's only likely to happen if the council decides to accept multiple different formatting specs as experimental and work on all of them in parallel. With my council hat on, I don't think that's likely to happen. I would also be interested in a protactive measure to prevent this, say, starting a group to come up with requirements and eventually a spec for the next generation of formatted messages (this is something I was already planning on proposing, I'm sure many people who have spoken up on this list would be interested in working together towards a single spec). > I also wonder what it would look like to have the only markup protocol with > actual deployment being obsoleted I don't think it would look any different than today. Clients that support it will continue to support it, clients that don't support it probably won't. Maybe one or two people add an implementation, maybe one or two people drop it, but it's not likely to drastically change anything in the short term. I'd also like to point out that not deprecating or obsoleting old XEPs that we don't recommend is one of the reasons fragmentation happens. For instance, I've had several people express confusion to me about which spec they should use for archiving (this community knows that MAM is recommended and what most implementations do, the layman however sees that Message Archiving has a big green banner at the top and starts to implement that). Another example is the fragmentation between Privacy Lists (now deprecated, thankfully) and the Blocking Command. For quite a while people insisted that we couldn't deprecate Privacy Lists until there was a feature-parity alternative, and this led to lots of client and server incompatibilities, these were mostly resolved before we deprecated Privacy Lists, but it took a lot of work. Since XHTML-IM isn't just a spec with a few issues that make it hard to implement, it causes security issues, this seems like a good reason to stop recommending it as the way forward. In fact, I'd go so far as to say that it is irresponsible of the XSF to continue recommending a protocol with a security history as bad as XHTML-IMs regardless of whether the spec is "technically" secure or not (technically doesn't count for anything for the reasons outlined by multiple other people numerous times in this thread; in the real world, it's broken regardless of what the spec says and we can certainly do better). —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
