If you don't have a way to deal with non standard extensions, then the status of proposal, draft and community approved become meaningless and should be abandoned. Because the result would be that extensions which are consensus based and multi-vendor implementation based find themselves in "community approved" alongside extensions which aren't. That would be quite confusing.On Wed, Feb 11, 2015 at 1:56 PM, Florian Bösch <email@example.com> wrote:OpenGL and OpenGL ES has a clear scheme to deal with non-standard extensions. They're vendor prefixed. They don't have publicly transparent scheme for proposal/draft/community approved/ratified states (although some of that is noted on the extensions).WebGL lacks a clear scheme to deal with non-standard extensions, and so we're having discussions about the deeper meanings of the standards track states. Adding a non-standard category allows the standard categories to be rigid and easy to follow. Not allowing a non-standard category makes it muddy and uncertain what these "standard track" categories even mean.On Wed, Feb 11, 2015 at 1:38 PM, Florian Bösch <firstname.lastname@example.org> wrote:On Wed, Feb 11, 2015 at 1:29 PM, Kenneth Russell <email@example.com> wrote:In my opinion, adding an extension proposal for a vendor's particular
extension idea is a viable option.It's not a viable option. In order to publicly expose an extension it has to move to "Community Approved". In order to do that, consensus has to reached on the proposal, and multiple vendors have to be implementing it. It's a good option for an extension for which that process is intended, and it should if at all possible be intended for every extension. But it could happen that that's not the case (for instance there could be proprietary IP attached to the extension, or no consensus could be reached, or unsurmountable implementation difficulties could emerge etc.), but the vendor would still like to expose the extension. Moving something to "Community Approved" that isn't is perverse.