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 <syea...@gmail.com> 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

Reply via email to