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
Thank you, Andrew, for answering the question. What Stuart wrote,
however, is misleading:
On Tue, Aug 18, 2015 at 02:59:37PM +1200, Stuart A. Yeates wrote:
On Tue, Aug 18, 2015 at 10:08 AM, Andrew Anderson and...@lirn.net wrote:
That said, there is a big push recently for dropping non-SSL
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
@LISTSERV.ND.EDU] On Behalf Of Stuart
A. Yeates
Sent: Monday, August 17, 2015 3:41 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: [CODE4LIB] Protocol-relative URLs in MARC
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
I think that this is a great idea, if you control all of the URLs in your
systems. Otherwise unless all of the major browsers drop http — unlikely — it
easily has another ten years in it.
Chrome dropped support for SHA-1 a few months ago, and I am sure that it will
be another 33 months before
In theory the 1st indicator dictates the protocol used and 4 =HTTP. However, in
all examples on http://www.loc.gov/marc/bibliographic/bd856.html, despite the
indicator being used, the protocol part of the URI it is then repeated in the
$u field.
You can put ‘7’ in the 1st indicator, then use
On Tue, Aug 18, 2015 at 10:08 AM, Andrew Anderson and...@lirn.net wrote:
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
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
Information in subfield u should be complete, but even if that weren't the
case, it's important to consider how systems handle the information they're
given. MARC is just a container, and just because the information is
syntactically kosher does not mean it will be processed how you like.
In the
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
10 matches
Mail list logo
