Thank you Christian Pietsch and Kevin Ford for saving me the trouble, and for doing so with more correctness than I would have mustered.
IMHO, where an https url is available, adding a insecure link as an alternative is 100% disadvantageous to users.
President, Free Ebook Foundation
Founder, Unglue.it https://unglue.it/
> On Aug 18, 2015, at 5:50 AM, Christian Pietsch <[log in to unmask]> wrote:
> On Tue, Aug 18, 2015 at 09:29:17PM +1200, Stuart A. Yeates wrote:
>> While these may appear to be OAI-PMH providers, they're non-conformant:
>> OAI-PMH requests *must* be submitted using either the HTTP GET or POST
> Everything that holds for HTTP also holds for HTTPS because HTTPS is
> simply HTTP over TLS, as the HTTPS standard is aptly titled:
> A discussion on the OAI implementers mailing list seemed to converge
> on the position to accept HTTPS wherever possible but not to require
> it. That was in 2005 when the IETF had not started to consider
> declaring HTTP without TLS obsolete altogether.
>> Maybe because forcing people to upgrade their tech leaves behind those with
>> the least resources. Maybe because switching to a protocol whose minimum
>> message cost (in cpu cycles) is many thousands of times higher is a dubious
>> cost/benefit trade-off in some situations.
> The burden of TLS encryption on CPUs is negligible these days:
> Christian Pietsch ∑ http://purl.org/net/pietsch
> LibTec (Library Technology and Knowledge Management) department
> of Bielefeld University Library, Bielefeld, Germany
> On Aug 18, 2015, at 11:21 AM, Kevin Ford <[log in to unmask]> wrote:
> I think it is technically permissible, but unwise for a host of reasons, a number of which have been noted in this thread.
> It boils down to this: at the end of the day - and putting aside the whole SSL/non-SSL tangent - it is a "relative reference" according to the RFC and that begs the question, "Relative to what?" Is it relative to your specific system? Relative to the value found in the $2? And how is this crucial component - the base-uri/scheme with which to make the reference absolute - captured?
> And thatís the crux of the issue. You are looking to address the binary choice between http/https, but those are only two possible schemes out of many. Other valid schemes could be: ftp, sftp, ldap, rtmp, rsync, udp, file, etc.
> And, without anyway of knowing which scheme is valid, if you dropped the 'scheme' from the URI and those records made it into the wild, the utility of those $u subfields will be substantially diminished, minimally.
> Finally, I also suspect that it is uncommon (at best) to find relative references in $u (for the reasons above). The RFC recognizes as much, noting "a relative reference that begins with two slash characters...are rarely used."
> Why not just repeat the $u? This is one of the reasons it is repeatable.