Respec reference database still lists this as "POWERFUL-FEATURES"

[mwatson2]

Since the document name has been changed, this should be visible as "SECURE-CONTEXTS".

https://github.com/w3c/encrypted-media/issues/164 is blocked on this.

[mikewest]

@marcoscaceres @tobie: I assume respec is using SpecRef? Can we change the name there?

@wseltzer: How painful would it be to change the /TR-space shortname?

[tobie]

Specref will automatically adjust to whatever TR does. If changing the shortname there is what you have in mind, the best course of action on the Specref side of things is just to wait.

You'll get the name change plus the original name aliased to the new one so nothing breaks for anyone.

[mikewest]

Great, thanks @tobie.

@wseltzer, @hillbrad, @dveditz: Changing the shortname from powerful-features to secure-contexts seems like the right thing to do. What's the process to kick that off?

[wseltzer]

@mikewest ask at the next publication (or republish the existing doc). We can't do that by automated publication, but can ask the webmaster for the update. I agree it makes sense.

[mikewest]

@wseltzer: Can you ask the webmaster to republish the existing document with "secure-contexts" as the shortname? Do you need me to put together a new version?

[sideshowbarker]

@wseltzer: Can you ask the webmaster to republish the existing document with "secure-contexts" as the shortname? Do you need me to put together a new version?

The URLs at the top of the https://www.w3.org/TR/secure-contexts/ published version will need to contain the new shortname—in at least the Latest Version URL, and probably also for This version URL, a http://www.w3.org/TR/2016/WD-secure-contexts-20160413/ directory should be created as well.

The webmaster is never expected to touch the source of the drafts that get published, so I think somebody needs to do that before making the request to the webmaster to publish the update.

[mikewest]

@sideshowbarker, @wseltzer: Thanks, done at https://w3c.github.io/webappsec-secure-contexts/WD.html. If we're touching things, can we also move to the bikeshed-approved [shortname]-[level] structure? So, secure-contexts-1? The draft above does just that.

[sideshowbarker]

If we're touching things, can we also move to the bikeshed-approved [shortname]-[level] structure? So, secure-contexts-1?

Adding numbered suffixes to shortnames is very unfamiliar to me. If the motivation for doing that is because bikeshed prefers that for some reason, it seems like a tail-wagging-the-dog bug in bikeshed.

In my experience we do not add numbered suffixes to shortnames. But maybe there is some context here that I’m missing.

[mikewest]

Adding numbered suffixes to shortnames is very unfamiliar to me.

CSP -> CSP2 -> CSP3.

@tabatkins can comment on the CSSWG's use of level numbers; it's pretty common there, from what I understand. That's likely why bikeshed has the behavior it has. See https://wiki.csswg.org/spec/levels for instance.

[sideshowbarker]

Adding numbered suffixes to shortnames is very unfamiliar to me.

CSP -> CSP2 -> CSP3.

OK, but see for CSP you’ve done the names like this:

https://www.w3.org/TR/2015/CR-CSP2-20150721/ https://www.w3.org/TR/2016/WD-CSP3-20160425/

That is, with no dash between the shortname and version number.

So in contrast, http://www.w3.org/TR/2016/WD-secure-contexts-1-20160426/ looks really odd to me, with that -1- floating between the shortname and date.

But I see that the CSS WG has already been publishing specs with URLs like that; for example, https://www.w3.org/TR/2014/WD-css-align-3-20141218/

So oh well.

@tabatkins can comment on the CSSWG's use of level numbers; it's pretty common there, from what I understand. That's likely why bikeshed has the behavior it has. See https://wiki.csswg.org/spec/levels for instance.

Yeah to be clear, no objection from me to y’all doing the shortnames in whatever way you need.

I think the actual problem here is not the URLs but the proliferation of version numbers that is leading to them. I know in the case of CSP it is very confusing to readers to know which version is current, and which one they should be working from. And I have seen the same pattern of confusion from people when trying to figure out which version of spec for a particular CSS feature set they should be reading.

[mikewest]

OK, but see for CSP you’ve done the names like this:

Yup. Perhaps that was a misstep, in hindsight. Or, at least, out of step with what other groups are doing.

I think the actual problem here is not the URLs but the proliferation of version numbers that is leading to them.

That seems like a good reason to standardize on something. Since I don't particularly care, and CSSWG is already moving in this direction, standardizing on -[level] seems reasonable. shrug

I'd like one answer, one way or the other, because I've been manually tweaking Bikeshed's output for a while now, and I'd like to stop doing that, either by teaching Bikeshed about some new rule, or by adopting the rule it understands. How we get there from a process perspective is kinda irrelevant. :)

(Also, sorry @mwatson2 for hijacking your report. :) )

[sideshowbarker]

I'd like one answer, one way or the other,

The answer is, keep -[level] as you have it, following the CSS WG precedent. That got through the publication process already for the CSS WG drafts, so I guess it’s now the de facto convention.

[wseltzer]

Do we expect secure contexts to need levels? It seems at least we want a bare secure-contexts as well.

[mikewest]

Surely our notion of "secure" will change over time? We can either represent that by versioning the document, or by publishing new RECs as our understanding changes. Up to y'all. The editor's draft will update regardless of what we call the snapshots.

[wseltzer]

Webmaster concurs that the shortname should not include -1-. I'll stage it for publication tomorrow, and then it should be ready for automatic updates as secure-context. thanks @mikewest

[tabatkins]

because I've been manually tweaking Bikeshed's output for a while now

And not telling me. >_<

[mikewest]

Yeah. Next time I'll file a bug. I only ever hit it when publishing something to /TR, and I did that practically never. Sorry!

[tabatkins]

Bikeshed likely has some funky stuff surrounding levels in it, due to it originating as a CSSWG tool, but that's a bug. It can definitely handle single-level specs with whatever shortname/url (it does so for plenty of WHATWG specs), and when we get a spec with a second level that's a different name (so Bikeshed's automatic deduping/preferring the most recent spec's anchors doesn't work) I'll fix Bikeshed accordingly. (Likely by finally updating it to use explicit obsoletion indicators, falling back to inferring obsoletion from same-shortname-smaller-level like it does today. Handling obsoletion better is high on my TODO already.)

[mikewest]

Ok. We're officially way off topic. I've created https://github.com/tabatkins/bikeshed/issues/683 to discuss the leveling question.

[wseltzer]

The shortname has been updated! https://www.w3.org/TR/secure-contexts/ now works.

[mikewest]

Hooray, thank you.

I assume this means that the database will update itself magically, so I'm closing this out.