Re: Pubrules: Use https for /TR documents

On 05/09/2016 09:19 AM, Philippe Le Hegaret wrote:
> 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.

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



> 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 Tuesday, 21 June 2016 19:31:13 UTC