- From: Philippe Le Hegaret <plh@w3.org>
- Date: Mon, 9 May 2016 09:19:14 -0700
- To: Chairs <chairs@w3.org>, spec-prod <spec-prod@w3.org>, Tobie Langel <tobie.langel@gmail.com>, Marcos Caceres <w3c@marcosc.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Shane McCarron <shane@spec-ops.io>
- Cc: Denis Ah-Kang <denis@w3.org>, Antonio Olmo Titos <antonio@w3.org>
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
Received on Monday, 9 May 2016 16:19:22 UTC