The International Cooperation for the Integration of Processes in Prepress, Press and Postpress Organization (CIP4) is a not-for-profit association and is registered with the U.S. Department of Justice and the Federal Trade Commission as a Standards Development Organization. CIP4 is established in Switzerland, it has no regular offices; rather is a global organization with representatives in several countries. CIP4 brings together vendors, consultants and end-users in the print communications, Graphic Arts industry, and associated sectors, covering a variety of equipment, software, peripherals, and processes. Members participate in focused working groups to define future versions of Job Definition Format (JDF), to study user requirements, and to design a JDF Software Development Kit (SDK).

Currently the CIP4 Organization has 310 members. The membership is constantly growing and a few new members join every month. CIP4 lives and breaths over WebEx - there are approximately 20 technical and administrative working groups and some of them "meet" weekly via WebEx; hence, the pace that CIP4 has kept is rather impressive but would not have been possible just a few years ago. There are approximately six face to face meetings every year at locations around the world, including the annual member meeting, which is always held in conjunction with GraphExpo.

CIP4 was formed in September of 2000. Its predecessor, CIP3, was formed by Heidelberg in 1995 and was managed by the Fraunhofer Institute for Computer Graphics. CIP3 created the Print Production Format (PPF), which has found some success in ink key pre-setting and postpress operations. The PPF format was written in a proprietary format, and CIP3 was considering the move to XML at the time. In the meanwhile, Adobe, Heidelberg, Agfa, and MAN Roland had put together an XML based job ticket called the Job Definition Format (JDF). They asked CIP3 to take over stewardship of the specification, provided that CIP3 would reorganize as a public not-for-profit entity open to all, which it did.

Adobe's Portable Job Ticket Format (PJTF) was another early attempt at creating a method for exchanging print metadata, as was Graphic Communications Association's Industry Architecture Project and IFRA's ifraTrack. Each metadata program had its own unique failings and lessons learned; hence, JDF is not a "first attempt" but rather builds on the experience gained from all of these efforts:

1. Embedding metadata into production files and/or PostScript (PJTF and ifraTrack) isn't going to work for many reasons: the least being that front-end systems cannot handle the size and volume of these large production files.
2. Metadata must be typed and structured so that it can move from data store to data store (IAP)
3. The basic language needs to be XML because it is open and also widely used by programming tools (all)
4. The environment that JDF is developed in must be a public and open environment (all)

In fact, PJTF and PPF are "mapped" into JDF. In the JDF document you will find appendices that provide explicit instructions for moving from PJTF or PPF to JDF.

Once the four creators of the initial draft of the JDF specification transferred it to the new CIP4 organization in 2001, JDF 1.0 was published. Everyone agrees that it was not possible to implement JDF 1.0. Rather it served as a "straw man" document that members of CIP4 could shape, change, and improve. It was a starting point. JDF 1.1 and 1.1a were published in April and October of 2002. Significant changes were made in the specification and accompanying schema. Most of the equipment that you see on the market today was built to JDF 1.1 and 1.1a specifications. This course is based on JDF 1.2. It was formally published in April 2004. Many of the products released at drupa 2004 included some JDF 1.2 functionality, as members had been developing their systems in conjunction with the new edition of JDF 1.2.

JDF is managed in four simple tiers. Working Groups, such as "Prepress" or "Digital Printing," discuss and agree to changes that are pertinent to their area. These changes are submitted to a Technical Steering Committee (TSC) that is responsible for reviewing and approving all changes to the specification. The TSC is charged with settling issues that arise between Working Groups and ensuring that the overall architecture of the JDF specification and schema remain sound. Approved changes are then submitted to the Managing Editor who is charged with integrating changes to the document. Finally, a Technical Specialist is responsible for implementing the approved changes to the schema and ensuring that the schema is reconciled to the specification itself.