On questions regarding ISO/DIS 18626, Information and documentation — Interlibrary Loan Transactions

There is a ballot under consideration within the ISO TC 46/SC 4 on InterLibraryLoan Transactions. The ballot description is:

This International Standard specifies the transactions between libraries or libraries and other agencies to handle requests for library items and following exchange of messages. This standard is intended to at first supplement and eventually succeed the existing international ILL standards ISO 10160, ISO 10161-1 and ISO 10161-2, which are based on the outdated open systems interconnection model. The introduction of the draft standard provides some background on the relationship of the new standard to the previous one.

The working group has reached the Draft International Standard (‘DIS’) stage, and my employer — as a member of NISO — is able to cast an advisory vote on whether to approve the DIS for publication. Last week, the ALA representative to NISO posted a question to several mailing lists seeking advice on some controversy in a few sections of the document. My comments to the ballot are likely the source of that controversy, so I’d like to invite feedback here or through other forums before the NISO advisory ballot closes on November 19th. Below is a slightly edited version of my official ballot comments. Some feedback on whether I’m simply picking at nits would be helpful.

My main concern is duplicative and conflicting information between the draft standard (officially called “ISO/DIS 18626”) and the IETF‘s HTTP 1.1 standard (officially called “RFC 2616”). Unfortunately, as with much ISO work, the document itself is protected by copyright and the draft is only available to voting members for the purposes of evaluating and commenting on the standard. I think it is okay to post the parts of concern here.

5.2.2 Applications Acting as Responders

Applications acting as responders must support all of the following transport protocols:

  • HTTP

The selection of the transport protocol by the initiator of a message will govern the transport protocol used by the responder. The responder must respond using the same connection, and therefore, the same transport protocol that was used by the initiator.

All ISO 18626 messages sent via HTTP or HTTPS must use the POST method as specified in the version 1.1. of the Hypertext Transfer (HTTP) protocol (RFC 2616), thus:

POST http://biblstandard.dk/ill HTTP/1.1 CRLF

All ISO 18626 response messages sent via HTTP or HTTPS must use the normal HTTP/HTTPS protocol response mechanism used to respond to POSTs. For example:

HTTP/1.1 200 OK CRLF
<response header fields> CRLF CRLF
<response message>

5.2.3 HTTP/HTTPS Message Headers

For both optional ISO 18626 initiation and response messages, the HTTP/HTTPS Content-Type and Content- Length headers must be included and coded as follows:

Content-Type: application/xml; charset="utf-8" CRLF
Content-Length: nnnn CRLF

Where nnnn is the length of the data being sent (not including the length of the message headers).

The entity transferred via the HTTP message must contain the entire text of the message following a carriage return/line feed (CRLF) with no preceding text, thus:

<initiation message> | <response message>

Where <initiation message> or <response message> contains the XML formatted data (see section 5.1) for the message being sent.

Parts of section 5.2.2 and all of section 5.2.3 are duplicative of RFC 2616. To eliminate confusion and the possibilities of conflict, I think these portions should be removed or declared non-normative in the document. If ISO/DIS 18626 places constraints on RFC 2616, then those need to be explicitly called out in the ISO/DIS 18626 document. There are multiple implementations of RFC 2616 for various programming languages at, admittedly, various levels of conformance to that standard. If particular implementation details are required by ISO/DIS 18626 — call it an implementation profile of RFC 2616, if you will — those must be spelled out in the standard. For instance, section ISO/DIS 18626 section 5.2.3 says (emphasis added):

For both optional ISO 18626 initiation and response messages, the HTTP/HTTPS Content-Type and Content-Length headers *MUST* be included…

whereas RFC 2616 section 14.13 says (emphasis added):

Applications *SHOULD* use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in section 4.4.

and RFC 2616 section 7.2.1 says (emphasis added):

Any HTTP/1.1 message containing an entity-body *SHOULD* include a Content-Type header field defining the media type of that body.

It is conceivable that a developer implementing ISO/DIS 18626 may use a code library that doesn’t send or honor received Content-Type and Content-Length headers. That doesn’t necessarily cause a violation of the HTTP standard. In reality, I believe the implementation details of an RFC2616-compliant code library are irrelevant to ISO/DIS 18626; what that code library hands to the higher level application is the Request-URI, the entity body, and possibly the Content-Type; HTTP protocol details such as the Content-Length of the entity body don’t appear to be relevant to ISO/DIS 18626. (The use of Content-Length, at least, is not mentioned further in the ISO/DIS 18626 draft.)

In reviewing RFC 2616 in the course of writing this response, there is an additional area of concern with the example used in ISO/DIS 18626 section 5.2.2:

POST http://biblstandard.dk/ill HTTP/1.1 CRLF

This HTTP Request-Line uses the absoluteURI form of the Request-URI. RFC 2616 section 5.1.2 goes on to say:

The absoluteURI form is REQUIRED when the request is being made to a proxy.


To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.


The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (authority) MUST be transmitted in a Host header field.

It is unclear whether ISO/DIS 18626 is insisting on the use of absoluteURIs in the HTTP Request-Line (in which case I strongly encourage the draft to explicitly say “The HTTP/HTTPS Request-Line *MUST* include the absolute URI of the responder.”) or if it is over-specifying the example. Again, I believe these implementation details of RFC 2616 are irrelevant with respect to ISO/DIS 18626.

Your thoughts?

Interlibrary Loan Standards Undergoing Revision at the ISO Level

My employer (LYRASIS) is a member of NISO (the accredited standards organization for information and documentation in the U.S.), and as the primary contact I see and consider ballots for standards issues that impact LYRASIS member libraries. The Interlibrary Loan (ILL) Application Protocol Specification (a.k.a. ISO 10160/10161) is up for its periodic review, and there is a bit of interesting movement on this standard. ISO 10160/10161 became a standard in 1993 so it predates the modern era of the web. The group shepherding the standard realized that progress had overtaken the specification and they started work on a reformulation of inter-machine ILL standards. This ballot and its supplemental documentation gives a view of the plans.

The text accompanying the ballot says:

The future of this standard has been discussed by TC46/SC4 at both their 2011 and 2012 meetings. Following these discussions, a resolution was passed to “invite Danish Standards to prepare a NWIP [new work item proposal] in cooperation with other interested parties for a new ILL standard.” This proposal was forthcoming, based on discussions with representatives from USA, Canada, UK, Denmark, Finland, New Zealand, Japan, and Australia, and was presented in a ballot that ends on February 3, 2013. The proposal is expected to be approved and the new standard is intended to replace this current set of standards.

However, since the development of the proposed new standard and its subsequent implementations are expected to take several years, the committee has recommended that this existing ILL standard remain active in the interim. For this reason, it is recommended that you vote to CONFIRM this standard.

The ballot for the new work item indeed closed on February 3rd and was approved. There is now a document from the Finish Standards Association (embedded below) that goes into more detail about the plans for a new working group.

So the work begins…