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.

Eric Hellman
President, Free Ebook Foundation
Founder, Unglue.it https://unglue.it/
http://go-to-hellman.blogspot.com/
twitter: @gluejar

> 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:
>> 
>> http://www.openarchives.org/OAI/openarchivesprotocol.html#ProtocolFeatures
>> 
>> OAI-PMH requests *must* be submitted using either the HTTP GET or POST
>> methods.
> 
> Everything that holds for HTTP also holds for HTTPS because HTTPS is
> simply HTTP over TLS, as the HTTPS standard is aptly titled:
> https://tools.ietf.org/html/rfc2818
> 
> 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.
> https://www.openarchives.org/pipermail/oai-implementers/2005-February/001419.html
> 
>> 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:
> https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
> 
> C:
> 
> -- 
>  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.
> 
> Rgds,
> Kevin
> 
>