NISO Circulation Interchange Protocol
  • Home
  • NCIP News
  • About NCIP
    • The Protocol
    • Extensibility
    • Implementer Profiles
  • About NCIP Standing Committee
    • Meeting Minutes>
      • 2014
      • 2013
      • 2012
      • 2011
      • 2010
      • 2009
      • 2008
      • 2007
      • 2006
      • 2005
      • 2004
      • 2003
      • 2002
    • Members
  • Documentation
    • Introduction to NCIP
    • The Standard
  • Links and Resources
    • Related Standards and Initiatives
    • XML Processing Tools and Utilities
    • Presentations and Publications

April 27-29, 2010 (In Person Meeting)

NCIP Implementers Group
Minutes - In Person Meeting
April 27-29, 2010
Present:
Voting Members
Sue Boettcher - 3M
Mary Jackson - Auto-Graphics
Susan Campbell - College Center for Library Automation (CCLA)
Rob Walsh - EnvisionWare (NCIP Maintenance Agency)
Mike Dicus - Ex Libris
Eric Leckbee - Innovative Interfaces
Tony OʼBrien - OCLC
Dan Iddings - PALCI
John Barr - Polaris
Rob Gray - Polaris
Kevin Stewart - Relais International
Gail Wanner - SirsiDynix (Chair)
Thalia Dickson - TLC
Observers
Karen Wetzel - NISO (Tuesday, Wednesday only)
Dhaval Kotecha - RapidRadio (Wednesday only, participated from India via conference 
call)
Jennifer Bowen - Rochester University / eXtensible Catalog Project (Wednesday only)
Randy Cook - Rochester University / eXtensible Catalog Project (Wednesday only)
Minutes prepared and submitted by:
Rob Walsh, EnvisionWare / NCIP Maintenance Agency
Editorʼs Note: In some situations, the record of the conversations was reorganized 
slightly from the way those conversations occurred chronologically in order to keep 
related information together. Efforts have been made to ensure that that the 
reorganization does not affect the meaning or the context of the discussions.
Page 1 of 47Table of Contents
Welcome and Introductions 4
Review of 2009 Goals 4
Review of Core Messages 8
Implementation Updates 9
Self-Service and NCIP 10
Core Messages 11
Recall Item 15
Implementer Registry 15
Continuous Maintenance 16
Taking NCIP to ISO 16
ALA Social Hour 16
Presentation by RapidRadio 17
Presentation by the eXtensible Catalog Project 17
Change Requests Review 19
Repeating the Bibliographic Id and Item Id in Request Item 30
Review of Action Items 31
Open Test Bed 31
2010 Goals 32
Technical Support for Implementers 33
Encouraging Implementation of Version 2 33
Page 2 of 47Planning for the Next Meeting 33
Conference Call Times and Technologies 34
Next Conference Call 34
Adjournment 34
Appendix A - Presentation by Dhaval Kotecha, RapidRadio 35
Appendix B - Handouts from eXtensible Catalog Project 41
Appendix C - Action Items 47
Page 3 of 47Tuesday, April 27
Welcome and Introductions
Wanner began the meeting with a quick round of introductions. Innovative Interfaces, 
Polaris, and TLC were each represented by someone attending his or her first NCIP 
Implementers Group (NCIP IG) meeting. Wanner also thanked Gray and Polaris for 
serving as the host organization for the meeting and for making the various logistical 
arrangements.
Review of 2009 Goals
Wanner then reviewed an email she had previously sent to the Implementer Group list 
serve outlining the groupʼs goals for 2009 and the progress that had been made for 
each.
* Formal requirements for membership in the Implementers Group
At a previous meeting (April 2009), the NCIP IG agreed to abide by the NISO 
Guidelines for committee membership (as outlined in the NISO Policies and Procedures 
Guide, http://www.niso.org/about/documents/NISOprocedures2008final.pdf). Over the 
course of the past year, the NCIP IG has removed some organizations from the roster 
for failing to meet the participation requirements. Wanner explained that there is no 
intent to become overly formal, but we do need some way to ensure that we know who 
is participating. Of those on the current roster, only VTLS is not actively participating. 
Wanner, Walsh, and Wetzel will coordinate to contact VTLS to determine if they wish to 
continue their participation and are willing to commit to the membership requirements.
Additionally, there has been interest from several entities who wish to be involved with 
the NCIP IG, at least as observers. RapidRadio in India has participated in a few recent 
phone calls and is planning to give a web presentation to the group on Wednesday. 
The eXtensible Catalog Project also has participated in past calls and will be present on 
Wednesday to talk about their progress. Finally, Mick Fortune, a consultant in the UK 
has been in contact with both Wanner and Walsh asking about how NCIP might be used 
to interoperate with RFID applications.
Gray asked if new members are required to pay NISO membership fees. Walsh 
answered that NISO membership is not required for NCIP IG (or other NISO working 
group) participation.
Wanner asked if anyone had any issues or problems with continuing to abide by the 
NISO Guidelines for membership. No one present voiced an objection.
Page 4 of 47* Continuous Maintenance
Walsh provided a basic summary of Continuous Maintenance and the procedures 
approved by ANSI (http://www.niso.org/workrooms/ncip/continuous). He explained that 
there is some confusion within the group about what sorts of changes are allowed under 
Continuous Maintenance. An agenda item exists for further discussion later in the 
meeting.
* Encourage Implementation of NCIP
* Define core set of messages and responses
At the September 2009 meeting, there was discussion about whether Recall Item 
truly belongs in the Core Message Set. Additionally, there was suggestions that 
the Core should be pared down even further - from 9 to 4 or 5 since most selfservice applications need fewer messages than resource sharing applications do. 
Finally, the previous discussion included how we define compliance against the 
Core. Does an application comply only if it implements all 9 messages, or is 
some level of partial support allowed.
Campbell asked how an applicationʼs role affects compliance. “Is is possible for 
an application to be compliant as an initiator?” Wanner added that an ILS with no 
ILL capabilities would always be a responder. “We need to be clear when an 
application is playing only a single role,” she continued. “We should focus 
compliance on Core Messages rather than on the applicationʼs context (DCB3, 
Self Service Circulation, etc.).”
* Promote adoption of Version 2
Wanner reminded the group that NISO feels strongly that implementations should 
be moving to Version 2. At this time, little progress has been made. We are 
becoming aware of new implementers, like RapidRadio in India, who are using 
Version 2. Likewise, some existing implementers are beginning to add support 
for Version 2. Some implementers are struggling to find a solid business case to 
justify the additional development investment to add support for Version 2. 
However, as we see more Version 2 implementations, implementers will have 
more reason to support both, especially for initiators.
* Create educational documents for implementers
Wanner summarized that, while we have created tasks for preparing these 
documents, we struggle to get them done. She hopes to have time during this 
meeting to break into working groups to make some progress on this material.
* Outreach programs to potential implementers
Page 5 of 47Again, Wanner stated that, although we have discussed various ideas, we have 
struggled to do anything significant in this area.
* Encourage global dialog with implementers
Wanner said that, in this area, we have had some success. We have seen 
interest from India and from some parts of Europe. However, weʼre also seeing 
some resistance internationally to adopting a NISO Standard (rather than an ISO 
Standard). NISO is seen to be a US-centric body. At times in our past, we have 
discussed seeking ISO standardization for NCIP. It has always seemed like a 
daunting task, but it is something we could reconsider. Presently, there is no 
international analog to NCIP, and that may indicate that the level of 
interoperability between international systems is low. 
Iddings suggested that ISO standardization might be something we should 
consider when we reach a point where we are ready to draft Version 3. Wanner 
added that we could use that as an opportunity to clean up the existing version 
by removing unneeded messages and reviewing the various data elements 
available in each message. OʼBrien suggested that we could consider a means 
for exchanging policy information.
Walsh asked how we deal effectively with international logistics. “Europe is 4-5 
hours off of US Eastern time, but India, China, and Australia are closer to 12. 
Would we be able to hold participants in those regions to our membership 
standards?” Boettcher suggested that we could use video conferencing and 
schedule conference calls for 8 am or 8 pm US Eastern time. Wanner added that 
Wednesdayʼs presentation by RapidRadio in India will serve as a test case for 
using remote technology to facilitate international participation.
* Educate the library community about NCIP
* Revise NISO RFP document section on NCIP
We have discussed revising NISOʼs RFP Guidelines to help explain to libraries 
how they should be requesting NCIP, but no progress has yet been made. 
* Create an implementers registry to track the use of messages
We have plans to create an implementer registry to track the use of messages in 
each vendorʼs applications, and we have created forms for initiators and 
responders to fill out, but weʼre not sure how to deliver the information. Also, we 
need to determine how the Core Messages relate to the implementer registry to 
best show, in a way that libraries will understand, how applications interoperate.
* Create documentation to explain NCIP to librarians
Page 6 of 47Wanner acknowledged that this has been a real challenge. “It is difficult to 
explain NCIP,” she said. “There are lots of messages, but not are all necessary 
in a given application. We use specific terminology (like DCB3) that many do not 
understand, but there is no single context or purpose.” In the past, we have 
discussed creating documentation that will explain NCIP to librarians. It should 
talk about how NCIP works, and it should include information about how to 
explain it to the information technology (IT) people in the library.
* Outreach programs, presentations, and activities
Wanner stated that we have been a regular participant in the LLAMA-SASS/
RUSA STARS panels at ALA. Wanner agreed to follow up with those groups 
about participating again this summer. Also, we have given presentations at 
LITA conferences. The most recent, though, did not seem to be particularly 
effective. Attendance was low, and those who did attend seemed to have higher 
levels of current knowledge and awareness than at previous conferences. We 
held a social event at ALA annual in 2009, but it was poorly attended. We are 
planning another for this yearʼs ALA in Washington, D.C., and we hope to do 
more to let people know about it.
Wanner asked if anyone had other goals or ideas about additional ways to reach the 
library industry. Gray stated that whatever momentum we seem to gain in the industry 
ultimately stalls due to situations outside our control -- 9/11, a down economy, etc. The 
library market wants to see NCIP succeed. They want standards, not one-off web 
services. “If we had a big widespread use of the Standard in some region,” he 
continued, “that would encourage more awareness and adoption. We seem to have 
very low inertia right now.”
Wanner added that libraries are faced with low budgets. Even though NCIP could save 
them money, they donʼt have enough money to get started. Jackson said that, at a 
recent presentation she gave in Connecticut, people expressed surprise about how low 
the vendor adoption rate is. “Libraries expect it to be ʻplug-and-playʼ at this point in it 
evolution.” Wanner mentioned that testing has been so daunting that those who have 
implemented have done only what is necessary. “Further,” she continued, “many of us 
are not in a position to dictate what our companies do.” 
Barr reported that Polaris has had some success when they are able to find a local 
champion in a library. That person can explain what the library wants, and he or she is 
then available to help. Jackson said that she tried to convey that same message during 
her presentation. Barr added that customers have some of the same challenges as 
vendors - no time, no money, and too many other projects. Wanner asked how we get 
libraries to step up and accept the challenge of being the champion. Barr responded by 
saying that we need to find the libraries that are in the best position to do it. Those 
generally are the larger libraries or consortiums to have adequate resources. Iddings 
agreed that has worked at PALCI. “However,” he said, “it took five years to get enough 
libraries to commit to work with Innovative Interfaces to have NCIP added.” Boettcher 
Page 7 of 47asked if we could emphasize the savings associated with implementing NCIP. Wanner 
mentioned a time and motion studied conducted by a group in Minnesota that showed 
significant savings. Jackson added that one of her customers recently updated a study 
showing that 75% of the staff time allocated to ILL had been freed up for other purposed 
due to NCIP.
Iddings stated that, while there has been a demand for applications that NCIP could 
support, some vendors have found others ways to implement. Wanner added that 
developers still feel that alternatives to NCIP (like web services and SIP) are easier to 
implement. OʼBrien said that the actual effort, however, to implement NCIP would have 
been an order of magnitude less that the alternative (telnet screen scraping, for 
example) that was used in situations where NCIP was not an option (for non-technical 
reasons). “Commercial considerations,” he continued, “generally override the desire to 
be standards based.” Wanner asked if that can be solved. OʼBrien said that we can 
look to identify situations that are conducive to NCIP and focus on those. That might 
provide a groundswell of activity on which to build. Campbell mentioned that NCIP 
should be something that a vendor could use as a competitive advantage. “Having 
NCIP should be more valuable and make vendors more competitive than not having it,” 
she said.
Iddings noted that operations that use NCIP probably account for only about 2% of the 
total functionality available within an ILS. “That isnʼt enough to compel its use,” he said. 
“The customerʼs drive should be for an application that uses NCIP to achieve its goals 
rather than for an NCIP implementation.” Walsh added that the customerʼs expectation 
is to buy a solution comprised of components from multiple vendors and have them plug 
in and work together. “The ʻhowʼ is unimportant,” he said, “but NCIP provides a 
common platform that promises seamless interoperability.” Campbell said that she liked 
the idea of focusing on applications. “NCIP might make implementations less difficult,” 
she said, “but it should not be necessary for libraries to understand the intricate details.”
Review of Core Messages
Campbellʼs comment provided a segue into a discussion centered on the Core 
Messages. Wanner suggested that we might have a common core composed of four 
messages, then an ILL core containing another 5 and a self-service core with others. 
Gray noted that self-service might be better termed circulation since the messages that 
would likely be included might be used for more than self-service. Leckbee said that his 
preference would be for a circulation core in addition to a self-service core. “They have 
different requirements,” he added. Wanner observed that we may be talking about 
multiple cores that act like profiles. “However,” she continued, “we probably donʼt want 
to use the term ʻprofileʼ.” Gray noted that we often use terms like “CIRC,” “ILL,” “RPA,” 
etc., to communicate with other vendors about what we need them to support. 
Page 8 of 47Implementation Updates
After a brief break, the group listened as each member presented implementation status 
updates.
* Auto-Graphics is now in production with TLCʼs Library.Solution. They have 
experienced some difficulty communicating with people at SirsiDynix, and this 
highlights an issue inherent with interoperability testing. Auto-Graphicsʼ
implementations are against Version 1. They have no timeline for implementing 
Version 2.
* SirsiDynix has finished testing with CARL and is working on testing with TLC. They, 
too, are using Version 1 and have no schedule for Version 2 (because they have no 
strong business case).
*Innovative Interfaces has finished coding for the Michigan project and is waiting on 
other vendors to test and confirm. This implementation is using Version 1. They are 
working on a Version 2 implementation with Relais for PALCI, and they expect for this 
to be ready for testing in the third quarter of this year.
* Relais International is working with Innovative Interfaces. Also, they have tested 
against the latest version of Voyager from Ex Libris. They, too, are experiencing some 
struggles communicating with people at SirsiDynix. Relais is supporting both Version 
1 and Version 2.
* 3M is still supporting Version 1 and waiting on additional vendors. They had one 
implementation in the US and another in the Czech Republic, but both have returned 
to SIP because they were unable to use Lookup User to obtain sufficient information 
about user privileges.
* OCLC is supporting Version 1.01 in WorldCat Navigator as an initiator. They have 
tested with several vendors (including SirsiDynix and Ex Libris), and they are willing to 
test with any responders. They are currently testing a Version 2 toolkit, but they are 
unsure as to when it will be ready for production. It works as a service layer, and it will 
work in parallel with other available interoperability mechanisms.
* PALCI is in the process of implementing Relais. They are expecting to go live on 
August 20, 2010, with NCIP in as many places as possible. They will support Voyager 
(using both NCIP and SIP), TLC (using NCIP), and Innovative Interfaces (using telnet 
until Innovative Interfacesʼ support for NCIP is complete). Their implementations will 
be a mix of Versions 1 and 2.
* CCLA reports that the Florida legislature is looking for more ways to interoperate 
among colleges, universities, K12, and public libraries. NCIP seems like it should be a 
natural fit.
* Ex Libris has done recent testing between Relais and Voyager using Version 1. They 
found a few areas that need to be enhanced.
* TLC has implemented Version 1 with SirsiDynix.
* Polaris has a test bed that is always available. Not much has changed since the last 
meeting. They will begin working on Version 2 as other vendors want support for 
those messages. In the meantime, both Versions 1 and 1.01 will be available.
Page 9 of 47* EnvisionWare has nothing to report as they have not found a sufficient business case 
to implement NCIP.
Self-Service and NCIP
Wanner asked whether self-service belongs inside NCIP. Jackson said it might be 
easier to answer after hearing more about 3Mʼs plans for SIP 3.0. Boettcher indicated 
that NCIP started with self-service as a core piece and added ILL and other functions. 
“Today, though,” she continued, “NCIP makes sense for ILL, but not enough have 
implemented the appropriate support for self-service. I think that it will get there 
eventually.” Walsh asked how many vendors support the various NCIP messages for 
fiscal transactions. Most, though, support SIPʼs 37/38 fee paid messages. “Basic selfservice circulation stations,” he continued, “need Lookup User, Lookup Item, Check Out 
Item, Check In Item, and Renew Item. However, thatʼs where the industry was 6-7 
years ago. Today, we need messages that are not part of the Core Message Set, and 
those donʼt overlap with the messages needed for ILL.”
OʼBrien noted that we often start with the messages rather than the services. “If we 
started with wire frame diagrams to show what functionality is expected,” he said, “then 
we could determine what messages are required on the backend. These might help us 
better communicate, both amongst ourselves and with libraries.” Wanner agreed, 
saying that we may have skipped a step. “We assume that we all understand the 
requirements. However, we seem to have identified three potential message cores: 
Patron Services, ILL, and Circulation.” Iddings suggested that we might consider 
adding a Discovery-to-Delivery core. 
OʼBrien suggested that we should review what “circ-to-circ direct” looks like and attempt 
to see how it differs from DCB. “That might lead to a more consistent view of the 
interactions that can then be applied to the more general case of DCB,” he said. 
Jackson expressed a concern with the approach. “I would worry,” she said, “that, while 
interesting as a theoretical discussion, we may not have a true business case.” Iddings 
said we should talk to the people at the eXtensible Catalog (XC) project to see if they 
have envisioned circ-to-circ connections or if they expect to have a middle component. 
Wanner indicated that there focus thus far has been to talk to their own system. 
OʼBrien added that we should consider, too, some of the details associated with an 
intelligent client talking to a server (particularly for self-service and as opposed to server 
to server). “We think about a user checking out,” he said. “Perhaps they owe a fine and 
pay it. However, there are more details like whether the user can browse a list of fine 
items owed and individually select them. Starting with a hypothetical user interface 
showing the userʼs perspective might make it possible to more clearly differentiate selfservice from DCB or ILL.”
Page 10 of 47Core Messages
Wanner asked the group to continue the discussion of Core Messages. “Weʼve talked 
about dividing them by application context and addressing Circulation, Patron Services, 
and ILL,” she said. “Weʼve also talked about approach the messages as either Client/
Server or System-to-System.” The group decided to first consider a circulation core by 
focusing on functions rather than messages. It created the following list of tasks that 
might be performed by a circulation system.
* Circulation
* Check In
* Check Out
* Patron Identification
* Patron Verification
* Renew
* Holds
* Reserves
*Item Availability
* Fines and Fees
* Overdues
* Notification for Overdues, Hold Pickup, etc.
* Patron CRUD (Create, Update, and Delete)
*Inventory Control (Item CRUD)
*Item Identification
* Blocks and Traps
The group then did the same for Patron Services.
* Patron Services
* Patron Identification
* Patron Verification
* Blocks and Traps
* Single Sign On
* Holds
* Reserves
* Home Delivery
* Fines and Fees
* Patron CRUD (possibly without Delete)
* Recall
* Download / Create (eResources)
*Item Expiration / Delete (eResources)
* Usage History and Reporting
Finally, the group addressed ILL.
Page 11 of 47*Inter-Library Loan
* Request (may be synonymous with Holds)
* Manage Temporary Resources
*Items
* Patrons
* Fines and Fees
* Overdues
* Recalls
* Notifications
* Patron Identification
* Patron Verification
*Item Identification
* Check Out
* Check In
* Ship / Receive Item
* Download / Create (eResources)
* Renew
The group observed that there appeared to be much overlap among the items on the 
three lists. OʼBrien, though, noted that things that are named similarly in different lists 
may be handled subtly but significantly differently.
Wanner asked if we need a separate category for DCB or if the core functions would be 
the same even if the underlying steps are different. Gray stated that he thinks of ILL as 
lending an item to another institution. “In that context,” he continued, “it doesnʼt matter 
to me what patron or item the other institution uses. I know that eventually I will get the 
item back.” OʼBrien said that he views DCB and separate from ILL. “There are 
differences in the functions each supports at the conceptual level. When you include 
the patron, DCB offers a richer set of functionality than ILL.” He cited “pick up 
anywhere” as a concept that might require one system to copy patron records from 
another. Jackson said that ILL can also allow a patron to pick up an item anywhere. 
OʼBrien clarified that ILL defines a relationship between two libraries and no patron is 
involved. In DCB, the relationship is between a remote library and a local patron. DCB 
allows patrons to perform functions in another libraryʼs system. Wanner said that 
underneath the functions are similar. “The difference is in who performs them,” she 
added. “It may be a matter of policy.”
Walsh said that we appear to have created the same list three times. “I imagined a 
narrower view of circulation,” he continued. “Patron Services might include much of 
Circulation, but it would add other functions. ILL would include Circulation, too, and it 
would add its own functions which would be different than those added for Patron 
Services.” Wanner suggested that we might consider trying to define the more narrowly 
focused lists. Jackson, though, said that if we remove holds and overdues (for 
example) from Circulation, then people look at the Circulation list and say, “You donʼt do 
circulation because you donʼt do overdues and holds.” Wanner said she would make 
that statement the other way. “I do circulation plus ILL.” Barr suggested that instead of 
Page 12 of 47attempting to define 3 or 4 narrowly focused lists, we could create lists that build on 
each other. OʼBrien expressed support for the idea so long as we are able to create 
overlapping concentric circles rather than Venn diagrams. Gray and Jackson somewhat 
simultaneously suggested that the proper separations might be “managing the user 
(Patron),” “managing the items (Circulation),” and “managing my relationship with 
another institution (Resource Sharing).”
Iddings observed that we have not yet begun to address the cases where the item is not 
known. These cases all assume we have a known item. OʼBrien explained that NCIP is 
all about having a known item and a known patron. “It isnʼt defined to deal with 
discovery to handle the special cases where the item is unknown,” he said. Jackson 
asked if that is something we should address as we prepare documentation. Wanner 
agreed that it might be good to add information explaining that NCIP assume that the 
item and the patron are known.
OʼBrien asked what would happen if we assumed that Circulation, ILL, and DCB are all 
the same and that anything can be a patron. Perhaps then we could have concentric 
circles representing levels of minimum functionality. Level 1 might be Check Out, Check 
In, ad Lookup User. Level 2 would represent additional functionality. Walsh indicated 
that it might not take long, though, before we find the need to branch. For example, 
some applications might need fiscal transactions while others donʼt. Any functionality 
that is defined in a level beyond that which contains fiscal transactions is unavailable to 
any application that does not need fiscal transactions.
Stewart noted that when we originally defined the Core Message Set, the focus was on 
simplifying. “It seems now like weʼre making things more complex,” he said. “If the 
Core has too many messages, we should see if some can be removed.” Jackson 
offered that the problem with the Core is that not everyone supports the whole Core. 
Stewart suggested that, in cases where the vendor is missing only one or two 
messages, it should just implement them. Alternatively, we could redefine the core to 
remove those considered to be extraneous. Iddings said that from his usersʼ
perspectives, everything in the Core is necessary. Wetzel suggested that we might 
need to collect more user feedback on what messages and functions are truly 
necessary.
The group decided to compare the current Core Message Set to SIP.
* Core Message Set
* Lookup User
* Lookup Item
* Request Item
* Cancel Request Item
* Accept Item
* Check Out
* Check In
* Renew Item
Page 13 of 47* Recall Item
* SIP (NCIP messages to perform tasks possible with SIP)
* Lookup User
* Lookup Item
* Check Out Item
* Undo Check Out Item
* Check In Item
* Create User Fiscal Transaction
* Renew Item
* Update User (limited availability in SIP; currently used to block a user)
* Create User (not available in SIP but needed)
Campbell said that this still does not address the issue of whether an application is a 
responder or an initiator. If two vendors have only responders, then I cannot implement. 
The circ-to-circ piece is missing. Jackson added that sometimes the messages define a 
given workflow. For example, the item in an ILL transaction must be returned to a 
specific location. OʼBrien noted that vendors will need to be clear about what roles they 
play in given contexts. Wanner said that while we donʼt disagree philosophically with 
the idea of circ-to-circ. “However,” she continued, “if that is required for Core Message 
compliance, then the fact is that no systems will be compliant.” Campbell reiterated that 
we need to stress the importance to be clear about the role. Wanner asked if 
compliance is required only for a responder or if it is equally valid for an initiator. 
OʼBrien suggested it makes sense only for a responder. Walsh suggested that it should 
be possible for an initiator to be compliant if it makes sense in the specific context 
associated with the application. OʼBrien also noted that initiators may need to be 
careful about implementing messages beyond the core since compliant responders are 
not guaranteed to respond.
Wetzel said that NCIP compliance has been (and should remain) a single message. 
Compliance with the core, though, should be all messages in the Core. OʼBrien agreed 
that we need to pick a label that indicates when an implementer says “I comply” that 
there can be no misunderstanding. Stewart said that when an initiator claims to support 
the ILL Core, it should support all of the messages in that Core. Wanner said that it 
should be acceptable for implementers to say “No, I donʼt support all of the messages in 
the Core because only one is needed for this application.”
Boettcher suggested using the term “Support” rather than the term “Compliant.”
OʼBrien suggested a system (using non-sensical animal names as placeholders for real 
labels that would need to be determined) for claiming full or partial compliance with the 
Core. Full support would be associated with one label, while partial support would use 
another. Walsh suggested something like “Full support as an initiator,” “Partial support 
as a responder,” etc. as labels that we might use.
Page 14 of 47Wanner asked whether responding to a message with some kind of “Message Not 
Understood” is sufficient for a responder to claim compliance. Jackson said that since 
the result would not be that which is desired, this should not indicate compliance.
Ultimately, the group agreed to identify a common Core with extensions for Self-Serivce 
and other extensions for Resource Sharing. Iddings, Campbell, and Wanner offered to 
help draft some language describing the Core Message Sets and how an implementer 
describes its support for them. They hope to complete this task before ALA in June 
2009.
Recall Item
Wanner asked if anyone objected to having Recall Item as part of the Core Message 
Set. Dickson said that it did not appear to be as important as other messages in the 
Core. Wanner agreed that, in public libraries particularly, the need for Recall Item is 
probably small. Boettcher asked whether it is truly necessary to do ILL. Walsh recalled 
that at the September 2009 meeting Campbell suggested defining a public and an 
academic core. Dickson asked whether recall would become more important to public 
libraries in the future, and Wanner observed that some consortiums have both public 
and academic members. After some additional discussion, the group agreed that Recall 
Item should remain in the Core Message Set for Resource Sharing.
Implementer Registry
Wanner noted that we will need to modify the submission forms that have been created 
for responders and initiators to indicate their support for the Core Message Sets. She 
asked how we want to capture and display the information. Wetzel showed a system 
created by the SUSHI working group (http://sites.google.com/site/sushiserverregistry). 
Dickson asked whether the system has support for version control. Wetzel was not 
sure. She thinks they retain older versions manually.
Campbell asked whether only limited support for data elements undermines 
compliance. Wanner said that the submission forms should indicate which data 
elements are required and which are optional. “A compliant system must support all 
required data elements,” she added. Jackson suggested that the form should group 
data elements into categories for “Required,” “Optional,” and “If Requested.” Stewart 
asked if the forms should go to the level of which User Optional Fields are supported. 
Wanner said that this level of detail was not planned because it seems like too much 
information for customers. It would, though, be necessary for other implementers.
Wanner, Campbell, and Jackson agreed to revise the existing submission forms and to 
create analogs for Self-Service before ALA in June 2009.
Page 15 of 47Continuous Maintenance
Wetzel explained that, even though the Standard may change through Continuous 
Maintenance, the official version will always be Z39.83-2008. Because the schema was 
not part of what was balloted, it may change at any time. Jackson presented a 
hypothetical example where we removed Recall Item from the protocol. “How would an 
implementer know what ʻversionʼ has Recall Item and which does not?” she asked. 
Wetzel said that we can track changes with information version labels. She suggested, 
too, that we keep a change log. The Standard can change; the Standardʼs designator 
cannot. It would be acceptable, for example, to identify a revision as Z39.83-2008 
followed by some sort of revision indicator. To do that, we need to add language to the 
Standard that defines the versioning structure. OʼBrien indicated that changes to the 
schema require a new label for the schema. That implies a new version (2.0 -> 2.01, for 
example), and the Standard should somehow reflect that versioning. Walsh 
summarized the conversation by indicating that we should adopt a versioning scheme 
beneath the Z39.83-2008, that we should add a preface that describes the versioning 
process, and that we should keep some kind of change history (perhaps as an 
Appendix) and/or explanation of the changes from the prior version.
Taking NCIP to ISO
Wanner reopened the discussion about whether we should ask ISO to standardize 
NCIP. Wetzel said that this would require a proposal to the Discovery-to-Delivery Topic 
Committee. “The fact that there are no Version 2 implementations,” she added, “would 
make ISO adoption challenging.” Wanner observed that support is growing, and she 
asked why we have to distinguish between Version 1 and Version 2 implementations. 
Wetzel said that ANSI limits us to only the current version. Version 1 is no longer 
consider “active.” OʼBrien said that he understands both sides of the issue. “It may be 
embarrassing to submit Version 2 because there are so few implementations. At the 
same time, though, Version 1 is 4-6 years old. It seems that the only real option is to 
wait for more Version 2 implementations before submitting to ISO.” Wanner agreed with 
OʼBrien.
ALA Social Hour
Wanner explained that the current plan is to meet Sunday afternoon or early evening at 
some place near the convention center. Wetzel said that it may be challenging to find a 
place that will handle a group without committing to dinner seating. Wanner indicated 
that we would like to find a casual but relatively quiet place where we can converse. 
Iddings suggested that we convene in the lobby bar in the Renaissance Hotel. The 
group agreed that this would be an appropriate location. Wanner and Jackson agreed 
to draft an invitation that can be sent to groups like the ILL-DD, Rethinking Resource 
Sharing, LLAMA-SASS, and RUSA STARS. Given the low turn out at last yearʼs event, 
we should not be too concerned about inviting too many people.
Page 16 of 47Wednesday, April 28
Presentation by RapidRadio
Kotecha gave a presentation (remotely from India) outlining RapidRadioʼs journey with 
NCIP, NCIP awareness in Asian markets, and suggestions for improving the adoption of 
NCIP. (Kotechaʼs presentation is included in Appendix A.)
Walsh agreed to follow up with Kotecha to get the additional information that he 
indicated he would be willing to provide during the question and answer session that 
followed his presentation.
Presentation by the eXtensible Catalog Project
Bowen provided a summary of the eXtensible Catalog (XC) Projectʼs efforts and how it 
has incorporated NCIP. (Handouts were provided and have been reproduced in 
Appendix B.) The project has four open source toolkits (available at 
extensiblecatalog.org) that collectively allow applications to harvest data from the ILS. 
One toolkit does the actual data harvesting, while another does metadata processing. 
These do not use NCIP. The third and fourth toolkits are called the Drupal Toolkit and 
the NCIP Toolkit. The Drupal Toolkit talks to the NCIP Toolkit which gets the information 
from the ILS. When used together, the four toolkits provide an end-to-end solution. 
Many libraries use various combinations of the four to do specific tasks. The XC Project 
works with many libraries to develop the connectors to specific back-end ILS. Currently, 
they have support for Voyager Classic versions 6 and 7 (developed by the University of 
Rochester), Aleph version 1.8 (developed by Notre Dame; efforts are underway to 
migrate to Aleph version 2.0), and Innovative Interfaces running on Oracle. Support for 
Innovative Interfaces using the non-Oracle database is underway at the University of 
North Carolina, Charlotte. Cornell has done some work to interoperate with ILLiad and 
has portions in production. Some of their system uses NCIP. The XC Project hopes to 
incorporate Cornellʼs work into the project soon.
Cook explained the Drupal and NCIP Toolkits in more detail, and he showed their NCIP 
Test Bed implemented in Drupal. All of their work so far is with NCIP Version 1. He 
explained that there are some messages in the Core Message Set that are not 
implemented in the XC. Since they are primarily a discovery tool rather than a 
transaction processing application, so they have no need to circulate. They are, though, 
thinking of adding support for Renew. They did add additional verbs to their 
implementation of NCIP in order to meet specific needs. They added XC Lookup User 
and XC Get Availability, primarily to meet ILS-DI/DLF requirements. Walsh found the 
ILS-DI/DLF recommendations on the Internet and explained that GetPatronInfo requires 
that Contact Information, Fines, Holds, Loans, Recalls, and Messages be available. In 
NCIP Version 1, some of this information is available via Lookup User. In Version 2, all 
Page 17 of 47but Recalls and Messages should be available, but those could be implemented via 
extensions.
Cook asked whether Version 2 supports a way to request a range of IDs to generate 
results set. Wanner explained that we do have a proposal that would allow various item 
IDs to be repeated in some messages. Wetzel suggested that the XC Project might 
consider submitting a proposal to address its specific needs. She explained that, under 
Continuous Maintenance, change requests are reviewed twice per year.
Wanner asked whether ILLiad is supporting NCIP messages directly. Cook indicated 
that he thinks they are getting the information through some other manner and the 
Cornell interface is formatting the response in NCIP.
Cook reported on a new code4lib group called ILS Interop that has formed to create a 
standard mechanism for communicating with ILS backends in order to do discovery. 
They are considering the use of the XC NCIP Toolkit, but they are also considering 
Jangle and other options. Bowen added that the goal is to have one approach that is 
standard for discovery applications to harvest information from the ILS. Cook said that 
the XC believes that NCIP provides a good approach since it already exists. However, 
some in the ILS Interop group feel that NCIP is overkill for this project. They cite NCIPʼs 
option to use either structured or unstructured information (for patron names and 
addresses, for example) as one reason why NCIP is inappropriate. The XC NCIP 
Toolkit uses unstructured names, but the ILS Interop group wants to use structured data 
so that the last name is easily identified. Also, some have said that NCIP moves too 
slowly and does not respond to library needs. The concept of currency, too, is one that 
seems overly complicated to use.
Wanner indicated that weʼve struggled before with structured versus unstructured data. 
The NCIP IG is not in a position to dictate whether to use one or the other. She 
volunteered that we would be happy to open lines of communication with the ILS Interop 
group, either by participating in their calls or having them participate in ours. However, 
if John Bodfish of OCLC is part of that group, he is very knowledgeable about NCIP and 
will represent it well. Cook indicated that the ILS Interop group has calls every two 
weeks. Bowen added that anyone interested in participating should contact Karen 
Coombs at OCLC.
Cook mentioned also that the ILS Interop group has discussed using RESTful web 
services. OʼBrien explained that REST is a flavor of web service that uses XML over 
HTTP POST. When used over HTTP, the NCIP schema may be considered a RESTful 
service. Wetzel and Stewart agreed to research whether NCIP could be considered 
RESTful.
Wetzel asked what it would take for the XC Project to migrate to NCIP Version 2. Cook 
explained that the project is currently understaffed, and it does not have the resources 
necessary to undertake the migration to Version 2. The current issues list may be a 
month of work for two developers. At some point, the Project will need to decide 
Page 18 of 47whether to address the existing issues to make the current Version 1 implementation 
compliant or whether to simply move to Version 2. If the ILS Interop group decides to 
use NCIP, it will probably want to use Version 2. Wanner offered that we could review 
the issues list and help determine whether any are already addressed in Version 2. 
Bowen agreed that the Project might benefit from having someone advise it on what it 
could gain by moving to Version 2. OʼBrien volunteered to provide some guidance, 
particularly as it relates to the schema. He added that many of the messages and data 
elements have the same names and structures in Versions 1 and 2.
Cook explained that they XC Project roadmap has most of their efforts going toward the 
metadata and Drupal Toolkits.
Wetzel asked if there is any value for the XC Project to move from Version 1 to Version 
1.01. OʼBrien indicated that he did not think any of the 1.01 changes would justify the 
effort.
Cook asked if anyone has ever requested a “Renew All” function. OʼBrien indicated that 
Renew All could be supported today via iteration. However, this calls into question the 
stateless nature of the protocol since subsequent requests may expect changes as a 
result of earlier requests. Bowen asked whether GetAvailability used to get the status 
on multiple items might have the same potential problem. OʼBrien said it may be 
similar, but NCIP has no support for that function currently. Leckbee added that Renew 
All also raises the question of partial success or failure. Some items may successfully 
renew while others do not.
Cook asked if there is a list of people using NCIP. Wanner said that there is a list (http://
www.ncip.info/implementer_registry) but it may be dated. Wetzel added that we are 
working on a more interactive Implementer Registry to provide this information.
Wanner closed the discussion noting that it was valuable. She invited the XC Project to 
have a representative (or even a rotation of individuals) participate in the NCIP IG.
Change Requests Review
Walsh summarized the Continuous Maintenance process and explained that, for each 
request, the group must decide whether to accept it without modification, accept it with 
modification, accept it for further study, or reject it. Some discussion of versioning and 
the challenges associated with changes that involve the schema and changes that 
involve only the Standard. The group decided that, when viewed collectively, change 
requests are unlikely to effect only one or the other.
Page 19 of 47Walsh led a review of the change requests that had been received prior to the March 1, 
2010, deadline. He began with those reporting defects against the Standard.
Number: 2010-01-0001
Type: Defect
Subject: The optional Ext element is not reflected anywhere in the Standard
Description: The fact that Ext is optional in many elements is not reflected in the 
Standard.
Discussion: OʼBrien noted that the Ext element is, in fact, optional in every 
message in the protocol.
Decision: Accept without modification. Update the Standard document to 
show all of the places where the Ext element may be used.
Number: 2010-01-0002
Type: Defect
Subject: The optional Institution Header and Response Header are not 
reflected anywhere in the Standard.
Description: The fact that Initiation Header and Response Header are optional in 
every message is not reflected anywhere in the Standard. To be correct, they need to 
be added as optional data in every element in Section 5.
Discussion: None
Decision: Accept without modification. Update the Standard document to 
show all of the places where Initiation Header and Response Header may be used.
Number: 2010-01-0003
Type: Defect
Subject: Accept Item Response “Required Data:” and “Optional Data:” may 
be misleading.
Description: In Section 5.4.1, Accept Item Response - Required Data: and 
Optional Data: may misleading. Currently, they read
Required data: Problem, or Request Id
Optional data: Item Id
That might lead one to think that the Item Id an be part of the Problem element. 
However, Item Id is not valid within the Problem element; it is meant to be used only 
with Request Id.
Discussion: None
Decision: Accept without modification. Update the Standard document to 
clarify that Item Id is valid only as part of Request Id.
Page 20 of 47Number: 2010-01-0004
Type: Defect
Subject: User Optional Fields in Item Recall Cancelled is an optional 
element in the schema but not in the Standard.
Description: In Section 5.5.8, Item Recall Cancelled - User Optional Fields is an 
optional element in the schema but not in the Standard. Given that in most cases 
where both User Id and Item Id are valid, it is appropriate to have both Item Optional 
Fields and User Optional Fields, it would seem that this represents a defect in the 
Standard and the schema is correct.
Discussion: None
Decision: Accept without modification. Update the Standard document to 
match the schema.
Number: 2010-01-0005
Type: Defect
Subject: The text of “Required Data:” in Lookup Request Response should 
be reworded.
Description: In Section 5.3.3, Lookup Request Response - The test of “Required 
Data:” in the Standard should probably read:
{Item Id or {Request Id and, optionally Item Id}}
as it does in Section 5.3.2 Lookup Item Response. This reflects the structure of the 
schema.
Discussion: None
Decision: Accept without modification. Update the Standard document to 
match the schema.
Number: 2010-01-0006
Type: Defect
Subject: Elements in Lookup Request are repeatable in the schema but not 
in the Standard.
Description: In Section 5.3.3, Lookup Request - Item Element Type, Request 
Element Type, and User Element Type are all repeatable in the schema but not in the 
Standard. It seems that the schema is correct and the Standard needs to be changed 
to match.
Discussion: None
Decision: Accept without modification. Update the Standard document to 
match the schema.
Page 21 of 47Number: 2010-01-0007
Type: Defect
Subject: Table 2 in Implementation Profile 1 should have space between 
Public and System Ids
Description: In the XML example in Table 2 in Implementation Profile 1, there 
should be a space between the PUBLIC and SYSTEM ids.
Discussion: OʼBrien found several examples of valid XML on the Internet and all 
have a space between the PUBLIC and SYSTEM ids.
Decision: Accept without modification. Update the Standard document to add 
a space between the PUBLIC and SYSTEM ids.
Number: 2010-01-0008
Type: Defect
Subject: Table 2 in Implementation Profile 1 gives a URI that does not 
resolve to the NCIP schema.
Description: The NCIP schema does not appear to be located at http://
www.niso.org/ncip/v2_0/imp1/xsd/ncip_v2_0.xsd.
Discussion: None
Decision: Accept without modification. Request that NISO move the schema 
document to the location specified in Table 2 of Implementation Profile 1.
Number: 2010-01-0009
Type: Defect
Subject: Table 2 in Implementation Profile 1 has the wrong XML version.
Description: The example is Table 2 in Implementation Profile 1 gives the XML 
version as “2.0.” This should be “1.0.”
Discussion: None
Decision: Accept without modification. Update the Standard document to fix 
the XML version number.
Number: 2010-01-0010
Type: Defect
Subject: User Id is allowed both inside and outside of User Optional Fields; 
however, Item Id is not allowed inside Item Optional Fields.
Description: Need to determine which is “correct” and ensure that both are 
handled consistently.
Discussion: User Id can be used both as an identifier and as data. When used 
outside of User Optional Fields, it is a key. When used inside, it is simply data.
Decision: Accept for further study. Attempt to find concrete use cases that 
require Item Id to be used outside of Item Optional Fields.
Page 22 of 47Number: 2010-01-0011
Type: Defect
Submitted By: Dushyant C. Upadhyay (dushyant@rapidradio.co.in)
Organization: RapidRadio Solutions Pvt. Ltd.
Submitted Date: 25 January 2010
Subject: Table 1 in Implementation Profile 1 has incorrect XML structure.
Description: In Version 2.0, all of the Scheme/Value pair elements were replaced 
with a simple string value and an optional scheme attribute. In other words, what in 
Version 1.x was:
<Amount>
<CurrencyCode>
<Scheme>SomeSchemeURI</Scheme>
<Value>SomeValueForCurrencyCode</Value>
</CurrencyCode>
<MonetaryValue>TheAmountAsAnInteger</MonetaryValue>
</Amount>
would in Version 2 be:
<Amount>
<CurrencyCode Scheme=”SomeSchemeURI”>
SomeValueForCurrencyCode
</CurrencyCode>
<MonetaryValue>TheAmountAsAnInteger</MonetaryValue>
</Amount>
The example in Table 1 in Implementation Profile 1 may be one that was overlooked 
during the final editing process for Version 2.
Discussion: None
Decision: Accept without modification. Update the example in the Standard 
document to be correct for Version 2.
Page 23 of 47Number: 2010-01-0012
Type: Defect
Submitted By: Robert Gray (Robert.Gray@PolarisLibrary.com)
Organization: Polaris Library Systems
Submitted Date: 27 January 2010
Subject: The order of the elements in Prompt Input is different in the 
Standard and the schema.
Description: The Standard declares the subelements of Prompt Input as 
Authentication Data Format Type, Authentication Input Type, then Sensitive Data Flag. 
The schema presents these elements as Authentication Input Type, Authentication Data 
Format Type, then Sensitive Data Flag (followed by Ext).
Discussion: Gray explained that the order in the schema may cause some code 
to be forced to parse the Authentication Input Type element before it knows what format 
the data is in. OʼBrien, though, indicated he did not see a compelling reason to 
potentially break implementations in order to switch the order of the elements. Since 
most implementations use generated classes to parse the XML, this should rarely be an 
issue in practice since the all of the data is put into a class before it becomes available 
to the application.
Decision: Accept without modification. Update the Standard document to 
match the schema.
Number: 2010-01-0013
Type: Defect
Submitted By: Robert Gray (Robert.Gray@PolarisLibrary.com)
Organization: Polaris Library Systems
Submitted Date: 27 January 2010
Subject: The order of the elements in Authentication Prompt is different in 
the Standard and the schema.
Description: The Standard declares the subelements of Authentication Prompt 
as Prompt Input and then Prompt Output. The schema presents them in the reverse 
order.
Discussion: None
Decision: Accept without modification. Update the Standard document to 
match the schema.
Page 24 of 47Number: 2010-01-0014
Type: Defect
Submitted By: Dushyant C. Upadhyay (dushyant@rapidradio.co.in)
Organization: RapidRadio Pvt. Ltd.
Submitted Date: 22 February 2010
Subject: Loaned Items and Requested Items are named differently in the 
Standard and the schema.
Description: On page 20 of the Standard (the printed number on the page is 10), 
the data elements of Lookup User Request have been listed. In the list, “Loaned Items” 
and “Requested Items” do not match the schema. According to the schema, the 
element names should be “Loaned Items Desired” and “Requested Items Desired.” 
Discussion: The group acknowledged that this was an oversight during final 
editing for Version 2.
Decision: Accept without modification. Update the Standard document to 
match the schema.
Number: 2010-01-0015
Type: Enhancement
Submitted By: OCLC
Submitted Date: During Version 2 balloting
Subject: Bibliographic Record Id is not repeatable in Bibliographic 
Description of Accept Item.
Description: Bibliographic Record Id is not repeatable in Bibliographic 
Description of Accept Item. It should be possible, for example, for an initiator to send 
Accept Item using both an OCLC number and an LCCN number.
Discussion: Jackson clarified that the requested change should be generic with 
respect to the types of ids allowed and not limited to OCLC and LCCN. Gray asked 
what the responder is accepting. Is it one item with two ids, or is it two separate items. 
OʼBrien explained that, when one is creating a temporary record, one may need multiple 
ids to represent a single item. “It seems like a fairly non-offensive change that would be 
generally useful,” he said. Wanner added that it is primarily a resource sharing issue. 
The lending organization may use one id, but the borrowing organization may use a 
different one. The common record, then, needs both. Gray asked if this would make 
Bibliographic Record Id repeatable everywhere it is used. OʼBrien indicated that the 
field is used only to carry information, never to identify an item, so allowing it repeat 
should not cause any problems.
Decision: Accept without modification. Change the schema to make 
Bibliographic Record Id repeatable within Bibliographic Description. Then update the 
Standard document to match the changed schema.
Page 25 of 47Number: 2010-01-0016
Type: Enhancement
Submitted By: OCLC
Submitted Date: During Version 2 balloting
Subject: Request Item does not allow a combination of Bibliographic Record 
Id and Item It.
Description: Request Item does not allow a combination of Bibliographic Record 
Id and Item Id, and it does not allow either to be repeated. An initiator should be able to 
send both, and it should be possible to send more than one of each.
Discussion: OʼBrien explained that today one must choose to send either an 
Item Id or a Bibliographic Id but not both. This proposal would allow an initiator to send 
either or both. Gray asked if that meant the request would be for a specific item or any 
item that matches the Bibliographic Id. OʼBrien said that he did not think that was 
meant to be the case. It was meant to provide extra information. Wanner asked if it 
was extra or alternative information. Gray said that his understanding is that an Item Id 
always represents a single item. A Bibliographic Id would mean any item that matches 
the given criteria. Stewart noted that the proposal also includes a request that each be 
made repeatable. OʼBrien suggested that we need more information on why this 
change was requested so that we donʼt risk an implementation that is ambiguous.
Decision: Accept for further study. Attempt to find a use case that 
demonstrates how multiple and repeatable Item Ids and Bibliographic Ids might be 
used. However, through additional discussion, this decision was changed to “accept 
without modification.”
Number: 2010-01-0017
Type: Enhancement
Submitted By: OCLC
Submitted Date: During Version 2 balloting
Subject: NCIP is too cautious with respect to element repeatability.
Description: Recent implementation experience has shown that NCIP remains 
too cautious in the design of its data structures, specifically in the area of element 
repeatability. The Standard allows for tightening of rules via application profiles (e.g., 
marking an optional element mandatory), but it does allow permit loosening of rules as 
would be the case if a non-repeatable element were allowed to repeat. If more 
elements are allowed to repeat it will also be necessary to specify the semantics. In 
some cases, it may be obvious how multiple or repeated elements are to be handled. 
But where the element is part of a key (e.g., Request Itemʼs Bibliographic and Item Ids), 
perhaps the semantics are that the initiator thinks any of them is valid, and the 
responder gets to choose. In these cases the responder ought to return the key chosen 
in the response.
Discussion: OʼBrien indicated that this seems to require open discussion within 
the group. It may be quite useful, but it may lead to chaotic and ambiguous 
implementations. Wanner explained that she could see making something like ISBN 
repeatable since many bibliographic records contain multiple ISBN numbers. Two 
disparate systems may not have identical bibliographic records. Repeating ISBNs, 
then, would seem to make sense. Jackson asked if we would also allow elements like 
Page 26 of 47title and author to repeat so that we could send different titles and different authors. 
Gray indicated that would not be relevant since we cannot search on title and author. 
Walsh noted, though, that the same example might be valid with ISBNs where two 
ISBNs do not represent the same work. That could lead to a confusing implementation. 
OʼBrien explained that the request is to make every element repeatable and to restrict 
them where necessary through profiles. Jackson asked what problem the proposal is 
trying to solve. OʼBrien said that the problem is philosophical rather than practical. He 
presented an example using Accept Item. It contains User Id. Repeating that might 
prove to be problematic. Jackson, however, said it could represent a book club. 
Stewart asked what it would mean to repeat a Pickup Location. The group 
acknowledged that would be a problem Gray indicated that the excessive repeatability 
might significantly increase the overall bulk of the messages. A Check In message with 
many items could get pretty big. Walsh observed that if one plan to execute the same 
number of check ins with separate messages, the aggregate would probably be less. 
Gray said that the response would likely be slower, however.
Decision: Accept for further study. Attempt to find use cases for how it might 
be used effectively and provide examples to the submitter showing potential problems.
Number: 2010-01-0018
Type: Enhancement
Submitted By: The Library of Congress
Submitted Date: During Version 2 balloting
Subject: There is no way to distinguish individual users from institutional 
users.
Description: There is no way to distinguish individual users (with personal 
names, birth dates, etc.) from institutional users (libraries). This has been a shortcoming in our circulation patron data since our ILS was implemented.
Discussion: The group noted that there is nothing that precludes the use of 
User Id to represent institutions. The “User” in NCIP is the entity requesting an action or 
information, and patron type, agency, and other data elements could be used to 
distinguish various types of users.
Decision: Reject
Number: 2010-01-0019
Type: Enhancement
Submitted By: The Library of Congress
Submitted Date: During Version 2 balloting
Subject: It is not possible to represent patrons “owned” by larger patron 
entities.
Description: NCIP has no facility to allow patrons to be “owned” by larger 
institutions (e.g., Congressional offices).
Discussion: The group noted that this is a function of the ILS rather than 
something that should be provided through NCIP. Data elements may be used to 
provide hints to the ILS as to the true nature of the “patron” identified through the User 
Id.
Decision: Reject
Page 27 of 47Number: 2010-01-0020
Type: Enhancement
Submitted By: Brent Jensen (brent.jensen@sirsidynix.com)
Organization: SirsiDynix
Submitted Date: During Version 2 balloting
Subject: Allow the Problem element to repeat
Description: Ensure that the Standard and the schema agree on whether the 
Problem element is repeatable.
Discussion: None
Decision: Accept without modification. Update the Standard document to 
match the schema.
Number: 2010-01-0021
Type: Enhancement
Submitted By: Brent Jensen (brent.jensen@sirsidynix.com)
Organization: SirsiDynix
Submitted Date: During Version 2 balloting
Subject: Add “transaction agency” or “transaction location” to Accept Item 
message.
Description: Add “transaction agency” or “transaction location” to Accept Item 
message.
Discussion: Wanner explained that Accept Item needs a third agency to 
represent the pick up location. There may even be a need for a fourth agency 
representing where the lending agency needs to send the item in order to get it into the 
borrowing system. Jackson asked if that is simply a function of the borrowing system. 
Wanner asked how the borrowing system knows where the user wants to pick up the 
item. Stewart noted that Version 2 has Pickup Location within the Accept Item 
Response.
Decision: Accept for further study. Ask Jensen whether Pickup Location 
within Accept Item Response meets his needs or if there are additional use cases.
Page 28 of 47Number: 2010-01-0022
Type: Enhancement
Submitted By: Brent Jensen (brent.jensen@sirsidynix.com)
Organization: SirsiDynix
Submitted Date: During Version 2 balloting
Subject: Re-review the process for requesting optional information in the 
Lookup User message.
Description: Towards the end of the Version 2 review process, some changes 
were made to the way the Lookup User message allows an initiator to request optional 
information. Some of those changes had to be “undone” during final editing, and the 
result is an inconsistent and suboptimal approach to requesting optional data. See 
Loaned Items and Loaned Items Count for examples.
Discussion: OʼBrien noted that we should probably revisit the entire approach to 
requesting optional data. We need a container that can hold all of the things that can be 
requested, and that set of boolean elements would indicate what I want returned. This 
would be consistent and much simpler. However, it would break backward compatibility. 
Walsh said that weʼve discussed, at least informally, that compatibility breaking changes 
are to be reserved for major revisions (i.e., when moving from Version 2.x to Version 
3.0). OʼBrien suggested that, according to that rationale, we should not make this 
change. Stewart acknowledged that while the current approach is message it does not 
impact the functionality of the system. Wanner agreed that it does not seem like a 
critical issue.
Decision: Reject. This change would break compatibility without adding any 
new functionality.
Number: 2010-01-0023
Type: Defect
Submitted By: Rob Walsh
Organization: EnvisionWare
Submitted Date: During review of change requests at this meeting
Subject: Lookup User shows Loaned Items as a required element in the 
Standard.
Description: Loaned Items should be moved into the list of optional elements in 
the documentation for Lookup User in the Standard.
Discussion: None
Decision: Accept without modification. Update the Standard document to 
correct the error.
After a brief break, Wanner asked if we made enough changes to justify a new revision. 
She reminded the group that it would be required to publish the revision within two 
months because that is the process that was approved by ANSI. The group agreed that 
we should publish a 2.01 revision with the accepted changes. OʼBrien agreed to make 
the necessary schema changes, Walsh agreed to update the Standard as appropriate, 
and Walsh and Wanner agreed to contact those who submitted change requests to let 
them know the disposition of their proposals.
Page 29 of 47Repeating the Bibliographic Id and Item Id in Request Item
OʼBrien returned to the issue of repeating the Bibliographic Id and Item Id in Request 
Item. He had been able to communicate with colleagues at OCLC and had some 
additional information about the proposal. He said the intent of the change request is to 
be able to place a hold on any copy of any of the ids submitted. Jackson asked whether 
that would result on a single title. OʼBrien indicated that, yes, the request would be for a 
single title. In other words, no matter how many ids were part of the request, the 
responder should pick one and place a hold. The user might have found a only a single 
bibliographic record, but the system could be smart enough to know that other options 
exist. It could then send all of the various ids that match the userʼs request to another 
system to place a hold. “Systems should be capable of bridging that gap and make 
appropriate connections to improve customer service,” said OʼBrien. Walsh asked if the 
same effect could be created through iteration. OʼBrien said that might result in multiple 
holds. Jackson said that when the request goes to a particular vendor it should be 
possible to say, “I know you have multiple versions of this item and I want any one of 
them.” Walsh added that the potential for misuse is mitigated by having the system fail 
to do what the abuser hopes it would. For example, if the requesting system wants the 
responding system to place a hold on ALL matching items, the user will not get what he 
wants. OʼBrien noted that this is a real world problem. “Weʼve seen it in practice,” he 
added.
Wanner expressed a concern that NCIP has limited ability for distinguishing media 
types. “It may be difficult to restrict the scope to a certain subset of the available 
formats,” she said. OʼBrien said that could be handled by including only the ISBNs for 
the formats you want. Iddings added that there is a need to say I only want a particular 
edition, and that should be handled in the application rather than in the protocol.
Wanner asked if anyone objected to the proposal after the additional discussion. 
Stewart asked if it would break compatibility. OʼBrien answered that it would break 
responders who receive a request with multiple ids and they expect to get only one. 
Stewart asked whether all changes that affect compatibility should be implemented as 
extensions. “Changing the structure up to twice each year may upset implementers,” he 
said. Dickson asked if we want to make this kind of breaking change for a single issue 
or if we should wait and compile them into a bundle. OʼBrien indicated that he could 
see pros and cons to both approaches. Walsh asked if there are any changes that can 
be made in the schema that do not cause the same problems. “Even an entirely 
optional element would choke a responded that does not know it can exist,” he said. 
Stewart suggested that we might want to limit our updates to less than twice each year. 
Wanner noted that frequent changes might encourage more people to become active so 
that their voices could be heard. Dicus observed that many of these proposals have 
been pending for almost two years. Walsh noted that deciding to do changes only once 
per year might contradict the process that weʼve had approved by ANSI. Jackson asked 
how we deal with management when they resist the constant updates, and Gray added 
that weʼll end up with customers nagging vendors. Wanner suggested that we could 
Page 30 of 47explore what is required to change our process with ANSI. Boettcher suggested that we 
go ahead with the changes and let vendors pick the appropriate (and hopefully the most 
current) version to implement when they are ready. Wanner agreed that could work as 
long as we define compliance against the original Version 2 instead of against each 
minor revision.
Ultimately, the group decided to change the disposition for proposal 2010-01-0016 from 
“accept for further study” to “accept without modification.”
Review of Action Items
The group briefly reviewed the various action items that had been assigned over the 
course of the first two days.
Open Test Bed
The group briefly discussed the notion of an open NCIP test bed that could be used to 
verify interoperability. In previous discussions on this topic, the group has struggled to 
come up with a practical way to implement. Someone would need to volunteer to 
develop a responder (and possibly an initiator) that other vendors could use to 
exchange messages. Gray noted that this may not be particularly useful in practice. 
“Validating the XML is the easy part,” he said. “Decisions about whether to use 
structured or unstructured names or addresses is where the real problems occur.” 
Walsh agreed that what needs to be tested when verifying interoperability are the 
outcomes of the messages, not the format and structure of the messages themselves. 
That is difficult to do with a common and generic system. Leckbee noted also that we 
would need to have test systems for each version of the Standard.
Page 31 of 47Thursday, April 29
2010 Goals
Wanner revisited the 2009 goals and asked the group to define goals for 2010. She 
noted that some of the goals are on-going. “One of the things I would like to do,” she 
said, “is to ensure that the goals we set are achievable. I would prefer to have fewer 
goals that we can accomplish rather than many, even if it makes it look like weʼre being 
less ambitious.”
The group decided on the following goals for 2010:
Editorʼs Note: The following goals were revised slightly by the Chair and the 
Maintenance Agency following the meeting to improve the wording and to clarify the 
intent. What is presented here is the revised version rather than the original.
* Support NISO guidelines for membership to ensure a balanced, actively contributing 
group
*Improve processes to track and implement formal requirements for attendance 
and contribution
* Encourage global participation by implementers outside of North America
* Seek to add library practitioners as members and observers
*Implement the continuous maintenance model for updating the Standard
* Clarify conformance for Version 2 and future versions
* Create, post, and utilize a form for submitting change requests and defects
* Review and act on requests for change in Spring and Fall meetings
* Finalize and publish changes with detailed documentation in a timely manner
* Encourage implementation of NCIP through education and outreach
* Promote adoption of Version 2 by implementers
* Publish Resource Sharing and Self Service Core Message Sets
* Publish an Implementer Registry to track support for Core Messages by 
implementers
* Create educational documents for librarians and implementers
* Research other methods to simplify the NCIP learning curve for new 
implementers
* Gather and publish NCIP-related case studies and success stories
* Conduct outreach programs to potential implementers, participants, and 
observers
Page 32 of 47Technical Support for Implementers
Walsh asked what we recommend to RapidRadio as a means to get help with 
implementing. Should we tell them to post a question to the general interest list as has 
been done in the past? Jackson said that the general interest list has some inherent 
overhead. Having to join and wait for confirmation might discourage people who are 
new. Campbell suggested that we create a link on the website where people could 
submit questions. The questions (and answers) could then be used to create a 
Frequently Asked Questions (FAQ) list. Wanner agreed that this could help us discover 
those who are implementing NCIP. Walsh said that it is relatively easy to put a link on 
the website, but we have to be prepared to respond to the requests. The group decided 
to defer further discussion on this issue until the next conference call.
Encouraging Implementation of Version 2
Iddings noted that one of the issues that plagues implementers may be the lack of 
backwards compatibility. “If the vendor community would stop supporting the older 
versions, people would need to implement Version 2,” he said. “When Innovative 
Interfaces agreed to move forward with NCIP development [using Version 2], we got a 
very positive response in the library community.” Campbell added that some states are 
beginning to mandate statewide interoperability among K-12, colleges, universities, and 
public libraries. “NCIP needs to be ready to step in and make these systems possible,” 
she said. Walsh observed that the K-12 vendor community is one that is not 
represented in this group. Jackson noted that the question often is who will pay for the 
development. Campbell said that she thinks the states will be willing to pay for the 
systems, but they need to know what to buy. Walsh suggested that there would need to 
be a single entity representing a collection of disparate vendors to serve as the analog 
to the entity representing the customers (the states in Campbellʼs scenario). At PALCI, 
Iddings has played both roles. Wanner agreed that the project needs to be driven by 
someone.
Planning for the Next Meeting
Dicus reported that Ex Libris is willing to host the next meeting in Chicago. The group 
tentatively decided to schedule a meeting for September 8-9. The plan is to start at 
approximately 9 am on Wednesday and break at around 3 pm on Thursday. The group 
decided to schedule only two days for this meeting since we know the significant burden 
participating in these committees often places on companies and institutions. Chicago 
is a desirable venue since it is a central, easy-to-reach location that allows some 
participants to limit the number of overnight stays required to attend.
Page 33 of 47Conference Call Times and Technologies
Wanner suggested that we should consider using WebEx or other remote conferencing 
technologies to help make our conference calls more productive. The group also noted 
that the standard 1:00 pm US Eastern time for calls is not particularly conducive to 
people in India. Walsh suggested that we could rotate through a series of time slots 
over a three or four month period. The group decided to retain the 1:00 pm US Eastern 
for the monthly conference calls until we can determine whether it prevents or deters 
global participation.
Next Conference Call
Wanner announced that the next monthly conference call is scheduled for May 20, 
2010, at 1:00 pm US Eastern. Call in details are available on the NCIP website (http://
www.ncip.info).
Adjournment
Wanner adjourned the meeting.
Page 34 of 47Appendix A - Presentation by Dhaval Kotecha, RapidRadio
Page 35 of 47Page 36 of 47Page 37 of 47Page 38 of 47Page 39 of 47Page 40 of 47Appendix B - Handouts from eXtensible Catalog Project
Page 41 of 47Page 42 of 47Page 43 of 47Page 44 of 47Page 45 of 47Page 46 of 47Appendix C - Action Items
What Who By When
Check with LLAMA-SASS / RUSA STARS groups about 
participating in ALA forum again this summer
Wanner
Draft language describing the Core Message Sets and 
how an implementer describes its support for them
Iddings, Campbell, 
Wanner
ALA Annual 2010
Revise existing implementer registry submission forms 
and create versions for self-service
Wanner, Campbell, 
Jackson
ALA Annual 2010
Draft an invitation to NCIP Social at ALA Annual Wanner, Jackson
Follow up with Kotecha at RapidRadio to get additional 
details from presentation
Walsh
Attempt to determine whether NCIP can be considered 
RESTful
Wetzel, Stewart May 7, 2010
Implement accepted change requests in schema OʼBrien
Update Standard to reflect accepted change requests Walsh June 30, 2010
Respond to those who submitted proposals to let them 
know the disposition of their requests
Walsh, Wanner
Review codepad.org to determine whether something 
similar might be possible for NCIP
Campbell
Contact VTLS to determine if they wish to remain active 
in the NCIP IG
Walsh, Wanner, 
Wetzel
Clarify with NISO how information is disseminated 
publicly (i.e., Minutes moved to public NISO workroom 
for NCIP)
Wanner, Walsh
Confirm dates for September meeting with Ex Libris Dicus
Obtain list of those subscribed to the general interest list 
serve
Walsh
Page 47 of 47
Powered by Create your own unique website with customizable templates.