[Asis-standards] reminder

Thu Nov 7 11:40:43 EST 2013

Folks

at the standards meeting in Montreal I was aced to resent a couple of things that are coming up vote soon - they are

1)Call for participation - New TC46/SC10 on document storage and conditions for preservation

Standardization of requirements for storage and use of documents in libraries, archives and documentation centres, as well as practices related to maintenance and improvement of the conditions of preservation. Excludes: photography and other media within the scope of ISO/TC 42; and Micrographics and optical memories within the scope of ISO/TC 171.

The original proposal regarding the group's reactivation (which was subsequently approved) is provided for your information and is available from the link on the ballot webpage and in the announcement email.

This ballot is a call for participation to nominate U.S. experts to this new subcommittee and/or for its two working groups:
-- WG 1, which will be working on a revision of ISO 11799, Document storage requirements for archive and library materials 
-- WG 2, which will be developing a new Technical Specification (ISO/TS 18344, Recommendation on methods of validating the success of deacidification processes for printed and handwritten documents)

Note that subcommittee work is different from that of a working group. Subcommittees are responsible for setting strategic direction, soliciting or reviewing new project proposals, voting on resolutions at meetings, and overseeing the working groups. They do not generally get involved directly in a standard's development. That is done by the working groups that the subcommittee establishes. Subcommittees do most of their work at in-person meetings, which typically occur once or twice a year, so attendance at those meetings is critical. Although meeting attendance can often be done virtually through audio or videoconference, it is recommended that subcommittee members attend in person. This new subcommittee plans to hold a meeting on January 15-17, 2014 in Berlin, Germany. There is also a TC46 plenary meeting scheduled for May 5-9, 2014 in Washington, DC, where all the subcommittees are expected to meet. Subcommittees are standing committees and members often stay on them for many years, although you can resign whenever you no longer want or are able to participate.

The two working groups listed will be responsible for developing the named standard/specification. Their work is done both at meetings and via teleconference and email between meetings. The time involvement for a working group is greater than for a subcommittee but shorter in duration as it lasts only until the standard is completed. The Working Groups may also hold in-person meetings at the subcommittee meeting venues (see 2014 meeting schedule in paragraph above), however in-person attendance is less critical for WG members.

This requires that we nominate some (if we desire to do so by Tomorrow - November 8

If you are interesting in volunteering or no someone who you thing should be involved in this let me know ASAP

ISO/DIS 32000-2, Document management — Portable Document Format— Part 2: PDF 2.0

his is a liaison ballot from ISO/TC 171, Document management applications, Subcommittee SC 2, Application issues, Working Group 8, PDF, in cooperation with TC130, Graphic technology, and TC46 SC11, Archives/records management for the ballot of: ISO/DIS-32000-2, Document management — Portable document format — Part 2: PDF 2.0.

This International Standard specifies a digital form for representing electronic documents to enable users to exchange and view electronic documents independent of the environment in which they were created or the environment in which they are viewed or printed. The Adobe Systems version PDF 1.7 is the basis for ISO 32000 Part 1. This document is ISO 32000 Part 2 which is a self contained replacement for Part 1 and specifies PDF 2.0. This is an ISO standard for the full function PDF; there are several other standards for specific applications of PDF that have evolved where limiting the use of some features of PDF and requiring the use of others, enhances the usefulness of PDF (e.g., PDF/A and PDF/X).

Since TC46 is a liaison organization for this ballot, we can only recommend a vote and provide comments. The U.S. vote will be submitted by AIIM. If approved, the standard will proceed directly to publication. If not approved or if the Working Group gets comments requiring substantive changes, an FDIS ballot may be issued.

Comments and a recommendation for a vote needed by November 11

3)  ISO/DIS 18626 - Information and Documentation - Interlibrary Loan Transactions

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.

If this draft is approved, it can go directly to publication. If substantive comments are received and accepted by the Working group, another FDIS draft may be submitted for ballot prior to publication.

A NO vote has been recommended on this but it was suggested at the meeting that I resend the document along with the resins for voting no which are

1) we support the comments of Lyrasis:

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, 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 18626. 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 (https://tools.ietf.org/html/rfc2616#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 (https://tools.ietf.org/html/rfc2616#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. 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 (https://tools.ietf.org/html/rfc2616#section-5.1) uses the absoluteURI form of the Request-URI (https://tools.ietf.org/html/rfc2616#section-5.1.2). 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.

In addition I have a problem with the fact that the standard define certain conditions like recall, renew, etc but does not have any explicit language stating what happens if the receiving library says that it doesn't support that action. I believe the standard whould state explicitly that the state of the transaction remains what it was before the unsupported action was received

However since I am a member of the ISO committee that developed this standard I didn't feel if was right to make that comment without the approval and review of others on the standards committee. I should point out that I have made this comment (apparently to no effect) to the editors of the standards

Please review the document and let me know if you agree or disagree with both of these comments

Comments needed by November 18

I have attached both the ISO ILL and the PDF draft standards to this note

Thanks

Mark

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ISO_DIS_18626(E)-Character_PDF_document.pdf
Type: application/pdf
Size: 1206795 bytes
Desc: not available
URL: <http://mail.asis.org/pipermail/asis-standards/attachments/20131107/07cbc841/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ISO-TC171-SC2_N0832_ISO_32000-2-07242013-acro1.pdf
Type: application/pdf
Size: 7969412 bytes
Desc: not available
URL: <http://mail.asis.org/pipermail/asis-standards/attachments/20131107/07cbc841/attachment-0003.pdf>