Pubrules: Use https for /TR documents

[Philippe Le Hegaret]

Chairs, Editors,
Tool makers,

we had requests to use https in the /TR documents for quite sometime now
so here is a proposal.

Timeline:

The current target for deployment is July 1st, to give enough time for
folks to comment and tools to adapt.

We'd appreciate comments on the new rule and the metadata/API before
June 15, 2016.

You may use issue #282 in Echidna to provide feedback:
https://github.com/w3c/echidna/issues/282

Proposed new rule:

[[
All links to www.w3.org that are
required by the publication requirements MUST start with
https://www.w3.org/, with the exception of namespace URIs.
]]

Here is the exact list of links impacted by the changes:

This impacts:
- link to TR stylesheets
- links to W3C logo and W3C main homepage
- ALL document identifiers ("This Version", "Latest Version", "Previous
Version", etc.)
- links to W3C IPR notice, liability, trademark, and document use
- link to the W3C technical reports index
- links to W3C Patent Policy, patent disclosures, and W3C Process
- link to fixup.js and other supported scripts
- links to errata page and translation

The Namespace URI policy [1] is NOT impacted by this change.

All other links to www.w3.org or other domains are NOT impacted by the
change, including normative and informative references. We do however
recommend to use https whenever possible.

Depending on your type of documents, this impacts around 16 links maximum.

The rational for the move goes as follows:

1. Our canonical URI is https (well, as much as possible)
https://www.w3.org/2016/04/07-hsts-uir/
2. Using relative paths break drafts that are hosted outside our
website, e.g. w3c.github.io
3. Using protocol relative links would make it a more complex rule given
that links like "This Version" are displayed to the user.


Impact on metadata and API:

(unless you're a tool user or maker, feel free to ignore anything below)



Let's imagine that HTML 5.1 gets published in June, July and August 2016
and that we do the switch for the new rule on July 1, 2016. The proposal
is to obtain the following:


HTML document published in /TR

June 2016 document:

This version:
http://www.w3.org/TR/2016/WD-html51-20160602/
Previous Version:
http://www.w3.org/TR/2016/WD-html51-20160502/
Latest version:
http://www.w3.org/TR/html51/

July 2016 document:

This version:
https://www.w3.org/TR/2016/WD-html51-20160717/
Previous version:
https://www.w3.org/TR/2016/WD-html51-20160602/ (or http://...)
Latest version:
https://www.w3.org/TR/html51/

August 2016 document:

This version:
https://www.w3.org/TR/2016/WD-html51-20160817/
Previous Version:
https://www.w3.org/TR/2016/WD-html51-20160717/
Latest version:
https://www.w3.org/TR/html51/

tr.rdf representation of those documents:

(note that this change may break specref.org @@check with Tobie)

<!-- W3C server redirects from http to https, so let's represent this
equivalence here -->
<rdf:Description rdf:about="http://www.w3.org/TR/html51/">
<sameWorkAs rdf:resource="https://www.w3.org/TR/html51/"/>
</rdf:Description>

<WD rdf:about="http://www.w3.org/TR/2016/WD-html51-20160602/">
<dc:date>2017-06-02</dc:date>
<dc:title>HTML 5.1</dc:title>
<doc:obsoletes
rdf:resource="http://www.w3.org/TR/2016/WD-html51-20160502/"/>
<doc:versionOf rdf:resource="http://www.w3.org/TR/html51/"/>
<patentRules
rdf:resource="https://www.w3.org/Consortium/Patent-Policy-20040205/"/>
</WD>

<WD rdf:about="https://www.w3.org/TR/2016/WD-html51-20160717/">
<dc:date>2017-07-17</dc:date>
<dc:title>HTML 5.1</dc:title>
<!-- we force http:// for all *dated* URI published before the
switch -->
<doc:obsoletes
rdf:resource="http://www.w3.org/TR/2016/WD-html51-20160602/"/>
<doc:versionOf rdf:resource="https://www.w3.org/TR/html51/"/>
<patentRules
rdf:resource="https://www.w3.org/Consortium/Patent-Policy-20040205/"/>
</WD>

<WD rdf:about="https://www.w3.org/TR/2016/WD-html51-20160817/">
<dc:date>2017-08-17</dc:date>
<dc:title>HTML 5.1</dc:title>
<doc:obsoletes
rdf:resource="https://www.w3.org/TR/2016/WD-html51-20160717/"/>
<doc:versionOf rdf:resource="https://www.w3.org/TR/html51/"/>
<patentRules
rdf:resource="http://www.w3.org/Consortium/Patent-Policy-20040205/"/>
</WD>

w3c api:

Before the switch:

"_embedded": {
"version-history": [
{
"status": "Working Draft",
"uri":
"http:\/\/www.w3.org\/TR\/2016\/WD-html51-20160602\/",
"date": "2016-06-02",
"informative": false,
"title": "HTML 5.1",
"shortlink": "http:\/\/www.w3.org\/TR\/html51\/",
"editor-draft": "https:\/\/w3c.github.io\/html\/",
"process-rules":
"http:\/\/www.w3.org\/2015\/Process-20150901\/",
}, ... ]

After the switch: we can't represent the equivalence between
http://www.w3.org/TR/html51/ and https://www.w3.org/TR/html51/ so we
make the choice of using https. This could break things but the API
isn't largely used yet so we might get away with it. Most critical would
be that we might break pheme (and consequently ash-nazg...).

"_embedded": {
"version-history": [
{
"status": "Working Draft",
"uri":
"http:\/\/www.w3.org\/TR\/2016\/WD-html51-20160602\/",
"date": "2016-06-02",
"title": "HTML 5.1",
"shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
"process-rules":
"https:\/\/www.w3.org\/2015\/Process-20150901\/",
},
{
"status": "Working Draft",
"uri":
"https:\/\/www.w3.org\/TR\/2016\/WD-html51-20160717\/",
"date": "2016-07-17",
"title": "HTML 5.1",
"shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
"process-rules":
"https:\/\/www.w3.org\/2015\/Process-20150901\/",
},
{
"status": "Working Draft",
"uri":
"https:\/\/www.w3.org\/TR\/2016\/WD-html51-20160817\/",
"date": "2016-08-17",
"title": "HTML 5.1",
"shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
"process-rules":
"https:\/\/www.w3.org\/2015\/Process-20150901\/",
}, ... ]


Thank you,

Philippe

[1] https://www.w3.org/2005/07/13-nsuri

[Robert Sanderson]

Dear Philippe, all,

In the Web Annotation model we also refer to W3C specifications' URIs as a
means of identifying the URI fragment rules that they maintain.
For example, we currently recommend the URI "
http://www.w3.org/TR/media-frags/" as a way to say "this fragment conforms
to the rules of the media fragments specification".
You can see the table here:
https://www.w3.org/TR/annotation-model/#fragment-selector

I believe that this would also fall under the change to use https rather
than http URIs, correct?

As we intend to go to CR in the next few weeks, would the recommendation be
to change to https now in advance?

Many thanks,

Rob Sanderson

Post by Philippe Le Hegaret
Chairs, Editors,
Tool makers,
we had requests to use https in the /TR documents for quite sometime now
so here is a proposal.
The current target for deployment is July 1st, to give enough time for
folks to comment and tools to adapt.
We'd appreciate comments on the new rule and the metadata/API before June
15, 2016.
https://github.com/w3c/echidna/issues/282
[[
All links to www.w3.org that are
required by the publication requirements MUST start with
https://www.w3.org/, with the exception of namespace URIs.
]]
- link to TR stylesheets
- links to W3C logo and W3C main homepage
- ALL document identifiers ("This Version", "Latest Version", "Previous
Version", etc.)
- links to W3C IPR notice, liability, trademark, and document use
- link to the W3C technical reports index
- links to W3C Patent Policy, patent disclosures, and W3C Process
- link to fixup.js and other supported scripts
- links to errata page and translation
The Namespace URI policy [1] is NOT impacted by this change.
All other links to www.w3.org or other domains are NOT impacted by the
change, including normative and informative references. We do however
recommend to use https whenever possible.
Depending on your type of documents, this impacts around 16 links maximum.
1. Our canonical URI is https (well, as much as possible)
https://www.w3.org/2016/04/07-hsts-uir/
2. Using relative paths break drafts that are hosted outside our website,
e.g. w3c.github.io
3. Using protocol relative links would make it a more complex rule given
that links like "This Version" are displayed to the user.
(unless you're a tool user or maker, feel free to ignore anything below)
Let's imagine that HTML 5.1 gets published in June, July and August 2016
and that we do the switch for the new rule on July 1, 2016. The proposal is
HTML document published in /TR
http://www.w3.org/TR/2016/WD-html51-20160602/
http://www.w3.org/TR/2016/WD-html51-20160502/
http://www.w3.org/TR/html51/
https://www.w3.org/TR/2016/WD-html51-20160717/
https://www.w3.org/TR/2016/WD-html51-20160602/ (or http://...)
https://www.w3.org/TR/html51/
https://www.w3.org/TR/2016/WD-html51-20160817/
https://www.w3.org/TR/2016/WD-html51-20160717/
https://www.w3.org/TR/html51/
<!-- W3C server redirects from http to https, so let's represent this
equivalence here -->
<rdf:Description rdf:about="http://www.w3.org/TR/html51/">
<sameWorkAs rdf:resource="https://www.w3.org/TR/html51/"/>
</rdf:Description>
<WD rdf:about="http://www.w3.org/TR/2016/WD-html51-20160602/">
<dc:date>2017-06-02</dc:date>
<dc:title>HTML 5.1</dc:title>
<doc:obsoletes
rdf:resource="http://www.w3.org/TR/2016/WD-html51-20160502/"/>
<doc:versionOf rdf:resource="http://www.w3.org/TR/html51/"/>
<patentRules
rdf:resource="https://www.w3.org/Consortium/Patent-Policy-20040205/"/>
</WD>
<WD rdf:about="https://www.w3.org/TR/2016/WD-html51-20160717/">
<dc:date>2017-07-17</dc:date>
<dc:title>HTML 5.1</dc:title>
<!-- we force http:// for all *dated* URI published before the
switch -->
<doc:obsoletes
rdf:resource="http://www.w3.org/TR/2016/WD-html51-20160602/"/>
<doc:versionOf rdf:resource="https://www.w3.org/TR/html51/"/>
<patentRules
rdf:resource="https://www.w3.org/Consortium/Patent-Policy-20040205/"/>
</WD>
<WD rdf:about="https://www.w3.org/TR/2016/WD-html51-20160817/">
<dc:date>2017-08-17</dc:date>
<dc:title>HTML 5.1</dc:title>
<doc:obsoletes
rdf:resource="https://www.w3.org/TR/2016/WD-html51-20160717/"/>
<doc:versionOf rdf:resource="https://www.w3.org/TR/html51/"/>
<patentRules
rdf:resource="http://www.w3.org/Consortium/Patent-Policy-20040205/"/>
</WD>
"_embedded": {
"version-history": [
{
"status": "Working Draft",
"http:\/\/www.w3.org\/TR\/2016\/WD-html51-20160602\/",
"date": "2016-06-02",
"informative": false,
"title": "HTML 5.1",
"shortlink": "http:\/\/www.w3.org\/TR\/html51\/",
"editor-draft": "https:\/\/w3c.github.io\/html\/",
"http:\/\/www.w3.org\/2015\/Process-20150901\/",
}, ... ]
After the switch: we can't represent the equivalence between
http://www.w3.org/TR/html51/ and https://www.w3.org/TR/html51/ so we
make the choice of using https. This could break things but the API
isn't largely used yet so we might get away with it. Most critical would
be that we might break pheme (and consequently ash-nazg...).
"_embedded": {
"version-history": [
{
"status": "Working Draft",
"http:\/\/www.w3.org\/TR\/2016\/WD-html51-20160602\/",
"date": "2016-06-02",
"title": "HTML 5.1",
"shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
"https:\/\/www.w3.org\/2015\/Process-20150901\/",
},
{
"status": "Working Draft",
"https:\/\/www.w3.org\/TR\/2016\/WD-html51-20160717\/",
"date": "2016-07-17",
"title": "HTML 5.1",
"shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
"https:\/\/www.w3.org\/2015\/Process-20150901\/",
},
{
"status": "Working Draft",
"https:\/\/www.w3.org\/TR\/2016\/WD-html51-20160817\/",
"date": "2016-08-17",
"title": "HTML 5.1",
"shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
"https:\/\/www.w3.org\/2015\/Process-20150901\/",
}, ... ]
Thank you,
Philippe
[1] https://www.w3.org/2005/07/13-nsuri

[Martin J. Dürst]

Post by Robert Sanderson
In the Web Annotation model we also refer to W3C specifications' URIs as a
means of identifying the URI fragment rules that they maintain.
For example, we currently recommend the URI "
http://www.w3.org/TR/media-frags/" as a way to say "this fragment conforms
to the rules of the media fragments specification".
https://www.w3.org/TR/annotation-model/#fragment-selector
I believe that this would also fall under the change to use https rather
than http URIs, correct?
As we intend to go to CR in the next few weeks, would the recommendation be
to change to https now in advance?

To me, this usage feels close to namespaces in functionality, so it may
be worth discussing whether this can be treated the same way.

Regards, Martin.

[David (Standards) Singer]

We have a similar issue in that DASH needs a URI to refer to the ‘kind’ table in HTML.

A current proposal is again to use the section URI:

• The W3C HTML5 specification of track 'kind', as identified by the schemeURI [[TBD? https://www.w3.org/TR/html5/embedded-content-0.html#the-track-element]]

Post by Robert Sanderson
In the Web Annotation model we also refer to W3C specifications' URIs as a
means of identifying the URI fragment rules that they maintain.
For example, we currently recommend the URI "
http://www.w3.org/TR/media-frags/" as a way to say "this fragment conforms
to the rules of the media fragments specification".
https://www.w3.org/TR/annotation-model/#fragment-selector
I believe that this would also fall under the change to use https rather
than http URIs, correct?
As we intend to go to CR in the next few weeks, would the recommendation be
to change to https now in advance?

To me, this usage feels close to namespaces in functionality, so it may be worth discussing whether this can be treated the same way.
Regards, Martin.

David Singer
Manager, Software Standards, Apple Inc.

[Philippe Le Hegaret]

Post by Martin J. Dürst

Post by Robert Sanderson
In the Web Annotation model we also refer to W3C specifications' URIs as a
means of identifying the URI fragment rules that they maintain.
For example, we currently recommend the URI "
http://www.w3.org/TR/media-frags/" as a way to say "this fragment conforms
to the rules of the media fragments specification".
https://www.w3.org/TR/annotation-model/#fragment-selector
I believe that this would also fall under the change to use https rather
than http URIs, correct?
As we intend to go to CR in the next few weeks, would the
recommendation be
to change to https now in advance?

To me, this usage feels close to namespaces in functionality, so it may
be worth discussing whether this can be treated the same way.

If the linked data community wishes to have a discussion on the
namespace policy, they can certainly do so. The fact is that we can't
change deployed namespaces due to lack of consensus and tooling. In
addition, we don't seem to create new ones nowadays anyway. I'm not
convinced that linking the two changes together would bring a
predictable timed outcome.

Philippe

[Ivan Herman]

Post by Martin J. Dürst

Post by Robert Sanderson
In the Web Annotation model we also refer to W3C specifications' URIs as a
means of identifying the URI fragment rules that they maintain.
For example, we currently recommend the URI "
http://www.w3.org/TR/media-frags/" as a way to say "this fragment conforms
to the rules of the media fragments specification".
https://www.w3.org/TR/annotation-model/#fragment-selector
I believe that this would also fall under the change to use https rather
than http URIs, correct?
As we intend to go to CR in the next few weeks, would the
recommendation be
to change to https now in advance?

To me, this usage feels close to namespaces in functionality, so it may
be worth discussing whether this can be treated the same way.

If the linked data community wishes to have a discussion on the namespace policy, they can certainly do so. The fact is that we can't change deployed namespaces due to lack of consensus and tooling. In addition, we don't seem to create new ones nowadays anyway.

That is not really true. 'Namespace', though incorrectly, is often used as a term for vocabularies, which are still regularly defined (hence the question of Rob for annotations), as well as context files for JSON-LD terms which, though not 'namespaces' by any means, may have a similar issues.

Ivan

I'm not convinced that linking the two changes together would bring a predictable timed outcome.
Philippe

----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: [phone]
ORCID ID: http://orcid.org/0000-0003-0782-2704

[Eric Prud'hommeaux]

Post by Ivan Herman

Post by Philippe Le Hegaret

Post by Martin J. Dürst

Post by Robert Sanderson
In the Web Annotation model we also refer to W3C specifications' URIs as a
means of identifying the URI fragment rules that they maintain.
For example, we currently recommend the URI "
http://www.w3.org/TR/media-frags/" as a way to say "this fragment conforms
to the rules of the media fragments specification".
https://www.w3.org/TR/annotation-model/#fragment-selector
I believe that this would also fall under the change to use https rather
than http URIs, correct?
As we intend to go to CR in the next few weeks, would the
recommendation be
to change to https now in advance?

To me, this usage feels close to namespaces in functionality, so it may
be worth discussing whether this can be treated the same way.

If the linked data community wishes to have a discussion on the

namespace policy, they can certainly do so. The fact is that we can't
change deployed namespaces due to lack of consensus and tooling. In
addition, we don't seem to create new ones nowadays anyway.

Post by Ivan Herman
That is not really true. 'Namespace', though incorrectly, is often used

as a term for vocabularies, which are still regularly defined (hence the
question of Rob for annotations), as well as context files for JSON-LD
terms which, though not 'namespaces' by any means, may have a similar
issues.

Right, I think that the term "namespace" is standing in for the general
idea of dereferencable identifier. What you get back when you GET it
probably doesn't change our strategy.

Post by Ivan Herman
Ivan

Post by Philippe Le Hegaret
I'm not convinced that linking the two changes together would bring a

predictable timed outcome.

Post by Ivan Herman

Post by Philippe Le Hegaret
Philippe

----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: [phone]
ORCID ID: http://orcid.org/0000-0003-0782-2704

[Tobie Langel]

Yes, this seems like it might wreck havoc. Can you stage the new version
somewhere and give me time to transition?

Post by Philippe Le Hegaret
<!-- W3C server redirects from http to https, so let's represent this
equivalence here -->
<rdf:Description rdf:about="http://www.w3.org/TR/html51/">
<sameWorkAs rdf:resource="https://www.w3.org/TR/html51/"/>
</rdf:Description>

I use shortnames to identify specs, nor URLs, so there's not distinction
between the two resources shown above, so I have no idea what this
change could cause (probably a stack overflow).

--tobie

[Philippe Le Hegaret]

Post by Tobie Langel
Yes, this seems like it might wreck havoc. Can you stage the new version
somewhere and give me time to transition?

yes. Not sure how far however, ie I'll have to produce that manually so
I may not do for every single shortname.

Post by Tobie Langel

Post by Philippe Le Hegaret
<rdf:Description rdf:about="http://www.w3.org/TR/html51/">
<sameWorkAs rdf:resource="https://www.w3.org/TR/html51/"/>
</rdf:Description>

I use shortnames to identify specs, nor URLs, so there's not distinction
between the two resources shown above, so I have no idea what this
change could cause (probably a stack overflow).

I could:

1. make a copy of tr.rdf somewhere on the website
2.
a. add fake https entries that are past July 1, 2016 in it
b. add fake https entries that are past May 1, 2016 in it

Between a and b, what's your preference?

Philippe

[Tobie Langel]

Post by Philippe Le Hegaret

Post by Tobie Langel
Yes, this seems like it might wreck havoc. Can you stage the new version
somewhere and give me time to transition?

yes. Not sure how far however, ie I'll have to produce that manually so
I may not do for every single shortname.

It hasn't been uncommon in the past that tr.rdf had subtle bugs that
broke things. This seems like a rather important change. It seems that
having the two scripts side by side for a little while would be the
reasonable solution if you expect uptime guarantees on the Specref side.
I don't think that manually generating content is going to buy us much
in terms of dealing with corner cases or multiple updates as specs are
modified over time.

Also note that I will be OoO this summer at dates still TBD and so might
not necessarily be available to fix things if you suddenly turn this on
without allowing prior testing.

Post by Philippe Le Hegaret

Post by Tobie Langel

Post by Philippe Le Hegaret
<rdf:Description rdf:about="http://www.w3.org/TR/html51/">
<sameWorkAs rdf:resource="https://www.w3.org/TR/html51/"/>
</rdf:Description>

I use shortnames to identify specs, nor URLs, so there's not distinction
between the two resources shown above, so I have no idea what this
change could cause (probably a stack overflow).

1. make a copy of tr.rdf somewhere on the website
2.
a. add fake https entries that are past July 1, 2016 in it
b. add fake https entries that are past May 1, 2016 in it

As mentioned above, I don't think manually generating content is the
appropriate solution here. :-/

--tobie

[Philippe Le Hegaret]

Tobie,

Let me see what we can do on our side and get back to you asap.

Thanks for the feedback,

Philippe

Post by Tobie Langel

Post by Philippe Le Hegaret

Post by Tobie Langel
Yes, this seems like it might wreck havoc. Can you stage the new version
somewhere and give me time to transition?

yes. Not sure how far however, ie I'll have to produce that manually so
I may not do for every single shortname.

It hasn't been uncommon in the past that tr.rdf had subtle bugs that
broke things. This seems like a rather important change. It seems that
having the two scripts side by side for a little while would be the
reasonable solution if you expect uptime guarantees on the Specref side.
I don't think that manually generating content is going to buy us much
in terms of dealing with corner cases or multiple updates as specs are
modified over time.
Also note that I will be OoO this summer at dates still TBD and so might
not necessarily be available to fix things if you suddenly turn this on
without allowing prior testing.

Post by Philippe Le Hegaret

Post by Tobie Langel

Post by Philippe Le Hegaret
<rdf:Description rdf:about="http://www.w3.org/TR/html51/">
<sameWorkAs rdf:resource="https://www.w3.org/TR/html51/"/>
</rdf:Description>

I use shortnames to identify specs, nor URLs, so there's not distinction
between the two resources shown above, so I have no idea what this
change could cause (probably a stack overflow).

1. make a copy of tr.rdf somewhere on the website
2.
a. add fake https entries that are past July 1, 2016 in it
b. add fake https entries that are past May 1, 2016 in it

As mentioned above, I don't think manually generating content is the
appropriate solution here. :-/
--tobie

[Martin J. Dürst]

Post by Philippe Le Hegaret
we had requests to use https in the /TR documents for quite sometime now
so here is a proposal.
The current target for deployment is July 1st, to give enough time for
folks to comment and tools to adapt.

As far as I understand the proposal below, there's no plan for something
like a grace period. Why not? Or did I misunderstand?

Regards, Martin.

[Philippe Le Hegaret]

Post by Martin J. Dürst

Post by Philippe Le Hegaret
we had requests to use https in the /TR documents for quite sometime now
so here is a proposal.
The current target for deployment is July 1st, to give enough time for
folks to comment and tools to adapt.

As far as I understand the proposal below, there's no plan for something
like a grace period. Why not? Or did I misunderstand?

A grace period here means that links like "this version" can no longer
be determined to be https or not just based on the date since it will
depend on what the editor used. This might make things significantly
harder on the infrastructure and the current dev priority is to retire
the old pubrules tool by the end of July. I'll have to check with the
webmaster on that front to make sure I understand things well. An other
approach here would be to bundle the https at the end of July as well
but some folks have been patiently waiting for https to happen.

Philippe

[Wendy Seltzer]

Post by Philippe Le Hegaret

Post by Martin J. Dürst

Post by Philippe Le Hegaret
we had requests to use https in the /TR documents for quite sometime now
so here is a proposal.
The current target for deployment is July 1st, to give enough time for
folks to comment and tools to adapt.

As far as I understand the proposal below, there's no plan for something
like a grace period. Why not? Or did I misunderstand?

A grace period here means that links like "this version" can no longer
be determined to be https or not just based on the date since it will
depend on what the editor used. This might make things significantly
harder on the infrastructure and the current dev priority is to retire
the old pubrules tool by the end of July. I'll have to check with the
webmaster on that front to make sure I understand things well. An other
approach here would be to bundle the https at the end of July as well
but some folks have been patiently waiting for https to happen.

/me me, and the WebAppSec WG, who have been working hard to make HTTPS
more usable and more widespread, and would like to use HTTPS as the
canonical reference for that work.

Thanks!
--Wendy

Post by Philippe Le Hegaret
Philippe

[Frederick Hirsch]

I assume legacy documents in TR (e.g existing Recommendations) will continue to render properly, have working links etc, without change.

if not, will the Team fix all the pre-existing documents?

regards, Frederick

Frederick Hirsch

Post by Philippe Le Hegaret
Chairs, Editors,
Tool makers,
we had requests to use https in the /TR documents for quite sometime now so here is a proposal.
The current target for deployment is July 1st, to give enough time for folks to comment and tools to adapt.
We'd appreciate comments on the new rule and the metadata/API before June 15, 2016.
https://github.com/w3c/echidna/issues/282
[[
All links to www.w3.org that are
required by the publication requirements MUST start with
https://www.w3.org/, with the exception of namespace URIs.
]]
- link to TR stylesheets
- links to W3C logo and W3C main homepage
- ALL document identifiers ("This Version", "Latest Version", "Previous
Version", etc.)
- links to W3C IPR notice, liability, trademark, and document use
- link to the W3C technical reports index
- links to W3C Patent Policy, patent disclosures, and W3C Process
- link to fixup.js and other supported scripts
- links to errata page and translation
The Namespace URI policy [1] is NOT impacted by this change.
All other links to www.w3.org or other domains are NOT impacted by the change, including normative and informative references. We do however recommend to use https whenever possible.
Depending on your type of documents, this impacts around 16 links maximum.
1. Our canonical URI is https (well, as much as possible)
https://www.w3.org/2016/04/07-hsts-uir/
2. Using relative paths break drafts that are hosted outside our website, e.g. w3c.github.io
3. Using protocol relative links would make it a more complex rule given that links like "This Version" are displayed to the user.
(unless you're a tool user or maker, feel free to ignore anything below)
HTML document published in /TR
http://www.w3.org/TR/2016/WD-html51-20160602/
http://www.w3.org/TR/2016/WD-html51-20160502/
http://www.w3.org/TR/html51/
https://www.w3.org/TR/2016/WD-html51-20160717/
https://www.w3.org/TR/2016/WD-html51-20160602/ (or http://...)
https://www.w3.org/TR/html51/
https://www.w3.org/TR/2016/WD-html51-20160817/
https://www.w3.org/TR/2016/WD-html51-20160717/
https://www.w3.org/TR/html51/
<!-- W3C server redirects from http to https, so let's represent this
equivalence here -->
<rdf:Description rdf:about="http://www.w3.org/TR/html51/">
<sameWorkAs rdf:resource="https://www.w3.org/TR/html51/"/>
</rdf:Description>
<WD rdf:about="http://www.w3.org/TR/2016/WD-html51-20160602/">
<dc:date>2017-06-02</dc:date>
<dc:title>HTML 5.1</dc:title>
<doc:obsoletes
rdf:resource="http://www.w3.org/TR/2016/WD-html51-20160502/"/>
<doc:versionOf rdf:resource="http://www.w3.org/TR/html51/"/>
<patentRules
rdf:resource="https://www.w3.org/Consortium/Patent-Policy-20040205/"/>
</WD>
<WD rdf:about="https://www.w3.org/TR/2016/WD-html51-20160717/">
<dc:date>2017-07-17</dc:date>
<dc:title>HTML 5.1</dc:title>
<!-- we force http:// for all *dated* URI published before the
switch -->
<doc:obsoletes
rdf:resource="http://www.w3.org/TR/2016/WD-html51-20160602/"/>
<doc:versionOf rdf:resource="https://www.w3.org/TR/html51/"/>
<patentRules
rdf:resource="https://www.w3.org/Consortium/Patent-Policy-20040205/"/>
</WD>
<WD rdf:about="https://www.w3.org/TR/2016/WD-html51-20160817/">
<dc:date>2017-08-17</dc:date>
<dc:title>HTML 5.1</dc:title>
<doc:obsoletes
rdf:resource="https://www.w3.org/TR/2016/WD-html51-20160717/"/>
<doc:versionOf rdf:resource="https://www.w3.org/TR/html51/"/>
<patentRules
rdf:resource="http://www.w3.org/Consortium/Patent-Policy-20040205/"/>
</WD>
"_embedded": {
"version-history": [
{
"status": "Working Draft",
"http:\/\/www.w3.org\/TR\/2016\/WD-html51-20160602\/",
"date": "2016-06-02",
"informative": false,
"title": "HTML 5.1",
"shortlink": "http:\/\/www.w3.org\/TR\/html51\/",
"editor-draft": "https:\/\/w3c.github.io\/html\/",
"http:\/\/www.w3.org\/2015\/Process-20150901\/",
}, ... ]
After the switch: we can't represent the equivalence between
http://www.w3.org/TR/html51/ and https://www.w3.org/TR/html51/ so we
make the choice of using https. This could break things but the API
isn't largely used yet so we might get away with it. Most critical would be that we might break pheme (and consequently ash-nazg...).
"_embedded": {
"version-history": [
{
"status": "Working Draft",
"http:\/\/www.w3.org\/TR\/2016\/WD-html51-20160602\/",
"date": "2016-06-02",
"title": "HTML 5.1",
"shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
"https:\/\/www.w3.org\/2015\/Process-20150901\/",
},
{
"status": "Working Draft",
"https:\/\/www.w3.org\/TR\/2016\/WD-html51-20160717\/",
"date": "2016-07-17",
"title": "HTML 5.1",
"shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
"https:\/\/www.w3.org\/2015\/Process-20150901\/",
},
{
"status": "Working Draft",
"https:\/\/www.w3.org\/TR\/2016\/WD-html51-20160817\/",
"date": "2016-08-17",
"title": "HTML 5.1",
"shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
"https:\/\/www.w3.org\/2015\/Process-20150901\/",
}, ... ]
Thank you,
Philippe
[1] https://www.w3.org/2005/07/13-nsuri

[Marcos Caceres]

I assume legacy documents in TR (e.g existing Recommendations) will continue to render
properly, have working links etc, without change.
if not, will the Team fix all the pre-existing documents?

Can this be done with?: 
http://www.w3.org/TR/upgrade-insecure-requests/

At least, it would be good start. 

[Philippe Le Hegaret]

Post by Philippe Le Hegaret
Chairs, Editors,
Tool makers,
we had requests to use https in the /TR documents for quite sometime now
so here is a proposal.
The current target for deployment is July 1st, to give enough time for
folks to comment and tools to adapt.

To ensure that we do proper testing on our side (we're missing some
person cycles otherwise), we moved the target date to August 1st, which
will match the date of retirement of the old pubrules tool.

Tobie kindly switched specref.org to use https already:
https://lists.w3.org/Archives/Public/spec-prod/2016AprJun/0106.html

We have an experimental TR rdf at
https://www.w3.org/2002/01/tr-automation/tr-https.rdf

Philippe

Post by Philippe Le Hegaret
We'd appreciate comments on the new rule and the metadata/API before
June 15, 2016.
https://github.com/w3c/echidna/issues/282
[[
All links to www.w3.org that are
required by the publication requirements MUST start with
https://www.w3.org/, with the exception of namespace URIs.
]]
- link to TR stylesheets
- links to W3C logo and W3C main homepage
- ALL document identifiers ("This Version", "Latest Version", "Previous
Version", etc.)
- links to W3C IPR notice, liability, trademark, and document use
- link to the W3C technical reports index
- links to W3C Patent Policy, patent disclosures, and W3C Process
- link to fixup.js and other supported scripts
- links to errata page and translation
The Namespace URI policy [1] is NOT impacted by this change.
All other links to www.w3.org or other domains are NOT impacted by the
change, including normative and informative references. We do however
recommend to use https whenever possible.
Depending on your type of documents, this impacts around 16 links maximum.
1. Our canonical URI is https (well, as much as possible)
https://www.w3.org/2016/04/07-hsts-uir/
2. Using relative paths break drafts that are hosted outside our
website, e.g. w3c.github.io
3. Using protocol relative links would make it a more complex rule given
that links like "This Version" are displayed to the user.
(unless you're a tool user or maker, feel free to ignore anything below)
Let's imagine that HTML 5.1 gets published in June, July and August 2016
and that we do the switch for the new rule on July 1, 2016. The proposal
HTML document published in /TR
http://www.w3.org/TR/2016/WD-html51-20160602/
http://www.w3.org/TR/2016/WD-html51-20160502/
http://www.w3.org/TR/html51/
https://www.w3.org/TR/2016/WD-html51-20160717/
https://www.w3.org/TR/2016/WD-html51-20160602/ (or http://...)
https://www.w3.org/TR/html51/
https://www.w3.org/TR/2016/WD-html51-20160817/
https://www.w3.org/TR/2016/WD-html51-20160717/
https://www.w3.org/TR/html51/
<!-- W3C server redirects from http to https, so let's represent this
equivalence here -->
<rdf:Description rdf:about="http://www.w3.org/TR/html51/">
<sameWorkAs rdf:resource="https://www.w3.org/TR/html51/"/>
</rdf:Description>
<WD rdf:about="http://www.w3.org/TR/2016/WD-html51-20160602/">
<dc:date>2017-06-02</dc:date>
<dc:title>HTML 5.1</dc:title>
<doc:obsoletes
rdf:resource="http://www.w3.org/TR/2016/WD-html51-20160502/"/>
<doc:versionOf rdf:resource="http://www.w3.org/TR/html51/"/>
<patentRules
rdf:resource="https://www.w3.org/Consortium/Patent-Policy-20040205/"/>
</WD>
<WD rdf:about="https://www.w3.org/TR/2016/WD-html51-20160717/">
<dc:date>2017-07-17</dc:date>
<dc:title>HTML 5.1</dc:title>
<!-- we force http:// for all *dated* URI published before the
switch -->
<doc:obsoletes
rdf:resource="http://www.w3.org/TR/2016/WD-html51-20160602/"/>
<doc:versionOf rdf:resource="https://www.w3.org/TR/html51/"/>
<patentRules
rdf:resource="https://www.w3.org/Consortium/Patent-Policy-20040205/"/>
</WD>
<WD rdf:about="https://www.w3.org/TR/2016/WD-html51-20160817/">
<dc:date>2017-08-17</dc:date>
<dc:title>HTML 5.1</dc:title>
<doc:obsoletes
rdf:resource="https://www.w3.org/TR/2016/WD-html51-20160717/"/>
<doc:versionOf rdf:resource="https://www.w3.org/TR/html51/"/>
<patentRules
rdf:resource="http://www.w3.org/Consortium/Patent-Policy-20040205/"/>
</WD>
"_embedded": {
"version-history": [
{
"status": "Working Draft",
"http:\/\/www.w3.org\/TR\/2016\/WD-html51-20160602\/",
"date": "2016-06-02",
"informative": false,
"title": "HTML 5.1",
"shortlink": "http:\/\/www.w3.org\/TR\/html51\/",
"editor-draft": "https:\/\/w3c.github.io\/html\/",
"http:\/\/www.w3.org\/2015\/Process-20150901\/",
}, ... ]
After the switch: we can't represent the equivalence between
http://www.w3.org/TR/html51/ and https://www.w3.org/TR/html51/ so we
make the choice of using https. This could break things but the API
isn't largely used yet so we might get away with it. Most critical would
be that we might break pheme (and consequently ash-nazg...).
"_embedded": {
"version-history": [
{
"status": "Working Draft",
"http:\/\/www.w3.org\/TR\/2016\/WD-html51-20160602\/",
"date": "2016-06-02",
"title": "HTML 5.1",
"shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
"https:\/\/www.w3.org\/2015\/Process-20150901\/",
},
{
"status": "Working Draft",
"https:\/\/www.w3.org\/TR\/2016\/WD-html51-20160717\/",
"date": "2016-07-17",
"title": "HTML 5.1",
"shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
"https:\/\/www.w3.org\/2015\/Process-20150901\/",
},
{
"status": "Working Draft",
"https:\/\/www.w3.org\/TR\/2016\/WD-html51-20160817\/",
"date": "2016-08-17",
"title": "HTML 5.1",
"shortlink": "https:\/\/www.w3.org\/TR\/html51\/",
"https:\/\/www.w3.org\/2015\/Process-20150901\/",
}, ... ]
Thank you,
Philippe
[1] https://www.w3.org/2005/07/13-nsuri

[Denis Ah-Kang]

Post by Philippe Le Hegaret

Post by Philippe Le Hegaret
Chairs, Editors,
Tool makers,
we had requests to use https in the /TR documents for quite sometime now
so here is a proposal.
The current target for deployment is July 1st, to give enough time for
folks to comment and tools to adapt.

To ensure that we do proper testing on our side (we're missing some
person cycles otherwise), we moved the target date to August 1st, which
will match the date of retirement of the old pubrules tool.

The day has finally come. With the official release of the new
pubrules [1], we now require people to switch the TR links to https.
The spec generators like Bikeshed and Respec have been updated to handle
that switch so if you are using these tools, you probably have nothing
to do.
As usual, if you want to make sure your documents are ready to be
published, you should check them with pubrules [2].

Feel free to report issues on irc (#pub) or github [3].

Denis

[1] https://lists.w3.org/Archives/Public/spec-prod/2016JulSep/0021.html
[2] https://www.w3.org/pubrules/
[3] https://github.com/w3c/specberus

[Tobie Langel]

Post by Denis Ah-Kang
The day has finally come. With the official release of the new
pubrules [1], we now require people to switch the TR links to https.
The spec generators like Bikeshed and Respec have been updated to handle
that switch so if you are using these tools, you probably have nothing
to do.

I just checked Specref[1] and everything seems to be running smoothly
(we had moved to full https about a month ago in preparation for these
changes).

We'll keep monitoring the situation as new specs are published to make
sure the system stays up and is up to date.

Please let me know (or file an issue[2]) if you observe unexpected
behavior.

Thanks,

--tobie

--
[1]: http://www.specref.org/
[2]: https://github.com/tobie/specref/issues/new

[Mike West]

Post by Denis Ah-Kang
The day has finally come. With the official release of the new
pubrules [1], we now require people to switch the TR links to https.
The spec generators like Bikeshed and Respec have been updated to handle
that switch so if you are using these tools, you probably have nothing
to do.
As usual, if you want to make sure your documents are ready to be
published, you should check them with pubrules [2].
Feel free to report issues on irc (#pub) or github [3].

Thanks for getting this done!

I filed https://github.com/tabatkins/bikeshed/issues/767 against Bikeshed
to correct one error I found (and update WebAppSec's templates), but was
otherwise able to publish an update to https://www.w3.org/TR/CSP3/ this
morning without issue.

As an aside, the only link in the boilerplate that can't currently be
converted to HTTPS is http://ev.buaa.edu.cn/; perhaps y'all could chat with
the folks at Beihang?

Thanks again!

-mike

[Tobie Langel]

Post by Mike West

Post by Denis Ah-Kang
The day has finally come. With the official release of the new
pubrules [1], we now require people to switch the TR links to https.
The spec generators like Bikeshed and Respec have been updated to handle
that switch so if you are using these tools, you probably have nothing
to do.
As usual, if you want to make sure your documents are ready to be
published, you should check them with pubrules [2].
Feel free to report issues on irc (#pub) or github [3].

Thanks for getting this done!
I filed https://github.com/tabatkins/bikeshed/issues/767 against
Bikeshed to correct one error I found (and update WebAppSec's
templates), but was otherwise able to publish an update to
https://www.w3.org/TR/CSP3/ this morning without issue.

And the latest update of CSP3 showed up as expected in Specref:
http://www.specref.org/?q=CSP3

Sounds like we're all good on the Specref side.

--tobie

[Philippe Le Hegaret]

Thank you to everyone who got this done!

Mike West, for pushing us forward.

Marcos, Tab, and Shane, for taking constant care of bikeshed and respec.

Denis and Antonio, for involving our back and front tools forward.

Editors in general, for their patience and understanding while we're
moving our tools forward.

Thank you,

Philippe

Post by Denis Ah-Kang

Post by Philippe Le Hegaret

Post by Philippe Le Hegaret
Chairs, Editors,
Tool makers,
we had requests to use https in the /TR documents for quite sometime now
so here is a proposal.
The current target for deployment is July 1st, to give enough time for
folks to comment and tools to adapt.

To ensure that we do proper testing on our side (we're missing some
person cycles otherwise), we moved the target date to August 1st, which
will match the date of retirement of the old pubrules tool.

The day has finally come. With the official release of the new
pubrules [1], we now require people to switch the TR links to https.
The spec generators like Bikeshed and Respec have been updated to handle
that switch so if you are using these tools, you probably have nothing
to do.
As usual, if you want to make sure your documents are ready to be
published, you should check them with pubrules [2].
Feel free to report issues on irc (#pub) or github [3].
Denis
[1] https://lists.w3.org/Archives/Public/spec-prod/2016JulSep/0021.html
[2] https://www.w3.org/pubrules/
[3] https://github.com/w3c/specberus

[Ian Jacobs]

Post by Philippe Le Hegaret
Thank you to everyone who got this done!
Mike West, for pushing us forward.
Marcos, Tab, and Shane, for taking constant care of bikeshed and respec.
Denis and Antonio, for involving our back and front tools forward.
Editors in general, for their patience and understanding while we're moving our tools forward.

Hear, hear!

Ian
--
Ian Jacobs <***@w3.org> http://www.w3.org/People/Jacobs
Tel: [phone]

[Philippe Le Hegaret]

Post by Philippe Le Hegaret
Thank you to everyone who got this done!
Mike West, for pushing us forward.
Marcos, Tab, and Shane, for taking constant care of bikeshed and respec.
Denis and Antonio, for involving our back and front tools forward.
Editors in general, for their patience and understanding while we're
moving our tools forward.

I left out Tobie from that list, probably because the list of drinks
that I ought to pay him is already quite long.

But, nevertheless, we needed him to make this happens and he was up for
it, so thank you as well and apologizes for omitting you yesterday.

Philippe