Pubrules: Use https for /TR documents

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

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".

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

On Mon, May 9, 2016 at 9:19 AM, Philippe Le Hegaret <[hidden email]> 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.

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




--
Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049
Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Tobie Langel-3
In reply to this post by Philippe Le Hegaret
> (note that this change may break specref.org @@check with Tobie)

Yes, this seems like it might wreck havoc. Can you stage the new version
somewhere and give me time to transition?
 
>     <!-- 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

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Philippe Le Hegaret


On 05/09/2016 09:46 AM, Tobie Langel wrote:
>> (note that this change may break specref.org @@check with Tobie)
>
> 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.

>>      <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

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Tobie Langel-3
On Mon, 9 May 2016, at 20:43, Philippe Le Hegaret wrote:
> On 05/09/2016 09:46 AM, Tobie Langel wrote:
> >> (note that this change may break specref.org @@check with Tobie)
> >
> > 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.

> >>      <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

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

--tobie

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Martin J. Dürst
In reply to this post by Robert Sanderson
On 2016/05/10 01:37, Robert Sanderson wrote:

> 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?

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.

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Martin J. Dürst
In reply to this post by Philippe Le Hegaret
On 2016/05/10 01:19, Philippe Le Hegaret wrote:

> 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.

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.

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Philippe Le Hegaret
In reply to this post by Tobie Langel-3
Tobie,

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

Thanks for the feedback,

Philippe

On 05/09/2016 12:23 PM, Tobie Langel wrote:

> On Mon, 9 May 2016, at 20:43, Philippe Le Hegaret wrote:
>> On 05/09/2016 09:46 AM, Tobie Langel wrote:
>>>> (note that this change may break specref.org @@check with Tobie)
>>>
>>> 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.
>
>>>>       <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
>
> As mentioned above, I don't think manually generating content is the
> appropriate solution here. :-/
>
> --tobie
>

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Philippe Le Hegaret
In reply to this post by Martin J. Dürst
On 05/10/2016 02:18 AM, Martin J. Dürst wrote:

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

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Wendy Seltzer-3
On 05/10/2016 10:22 AM, Philippe Le Hegaret wrote:

> On 05/10/2016 02:18 AM, Martin J. Dürst wrote:
>> On 2016/05/10 01:19, Philippe Le Hegaret wrote:
>>
>>> 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.
>>
>> 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

>
> Philippe
>


--
Wendy Seltzer -- [hidden email] +1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
https://wendy.seltzer.org/        +1.617.863.0613 (mobile)


Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

David Singer
In reply to this post by Martin J. Dürst
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]]


> On May 10, 2016, at 2:11 , Martin J. Dürst <[hidden email]> wrote:
>
> On 2016/05/10 01:37, Robert Sanderson wrote:
>
>> 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?
>
> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Frederick Hirsch
In reply to this post by Philippe Le Hegaret
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

> On May 9, 2016, at 6:19 PM, Philippe Le Hegaret <[hidden email]> 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.
>
> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Philippe Le Hegaret
In reply to this post by Martin J. Dürst
On 05/10/2016 02:11 AM, Martin J. Dürst wrote:

> On 2016/05/10 01:37, Robert Sanderson wrote:
>
>> 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?
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Marcos Caceres-4
In reply to this post by Frederick Hirsch




On May 13, 2016 at 8:19:51 PM, Frederick Hirsch ([hidden email]) wrote:
> 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. 

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Ivan Herman-2
In reply to this post by Philippe Le Hegaret

> On 13 May 2016, at 19:07, Philippe Le Hegaret <[hidden email]> wrote:
>
> On 05/10/2016 02:11 AM, Martin J. Dürst wrote:
>> On 2016/05/10 01:37, Robert Sanderson wrote:
>>
>>> 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?
>>
>> 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: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704





signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Eric Prud'hommeaux


On May 14, 2016 4:29 PM, "Ivan Herman" <[hidden email]> wrote:
>
>
> > On 13 May 2016, at 19:07, Philippe Le Hegaret <[hidden email]> wrote:
> >
> > On 05/10/2016 02:11 AM, Martin J. Dürst wrote:
> >> On 2016/05/10 01:37, Robert Sanderson wrote:
> >>
> >>> 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?
> >>
> >> 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.

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.

> 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: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Philippe Le Hegaret
In reply to this post by Philippe Le Hegaret
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Denis Ah-Kang


On 06/21/2016 11:31 PM, Philippe Le Hegaret wrote:

> 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.
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Tobie Langel-3
On Mon, 1 Aug 2016, at 08:14, Denis Ah-Kang wrote:
> 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 

Reply | Threaded
Open this post in threaded view
|

Re: Pubrules: Use https for /TR documents

Mike West-4
In reply to this post by Denis Ah-Kang
On Mon, Aug 1, 2016 at 9:14 AM, Denis Ah-Kang <[hidden email]> wrote:
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
12