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