There are multiple questions embedded in this:
1) What does the MARC standard have to say about 856$u?
$u - Uniform Resource Identifier
Uniform Resource Identifier (URI), which provides standard syntax for locating an object using existing Internet protocols. Field 856 is structured to allow for the creation of a URL from the concatenation of other separate 856 subfields. Subfield $u may be used instead of those separate subfields or in addition to them.
Subfield $u may be repeated only if both a URN or a URL or more than one URN are recorded.
Used for automated access to an electronic item using one of the Internet protocols or by resolution of a URN. Subfield $u may be repeated only if both a URN and a URL or more than one URN are recorded. Field 856 is repeated if more than one URL needs to be recorded.
Here, it is established that $u uses a URI, which leads to….
2) What do the RFCs say about protocol-relative URIs?
http://tools.ietf.org/html/rfc3986#section-4.1
URI-reference is used to denote the most common usage of a resource
identifier.
URI-reference = URI / relative-ref
A URI-reference is either a URI or a relative reference. If the
URI-reference's prefix does not match the syntax of a scheme followed
by its colon separator, then the URI-reference is a relative
reference.
So by the stated use of URIs in the MARC standard, and the RFC definition of the URI relative reference, there should be no standards basis by which protocol relative URLs should not be valid for use in 856.
Expanding out to the software support, most tools that I have used with general URL manipulation in general have no problems with this format, but I have only used PyMARC for manipulating MARC records, not any of the other MARC editors. If they try to be too clever about data validation and not quite clever enough about standards and patterns, there could be issues at this level.
As for browser support, IE7 & IE8 have issues with double-loading some resources when used in this manner, but those browsers are becoming nearly extinct, so I would not anticipate client-side issues as long as the intermediate system that consumed the 856 record and render it for display can handle this. Our web properties switched to using this pattern several years ago to avoid the “insecure content” warnings and we have had no issues on the client side.
Then the other consumers of MARC data come into play — title lists, link resolvers, proxy servers, etc. A lot of what I’ve seen in this space are lipstick wearing dinosaurs of a code base, so unless the vendor is particularly good about keeping up with current web patterns, this is where I would expect the most challenges. There may be implicit or explicit assumptions built into systems that would break with protocol-relative URLs, e.g. if the value is passed directly to a proxy server, it may not know what to do without a scheme prefixed to the URI, and attempt to serve local content instead.
That said, there is a big push recently for dropping non-SSL connections in general (going so far as to call the protocol relative URIs an anti-pattern), so is it really worth all the potential pain and suffering to make your links scheme-agnostic, when maybe it would be a better investment in time to switch them all to SSL instead? This dovetails nicely with some of the discussions I have had recently with electronic services librarians about how to protect patron privacy in an online world by using SSL as an arrow in that quiver.
Andrew
--
Andrew Anderson, President & CEO, Library and Information Resources Network, Inc.
http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | http://www.facebook.com/LIRNnotes
On Aug 17, 2015, at 16:41, Stuart A. Yeates <[log in to unmask]> wrote:
> I'm in the middle of some work which includes touching the 856s in lots of
> MARC records pointing to websites we control. The websites are available on
> both https://example.org/ and http://example.org/
>
> Can I put //example.org/ in the MARC or is this contrary to the standard?
>
> Note that there is a separate question about whether various software
> systems support this, but that's entirely secondary to the question of the
> standard.
>
> cheers
> stuart
> --
> ...let us be heard from red core to black sky
