`
`Ex. GOOG 1024
`
`EX. GOOG 1024
`
`
`
`
`
`

`

`IPTC NAA
`
`Information
`Interchange Model
`and
`Digital Newsphoto
`Parameter Record
`
`Version 2
`April 14, 1993
`
`. ·
`
`Ex. GOOG 1024
`
`

`

`Ex. GOOG 1024
`
`Ex. GOOG 1024
`
`

`

`IPTC-NAA INFORMATION INTERCHANGE MODEL
`Version No.2
`14 April 1993
`
`COPY NO:
`
`ALTHOUGH IPTC AND NAA HAVE REVIEWED THE DOCUMENTATION, IPTC AND NAA
`MAKE NO WARRANTY OR REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH
`RESPECT TO THIS DOCUMENTATION, ITS QUALITY, MERCHANTABILITY, OR FITNESS
`FOR A PARTICULAR PURPOSE. THIS DOCUMENTATION IS SUPPLIED 'AS IS', AND
`YOU, BY MAKING USE THEREOF, ARE ASSUMING THE ENTIRE RISK AS TO ITS
`QUALITY AND SUITABILITY FOR YOUR PURPOSE.
`
`IN NO EVENT WILL IPTC OR NAA BE LIABLE FOR DIRECT, INDIRECT, SPECIAL,
`INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
`INABILITY TO USE THE DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF
`SUCH DAMAGES.
`
`This document is copyrighted with all rights reserved. Under the copyright laws, it may not be
`copied, photocopied or reproduced, translated or reduced to any electronic medium or machine
`readable form, in whole or part, without the prior written consent of the International Press
`Telecor:nmunications Council or the Newspaper Association of America.
`
`Copyright© 1991,1993
`
`Comite International des Telecommunications de Presse
`8 Sheet Street
`Windsor
`Berks Sl4 1 BG
`UNITED KINGDOM
`
`Newspaper Association of America
`The Newspaper Center
`11600 Sunrise Valley Drive
`Reston, VA 22091
`USA
`
`All Rights Reserved. Second edition printed 1993. Printed in the United Kingdom.
`
`Ex. GOOG 1024
`
`

`

`IPTC-NAA Information Interchange Model Version No. 2
`Apri11993
`
`Page2
`
`Ex. GOOG 1024
`
`

`

`IPTC-NAA INFORMATION INTERCHANGE MODEL PART I
`
`1
`
`1.1
`
`1.2
`
`1.3
`
`1.4 ·
`
`1.5
`
`1.6
`
`1.7
`
`GENERAL
`
`INTRODUCTION
`
`Worldwide standardisation has become an acknowledged requirement in the graphics
`and information industry. In telecommunications, standardisation is centred upon the
`widely accepted seven-layer "Open Systems Interconnection• (OSI) model. While the
`lower five or six layers of this model are filled by other bodies, such as telecom(cid:173)
`munications companies or administrations, the CCITT, the ISO and manufacturers, it
`remains the responsibility of the users of information to define the model for the
`dissemination of data.
`
`The Newspaper Association of America (NM) and the International Press Telecom(cid:173)
`munications Council (IPTC) have worked jointly to design a globally applicable model
`for all kinds of data. Every effort has been made for this model to be as compatible as
`possible with ISO and CCITT standards in the fields of application. The joint effort will
`continue for further development and for amendment when advisable.
`
`This model is designed to provide for universal communications embracing all types of
`data, including text, photos, graphics, etc. on a single network or a single storage
`medium. A mechanism is provided to use existing formats during transition.
`
`The model assumes that the sender wishes to transfer a data object, such as a
`photographic image, text or perhaps a combination of many types. An envelope is
`provided around the object for information as to the type of data and the file format.
`Additional information, such as caption, news category or dateline also is included. The
`object itself is transferred, together with information regarding the size of the data.
`
`Thus ANY form of computerised data may be transferred, together with pertinent editorial
`and technical information.
`
`Older practice consisted primarily of rigidly formatted "headers• with a number of required
`fields denoting such things as story priority or category. The model here presented has
`relatively few required pieces of information. Instead, ·the information about the object
`consists of ·oataSets," each with its own identifier. Only those DataSets required for an
`application are mandatory. Other DataSets are optional and are utilised only when the
`provider deems it necessary to do so.
`
`IPTC-NAA Information Interchange Model Version No.2
`April1993
`
`Page3
`
`Ex. GOOG 1024
`
`

`

`1.8
`
`SCOPE
`
`This document defines:
`
`The envelope for information.
`
`The method by which existing standards for news information can be included.
`
`The records for additional information about the object.
`
`The data structure to be used for presentation of information.
`
`An application record to provide pertinent editorial information about the object to
`be transmitted.
`
`1.9
`
`1.9.1
`
`Guidelines for implementation.
`
`FIELD OF APPLICATION
`
`This document applies to the digital data distributed by news service carriers to their
`subscribers or interchanged between individual users.
`
`1.10
`
`RELATION TO OSI
`
`1.1 0.1
`
`This document describes the standardised representation of news information for the
`applications layer (Layer 7} of the ISO Open Systems Interconnection Model (OSI).
`NOTE: The association to OS! layers may be redefined as OSI connectionless
`application standards are developed.
`
`1.11
`
`MODEL DEVELOPMENT
`
`1.11.1
`
`The introduction of new DataSets (or dropping of old) in records 1, 2, 7, 8 and 9 will
`occur only after international concurrence.
`
`1.11.2 Records 3 through 6 will be managed by originators of the formats contained in record
`No.1.
`
`IPTC-NAA Information Interchange Model Version No. 2
`April1993
`
`Page4
`
`Ex. GOOG 1024
`
`

`

`2
`
`TERMS, DEFINITIONS AND NOTATION
`
`For the purpose of this recommendation, the following definitions apply:
`
`2.1
`
`Alphabetic; alphabetic, alphabetic character: An alphabetic character is member of
`- ..,.
`a set of characters representing letters of the alphabet.
`
`Example: In the ISO 646 character set, alphabetic characters are between 4/1 and 5/10
`(A through Z) and between 6/1 and 7/10 (a through z), all inclusive. Alphabetic
`characters are shown in this document enclosed in single quotation marks, e.g. 'a', 'T, 'u'.
`
`A series of alphabetic characters is shown in double quotation marks, e.g. "IPTC",
`"Berlin", "Paris".
`
`2.2
`
`binary number: A series of n data bits bn-1• bn-2 ••• bo where bn-1 is the highest
`order, or most significant bit and bois the lowest order, or least significant bit.
`
`As represented in this document. binary numbers always are expressed from left to right
`with the left-most bit the most significant bit and the right-most bit the least significant bit
`If the binary numbers are formed by multiple octets, the bits forming any octet are
`presumed to be less signifacant than those of any octet to the left and more significant
`than those of any octet to the right. For example, if two octets, numbered left to right as 1
`and 2, are taken together as a binary number, octet No. 1 will contain the most significant ·
`bits.
`
`Decimal Interpretation:
`The bit combinations are identified by notations of the form xxx ..• , where xxx ••. is a
`number in the range OOQ-infinity. The correspondence between the bits and their value
`is as follows:
`
`Bits
`Weight
`
`bn-1· bn-2 ••. bo
`2n-1. 2n-2 ••• 20
`
`2.3
`
`2.4
`
`2.5
`
`2.6
`
`The least significant bit. i.e. the bit of lowest value always is aligned with the least
`significant bit of the octet or other data frame containing it.
`
`CCITT: Comite Consultatif International Teh~graphique et Telephonique. An organisation
`of telephone and tel~raph providers with headquarters in Geneva, Switzerland. It is a
`division of the International Telecommunications Union (ITU), which in tum reports to the
`United Nations Organisation (UNO). All telecommunications administrations and
`recognised private common carriers belong to the organisation.
`
`The address is found in Appendix B.
`
`character: A member of a set of elements used for the organisation, control or
`representation of data.
`
`code table: A table showing the character allocated to each bit combination in a code.
`
`Coordinated Universal Time (UTC): The time scale defined by the Bureau
`International de I'Heure (International Time Bureau) that forms the basis of a coordinated
`dissemination of standard frequencies and time signals. The mismatch of ordering of
`characters between the name and initials is intentional.
`
`1, The source of this definition is Recommendation 460-2 of the Consultative
`Committee on International Radio (CCIR). CCIR has also defined the acronym for
`Coordinated Universal Time as UTC.
`
`IPTC-NAA Information Interchange Model Version No. 2
`April1993
`
`Page5
`
`Ex. GOOG 1024
`
`

`

`2.7
`
`2.8
`
`2.9
`
`2.1 0
`
`2.11
`
`2.12
`
`2.13
`
`2.14
`
`2.15
`
`2.16
`
`2, UTC is often (incorrectly) referred to as Greenwich Mean Time and appropriate
`signals are regularly broadcast.
`-
`
`day: A period of time of 24 hours starting at 0000 and ending at 2400 (which is equal to
`0000 the following day).
`
`editorial Information: Information primarily of interest to editors concerning the content
`of the object, such as date and place of creation, name of creator, etc. This information is
`contained in DataSets 2:xx of the Universal Application Record.
`
`editorial material: Data contained in the object that represents observations, ·opinions
`or analysis of the provider as opposed to statistical data, that simply reports data such
`as temperatures, sports scores, financial market prices, etc.
`
`graphic character: A member of a subset of a set of characters. The graphic character
`subset includes all characters that have visual representation, normally handwritten,
`printed or displayed, and that has a coded representation consistinQ of one or more bit
`combinations. Control codes or DEL (ISO 646 7/15) are not graph1c characters. The
`sets of alphabetic and numeric characters are subsets of the set of graphic characters.
`Graphic characters are shown in this document enclosed in single quotation marks, e.g.
`'*', 'T', '-'.A series of graphic characters are shown in double quotation marks, e.g.
`"IPTC-7901", "DuSSELDORF", "$1.99". Note that the visual rerresentation of a graphic
`character depends upon the character .set invoked at the time o evaluation.
`
`International Press Telecommunications Council (IPTC): An organisation of news
`agencies, newspapers and other news organisations, with headquarters in Windsor and
`formed for the establishment of news transmission standards and other activities for the
`common benefit of its members. (Also known as the Comite International des
`Telecommunications de Presse.)
`
`The address is found in Appendix B.
`
`International Organization for Standardization (ISO): An international body with
`headQuarters in Geneva, Switzerland. to co-ordinate· the work of national bodies such
`as ANSI, BSI or DIN. Also involved are IEEE, ECMA and the iPTC. ISO is broadly
`responsible for standards that operate over communications media. The mismatch of
`ordering of characters between the name and initials is intentionaL
`
`ISO 646: A coded set of characters based upon seven significant bits. ISO 646 has
`numerous national versions. Unless otherwise specified, all references herein contained
`are to the International Reference Version.
`·
`
`minute: A period of time of 60 seconds.
`
`month, calendar: A period of time resulting from the division of a calendar year in
`twelve sequential periods of time, each with a specific name and containing a specific
`number of days.
`
`NAA: The Newspaper Association of America was created on 1 June 1992 from the -
`American Newspaper Publishers Association (ANPA), the Newspaper Advertising
`Bureau (NAB), and six other newspaper associations. NAA represents nearly 2000
`newspapers in the United States, Canada, and around the world. The address is found
`in Appendix B.
`
`2.17
`
`numeric, numeric character: The textual representation by means of a specific
`character set of the binary values 0-9 in decimal notation. Numeric characters are a
`
`IPTC-NAA Information Interchange Model Version No. 2
`April1993
`
`PageS
`
`Ex. GOOG 1024
`
`

`

`subset of the set of graphic characters and are the characters '0', '1', '2', '3', '4', '5', '6', '7',
`'8'. '9'. In this document, numeric characters are enclosed in single quotation marks. Se(cid:173)
`ries of numeric characters are enclosed in double quotation marks, e.g. "23, "124".
`
`2.18
`
`2.19
`
`object: A collection of binary data, such as a photo, news graphic or text. that is the
`essence of the data to be transmitted.
`
`octet: A data frame of eight bits identified by b7, b6, b5, b4, b3, b2, b1 and bO where
`b7 is the highest order, or most significant bit and bO is the lowest order, or least
`significant bit.
`
`Unless otherwise specified, all references to bits of octets herein described are from left
`to right with the most significant bit on the left and the least significant bit on the right
`
`Character Definition by Chart Position:
`
`The bit combinations are identified by notations of the form xx/yy, where xx and yy are
`numbers in the range 00-15 or x/y where x andy are numbers in the range 0-7. The
`correspondence between the notations of the form xx/yy and the bit combination
`consisting of the bits b7-b0 are as follows:
`
`Bits
`Weight
`
`yy
`XX
`b7 b6 b5 b4 b3 b2 b1 bO
`2
`1
`1
`4
`8
`4
`2
`8
`
`Decimal Interpretation:
`
`The bit combinations are identified by notation of the form xxx, where xxx is a number in
`the range 000-255. The correspondence between the notations of the form xxx and the
`bit combination consisting of the bits b7 -bO are as follows:
`
`b7 b6 b5 b4 b3 b2 b1 bO
`~its
`4
`Weight 128 64 32 16 8
`2
`1
`
`220
`
`2.21
`
`2.22
`
`OSI model: OSI stands for Open Systems Interconnection, a term used to descnbe
`the agreed international standards by which open systems communicate. The OSI
`model, jointly defined by CCITT and the ISO, is an architectural model with seven
`.
`layers. Layers 5 through 7 (Session, Presentation, Application) concern the functions of
`interworking. The model is described in the ISO 7498 standard.
`
`second: A basic unit of measurement of time in the International System of Units (SI) as
`defined in ISO 31-1. -
`
`year, calendar: A cyclic period of time in a calendar that is required for one revolution of
`the earth around the sun.
`
`IPTC-NAA Information Interchange Model Version No. 2
`April1993
`·
`
`Page7
`
`Ex. GOOG 1024
`
`

`

`3
`
`3.1
`
`INFORMATION INTERCHANGE MODEL
`
`Functionality
`
`The Information Interchange Model consists of a number of records in a stmcture
`described below and which detail into five sub-layers, namely:
`•
`
`Envelope Record, DataSets in the range of 1 :xx
`
`Application Records, DataSets in the range 2:xx through 6:xx
`
`Pre-Object Descriptor Record, DataSets in the range 7:xx
`
`Object Record, DataSets in the range 8:xx
`
`Post-Object Descriptor Record, DataSets in the range 9:xx
`
`3.1.1
`
`Functionality of the Envelope Record
`
`3.1.1.1 This record is mandatory and envelops all types of objects, including data encapsulated
`in previously defined formats or headers, which themselves can be enveloped by the
`1 :xx record, thus enabling the use of older formats within the new model. Within record
`1 :xx, DataSets 1 :00, 1 :20, 1 :22, 1 :30, 1:40 and 1:70 are mandatory.
`
`3.1.1.2 File Formats are valid only by international agreement and are to be found in Appendix A
`to this document.
`
`3.1.1.3 The DataSets will permit a single link to be used for transmission of any type of data.
`The recipient may sort or buffer data temporarily so that the data may be sent to the
`appropriate subsystem.
`
`3.1.2
`
`Functionality of the Application Records
`
`3.1.2.1 Since the model is designed to encapsulate older formats, if required, some means must ·
`be provided to supply information that otherwise might not be provided in those older
`formats. Records 2:xx through 6:xx provide the capability to do this. Records 2:xx
`through 6:xx may optionally be used r~ardless of whether they duplicate any
`information that might be contained with•n the envelope record.
`
`3.1.3
`
`Functionality of the Pre-Object Descriptor Record
`
`3.1.3.1 R~cord 7 :xx is mandatory and provides a means of describing the size of the object.
`
`3.1.4
`
`Functionality of the Object Record
`
`3.1.4.1 Record 8:xx is mandatory and provides the actual data of the object contained in one or
`more DataSets. 'The object may be sent in one or more packets of DataSet 8:10,
`however, the DataSets must occur in sequential order without intervening DataSets.
`
`3.1.5
`
`Functionality of the Post-Object Descriptor Record
`
`3.1.5.1 Record 9:xx is mandatory and gives the size of the object file.
`
`IPTC-NAA Information Interchange Model Version No.2
`April1993
`
`PageS
`
`Ex. GOOG 1024
`
`

`

`4
`
`4.1
`
`4.1.1
`
`RECORDS
`
`Ordering of Records
`
`Records must be in numerical order. However, DataSets within a record need not be in
`numerical order, unless otherwise specified in the DataSet description.
`
`4.2
`
`Occurrence of Records
`
`If the provider elects to use Part II of the Model (Records No. 2 through No. 6), they
`should appear only in one iteration, e.g. there should be no more Record 2s after Record
`6.
`
`4.3
`
`Record Structure
`
`4.3.1
`
`Each record is composed of DataSets:
`
`Record
`DataSet 1 1 DataSet n-1 1 DataSet n
`
`4.4
`
`DataSets
`
`4.4.1
`
`4.4.2
`
`4.4.3
`
`4.4.4
`
`Each DataSet consists of a unique tag and a data field.
`
`Only a few DataSets have fixed length: all DataSets (except for record 8 containing the
`object) have maximum length, although in most cases it is not required to tiD that length.
`There is no end-of-DataSet marker.
`
`The tag identifier. is globally unique in the usage of records 1, 7, 8 and 9. In records 2
`through 6 different usages may occur for different types of data.
`
`There are two types of DataSets: standard and extended. A standard tag is utilised
`when the number of octets in the data field is equal to or less than 32761. Otherwise,
`the extended DataSet is used.
`
`Standard DataSet
`Tag I Data Field
`Tag I Oata Field J Data Field
`
`Extended DataSet
`
`Octet Count
`
`IPTC-NAA Information Interchange Model Version No.2
`April1993
`
`Page9
`
`Ex. GOOG 1024
`
`

`

`4.5
`
`Tags
`
`4.5.1
`
`General
`
`Tags may be of two types, depending upon whether the length of the data field is equal
`to or less than 32767 (decimal) octets in length.
`,.
`
`4.5.2
`
`The Standard DataSet Tag
`
`4.5.2.1
`
`If the length of the data field is equal to or less than 32767 octets in length, the tag is
`composed of five octets defined as follows.
`
`1
`Tag
`Marker
`
`Standard DataSet Tag
`5
`3
`2
`4
`Data Field
`Record DataSet
`Number Number Octet Count
`
`4.5.2.2 Octet 1 is the tag marker that initiates the start of a DataSet and is always position 1/12.
`
`4.5.2.3 Octet 2 is the binary representation of the record number. Note that the envelope record
`number is always 1, and that the application records are numbered 2 through 6, the pre(cid:173)
`object descriptor record is 7, the object record is 8, and the post-object descriptor record
`is 9.
`
`4.5.2.4 Octet 3 is the binary representation of the DataSet number.
`
`4.5.2.5 Octets 4 and 5, taken together, are the binary count of the number of octets in the
`following data field (32767 or fewer octets). Note that the value of bit 7 of octet 4 (most
`significant bit) always wm be 0.
`
`4.5.3
`
`The Extended DataSet Tag
`
`If the length of the data field is greater than 32767 octets, the tag ls composed of five
`octets defined as follows plus a field describing the length of the data field. The length of
`the Data Field Length Descriptor is provided in binary form in the 15 least significant bits
`of octets 4 and 5 taken together as a binary number. The value of the most significant
`bit (bit 7 of octet 4) always is 1 to flag that the extended DataSet is in effect. Otherwise,
`it is constructed the same as the Standard DataSet Tag.
`
`1
`Tag
`Marker
`
`Extended DataSet Tag
`2
`3
`5
`4
`6 •• n
`Record DataSet Length of Data Data Field
`Number Number
`Field Octet Octet Count
`Count Field
`
`Coded Character Set
`
`Record 1 :xx shall use coded character set ISO 646 International Reference Version or
`·
`ISO 4873 Default Version.
`
`4.6
`
`4.6.1
`
`4.7
`
`Envelope Record DataSets
`
`4.7.1
`
`Interpretation
`
`IPTC-NAA Information Interchange Model Version No. 2
`April1993
`
`Page 10
`
`Ex. GOOG 1024
`
`

`

`4. 7 .1.1 Some DataSets are described as "publishable." The information in such DataSets is
`expected to be composed in such a way that it can be printed or otherwise published
`"as-is."
`
`4.7.1.2 Some DataSets are described as "advisory." The information in such DataSets is
`expected to be human-readable. NO machine-readable information should be ~
`anticipated in these DataSets.
`
`4.7.2
`
`Encapsulation of Older Formats
`
`4.7 .2.1
`
`If a receiving system reads the file format as an existing header and content format such
`as IPTC7901, it may then interpret DataSet 8:10 (Object) as a switch to begin
`accepting data and mterpreting in that format. In such a case, that formars end of data
`signal would function as the signal to return to the envelope record level or to return
`control to lower layers, whichever is appropriate.
`
`Likewise, upon finding that the defined format has its own specific application records,
`the DataSets of records 2-6 will be interpreted in the. manner specific to that format.
`
`IPTC-NAA Information Interchange Model Version No. 2
`April 1993
`
`· Page 11
`
`Ex. GOOG 1024
`
`

`

`5
`
`IMPLEMENTATION GUIDELINES
`
`5.1
`
`5.2
`
`5.3
`
`5.4
`
`5.5
`
`5.6
`
`5.7
`
`5.8
`
`5.9
`
`This section is for the software engineer or programmer to use as a guideline when
`implementing this model.
`
`There is no end-of-DataSet marker. If the receiving system has not detected a new
`DataSet in the first octet following the end of the preceding data field, as described by
`the length, the system should assume an error and recover accordingly.
`
`An input programme should use the octet counts and not simply search for tag markers
`as delimiters because the fields can contain binary data that may be of the same value
`as the tag markers themselves.
`
`A programme should ignore a DataSet it does not recognise without rejecting the
`otherwise acceptable data or terminating the application programme. In this manner
`information that might be provided in new application records will not affect unmodified
`programmes.
`
`A programme encountering a DataSet with a repeated tag number should assume that it
`is "more or another of the same", e.g. as where a sequence of subfites (or sub-images)
`is encountered. If a repeated tag number is encountered for a DataSet defined as non(cid:173)
`repeatable, an error condition is assumed and handled without aborting the programme
`and without aborting data capture, i.e. the data of the first-encountered DataSet should
`be retained. The maximum number of repeats is not defined. Where DataSets are
`repeatable, only one piece of data should be included in that DataSet. For example, a
`DataSet defining news categories should include one category per DataSet
`
`A single transmission can include multiple objects of various types of data. If layer 5 or 6
`of the OSI model has not received an end-of-transmission, the receiving system should
`expect to receive a DataSet 1 :xx and subsequent DataSets.
`If the Envelope Record File Format DataSet (1 :20) identifies an existing format, such as
`NAA 89-3 (ANPA 1312) or IPTC 7901. the system may branch to Record 7:xx or to the
`header fields as identified in the existing format. Programmers are advised to look for the
`presence of the record No. 2 in order to take advantage of additional information that it
`might provide.
`
`If the File Format (1 :20) identifies a format that has no means of providing pertinent
`editorial information or whose information is insufficient, the sender is expected to use
`Record No. 2 as herein provided. Programmers should ensure that presence of Record
`No. 2, if not expected, does not cause-the programme to abort or reject otherwise
`acceptable data.
`
`Image Type (2:130) is designed to be used where the file formats utilised by the
`provider do not otherwise provide that information. If there is a conflict between Dataset
`2:130 and any DataSet in Record No.3 the Record No.3 DataSet takes precedence.
`
`DataSet 8:10. If the object is sub-divided and placed into multiple DataSets 8:10 there
`may be no correlation between the nature of the object and the sub-division structure.
`The division of the object into subfiles may be necessary because of equipment design
`constraints but has no relation to the object itself.
`
`IPTC-NAA Information Interchange Model Version No. 2
`April1993
`
`Page 12
`
`Ex. GOOG 1024
`
`

`

`6
`
`ENVELOPE RECORD
`
`DATASET
`NAME
`
`DESCRIPTION
`
`1:00 Model Version Mandatory, not repeatable, two octets.
`
`A binary number identifying the version of the Information Interchange
`Model, Part I, utilised by the provider. Version numbers are assigned by
`IPTCandNM.
`
`The version number of this record is two (2).
`
`1:05 Destination Optional, repeatable, maximum 1024 octets. consisting of sequentially
`contiguous graphic characters.
`
`This DataSet is to accommodate some providers who require routing
`information above the appropriate OSI layers.
`
`1:20 File Format Mandatory, not repeatable, two octets.
`
`A binary number representing the file format. The file format must be
`registered with IPTC or NM with a unique number assigned to it (see
`Appendix A). The information is used to route the data to the appropriate
`system and to allow the receiving system to perform the appropriate
`actions thereto.
`
`1:22 Rle Format Mandatory, not repeatable, two octets.
`Version
`
`A binary number representing the particular version of the File Format
`specified in 1 :20.
`.
`
`A list of File Formats, including version cross references. is included as
`Appendix A.
`·
`
`1:30 Service
`Identifier
`
`Mandatory. not repeatable. Up to 10 octets, consisting of graphic char(cid:173)
`acters.
`
`Identifies the-provider and product.
`
`1 :40 Envelope
`Number
`
`Mandatory, not repeatable, eight octets, consisting of numeric characters.
`
`The characters form a number that will be unique for the date specified in
`1 :70 and for the Service Identifier specified in 1 :30. If identical envelope
`numbers appear with the same date and with the same Service Identifier,
`records 2-9 must be unchanged from the original. This is not intended to
`be a sequential serial number reception check.
`
`IPTC-NM Information Interchange Model Version No. 2
`April1993
`·
`
`Page 13
`
`Ex. GOOG 1024
`
`

`

`1:50 Product I. D. Optional, repeatable. Up to 32 octets, consisting of graphic characters.
`
`Allows a provider to identify subsets of its overall service. Used to pro(cid:173)
`vide receiving organisation data on which to select, route, or otherwise
`handle data.
`
`1 :60 Envelope
`Priority
`
`Optional, not repeatable. A single octet, consisting of a numeric character.
`
`Specifies the envelope handling priority and not the editorial urgency
`(see 2:10, Urgency). '1' indicates the most urgent, '5' the normal urgency,
`and '8' the least urgent copy. The-numerals '9' and '0' are reserved for fu(cid:173)
`ture use.
`
`1 :70 Date Sent
`
`Mandatory, not repeatable. Eight octets, consisting of numeric characters.
`
`Uses the format CCYYMMDD (century, year, month, day) as defined in
`ISO 8601 to indicate year, month and day the service sent the material.
`
`Example:
`An entry of "19890412" indicates data sent on 12 April 1989.
`
`1 :80 Time Sent
`
`Optional, not repeatable, 11 octets, consisting of graphic characters.
`
`Uses the format HHMMSS±HHMM where HHMMSS refers to local hour,
`minute and seconds and HHMM refers to hours and minutes ahead (+) or
`behind (-) Universal Coordinated Time as described in ISO 8601. This
`is the time the service sent the material.
`
`·
`·
`Example:
`At 3:27 p.m. in New York in January it would be expressed as
`"152700-0500" as New York is five hours behind UTC. At the
`same moment in Paris, the time would be expressed as
`"212700+0100". In both instances the time is 20:27 (8:27p.m.)
`UTC. Midnight should be expressed as "240000 .. (with the appro
`priate offset from UTC).
`
`IPTC-NAA Information Interchange Model Version No. 2
`April 1993
`
`· Page 14
`
`Ex. GOOG 1024
`
`

`

`Optional, not repeatable, up to 32 octets, consisting of the escape
`1:90 Coded
`Character Set control character, and graphic characters.
`.
`
`One or more escape sequences for the announcement of the code
`extension facilities used in the data which follows, for the initial
`designation of the GO, G1, G2 and G3 graphic character set: and the
`initial invocation of the graphic set (7 bits) or the left-hand and the right(cid:173)
`hand graphic set (8 bits} and for the initial invocation of the CO (7 bits} or
`of the CO and the C1 control character sets (8 bits) in use for data fields
`in records 2-6 and 8. Follows the ISO 2022 standard. The recognised
`graphic repertoire and control function repertoire are listed in Appendix C.
`
`The announcement of the code extension facilities, if transmitted, must
`appear in this data set Designation and invocation of graphic and control
`function sets (shifting) may be transmitted anywhere where the escape
`and the other necessary control characters are permitted. However, it is
`recommended to transmit in this data set an initial designation and
`invocation, i.e. to define all designations and the shift status currently in
`use by transmitting the appropriate escape sequences and locking-shift
`functions.
`
`If 1 :90 is omitted, the default for records 2-6 and 8 is ISO 646 IRV (7
`bits} or ISO 4873 DV (8 bits}. Record 1 shall always use ISO 646 IRV
`or ISO 4873 DV respectively.
`
`IPTC-NAA Information Interchange Model Version No. 2
`April 1993
`
`Page 15
`
`Ex. GOOG 1024
`
`

`

`7
`
`PRE-OBJECT DESCRIPTOR RECORD
`
`7:10 Size Mode
`
`Mandatory, not repeatable, one octet.
`
`The octet is set to the binary value of 0 if the size of the object is not
`known and is set to 1 if the size of the object is known at the t;eginning
`of transfer.
`
`7:20 Max Subflle Mandatory, not repeatable.
`Size
`
`A binary number indicating the maximum size for the following subtile
`· DataSet{s).
`.
`
`The largest number is not defined, but programmers should provide at
`least for the largest binary number contained in four octets taken togeth(cid:173)
`er. If the entire object is to be transferred together within a single DataSet
`8:10, the number equals_the size of the object.
`
`7:90 Object Size Mandatory if Size Mode = 1 and not allowed if Size Mode = 0. Not
`Announced
`repeatable.
`
`A binary number representing the overall size of the object, expressed
`in octets, not including tags, if that size is known when transfer com(cid:173)
`mences.
`
`7:95 Maximum
`. Object Size
`
`Optional, not repeatable.
`
`A binary number used when object size is not known, indicating the
`largest size, expressed in octets, that the object can possibly have, not
`including tags.
`
`8
`
`OBJECT RECORD
`
`8~1 0 Subflle
`
`Mandatory. repeatable.
`
`Subtile DataSet containing the object itself. Subfiles must be sequential
`so that the subftles may be reassembled.
`
`9
`
`POST-OBJECT DE-SCRIPTOR RECORD
`
`9:10 Confirmed
`Object Size
`
`Mandatory, not repeatable.
`
`A binary number.
`
`Total size of the object, in octets, without tags. This number should
`equal the number in 7:90 if the size of the object is known and has been
`provided.
`
`IPTC-NAA Information Interchange Model Version No. 2
`April1993
`
`Page 16
`
`Ex. GOOG 1024
`
`

`

`IPTC-NAA INFORMATION INTERCHANGE MODEL PART II
`
`10
`
`APPLICATION RECORD
`
`10.1
`
`Functionality
`
`Part II provides details of an application record to provide pertinent editorial information
`about the object to be transmitted as described in Part I.
`
`10.2
`
`Implementation Guidelines
`
`Implementation guidelines as described in Part l·apply to Part II as well.
`
`10.3
`
`Uniqueness
`
`Use of Record No. 2 shall only be as described in this section. Any changes in
`DataSets will be by international concurrence.
`
`10.4
`
`Application Record No. 2
`
`All Record No. 2 DataSets herein described are optional. but if any are used DataSet 2:00 js
`mandatory. Some registered File Formats may regujre the mandatory use of some Record No. 2
`DataSets.
`
`2:00 Record
`-version
`
`Mandatory, not repeatable, two octets.
`
`A binary number identifying the version of the Information Interchange
`Model, Part II (Record 2:xx), utilised by the provider. Version numbers
`are assigned by IPTC and NAA.
`
`The version number of this record is two (2).
`
`2:05 Object Name Not repeatable, maximum 64 octets, consisting of graphic characters plus
`spaces.
`
`Used as a shorthand reference for the object. Changes to existinQ. data,
`such as updated stories or new crops on photos, should be identified in
`Edit Status.
`
`Examples:
`'Wall St."
`"Ferry