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 14-17, 2009

NCIP Implementers Group
Minutes - In Person Meeting
April 14-17, 2009
Present:
3M - Paul Sevcik (Tuesday, April 14 only)
Auto-Graphics - Mary Jackson
EnvisionWare - Rob Walsh (NCIP Maintenance Agency)
Ex Libris - Mike Dicus
Innovative Interfaces - Lynne Branche Brown
NISO - Karen Wetzel
OCLC - Tony OʼBrien
Relais International - Kevin Stewart
SirsiDynix - Gail Wanner (Chair), Brent Jensen
Minutes prepared and submitted by:
Rob Walsh, EnvisionWare / NCIP Maintenance Agency
Tuesday, April 14
Agenda Review
Wanner called the meeting to order and thanked Innovative Interfaces for hosting. She 
led group through a review of the proposed agenda. During the discussion around 
marketing and education efforts, Wetzel indicated that NISO has been receiving 
negative feedback relative to NCIP, mostly surrounding the lack of implementations. 
She stressed that the group should focus on how to foster more implementations. 
Wanner suggested that we might want to work to identify a core group of messages to 
reduce the perception that NCIP is so large. “We use only about a dozen messages,” 
she said. OʼBrien added that one of the main motivations behind version 2 was to 
remove the perceived and the real barriers that were alleged to be preventing people 
from implementing and collaborating. “We should really work to focus on fostering more 
collaboration and implementation,” he said.
News and Updates
Wanner opened a discussion on general news and updates. She reported that the 
Rethinking Resource Sharing group is planning an annual forum to be held in Dublin, 
OH, in May. Although NCIP is not that groupʼs main focus, they support standards and 
are particularly interested in NCIP. Wanner reported also that she has not yet received 
any information relative to the LITA presentation that was submitted by members of this 
group. She said that Susan Campbell at CCLA submitted another session, and she, 
too, has not yet heard whether the session was accepted. Wetzel reported on an effort 
from within NISO to pursue Single Sign On. A recent ballot appears to have garnered 
1 of 29enough votes for a working group to be formulated. Wetzel indicated that the expected 
outcome from those efforts is likely to be a recommended practice, not a new standard. 
OʼBrien reported that Walsh recently accepted an invitation to join the Discovery To 
Delivery Topic Committee. Walsh reported that he and Wanner had been working to 
increase the amount of NCIP-related information published through NISO. These 
efforts include articles in NISOʼs Information Standards Quarterly and news items in 
NISOʼs monthly newsletter. Wetzel commented that the group should continue to do 
this and more. “We really want to show people that this work is going on and that this is 
an open venue,” she said. “We want people to know that the issues that have been 
raised are being addressed.” Dicus reported that the eXtensible Catalog (XC) project 
(http://code.google.com/p/xcnciptoolkit/) has published an NCIP toolkit. Walsh indicated 
that a link to that project has been added to the Links and Resources section of the 
NCIP website.
Concerns over Pricing
Stewart expressed frustration over the fact that some vendorsʼ pricing models for NCIP 
serve as a barrier to entry for some of his customers. Wanner added that this group has 
always stayed away from pricing and costs. She suggested, though, that there might be 
something NISO could do to encourage people to make NCIP available at reasonable 
costs. Stewart indicated that there is no real need to take any specific action. “We 
simply need to make it clear that pricing issues may be damaging the standard,” he 
said. OʼBrien asked if there are ways to mitigate those issues to reduce the impact of 
concerns over pricing. Wetzel suggested that we should try to find ways to point out 
that it is possible to implement without incurring high costs. OʼBrien added that, given 
the current economic climate, we need to do all that we can to make NCIP more 
affordable. Wanner indicated that, by defining a core set of message, we simplify the 
process for implementing. Also, more work towards harmonization would reduce the 
number of different approaches responders would need to support. “Each new profile 
often requires support for different messages or different handling for some messages,” 
she said. “These things drive up the cost.” Jackson reported that Campbell has 
reviewed several of the various DCB profiles, and she has a lot to offer on where they 
differ and how they might be reconciled. Wanner encouraged the group to keep these 
points in mind as we talk throughout this meeting. “If we ensure that they are part of our 
discussions, then we might find ways to address them,” she said. Jackson suggested 
that there might be value in trying to identify messages that are rarely used and 
eliminate them. OʼBrien cautioned that we might be able to define core profiles that 
identify the must-have messages, but that we might not want to actually eliminate any. 
“I am reluctant to remove really good messages, but I do think we can relegate them to 
the background,” he said. Brown agreed that we should focus on the core set but leave 
the others to demonstrate that there is more functionality available if it is needed. 
Dicus, though, raised another point commonly heard from customers. “There is a belief 
that, if a vendor supports the standard,” he said, “it should support all of the standard. 
The core message set might create some confusion over what is supported.” Wanner 
responded that if we can agree on a core and people implement that core, then we can 
be clear about compliance.
2 of 29Review of NCIP IG Purpose, Structure, and Procedures
Wanner began a discussion of the purpose, structure, and procedures for the NCIP 
Implementers Group as posted on the NCIP website.
* Forum for discussion of technical issues - the group agreed that this remains a valid 
part of the purpose
* Advisory group to the Maintenance Agency - the group agreed that this remains a valid 
part of the purpose
* Manage and approve application profiles
Wanner asked whether it is really part of the purpose of this group to approve 
profiles. Brown said that, at previous meetings, we had agreed that the group 
would simply publish the profiles. By virtue of them being published, they were 
“approved.” Wanner suggested that we change the wording to reflect that we 
collect and publish rather than approve. “Someone outside the group may infer 
that we actually vote on them,” she said. Jackson asked if there is a distinction 
between the original profiles (created as part of the initial version 1 efforts) and 
those that have been created since. Walsh indicated that the older profiles have 
been separated from the newer ones and placed into an archive on the website. 
Jackson said that there may be a perception that the profiles with vendor 
information are not seen as “approved” or “official” in the same way as the 
originals. Walsh, though, asked whether the original profiles were really 
hypothetical because they were created before any implementations existed.
Wetzel indicated that NISO is getting a lot of pressure to pull support for NCIP 
due to issues associated with implementations. The profiles are confusing 
because they imply that each vendor has its own implementation. “Thereʼs a bit 
of reality in that,” Brown added. Wanner suggested that we could change the 
way that we are posting the information. “We did, though,” she continued, 
“create NCIP as a toolkit standard.” Wetzel asked if that perception is one we 
want to continue.
Sevick asked about the impact of an approach that collects and publishes, but 
without any approval or versioning. “How do libraries feel about long-term 
support and compatibility,” he asked. Wetzel suggested that more information on 
the website to explain with what systems and versions an application profile is 
intended to work might help to address this. Wanner recalled that, when the 
DCB profiles were drafted, the four approaches were done as exercises. “They 
are not a part of the standard,” she said. “They are just ideas for how it might be 
used.” Jackson added, however, that people think of the profiles as part of the 
standard because they are on the NCIP website. Wanner and Jackson agreed 
that the C-ILL profiles may more accurately reflect how NCIP systems 
3 of 29communicate, partly due to the fact that C-ILL had a firmer grounding than DCB 
at the time when the profiles were written. Wanner suggested that there might be 
value in continuing the efforts to harmonize DCB and C-ILL as they are done with 
NCIP to see if they can use the same set of messages. Jackson said that 
Campbell has been reviewing the profiles very carefully and is finding numerous 
discrepancies. “Most are probably due to editorial sloppiness,” said Jackson. 
“However, others who look at the profiles may have the same experiences.” 
Jackson continued by suggesting that we add a note that the existing profiles 
were written to support version 1 and may not work with version 2. Walsh asked 
whether the note should be applied to all existing profiles or just those currently 
residing in the archive. Wanner said that we should indicate that all of them were 
written to support version 1, and she suggested that those in the archive should 
have an extra note indicating that they are intended as examples and should not 
be used. “That way,” she said, “people wonʼt view them as authoritative.”
Wetzel asked if the group is planning to update the more current profiles to be 
compatible with version 2. Wanner suggested that our discussions around a core 
set of messages will likely impact the existing profiles.
OʼBrien returned to the point of this groupʼs role as it relates to profiles. “It is a 
responsibility of this group,” he said, “to review and make recommendations for 
all existing profiles.” Brown suggested that we change the bullet point in the list 
defining the groupʼs purpose from “Manage and approve application profiles” to 
“Collect and publish application profiles.” Sevcik reiterated a desire to make an 
effort to incorporate some kind of versioning scheme.
* Accelerate the implementation of NCIP - the group agreed that this remains a valid 
part of the purpose, possibly even the most significant part
* Promote NCIP through educational activities - the group agreed that this remains a 
valid part of the purpose and that it has been putting more efforts into this area
* Broaden the technical membership of the group
Wanner indicated that we have not done much of this lately. “We seem to have 
lots of other priorities,” she said. Walsh suggested that we should make an effort 
to consolidate the group and reach out to those who have been less active 
before we expand. Jackson asked whether we should reach out to more 
librarians. OʼBrien agreed that it has been valuable to have someone like 
Campbell participating in the group. Wetzel added that people appreciate that 
NISO represents both vendors and libraries. Wanner said that the economic 
climate may make it difficult to recruit more members. Oʼ Brien suggested that 
we might need to review the mechanisms by which we meet in order to be more 
cost conscious. Although we get more done when we meet face-to-face, he 
indicated that we might be more effective in recruiting more members, especially 
librarians, if we can find more effective ways to meet remotely. Wanner asked if 
4 of 29NISO is doing things in other arenas to compensate for difficulties holding inperson meetings. Wetzel said she was surprised that she had been able to 
attend this meeting due to cuts in travel expenses. “This is one of the few groups 
that continues to hold regular in person meetings. People are using more of the 
on-line tools and working hard to communicate really clear ideas about what 
needs to be accomplished” in order to make those virtual meetings more 
effective. Wanner asked if others have had success with teleconferences. 
OʼBrien said that the technology often gets in the way and that time often is 
wasted trying to get the infrastructure established. Jackson said that, while she 
has been part of effective sessions, they were not attempting to have the types of 
discussions that we have when we meet. Wanner agreed that teleconferences 
donʼt generally facilitate this type of discussion. Wetzel suggested that effective 
teleconferences require more up-front planning. Stewart indicated that he has 
had success with hybrid meetings where some people are local and others are 
remote via webcam and speaker phone.
Wetzel suggested that there might be value in having a smaller, very focused 
group and a larger, less active group. OʼBrien agreed that there are certain 
discussions that relate well to the larger group and others, like showing the XML 
schema, that need a smaller audience. He continued by reiterating that we need 
to work to address the logistics of how we are going meet, in this climate, before 
we can recruit effectively. Jackson added that we need to be able to provide 
compelling content for people to want to take time from their schedules and 
participate in the meetings. Walsh suggested that having a clear and fairly 
narrow focus (and a looming deadline, added Wanner) was part of what made 
the small group efforts effective last fall when we were working to finalize version 
2.
Brown asked whether we had sufficiently answered the question of whether a 
part of the groupʼs purpose is to broaden the technical membership. The group 
agreed that the emphasis on technical may not be necessary. Wetzel suggested 
that “Assure a balanced representation of interested parties” should be used 
instead. Wanner indicated a preference to keep the current item and add the one 
Wetzel suggested.
* Acquire feedback and requirements from end-users
Jackson suggested that we revisit this item at a later time. She felt that it is really 
part of the prior discussion around membership and balance.
Wanner asked if anyone could think of other things that should be part of the purpose. 
Jackson suggested that the current purpose does not address maintaining and revising 
the standard. Walsh suggested that would come under “advise the Maintenance 
Agency.” Wetzel added also that this notion may change after discussing whether to 
move to continuous versus periodic review of the standard.
5 of 29Negative Feedback Received by NISO
OʼBrien asked Wetzel to elaborate on the various pressures NISO is facing relative to 
NCIP. “The feedback weʼre hearing is ʻIt doesnʼt workʼ and NISO should not be 
supporting it,” she answered. She indicated that at ALA mid-winter in January there was 
talk about the pace of the standards process and how libraries donʼt know what to ask 
for. Those are the reasons being given for why it doesnʼt work. “The feedback isnʼt 
new,” she continued. “Itʼs things youʼve probably heard. This is why it is so important to 
focus on PR - a make-over for NCIP, so to speak.” OʼBrien asked what the most 
important target audience for efforts relative to restoring the image would be. Wetzel 
indicated that it is difficult to pick one, and that each member of this group needs to 
work to promote their own implementations and develop them if they do not exist.
NCIP Implementers Group Membership Requirements
Jackson suggested that we should review and possibly revise our requirements for 
participating in this group. Wetzel indicated that it is permissible under NISO to state 
requirements like “if you miss two calls in a row you can be removed.” Brown 
suggested that we establish membership requirements that conform to NISOʼs 
guidelines. Wetzel presented the NISO Policies and Procedures guide, specifically 
section 2.3, that governs committee membership (see http://www.niso.org/about/
documents/NISOprocedures2008final.pdf). OʼBrien made a motion to approve the 
NISO guidelines as they relate to defining membership requirements for the NCIP 
Implementers Group. Brown seconded the motion and the group raised no objections. 
Binding Decisions at In Person Meetings
Wanner reminded the group that, in the past, weʼve opted not to make binding decisions 
at in person meetings. Historically, weʼve posted recommendations to the list and 
allowed for a two week review period before calling a formal vote. “Is that something we 
want to change?” she asked. Jackson expressed her concerns and frustrations over 
the usual lack of response from the list during the review period. “If people know 
decisions will be made,” she said, “they may be more likely to attend.” Wetzel added 
that the agenda is published beforehand, so people with a specific interest have a 
chance to express their positions ahead of time if they will be unable to attend. Wanner 
suggested that the group should formally define what constitutes a quorum for meetings 
and votes.
Designated Contacts for Member Organizations
Jensen requested that it be possible to name both a primary and a second contact for 
each organization. OʼBrien suggested that wording should be added to the members 
list page on the website indicating that each organization receives one vote and may 
name a primary and secondary contact. The first name listed is the primary, and that 
personʼs vote is considered authoritative for the organization in the event that both the 
primary and the secondary contacts cast a vote. The primary contact may designate a 
6 of 29temporary contact who may speak for (and vote on behalf of) the organization for a 
specific time period or event.
Voting versus Non-Voting Membership
Walsh suggested that we may be changing the structure of the NCIP community to one 
where there are those who are members of the Implementers Group (with voting 
privileges) and those who are part of a general interest group. This might imply that we 
no longer need voting and non-voting membership within the Implementers Group. 
Wetzel asked whether there is a need for a third layer, some kind of technical subgroup. Wanner responded saying the the nature of the tasks probably will dictate the 
technical level required, and she saw no need to explicitly differentiate.
Contacting Inactive Implementer Group Members
Wanner requested that the minutes reflect the decision to adopt the NISO guidelines for 
membership in the Implementers Group. Further, she indicated that she and Wetzel will 
contact current members who are presently inactive and inform them that they are being 
removed from the group as they do not meet the new criteria. Those organizations will 
have the option to re-join the group by agreeing to abide by the new requirements for 
participation.
Review of NCIP Implementers Group Procedures
Wanner began a review of the NCIP Implementers Group procedures are posted on the 
NCIP website.
* Consensus is golden - the group agreed that this remains a valid part of the 
procedures
* One vote per member organization - the group agreed that this remains a valid part of 
the procedures
* Organization must be an NCIP developer
Wanner indicated that weʼve never enforced this requirement. Jackson 
recommended changing the item to read “Organization must be interested in the 
development of the NCIP standard.” Wanner suggested actually removing this 
item.
* Organization decides the member who votes - the group agreed to accept OʼBrienʼs 
earlier proposal as the definition for how an organizationʼs vote is determined
* Attendees at the first meeting are members - the group agreed to remove this item as 
it is no longer relevant
7 of 29* Chair accepts membership applications or refers applications to the group - the group 
agreed that this remains a valid part of the procedures
* Chair maintains membership list - the group agreed that this remains a valid part of the 
procedures
* Chair is always a voting member - the group agreed to remove this item as, by 
eliminating the notion of voting and non-voting membership, it is no longer relevant
* A member can propose a vote (must be seconded) - the group agreed that this 
remains a valid part of the procedures
* Two-thirds of participants in vote count as a majority
Wanner indicated that the NISO guidelines call for only a simple majority. 
Wetzel, though, said that the group is allowed to make its own decision for what 
constitutes a majority. OʼBrien recalled that the choice of two-thirds was 
intentional. Jackson asked whether “participants” means “those at the meeting” 
or “those in the group”. Wanner returned to the idea of defining a quorum. 
OʼBrien suggested that two-thirds of the membership should constitute a quorum. 
The group agreed and further defined that this number is required to hold a vote. 
50% of the membership plus 1 vote is required for a vote to pass. For example, 
if there are 12 members, 8 constitute a quorum. 8 or more would need to vote 
for the ballot to be considered binding, and 7 votes in favor would be required for 
passage.
* Abstentions donʼt count either for or against - the group agreed that item this remains 
a valid part of the procudures; further the group acknowledged the potential for 
confusion as to how abstentions count relative to defining a quorum
* All decisions, plus details of votes, must be recorded in meeting minutes - the group 
agreed that this item remains valid as part of the procedures
* Conference calls follow the same rules
Wetzel asked whether we should add any wording to reflect other forms of 
remote meetings. Wanner suggested that this item should be removed and that 
the group should assume that all meetings follow the same rules.
* List discussions follow the same rules but have a duration, exceeding of which 
amounts to abstention - the group agreed to revisit this item once a decision has been 
made on whether to use the voting facilities available at the NISO website
* Chair is the only person who convenes meetings - the group agreed that this item 
remains a valid part of the procedures
8 of 29* Chair is the only person who approves voting process - the group agreed to remove 
this item since the voting process is sufficiently well-defined elsewhere in these 
procedures
* Chair decides if reconsideration of decisions is warranted - the group agreed to 
remove this item and leave the decision to reconsider in the hands of the group and 
subject to the other procedures (i.e., motion and second to reconsider the decision)
* Chair may designate a proxy - the group agreed that this item remains a valid part of 
the procedures
* Chair reports success or failure of the vote - the group agreed that this item remains a 
valid part of the procedures
* Default email vote duration is one week; Chair may reduce or extend this at own 
discretion - the group agreed to revisit this item once a decision is made on how 
electronic voting is to be managed
* Finalization of application profiles will follow the established voting process - the group 
agreed that this item should be removed since the group does not approve application 
profiles
Sevcik asked whether we should add any procedures defining how the chair is selected. 
Wetzel suggested also that we should specify the term of the chair. Wanner indicated 
that, so far, the chair has served until he or she decides to step down. “Should there be 
a term limit?” she asked. Sevcik asked whether the term should actually be limited or 
whether there should simply be a periodic review or reaffirmation. OʼBrien indicated 
that we should not require someone who is doing well and who wants to continue to 
step down. Jensen suggested that we could allow the regular voting process (motion 
with second) to initiate the process to replace the chair. Wanner suggested that, at the 
very least, we should indicate that the chair is elected by the group. Jackson 
recommended adding that the term is undefined (or open-ended).
Continuous Versus Period Review
Wanner opened a discussion on whether the group should adopt a continuous review 
process for the standard rather than persisting the current process that requires a 
formal review every five years. Wetzel explained that ANSI provides for both 
mechanisms. NCIP is currently governed by the rules that require it to be reaffirmed 
once every five years. The scope of what can change between formal reviews is 
limited. Any substantial changes require another formal ballot. The continuous review 
process is starting to become more popular, probably due to the pace of advances in 
technology. Z39.7 is currently the only NISO standard using the continuous review 
process. With that group, comments are made regularly and a committee reviews them 
every six months. The committee decides which to adopt and then informs the 
membership of the changes. This does not require a formal vote before the full 
9 of 29membership, but it does require more formal process for communication and decision 
making. Wanner asked if the change interval has to be specified up-front. Wetzel 
indicated that the interval must be specified, but no changes are required to be 
published at each interval However, if no changes occur during the interval in which the 
standard would have had to be reaffirmed under periodic review, the standard would 
have to be formally reaffirmed with a ballot before the full membership. OʼBrien 
observed that we have not yet made it through any four year period without a change. 
Wetzel added that continuous review would allow for those changes to be made more 
regularly. Jackson asked whether each published change receives a new number. 
“How do we address issues associated with backwards compatibility?” Wetzel 
explained that there is a lot of flexibility inherent in the process, and handling for many 
of those issues is not prescribed. “The group would need to define how those sorts of 
issues are managed.” OʼBrien suggested that we can control versioning by requiring 
each update to the schema to trigger a version number update to the schema itself. 
Jackson asked how we communicate to the community the impact of, for example,
version 2.0 versus 2.01. OʼBrien indicated that, so far, weʼve broken backward 
compatibility only once. “I recommend that we continue that practice,” he said. Jackson 
expressed a concern over the perceptions associated with the frequency of change. 
Wanner added that, with the advent of extensions, we are likely to see more changes 
over time. “It would be better,” she said, “to see those changes become part of the 
standard rather than have them implemented as vendor-specific extensions.” OʼBrien 
indicated that was an intentional component of the extensions mechanism. “We wanted 
useful extensions rolled into the standard,” he said. Jackson continued to explain that 
her concerns relate to the potential for confusion over the compatibility of different 
versions. OʼBrien suggested that if we do a good job of maintaining backward 
compatibility, then two versus compliant with the same base version should be able to 
interoperate. Jensen recommended adopting a practice of allowing ourselves to break 
backward compatibility only in major versions. Wanner added that it is incumbent on 
vendors to document and publish what versions they support. OʼBrien reminded the 
group that we have this problem already in that we have two incompatible versions.
Jackson returned to the question of moving to continuous maintenance. “Is there 
anything really harmful that might prevent us from going to continuous maintenance? It 
sounds like we have everything to gain.” Wanner agreed that we do have a lot to gain, 
but cautioned the group to be mindful of the responsibility associated with creating new 
versions in less than four years. Walsh suggested that we donʼt have to publish new 
versions that frequently, but we have the option to do so when we have the need. 
Wetzel agreed that it puts the group in a position to act on things the community sees 
useful. “It more closely reflects reality,” OʼBrien continued. “Weʼre doing this already 
every time we update the schema.” Steward added that if we stick to the idea that only 
major versions may break compatibility, and we agree not to publish new versions every 
week, then we limit the risk that people will object to the changes. Sevcik reiterated that 
the on-going maintenance may require a higher level of commitment. OʼBrien 
suggested, though, that the changes could be implemented without additional face-toface meetings. Jackson added that we might encourage more adoption by being able 
to make small changes more frequently. Wanner said that, from a PR perspective, this 
10 of 29might be very beneficial to us. “If we announce that we are going into a continuous 
maintenance mode and really encourage feedback, then we may get some good input.” 
Wanner asked whether the group was generally in favor of moving to continuous 
maintenance. OʼBrien indicated that there appears to be consensus around the 
principle, but weʼll need to define more of the details as we begin to prepare the 
documentation necessary to make the change formally with ANSI. Walsh agreed to 
work with Wetzel to review the required documentation and formulate a list of the 
decisions that will need to be made. He will bring this information back to the group for 
further discussion and a formal, final decision.
Self-Service Needs
Wanner asked if any more discussion was necessary around needs specific to selfservice. Walsh explained that it might be better to give self-service implementers more 
time to explore the changes introduced in version 2. “Iʼm not sure it would be fair to 
harp on what else needs to be done,” he said, “until we have a chance to see what is 
possible.” Sevick added that what is really needed are more implementations. He 
agreed that there may be more work to be done, but a lot of functionality was added in 
version 2. Wanner asked what needs to be done to get those additional 
implementations. Walsh said that, historically, it has been difficult to define a strong 
business case. “Why do NCIP when thereʼs no benefit beyond what can already be 
done in SIP?” Version 2 adds some functionality to get more information with fewer 
requests than with SIP, but is that the kind of enhancement that adds real value that 
customers see as significant? Other features, like being able to offer patron selfregistration and address verification and update, do add real value, but there arenʼt 
systems that provide those functions. Self-service implementers are at the mercy of the 
ILS vendors to provide responders to do self-service with version 2. Walsh agreed to 
work with (Sue) Boettcher at 3M to define a set of discrete workflows that are specific to 
self-service.
Revisiting Application Profiles
Jackson suggested that the application profiles should be geared more towards 
workflows and performing tasks than on exchanging messages. “Such profiles,” she 
said, “allow us to begin to make lists of those vendors who implement the messages 
necessary to perform useful tasks. This information may be in the current profiles, but it 
is probably so buried that it isnʼt obvious.” Wanner agreed that we should again review 
the application profile template. The template should probably start with some 
information about what the profile will allow a user to do. Jackson added that the 
profiles, originally, were intended for developers, not for users. Brown suggested that 
we might need two documents. Wanner agreed that, at the least, there should be two 
sections, one aimed at each audience. OʼBrien added that one should focus on the 
raîson dʼetre - the high-level goal or objective - plus the technical detail.
11 of 29Possible Changes and Additions to Version 2
Wanner led a review of a list of items that had been compiled last fall during the efforts 
to finalize version 2 for publication. Some of these items originated as comments 
received during the balloting, and others were the result of work done to ensure the 
various pieces of documentation associated with version 2 were consistent with one 
another.
* Distinguish individual for institutional users - comment from Library of Congress
Wanner suggested that this might be dependent on how each individual ILS 
implements borrowing. Jackson explained that the issue might be that it isnʼt 
easy to pass the parent institution in the relevant messages. The group reviewed 
the actual comments and decided that the request was for a way to loan 
materials to an institution (i.e., a Congressional office) rather than to an individual 
user. Additional discussion suggested that another aspect of the request was to 
perform tasks in batches (i.e., expiring all users associated with a Congressional 
office). The group concluded that NCIP already has sufficient mechanisms for 
identifying the relevant agencies and that the specifics of this request depend on 
the actual implementation within the ILS. As a result, the group decided that no 
action should be taken on this issue.
* Allowing patrons to be owned as part of larger organizations - comment from the 
Library of Congress
The group concluded that this item was related to the previous one and again 
decided that no action should be taken.
* Re-review the process for requesting optional information in Lookup messages
Jensen explained that, early in the version 2 discussions, we had wanted to have 
only way of asking for optional information. However, version 2 still defines at 
least two ways: the use of empty elements and the use of what in vesion 1 was a 
scheme/value pair to request the desired information by name. OʼBrien 
explained that some of the desired changes had to be removed from version 2 
during the final editing because the balloted documentation did not agree with the 
schema. The changes necessary to make the standard match the schema were 
deemed to be “significant” and would have required us to reballot the standard. 
Walsh asked whether the situation could be corrected now without break 
backward compatibility. OʼBrien suggested that it might be possible to add a new 
optional element that represents the preferred approach and then allow 
implementers to choose which approach to use. In version 3, we could remove 
the non-preferred mechanism. “As an initiator, this would not be a problem,” he 
said. “However, as responders would have to implement both approaches.” The 
group decided to defer any action on this item until we next have a reason to 
12 of 29break backward compatibility since there is no real value in making the changes 
now. They would actually introduce additional complexity in the short term.
* Add transaction agency or transaction location to Accept Item
Jensen explained that when an item is created while handling Accept Item, there 
is no way to identify the physical location associated with the new item 
(particularly when the transaction is being processed in a central facility). 
OʼBrien indicated that version 2 contains Pickup Location as an element within 
Accept Item. Brown also pointed out that there is a repeatable location element 
that contains a Location Type which is just a string value. She suggested that 
the example of p.57 on Part 1 be updated to include “Borrower” and “Lender” as 
sample values.
* Determine whether user id, bibliographic id, and possible other id elements should 
repeat in places where they are used - comment from OCLC
Jensen explained that a response should be allowed to include multiple 
identifiers for the item if the item has more than one. OʼBrien indicated that 
multiple ids might be problematic in a request since it could make the request 
ambiguous, especially if the ids each resolved to a different entity. Jensen 
agreed that repeatability might be valid only for responses. Brown asked if there 
is a real market need for this functionality. Dicus read the original comment 
which cited an example where a request might include both the ISBN and an 
OCLC number. OʼBrien added that, as it relates to Accept Item, the request is 
not being used as a lookup. The ids are purely descriptive. Dicus indicated that 
a second part of the comment relates to using bibliographic id and item id in a 
Request Item message. The standard currently requires the use of one or the 
other. OʼBrien agreed that there might be valid uses for this, but that we might be 
implying a particular workflow if we allow both ids in the request. “Does the order 
in which the search is conducted matter, for example?” he asked. Wanner 
agreed that there may be a good case for being able to repeat something like an 
ISBN since records can have two ISBNs, a short and a long. In those cases, if 
you canʼt send both ids, you may not be able to find the item. Brown indicated 
that, while not opposed to the change, we should be mindful that we may be 
expanding the protocol from being specific to a single item to now being one of 
many items. Jackson added that, in some cases, we donʼt know the specific item 
anyway. Stewart asked if this is a place where we should recommend the use of 
extensions. OʼBrien suggested that if we feel it is a valid change why should 
require that it be implemented as an extension. “I do think, though,” he 
continued, “that there may be cases where the nature of the message may be 
different. Multiple ids in a request message may mean ʻrequest one ofʼ in some 
cases and ʻrequest allʼ in another.” Jackson suggested that we could review 
each case individually and decide whether the change makes sense in each 
context. OʼBrien indicated that might be a large task. Jensen suggested that we 
could wait for a valid use case implemented as an extension, then modify the 
13 of 29standard to incorporate that specific use case. Stewart agreed that he felt that 
was part of the intended purpose for extensions. Brown agreed also, stating that 
it makes more sense to address things as they come up in actual use than it 
does to make wholesale changes throughout the schema. Jackson 
recommended that we should note that we are intentionally addressing two 
specific cases and not reviewing the standard as a whole. The group agreed that 
the following changes should be made to the schema:
* Allow Bibliographic Id and Item Id to be both repeatable and not mutually 
exclusive in Request Item. At least one of the two must be present, but both 
can be present and both can repeat.
* Allow Bibliographic Record Id to be repeatable in Bibliographic Description 
within Accept Item
Wetzel cautioned that no changes should be made until a final decision is 
reached on the question of continuous maintenance and procedures are put into 
place for publicizing proposed changes. “Under continuous maintenance,” she 
said, “you have to provide forums for feedback.” The group briefly discussed 
how to allow changes to evolve through a series of drafts and conversations 
without compromising the obligations of the continuous review process. 
Ultimately, the group decided that informal and non-authoritative changes could 
be made in order for the group to review and refine them. Over time, these 
changes would be collected and published in accordance with the procedures 
that are to be defined for continuous review. OʼBrien agreed to make the 
changes to the schema as a draft and only for review purposes. Further, Walsh 
agreed to draft a “Release Notes” document explaining the technical details and 
the motivations behind the changes.
* Repeatable problem element
The group agreed that this represents a case where the schema and the 
standard disagree. The schema represents what the group intended for version 
2, but the standard was not properly updated before going to ballot. As a result, 
the standard could not be changed during final editing to be consistent with the 
schema. Brown volunteered to review the protocol to determine the scope of the 
changes necessary to make the standard agree with the schema. She was able 
to complete the review before the meeting was adjourned, and she reported that 
many elements as documented in the standard are not marked as repeatable in 
places where they are repeatable in the schema. The documentation for these 
elements needs to be updated in order for them to match the schema.
* Review use of User Id both inside and outside User Optional Fields
The group agreed that User Id is allowed to exist both inside and outside User 
Optional Fields (within Lookup User) as a result of the version 2 change to 
replace Visible User Id and Unique User Id with User Id. However, the group 
14 of 29further agreed that the duplication does no harm and actually might serve a 
useful purpose since the User Id within User Optional Fields is repeatable and 
contains a User Id Type element.
* Review use of Item Id both inside and outside Item Optional Fields, primarily for 
consistency with User Id and User Optional Fields
OʼBrien offered a use case where, during check in the system might check to see 
if one item belongs as part of another item. Having an Item Id inside Item 
Optional Fields would allow for a “Parent” or “Set” Id to be defined. The group 
agreed that the schema should be changed to allow Item Id to exist within Item 
Optional Fields as a repeatable element.
* Possible editorial defects within the standard
The group began to discuss a list of possible defects that had been identified 
during the version 2 finalization in the fall of 2008. OʼBrien suggested, though, 
that the list was created at a time when the standard was being scrutinized, and 
they had already been reviewed by a small group of people. He recommended 
that the full list be accepted as defects. Walsh agreed to ensure that they are 
corrected in the standard.
Wanner asked if anyone had other items that should be considered as part of a future 
update. Jensen raised an issue with Lookup User. “Is it intended,” he asked, “to 
represent a search for a valid record in the database or a user who is allowed to 
perform a given task?” Walsh suggested that the answer depends heavily on the 
context in which Lookup User is used. “There may be uses for the information that have 
nothing to do with anything the ILS might know about,” he said. “As a result, how would 
the ILS know whether to return a valid or an invalid record?” Brown added that the 
information necessary to make that decision is already available in other parts of the 
Lookup User Response. Jensen asked specifically about a user with a lost card. 
“Should I respond with the user data or deny the lookup and return a problem element?” 
He said that if the request does not include the Block Or Trap User Optional Element 
then the initiator has no way to know that the card has been reported lost. Stewart 
suggested that it is the responsibility of the initiator to include the Block Or Trap element 
in the request if that information is relevant to the purposes for which the request was 
made.
Mechanisms for Tracking Extensions and Lists
Wanner asked what we need to do to report and publish lists and extensions. Brown 
suggested that there is no need for an approval process because the intent is to simply 
let people know what has already been done. OʼBrien suggested the need for a 
template or on-line form for people to fill out and submit. Sevcik asked whether the lists 
are things people would be creating or extending, or are they references to things in the 
protocol. Wanner explained that in version 1, there were a set of known lists 
15 of 29(implemented as enumerations and scheme/value pairs). In version 2, we made all of 
them into simple string values with optional schemes. “The lists should represent what 
was in version 1,” she said. Brown asked where the lists would be housed, and Wetzel 
suggested that would likely be part of the larger question regarding using NISOʼs 
website for NCIP. Walsh asked if the lists should be machine readable. OʼBrien asked 
what value is gained if the lists are machine readable. Brown suggested that the URI 
might point to the machine readable copy of the list, but Walsh indicated that URIs are 
not required to resolve to a physical entity. Jackson recommended that, since we are 
unable to show a strong demand for the lists to be machine readable, we should not 
require that to be part of the implementation until a need can be demonstrated.
The group then shifted the discussion to what the lists should contain. Jensen observed 
that the real challenge may be getting everyone to agree on the actual list members. 
He recommended that we start with the lists that were defined in version 1 and add or 
remove items as desired. Brown suggested that we make an effort to determine those 
lists that are actually being used and start with those. “I have only one list that is 
important to my implementation - Agency User Privilege,” she said. Jensen added 
“Thatʼs one of the lists I wouldnʼt be able to provide. Each of my customers creates his 
or her own list.” OʼBrien reminded the group how difficult it has been to attempt to close 
lists in the past. “There will always be value outside the various lists that we come up 
with,” he said, and he offered 17th century French sheet music as an example of a valid 
media type that is unlikely to be part of a canonical list. Walsh asked how many lists 
exist. The group concluded that there are approximately 52 elements whose values 
might come from lists. Wanner said that, when we made the decision to make these 
elements into strings, there was a strong feeling that we wanted to continue to use the 
existing lists. Jensen added that we wanted an easy way to extend the lists, and 
making them strings allows us to extend them. “Whatʼs the value, then, in maintaining 
centralized lists of these strings?” Brown asked. Jackson replied that without a 
centralized list each implementer would have to contact each of the other implementers 
to find out what values are supported. Wetzel asked whether the centralized list would 
make it easier for new implementers. Jensen suggested that having the lists defined in 
the standard (rather than externally such as on a website) make them most accessible 
to new implementers. “However,” Wanner added, “that limits the potential for change.” 
Brown said that having them in the standard in version 1 may have introduced 
confusion. “Some of us felt that the lists in the standard were THE lists; others felt they 
were just examples.” OʼBrien raised a concern that, by creating finite lists, we are 
declaring limits. “For any particular library,” he said, “their needs will be inside or 
outside that limit. Some libraries may, then, decide they cannot implement because 
their desired value is not in the list.” Jensen pressed the need for a list, particularly to 
clarify potential ambiguity over spelling, casing, syntax, etc. Wanner agreed and 
suggested that we should at least recreate the lists that existed as part of version 1. 
She further suggested that they be clearly marked as examples and that implementers 
are not required to support the specific values. Many in the group, though, continued to 
raise questions over where the lists should exist (Jackson and Wanner suggested they 
might belong in the application profiles), how many of the lists are likely to have 
convergent and easily agreed upon members, and how many of the lists are likely to be 
16 of 29used. Wanner concluded that the group was unable to reach a decision on how to 
document lists, and further discussion was deferred until the group could review the 
messages that are implemented.
Intent to Implement Version 2
Wetzel raised a concern over whether vendors truly intended to implement version 2. 
OʼBrien asked the group whether anyone intended not to implement version 2, and no 
one responded.
Wednesday, April 15
On-Line Survey to Determine Viability of NCIP
Wanner asked Jackson to summarize the work she and Campbell have been doing to 
create a on-line form or survey that customers could use to determine whether NCIP is 
a viable mechanism to facilitate interoperability among their various vendors to 
accomplish their goals and objectives. Jackson explained that the hope is to have an 
interactive web tool that allows customers to input the tasks and actions they want to 
perform and have the system indicate whether a given combination of back-end 
systems support those workflows via NCIP. Wanner expressed a concern that the 
current state of the industry does not have enough working implementations for an 
automated system like this to be comprehensive. Jackson asked whether it would be 
more valuable to limit the form to only those options that are available today. 
“However,” she continued, “as a customer I still want to perform those tasks even if they 
are not support by an implementation via NCIP.” Brown indicated that the presentation 
of the material might be too technical for many librarians. Jackson agreed that there 
might be a need to show both views of the information - the technical details and the 
high-level desired outcomes. Brown and Wanner both suggested that any automated 
tool needs to remain vendor-neutral and not misrepresent information by limiting the 
scope to only certain workflows.
Wanner asked if it might be possible to simplify and shorten the questionnaire by 
combining various workflows that do the same thing but with different pieces. Jackson 
indicated that the plan is to have the answers early questions limit the scope of what is 
presented later in the survey. Wanner and Jackson continued to discuss the 
correlations between existing application profiles, existing implementations, and the 
options presented in the hypothetical survey. They used DCB as the primary example. 
“When Campbell started working on this,” Jackson explained, “she assumed that DCB 
would not have a broker. The profiles are written to speak directly as well, not going 
through a third party.” Jensen suggested that application profiles should be written from 
the perspective of what needs to be accomplished not how it is implemented. Jackson 
said that the original profiles focus more on the “how.” She volunteered to work with 
Campbell to review and refine the survey in an attempt to simplify it and focus on tasks 
and workflows rather than on the messages necessary to implement them. 
17 of 29Simplifying Application Profiles
Wanner said that profiles focused on “what” would be more valuable. “Whatʼs in DCB-1 
and DCB-2 differ mostly in ʻhow,ʼ” she said. OʼBrien provided a simple illustration of this 
point, showing how the ILS systems and the broker are really roles, not necessarily 
separate systems. “I think a librarian would tend to focus solely on the tasks and the 
outcomes,” he said. “I think the questions should focus more on the real-world functions 
and where they can happen. We can infer from that what parts may be supported. The 
broker, for example, is a capability - it does not have to be a system. If we could grasp 
that concept, we might be able to harmonize the various DCB profiles. Whether the 
function exists inside or outside the ILS is irrelevant.”
18 of 29Jensen suggested that, by harmonizing and reducing the number of profiles, the degree 
to which we are able to interoperate goes up. OʼBrien indicated that he felt we might 
have as few as two core profiles: one for self-service and one for resource sharing. 
Jensen said we should add authentication. Wanner agreed that having C-ILL and DCB 
described in a single resource sharing profile “would be wonderful.” She added that, a 
few years ago when a small group attempted to harmonize URSA and VDX, they 
discovered that the two were relatively similar. Jackson suggested that by simplifying 
the profiles we might get more people to support them.
Supported Messages
Wanner suggested that, as a group, we should review the last few pages of the material 
Jackson presented to determine what messages are currently supported by existing 
implementations.
* Accept Item: implemented by six implementations
* Authenticate User: implemented by five implementations, but is not part of version 2
Jensen observed that, while the message was removed in version 2, the 
functionality it provided is available in Lookup User. The Authenticate User 
message was judged to be redundant.
* Cancel Request Item: implemented by six implementations
* Check In Item: implemented by six implementations
* Check Out Item: implemented by six implementations
* Create User: implemented by three implementations
* Create User Fiscal Transaction: implemented by one implementation
*Item Checked In: implemented by five implementations
19 of 29*Item Checked Out: implemented by five implementations
*Item Recalled: implemented by one implementation
*Item Received: implemented by two implementations
*Item Renewed: implemented by three implementations
*Item Request Cancelled: implemented by three implementations
*Item Requested: implemented by four implementations
*Item Shipped: implemented by two implementations
*Item Updated: implemented by one implementation
* Lookup Agency: implemented by two implementations
* Lookup Item: implemented by six implementations
* Lookup Request - implemented by one implementation
* Lookup User: implemented by eight implementations
* Lookup Version: implemented by two implementations
* Recall Item: implemented by one implementations
Jackson and Stewart both indicated that their respective companies now support 
this message as well.
* Renew Item: implemented by six implementations
* Request Item: implemented by six implementations
* Undo Check Out Item: implemented by one implementation
* Update Request Item: implemented by three implementations
OʼBrien noted that, by setting an arbitrary threshold of messages used in at least four 
implementations, we have 11 core messages. If the threshold is reduced to two 
implementations, the core message set grows to about 19. Wanner asked whether 
Notification Messages belong within the core set. Brown explained that, in some 
implementations, notification messages are used to tell other systems that something 
happened. “While they arenʼt core to the workflow,” she said, “they are necessary to 
keep the external systems in sync with the primary.” Stewart asked if any implemented 
system takes action based on receiving a notification. Various members responded, 
indicating that some did and others did not. OʼBrien suggested that notification 
messages belong outside the core. By removing those from the initial set of 11, the 
group identified a core set of eight messages: Accept Item, Cancel Request Item, Check 
In Item, Check Out Item, Lookup Item, Lookup User, Renew Item, and Request Item. 
Stewart suggested that we include Recall Item in this list. The group agreed to accept 
those 9 messages as the NCIP Core Message Set. The group felt that this set 
represents the messages necessary to support the most common transactions and 
workflows in Resource Sharing and Self-Service implementations. Vendors should 
prioritize and focus on the implementation of these messages in order to be most widely 
interoperable with other systems using NCIP. Wanner agreed to work with Wetzel to 
draft a press release that can be used to announce the definition of the core message 
set.
20 of 29Changes To NCIP Website
Walsh reviewed changes he had made to the NCIP website based on discussions from 
Tuesday on NCIP Implementers Group purpose and procedures. A few were further 
refined, but the group approved the result without objection.
Application Profiles
Wanner began a discussion to review the application profiles in an effort to determine 
how they might need to be changed. Brown asked if there is a reason for the original 
(now archived) profiles to remain accessible. Jackson indicated that, while useful, those 
profiles should be clearly marked “Deprecated” or “Do Not Use.” Wanner volunteered to 
make those changes to the existing documents.
The group further agreed that more work should be done towards defining core 
workflows, possibly extended with product-specific profiles that explain how the 
workflows are implemented. Jackson agreed to work with Campbell in an effort to draft 
this core workflow document. 
The group continued to discuss how the Application Profile template might need to 
change. Jackson suggested that a new profile might contain much of the same 
information currently provided, but packaged differently to focus more on results. 
Wanner said that we need to be careful not to lose the details that are important for 
programmers. Brown indicated that the Event Table was very useful, and Wanner said 
the list showing what messages and elements are supported was also helpful. Jackson 
suggested that we might need two documents. “ʻService Descriptionʼ and a ʻProtocol 
Implementationʼ pop into mind from the ISO ILL,” she said. Wanner agreed to review 
the existing Application Profile template looking for ways to further streamline it, and 
Brown agreed to compare the DCB, INN-REACH, and C-ILL profiles to see where they 
are similar. The group agreed that we should make an effort to reduce the duplication 
between a core workflow and profiles.
NCIP Test Bed
Wanner asked if, by defining a set of core messages, we have made it possible to 
create a test bed. Jensen asked if a test bed is really just a simple responder, then 
OʼBrien asked how one would test a responder. Jensen suggested that the test bed 
could simply push pre-stored messages through a system and then check the results. 
OʼBrien indicated that a scripted approach that exercised the various messages with 
known control data might work better. Wanner observed that such a system would need 
a way to perform a global reset on the data. OʼBrien said that the scripts could be 
structured in such a way that the final result is the same as the starting point. “That 
works when the tests pass,” said Wanner, “but when they fail you still need a master 
reset.” The group raised questions around where the test bed and its scripts would live, 
who would create and maintain the system, and who would arbitrate and determine 
whether the results are appropriate. Brown suggested that the effort to build and 
21 of 29maintain a test bed might be better invested in creating and extending actual 
implementations. Wetzel offered that building a test bed would be supporting the 
standard, and that is part of the purpose of this group. The group agreed that, at this 
time, the test bed idea seems like a larger challenge than we are prepared to tackle. 
Instead, the group agreed to update the implementation status information currently 
accessible on the website. When a core workflow document exists, the group will again 
update the implementation information using the new format.
NCIP Advertisement Promoting Version 2
Wetzel presented a draft copy of an ad promoting NCIP version 2 that is planned for 
inclusion in an upcoming NISO publication. Most of the content had been drawn from 
materials published as part of the version 2 balloting process, and the group concluded 
that the ad should target a different audience by focusing more on tangible examples of 
simplification and real-world benefits. The group worked collaboratively to refine the ad, 
and Wetzel submitted the edited copy to NISO.
NISO RFP Guidelines
Wanner suggested that a small group should be created to revise the existing RFP 
Guidelines. She volunteered to participate, and Jackson agreed that either she or (Ted) 
Koppel would help. The goal is to have the draft of a revision in front of the larger group 
within six months.
LITA Presentation
Wanner agreed to check on the status of the presentation that was submitted for this 
yearʼs LITA conference.
Implementation Checklists
Brown and Jackson agreed to work together in an attempt to merge the various 
versions of the implementation status forms and checklists that currently exist.
LAMA / RUSA-STARS
Wanner indicated that LAMA / RUSA-STARS held a discussion forum at ALA mid-winter, 
and they had plans to have a similar session at ALA summer in Chicago. She agreed to 
contact Nada Vaughn in an effort to get more information. Others in the group 
suggested that we should have handouts promoting NCIP (possibly copies of the ad) 
and/or placards in vendor booths at ALA.
Other Efforts to Promote NCIP
Wanner requested that people bring to her attention ideas about other forums for 
promoting NCIP. She asked also that people send her any informational or educational 
22 of 29information relating to NCIP they may be able to find in their own personal document 
stores.
Extensions
Jensen asked how people who implement extensions document and publish them for 
others to use. Wanner said there are really two goals. “One is the discovery,” she said. 
“Unless you know about them, your interoperability will suffer. The other is to 
incorporate extensions into later versions of the standard.” Walsh asked what 
information about the extension is valuable and needs to be published. The group 
defined the following as a list of details that might be relevant:
* Why it was implemented
* The details of the change
* What element is being extended
* XML namespace, if used
* The version(s) affected
Wanner asked if extensions should be vetted or approved by this group. The group 
agreed that extensions should simply be published without any explicit approval. 
However, the group will actively select those that should be included in future versions. 
The group agreed to leave open the details for a mechanism for publishing extensions.
Lists
The group reopened the topic of publishing lists. After some discussion, though, 
OʼBrien noted that the lists that were part of version 1 are present in version 2 as nonnormative appendices. While having them included as part of the standard 
documentation fills the need to provide examples of list values, it does not address the 
need to allow the lists to change over time. The group agreed that the appendices are 
sufficient for now, and additional list values can be defined as part of application 
profiles.
Thursday, April 16
Action Items and Parking Lot
Wanner and Walsh reviewed the action items and the parking lot from the two prior 
days.
Next In Person Meeting
Wanner asked the group whether another in person meeting is needed this year. 
Wetzel suggested that, if the group ultimately decides to adopt continuous maintenance, 
another meeting might be justified. Wanner agreed to begin at least tentatively planning 
a meeting for the fall. Wetzel (NISO - Baltimore), Stewart (Relais - Ottawa), and OʼBrien 
23 of 29(OCLC - Dublin, OH) offered to host. Each agreed to determine whether facilities are 
available for a meeting tentatively scheduled for September 22-24, 2009. Based on 
availability, the group will make a decision in the near future.
Conference Call Schedule
Wanner outlined the conference call schedule for the remainder of this year. Each call 
is scheduled for the third Thursday of the month at 2 pm Eastern / 11 am Pacific.
* May 21
* June 18
* No call in July due to ALA
* August 20
* September 17 (if necessary to plan last minute details for in person meeting)
* October 15
* November 19
* December 17
Meet and Greet at ALA
Brown suggested that we might want to organize a meet and greet at ALA. “That would 
allow those who havenʼt been active to get re-involved,” she said. “It might help, too, 
attract new members.” The group agreed to think about organizing a meet and greet for 
Sunday evening during ALA. The time and location are to be determined.
Adjournment
Wanner adjourned the meeting.
24 of 29Appendix A - Action Items
The following list represents the various action items that need to be completed as a 
result of this meeting. The person to whom the items are assigned is responsible for 
reporting back to the group a date by which the items can be completed.
What Who By When
Review NISO website/workspace and 
make recommendation about moving 
NCIP website
Change “Manage and Approve Application 
Profiles” to “Collect and Publish 
Application Profiles” in the NCIP IG 
Purpose section on the website
Add Brent Jensen to NCIP IG members as 
secondary rep for SirsiDynix
Add Ted Koppel to NCIP IG members as 
secondary rep for Auto-Graphics
Revise wording on NCIP IG members page 
explaining the one vote per organization 
and the designation of primary and 
secondary members
Revise wording on NCIP IG members / 
procedures page to reflect use of NISO 
Policies and Procedures guidelines for 
committee membership
Send notices to current but inactive NCIP 
IG members whose membership will be 
revoked as a result of moving to NISO 
Policies and Procedures
Remove inactive members from list on 
website
Add “Assure balanced representation 
within the membership of those interested 
in NCIP” to the NCIP IG purpose
Remove “Acquire feedback and 
requirements from end users” from the 
NCIP IG purpose
Change “Candy Zemon” to “Gail Wanner” 
as contact person for requesting 
membership in NCIP IG
Remove “Organization must be an NCIP 
developer” from NCIP IG procedures
Remove “Attendees at the first meeting 
are members” from the NCIP IG 
procedures
Walsh, Wetzel
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
Wanner, Wetzel
Walsh After notices sent to inactive 
members
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
25 of 29What Who By When
Remove “Chair is always a voting 
member” from the NCIP IG procedures
Change “Two thirds of the participants in 
vote count as a majority” to “Two thirds of 
the NCIP IG membership is required to 
take a vote. 50% + 1 vote is required for 
the vote to pass.” in the NCIP IG 
procedures
Remove “Chair is the only person who 
approves the voting process” from the 
NCIP IG procedures
Remove “Chair decides if reconsideration 
of decisions is warranted” from the NCIP 
IG procedures
Add “Chair is elected by the group for an 
unspecified term” to the NCIP IG 
procedures
Add “Any group member may call for a 
vote for a chair at any time” to the NCIP IG 
procedures
Review requirements for converting to 
Continuous Maintenance and prepare list 
of decisions that will need to be made
Prepare task-oriented workflows for major 
self-service tasks (i.e., checkout, pay fee, 
update patron data, etc.) as a starting 
point for establishing a generic self service 
core profile
Provide editable version of Standard
Update list of examples of p.57 of Part 1 of 
the Standard to include “Borrower” and 
“Lender” (as location types)
Fix typographical error on p.57 of Part 1 of 
the Standard - “Text siring” should be 
“Text string”
Allow Bibliographic Id and Item Id to be 
both repeatable and not mutually exclusive 
in Request Item. (At least one 
Bibliographic Id or Item Id must be 
present, but both can be present and both 
can repeat.)
Allow Bibliographic Record Id to be 
repeatable in Bibliographic Description of 
Accept Item
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
Walsh, Wetzel
Walsh, Boettcher
Wetzel
Walsh After NISO provides editable 
version of Standard
Walsh After NISO provides editable 
version of Standard
O’Brien
O’Brien
26 of 29What Who By When
Prepare “Release Notes” describing the 
changes to make Bibliographic Id and Item 
Id repeatable and not mutually exclusive 
AND to make Bibliographic Record Id 
repeatable in Bibliographic Description in 
Request Item. Release Notes should 
describe not only the change, but also the 
motivation behind the change.
Update the Standard to be consistent with 
the Schema with respect to the 
repeatability of the Problem element.
Add Item Id as a repeatable element within 
Item Optional Fields
Prepare “Release Notes” describing the 
change to add Item Id to Item Optional 
Fields
Update Standard to address defects 
identified as part of Fall 2008 push to 
publish Version 2 and documented in email 
from Walsh to NCIP list on March 15, 2009
Remove old RFP guidelines link
Establish a “Success Stories” area on the 
website.
Prepare documentation for NCIP Core 
Message sets (Resource Sharing and Self 
Service)
Prepare press release announcing core 
message sets
Begin drafting a “core workflow” 
document
Edit existing archived profiles to add 
information indicating that they should no 
longer be used
Add wording to the archived profiles 
portion of the website to indicate that 
these profiles should no longer be used. 
They are meant only as examples.
Review current application profile 
template looking for ways to further 
streamline
Compare DCB, INN-REACH, and C-ILL 
profiles for similarities
Provide updated information for vendor 
status reports
Post updated information for vendor 
status reports
Walsh
Brown After NISO provides editable 
version of Standard
O’Brien
Walsh
Walsh After NISO provides editable 
version of Standard
Walsh
Walsh
Wanner
Wetzel, Wanner, Walsh
Jackson, Campbell
Wanner
Walsh
Wanner
Brown
Group
Walsh As information is received from 
members
27 of 29What Who By When
Attempt to merge two different 
perspectives on implementation status 
forms
Revise RFP Guidelines and submit to 
group for review
Check on status of LITA presentation
Continue work on a tool for identifying 
NCIP compliant systems
Check on plans for LAMA / RUSA-STARS 
session at ALA summer
Look for any existing NCIP tutorial or 
education materials (documents, 
presentations) and send to Wanner
Look for opportunities to promote NCIP - 
user group meetings, conferences, etc. - 
and inform Wanner
Determine whether potential host sites are 
available for a in person meeting in 
September (9/22-24)
Work with NISO to establish an NCIP IG 
listserve and a general interest listserve 
(migrating the current TLC-hosted list 
membership)
Publish meeting minutes
Jackson, Brown
Wanner, Jackson, Koppel Within 6 months
Wanner
Jackson, Campbell
Wanner
Group
Group
Stewart, O’Brien, Wetzel
Walsh, NISO
Walsh
28 of 29Appendix B - Parking Lot
Decisions were deferred on the following items.
Item Deferred Until
Review “List discussions follow same rules 
but have a duration, exceeding which counts 
as an abstention” in NCIP IG procedures
Review “Default email vote duration is one 
week. Chair may reduce or extend at own 
discretion” in NCIP IG procedures
Standardize mechanism for requesting 
optional information in an lookup request
Resubmit implementation status information
Review materials prepared around tasks, 
workflows, and core messages to determine 
if new generic application profiles can be 
created
Decision is made about where and/or how to host 
NCIP website
Decision is made about where and/or how to host 
NCIP website
Next change which breaks backward compatibility 
(probably v3)
When (and if) we have a new form for reporting 
implementation status
After core message documentation, core workflow 
documentation, and profile templates have been 
prepared and/or revised
29 of 29
Powered by Create your own unique website with customizable templates.