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

HTTPS

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

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:

CRLF |

Where or 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.

and:

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.

and:

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?