Currently any schema.org is equally retrievable as HTTP or HTTPS. For example, both of these URLs return a 200 response header:
https://schema.org/Offer
http://schema.org/Offer
Long-standing best practices for canonicalization would see a page resolve under one, and only one, URL, with the non-canonical URL resolving to the canonical form.
This first and foremost because search engines index the HTTP and HTTPS versions, where both return a 200 (and where there are no certificate issues for HTTPS) as separate URLs.
While the issues that arise from permitting dual protocol URLs are, indeed, chiefly related to a sub-standard presence in the search engines (due to the generation of duplicate content, split link popularity, and similar issues), there's no demonstrable benefit I know of for supporting dual protocol URLs.
It's worth noting, too, that because of their preference for HTTPS (http://bit.ly/1DtYcGA), Google has for some time being providing searchers with the HTTPS form of HTTP URLs, whereas Bing and Yandex (from a spot check) are directing searchers to the HTTP form - meaning that markup that originates on a copy/paste from the address bar following on a search is going to result in an arbitrary choice of protocols.
Accordingly, I propose that the HTTP form of schema.org URLs be 301 redirected to the HTTPS form. An acceptable alternative (although one that would make Google a sad panda) would be 301 in the opposite direction.
The bottom line is that (at least IMO) schema.org shouldn't leave it to chance which version of a URL search engines serve to users, as there's no need for that ambiguity.
Currently any schema.org is equally retrievable as HTTP or HTTPS. For example, both of these URLs return a 200 response header:
https://schema.org/Offer
http://schema.org/Offer
Long-standing best practices for canonicalization would see a page resolve under one, and only one, URL, with the non-canonical URL resolving to the canonical form.
This first and foremost because search engines index the HTTP and HTTPS versions, where both return a 200 (and where there are no certificate issues for HTTPS) as separate URLs.
While the issues that arise from permitting dual protocol URLs are, indeed, chiefly related to a sub-standard presence in the search engines (due to the generation of duplicate content, split link popularity, and similar issues), there's no demonstrable benefit I know of for supporting dual protocol URLs.
It's worth noting, too, that because of their preference for HTTPS (http://bit.ly/1DtYcGA), Google has for some time being providing searchers with the HTTPS form of HTTP URLs, whereas Bing and Yandex (from a spot check) are directing searchers to the HTTP form - meaning that markup that originates on a copy/paste from the address bar following on a search is going to result in an arbitrary choice of protocols.
Accordingly, I propose that the HTTP form of schema.org URLs be 301 redirected to the HTTPS form. An acceptable alternative (although one that would make Google a sad panda) would be 301 in the opposite direction.
The bottom line is that (at least IMO) schema.org shouldn't leave it to chance which version of a URL search engines serve to users, as there's no need for that ambiguity.