On Monday 2013-06-24 20:08 -0700, Brian Smith wrote: > These clarifications would greatly help me (and probably owners and peers of > other modules) scope our participation in this discussion. As far as the DOM > module is concerned, I am mostly part of the peanut gallery so my judgement > of whether this is a good idea is not so important. I generally trust the DOM > module owner and peers to do the right thing for their module anyway. At the > same time, I doubt such a policy is necessary or helpful for the modules that > I am owner/peer of (PSM/Necko), at least at this time. In fact, though I > haven't thought about it deeply, most of the recent evidence I've observed > indicates that such a policy would be very harmful if applied to network and > cryptographic protocol design and deployment, at least. But, let's not derail > this discussion of DOM module policy with further discussions of things for > which it is not relevant.
I think it is intended to be substantially broader than the DOM module. Why do you think it's not relevant to network protocol design? One answer to that question I can come up with is that the constraints may be different in cases where the other "side" is implemented in a very small number of pieces of software. (For example, that would be true for a new crypto algorithm to be used in SSL, but false for a new HTTP header with semantics relevant only to the client that just needs to be written by an author into an .htaccess file or python script.) But I'm not sure if that's the answer you were thinking of. (Also, I hope to send more comments on the proposal soon.) -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla http://www.mozilla.org/ 𝄂 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
