RFI Service Specification Draft Standard Version 2.0
17 November 2006
DGIWG Request For Information Service Specification Edition
2.0
Draft Standard
Document Identification:
Date:
Author:
Editor:
File Name:
Distribution:
Usage:
ST-DS-06-006-e2.0-RFI_Service_Spec
17 November 2006
S03 RFI Service Project Team
Mike Power, Canada
ST-DS-06-006-e2.0-RFI_Service_Spec.doc
For DGIWG members and any military agency with an
interest in RFI services.
This document is intended for review by DGIWG
members for consideration to move it to Draft Standard
status.
Copyright:
(C) Copyright DGIWG. This document is a derived work from a submission from Canada.
The source document is Copyright Canada Department of National Defence. Some rights
reserved - (CC) AttributionYou are free:
to copy, distribute, display, and perform/execute the work
to make derivative works
to make commercial use of the work
Under the following conditions:
(By:) Attribution. You must give the original author (DGIWG) credit.
For any reuse or distribution, you must make clear to others the license terms of this
work.
Any of these conditions can be waived if you get permission from the copyright holder DGIWG.
Your fair use and other rights are in no way affected by the above. This is a human-readable
summary of the Legal Code (the full license is available from Creative Commons
<http://creativecommons.org/licenses/by/2.0/>).
i
RFI Service Specification Draft Standard Version 2.0
Contents
17 November 2006
Page
i.
Preface ............................................................................................................................. vii
ii.
Submitting organizations .............................................................................................. vii
iii.
Document contributor contact points .......................................................................... vii
iv.
Revision history .............................................................................................................. vii
v.
Future work ..................................................................................................................... vii
Introduction .................................................................................................................................... 1
1
Scope ................................................................................................................................. 4
2
2.1
Conformance..................................................................................................................... 4
Conformance requirements............................................................................................. 4
3
Normative references ....................................................................................................... 5
4
Terms and definitions ...................................................................................................... 5
5
5.1
5.2
5.3
5.3.1
5.3.2
5.3.3
5.4
5.5
5.6
5.7
Symbols and abbreviated terms ..................................................................................... 6
Abbreviated terms ............................................................................................................ 6
UML notations ................................................................................................................... 7
UML model relationships ................................................................................................. 7
Associations ..................................................................................................................... 7
Generalization ................................................................................................................... 8
Instantiation/Dependency ................................................................................................ 8
Roles .................................................................................................................................. 8
UML model stereotypes ................................................................................................... 9
Package abbreviations ................................................................................................... 10
UML model/data dictionary relationships .................................................................... 10
6
6.1
6.1.1
6.1.2
6.1.3
6.2
6.2.1
6.2.2
6.2.3
6.2.4
6.3
6.3.1
6.3.2
6.4
6.5
Service Requirements .................................................................................................... 10
Actors and Associated Activities.................................................................................. 11
Originator ........................................................................................................................ 11
Manager (one or many) .................................................................................................. 11
Analyst (one or many) .................................................................................................... 12
Activity Diagrams, Services and Interfaces ................................................................. 13
RFI Submission and Processing Service ..................................................................... 13
RFI Change Service ........................................................................................................ 15
RFI Information Retrieval Service ................................................................................. 15
RFI Product Retrieval Service ....................................................................................... 17
Packages ......................................................................................................................... 17
Package and entity relationships.................................................................................. 17
Package descriptions ..................................................................................................... 17
Unified Modelling Language (UML) diagrams ............................................................. 17
Data dictionary ................................................................................................................ 18
7
7.1
7.2
7.3
7.4
7.5
Service Functionality ..................................................................................................... 18
Non-Digital Interoperability ........................................................................................... 18
Web Services-based Interoperability ........................................................................... 18
Limited Tracking and Monitoring .................................................................................. 18
Full Tracking and Monitoring ........................................................................................ 18
Implementation Options ................................................................................................ 19
8
8.1
Service Operations ......................................................................................................... 19
RFI Submission Service Specification ......................................................................... 20
ii
RFI Service Specification Draft Standard Version 2.0
17 November 2006
8.1.1
8.2
8.3
8.3.1
8.4
8.4.1
8.4.2
8.5
8.6
8.7
SubmitRFI Operation ...................................................................................................... 20
RFI Change Service Specification ................................................................................ 21
RFI Change Service specification ................................................................................. 21
ChangeRFIAttribute Operation...................................................................................... 21
RFI Attribute Retrieval Service specification ............................................................... 22
GetRFIAttribute Operation ............................................................................................. 22
SendRFIAttribute Operation .......................................................................................... 22
RFI Product Retrieval Service specification ................................................................ 23
GetRFIProduct Operation .............................................................................................. 23
SendRFIProduct Operation ........................................................................................... 23
9
Service Metadata ............................................................................................................ 24
10
10.1
10.2
10.3
10.4
Engineering Solutions ................................................................................................... 25
Engineering solution for non-digital interoperability ................................................. 25
Engineering solution for Web services-based interoperability ................................. 25
Engineering solution for full tracking and monitoring ............................................... 26
Abstract Test Suite ......................................................................................................... 26
Annex A. (normative) UML model .............................................................................................. A1
Annex B (normative) Data dictionary ........................................................................................ B1
1
1.1
1.2
1.3
1.3.1
1.3.2
1.3.3
1.4
1.5
1.6
Data dictionary overview ............................................................................................... B1
Name ................................................................................................................................ B1
Definition ......................................................................................................................... B1
Obligation/Condition ...................................................................................................... B1
Mandatory........................................................................................................................ B1
Conditional ...................................................................................................................... B1
Optional ........................................................................................................................... B2
Maximum Occurrence .................................................................................................... B2
Data Type......................................................................................................................... B2
Domain............................................................................................................................. B2
2
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
2.1.8
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
2.3
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
2.3.7
RFI service data dictionaries ......................................................................................... B3
RFI form general information ........................................................................................ B3
General information ....................................................................................................... B3
RF_Comment <<DataType>>......................................................................................... B7
RF_StatusCode <<CodeList>> ...................................................................................... B7
RF_MediaCode <<CodeList>> ....................................................................................... B8
RF_CountryCode <<CodeList>> ................................................................................... B8
RF_RFITypeCode <<Enumeration>> ............................................................................ B9
RF_RFICategoryCode <<Enumeration>> ..................................................................... B9
RF_PriorityCode <<Enumeration>> .............................................................................. B9
RFI form identification information .............................................................................. B9
Unique identifier information ........................................................................................ B9
Party identification information .................................................................................. B10
RFI destination identification information ................................................................. B10
Contact information ..................................................................................................... B11
Address information .................................................................................................... B11
Telephone information ................................................................................................. B12
RFI form information request information ................................................................. B12
Target information ........................................................................................................ B12
Reference system identifier information .................................................................... B13
Geographical location data information .................................................................... B14
Information request information ................................................................................. B14
Question information ................................................................................................... B15
Source consulted information..................................................................................... B15
RF_LocationTypeCode <<CodeList>> ....................................................................... B16
iii
RFI Service Specification Draft Standard Version 2.0
17 November 2006
2.3.8
2.3.9
2.4
2.4.1
2.4.2
2.4.3
2.4.4
2.5
2.5.1
2.5.2
2.5.3
2.5.4
2.5.5
2.6
2.6.1
2.7
2.7.1
2.7.2
2.7.3
2.7.4
2.7.5
2.7.6
2.8
2.8.1
2.8.2
2.8.3
Location Category<<CodeList>> ................................................................................ B16
RF_ReportingFrequencyCode <<CodeList>> ............................................................ B17
RFI form information product information ................................................................. B17
Product requirements information ............................................................................. B17
Product identity information ....................................................................................... B18
Product fusion source information ............................................................................ B18
RF_ContentTypeCode <<CodeList>> ......................................................................... B19
RFI form restrictions information ............................................................................... B19
Security information ..................................................................................................... B19
Product legal constraints information ....................................................................... B19
RF_ProtectMarkingCode <<CodeList>> ..................................................................... B20
RF_RestrictionCode <<CodeList>> ............................................................................ B20
RF_SecurityCaveatCode <<CodeList>> ..................................................................... B21
RFI changes information ............................................................................................. B21
Change RFI attribute information ............................................................................... B21
RFI attribute retrieval information .............................................................................. B22
Get attribute information ............................................................................................. B22
Send attribute information........................................................................................... B23
Result destination information.................................................................................... B23
Attribute information .................................................................................................... B24
RA_AttributeCode <<Enumeration>> ......................................................................... B24
RA_AttributeRequestStatusCode <<Enumeration>> ............................................... B24
RFI product retrieval information................................................................................ B24
Get product information .............................................................................................. B24
Send product information ............................................................................................ B25
RP_ProductRequestStatusCode <<Enumeration>> ................................................. B25
3
3.1
3.2
3.3
3.4
Externally referenced entities ..................................................................................... B27
Date ................................................................................................................................ B27
Time ............................................................................................................................... B27
DateTime........................................................................................................................ B27
Query ............................................................................................................................. B27
Annex C. (normative) Security issues ...................................................................................... C1
Annex D. (informative) RFI Service examples ......................................................................... D1
1
Canadian DND RFI Manager .......................................................................................... D1
2
NATO RFIMS ................................................................................................................... D2
Annex E. Considerations for Linking Subscription and Notification Services to the RFI
Service .......................................................................................................................................... E1
1
RFI Subscription Service ............................................................................................... E1
4
RFI Change and Notification Service ........................................................................... E2
5
5.1
5.2
RFI Subscription Service Specification ....................................................................... E3
SubscribeRFI Operation ................................................................................................ E3
AcknowledgeRFISubscription Operation .................................................................... E3
6
6.1
RFI Change and Notification Service Specification .................................................... E4
NotifyRFIChange Operation .......................................................................................... E4
7
7.1
7.2
7.3
7.4
7.5
RFI subscription information ........................................................................................ E7
General information ....................................................................................................... E7
Notification destination information ............................................................................. E7
Subscription to changes information ........................................................................... E8
Specific attribute information........................................................................................ E8
Acknowledge subscription information ....................................................................... E9
iv
RFI Service Specification Draft Standard Version 2.0
7.6
7.7
7.8
17 November 2006
RS_SubscriptionActionCode <<CodeList>> ............................................................... E9
RS_SubscriptionStatusCode <<CodeList>> .............................................................. E10
Notify RFI attribute information .................................................................................. E10
Annex F. Bibliography ................................................................................................................ F1
Figures
Page
Figure 1. Example of complex RFI processing with different communication mechanisms
in multiple levels of security. ................................................................................................ 2
Figure 2. UML notation .................................................................................................................. 7
Figure 3. UML roles ....................................................................................................................... 9
Figure 4. RFI Submission and Processing Activity diagram .................................................. 14
Figure 5. RFI Change Activity diagram ..................................................................................... 15
Figure 6. RFI Information Retrieval Activity diagram............................................................... 16
Figure 7. RFI Product Retrieval Activity diagram ..................................................................... 17
Figure 8. The general model of a service specification and its realization as a service port.
................................................................................................................................................ 19
Figure 9. RFI submission service specification ....................................................................... 20
Figure 10. RFI Change Service specification ............................................................................ 21
Figure 11. RFI Attribute Retrieval Service specification ......................................................... 22
Figure 12. RFI Product Retrieval Service specification ........................................................... 23
Figure 13. Services and service metadata ................................................................................ 24
Figure 14. Net-centric RFI management .................................................................................... 25
Figure 15. RFI Service packages................................................................................................ A1
Figure 16. RFI Form packages contained within the RFI Submission Service package ..... A1
Figure 17. Class composition of RF_RFIForm class ............................................................... A2
Figure 18. Class composition of RF_Comment, RF_UniqueID and RF_Target classes ...... A3
Figure
19.
Class
composition
of
RF_Contact,
RF_RFIDestinationID
and
RF_InformationRequest classes ........................................................................................ A4
Figure 20. Class composition of RF_ProductRequirements, RF_ProductIdentity,
RF_Security and RF_LegalConstraints classes................................................................ A5
Figure 21. Class composition of RC_ChangeRFI, RA_GetAttribute, RA_ResultDestination,
RA_Attribute and RA_SendAttribute classes .................................................................... A6
Figure 22. Class composition of RP_GetProduct and RP_SendProduct classes ................ A7
Figure 23. RFI Form general information .................................................................................. A8
Figure 24. RFI Form identification information ........................................................................ A9
Figure 25. RFI Form information request information ........................................................... A10
Figure 26. RFI Form information product information........................................................... A11
Figure 27. RFI Form restrictions information ......................................................................... A12
Figure 28. RFI change information .......................................................................................... A13
Figure 29. RFI attribute retrieval information ......................................................................... A14
Figure 30. RFI product retrieval information .......................................................................... A15
Figure 31. Date and time data types ........................................................................................ B27
Figure 32. RFI Submission activity diagram ............................................................................. E1
Figure 33. RFI Change and Notification activity diagram ........................................................ E2
Figure 34. RFI Subscription Service specification ................................................................... E3
Figure 35. RFI Change & Notification Service specification ................................................... E4
Figure 36. RFI subscription information ................................................................................... E5
Figure 37. RFI change and notification information ................................................................ E6
v
RFI Service Specification Draft Standard Version 2.0
Tables
17 November 2006
Page
Table 1. Category of RFI services under the Geographic Services Taxonomy ...................... 5
Table 2. Relationship between UML model and data dictionary ........................................... 10
vi
RFI Service Specification Draft Standard Version 2.0
i.
17 November 2006
Preface
This RFI Service Working Draft specification was developed by the Canadian Department of
National Defence and contributed to the Digital Geospatial Information Working Group for
international review as part of the process to make this specification an International Standard.
ii.
Submitting organizations
D Int Information Management, Canada Department of National Defence
iii.
Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors:
Person
Company
Phone
Email
Mike Power
Consultant to D +1 613 274 0961 [email protected]
Int IM, DND
Cynthia Fowler D Int IM, DND
[email protected]
iv.
Revision history
Editor
Description
27 Jan 05
Date
WD 1.2
M. Power
11 Oct 05
WD 1.5
M. Power
Mar 06
WD 1.6
M. Power
17 Nov 06 DS 2.0
M. Power
Initial document
The subscription and notification capabilities are removed
from this specification so that they may be handled by a
separate specification and thereby be used by other services
as required. The utility of linking/chaining an RFI service with
a subscription and notification service, especially for tracking
and monitoring RFIs, is explained. The various levels of
implementation of this specification are explained. For each
level of implementation the obligations for elements entities
and elements are provided. Examples of RFI systems were
updated. Numerous changes were made to the entities and
attributes of the data dictionaries.
Diagrams showing class relationships were added. A number
of minor changes were made such as clarification of
DateTime, distinguishing “country” from its use in address vs.
target, adding locationCategory code list, clarifying location
data, adding further information on requirements.
Added new information related to NATO RFIMS
v.
Release
Future work
As part of the process to move this standard from Working Draft to International Standard, it will
be important for future work to focus on getting a broad review of this specification from both the
military geospatial community and the military intelligence community. In addition, this
specification can be profiled to an implementation level by specifying HTML binding of the service
interfaces and XML encoding of the data.
vii
RFI Service Specification Draft Standard Version 2.0
17 November 2006
Introduction
A Request for Information (RFI) is a fundamental service offered by military intelligence agencies
to provide timely and relevant information to commanders and warfighters in response to their
unique information requirements that often cannot be readily fulfilled from local sources of
information. The objective of this RFI service specification is to enable RFIs to be exchanged and
processed between agencies in a military coalition environment at a moderate level of
interoperability. While NATO STANAG 2149 specifies a minimum set of attributes that compose
an RFI submission form, the RFI Service specification intends to extend this capability by
enabling certain RFI operations to be exchanged between agencies and by adding further key
attributes. The increase of interoperability of RFI processing between agencies that this
specification offers to support will result in an increase in the speed and efficiency of RFI
processing and an improvement in the quality of the RFI information product.
This document has been accepted by the DGIWG Service & Interfaces Technical Panel (SITP) as
a Draft Standard specification. It is anticipated that this specification will proceed through all the
DGIWG steps for specification maturity to a point where it can be released as a Final Approved
Standard for adoption by DGIWG member nations. This specification will be submitted by CAN
DND to NATO for consideration as a STANAG.
This specification assumes that each national intelligence unit has its own independent
procedures and capabilities to accept and process an RFI, and to create and return an
information product.
NATO STANAG 2149 already provides a starting point for the structure of data that can be
exchanged. This structure enables a basic level of interoperability. The service specification
expands on this structure and specifies formats. The approach is to add further attributes to
support submission, tracking, monitoring and processing. For instance, attributes are required to
indicate the status of the RFI and its parent and child relationships to other RFIs.
The service interface operations are constrained to those that will have a minimal impact on
existing RFI systems, whether manual or automated, but providing functionality that greatly
improves the submission, tracking, monitoring, and processing of RFIs that are being processed
by multiple intelligence units. This approach decouples RFI systems, allowing each to evolve
independently, while maintaining moderate interoperability.
A typical workflow in RFI processing is described. An RFI is initiated by a commander or
warfighter with an information requirement and sent to a pre-defined intelligence unit. This RFI is
reviewed, validated and resolved by a manager who is responsible for RFIs within this unit. One
or more measures can be taken by this manager. The manager may decide to a) send the RFI to
another manager within the vertical chain of command, b) send it horizontally to other units within
his organization or with other organizations, c) send it to an analyst under his command for
processing, and/or d) create one or more secondary RFIs and send these to managers and
analysts. For complex RFIs (see Fig. 1), it is possible for many intelligence units to become
involved creating an important need to be able track and monitor the primary RFI and its spawned
secondary RFIs until the primary RFI is fulfilled with an information product.
1
RFI Service Specification Draft Standard Version 2.0
Primary
Originator Agency A
Submits an
RFI
(Primary)
via Web
service
Returns
Information
Product 3
(fusion of 1
& 2) via
Web
service
Primary
Manager Agency B
Submits an
RFI
(Secondary)
via Fax
Returns
Information
Product 1
via Web
service
In this example, four different
agencies are involved in processing
the RFI. The originator in Agency A
can track the status of the RFI via
Web services to Agency B and D.
The status of processing in Agency C
is only known if Agency B requests
this information by phone or fax from
Agency C because Agency C has no
network capabilities. A similar
situation exists for Agency E because
Agency D does not have security
authorization to access the secure
network of Agency E.
17 November 2006
Secondary
Manager -Agency C
Returns
Information
Product 2 via
mailed hardcopy
Submits an RFI
(Secondary) via Web
service
Submits an
RFI
(Secondary)
via diskette
(air gap)
Secondary
Manager -Agency D
High level
security
Secondary
Manager -Agency E
Returns
Information
Product 1
via diskette
(air gap)
Figure 1. Example of complex RFI processing with different communication
mechanisms in multiple levels of security.
Exchanging information within the RFI Service specification is based on the following approach:
 A record of information will exist for each RFI to contain all information about the RFI,
where it came from, new RFIs that it has spawned, and its status.
 Any change of information to this RFI record will trigger a notification to anyone who has
subscribed to receive such a notification of change. This capability requires the RFI
Service to be linked to a separate subscription/notification service.
 Any authorized person can request information from the RFI record.
 If an RFI is passed onto another Manager, then a new RFI is created pointing back to the
RFI that created it.
 RFIs are tracked by searching down the RFI chain.
Based on this approach, the following types of information will be transmitted by RFI service
interface operations:
 RFI information,
 Changes to RFI information,
2
RFI Service Specification Draft Standard Version 2.0



17 November 2006
Requests for RFI information,
Requests for RFI products, and
RFI products.
When an RFI Service is linked to subscription/notification service, then further information can be
transmitted:
 Subscriptions to receive notification of these changes, and
 Notification of these changes,
3
RFI Service Specification Draft Standard Version 2.0
17 November 2006
Request For Information Service
1
Scope
The RFI Service specification is being developed by the military geospatial community to address
RFI processing that this community is readily engaged in; however, it is recognized that the
processing of RFIs will often go beyond the jurisdiction of geospatial intelligence to include any of
the other intelligence sectors. While this specification can be broadly used by all intelligence
sectors, it will retain a geospatial focus.
The RFI Service specification assumes that the client has been unsuccessful in exploiting readilyavailable local sources of information and conventional catalogue and library searches of external
sources, thereby necessitating the issuing of a Request for Information.
This specification does not set out to standardize RFI procedures and capabilities that are internal
to a military agency, but rather to standardize the interfaces to enable the exchange of RFI
information between agencies.
Service interfaces will be standardized at information and computational levels and not at
engineering and technology levels. That is, the specification will specify data structures and
formats for RFI exchange, and certain key operations that an exchange can invoke. It will not
specify the design of RFI systems, their technology platforms and their networks.
This specification does not have an objective to coordinate intelligence collection, analysis,
processing, production and dissemination activities, which may include trade-off analysis and
smarter workflows. This objective may be one that can be handled in a future specification, which
could work in conjunction with the RFI Service.
The RFI Service specification focuses on exchanging a minimal amount of information to enable
RFIs to be submitted, processed and tracked. Because it is not a tasking service, it will not
involve exchanging detailed technical information (i.e. information that an analyst may require
from a manager) about RFI processing and information products beyond that which can be
described in a narrative format. In this regard, the specification will be neutral to the types of
information processing and products.
2
2.1
Conformance
Conformance requirements
The ISO Standard 19119 for geographic information services [ISO 2003] provides the basis for
defining the services structure for the RFI Service. Three key terms are important:
 Service – A distinct part of the functionality that is provided by an entity through
interfaces.
 Interface – A named set of operations that characterize the behaviour of an entity.
 Operation – A specification of a transformation or query that an object may be called to
execute.
The processing of an RFI likely involves the execution of multiple services in the form of service
chaining. ISO 19119 defines three types of service chaining:
 Use defined (transparent) chaining where the user defines and controls the execution of
individual services
 Workflow-managed (translucent) services where a workflow service manages the
execution of the chain but allowing the user to monitor every step of execution.
4
RFI Service Specification Draft Standard Version 2.0

17 November 2006
Aggregate service (opaque chaining) where the user interacts with a single service but
has no awareness of the set of services that may execute behind.
The approach for the RFI Service specification focuses on opaque chaining.
The RFI Service specification conforms to a simple service architecture, whereby:
 Operations are modelled as request and response messages.
 Messages include one-way, event driven messages and two-way, synchronous requestresponse interactions.
 The control of the service is separated from the accessing of the data resulting from the
service.
The RFI Service Specification breaks down the RFI Service into four individual services. The
Geographic Services Taxonomy category is shown for each service.
Table 1. Category of RFI services under the Geographic Services Taxonomy
RFI Service
RFI Submission and
Service
RFI Change Service
Processing
RFI Information Retrieval Service
RFI Product Retrieval Service
Geographic Services Taxonomy category
Order
handling
service
under
geographic
model/information management services.
Order
handling
service
under
geographic
model/information management services.
Order
handling
service
under
geographic
model/information management services.
Product
access
service
under
geographic
model/information management services.
Conformance to this RFI Service specification can be established for profiles of certain levels of
interoperability and functionality, which are defined in Section 7 Service Functionality. This
specification does not include profiles or the conformance test requirements for these profiles.
3
Normative references
The following referenced documents are indispensable for the application of this International
Standard. For dated references, only the edition cited applies. For undated references, the latest
edition of the referenced document (including any amendments) applies.
ISO. 2002. ISO 19115 Geographic information – Metadata. ISO/TC 211 Geographic
information/Geomatics Final Draft Information Standard, 17 December 2002.
ISO. 2003. ISO 19119 Geographic information – Services. ISO/TC 211 Geographic
information/Geomatics International Standard, 26 November 2003.
NSA. 2003. NATO Standardization Agency (NSA) Standardization Agreement (STANAG)
Subject: Request For Information. STANAG No. 2149 (Edition 6), 23 July 2003.
4
Terms and definitions
For the purposes of this Working Draft Specification, the following terms and definitions apply.
4.1
client
software component that can invoke an operation from a server
4.2
coordinate reference system
coordinate system which is related to the real world by a datum [ISO 19111]
5
RFI Service Specification Draft Standard Version 2.0
4.3
17 November 2006
coordinate system
set of mathematical rules for specifying how coordinates are to be assigned to points [ISO 19111]
4.4
distribution transparency
property of hiding from a particular user the potential behaviour of some parts of a distributed
system [ISO/IEC 10746-2]
4.5
geographic information
information concerning phenomena implicitly or explicitly associated with a location relative to the
Earth
4.6
interface
named set of operations that characterize the behaviour of an entity
4.7
interoperability
capability to communicate, execute programs, or transfer data among various functional units in a
manner that requires the user to have little or no knowledge of the unique characteristics of those
units [ISO 2382-1]
4.8
operation
specification of a transformation or query that an object may be called to execute
4.9
request
invocation of an operation by a client
4.10 response
result of an operation returned from a server to a client
4.11 service
distinct part of the functionality that is provided by an entity through interfaces
4.12 service chain
sequence of services where, for each adjacent pair of services, occurrence of the first action is
necessary for the occurrence of the second action
4.13 server
a particular instance of a service
4.14 workflow
automation of a business process, in whole or in part, during which document, information or
tasks are passed from one participant to another for action, according to a set of procedural rules.
5
5.1
Symbols and abbreviated terms
Abbreviated terms
CCIRM
CWID
DCP
DGIWG
Collection Coordination and Intelligence Requirements Management
Coalition Warrior Interoperability Demonstrator
Distributed Computing Platform
Digital Geospatial Information Working Group
6
RFI Service Specification Draft Standard Version 2.0
DTD
EJB
GIS
HTTP
ISO
J2EE
JWID
LTIOV
PHP
RFI
SOAP
SITP
SQL
STANAG
UML
URI
URL
XML
5.2
17 November 2006
Document Type Definition
Enterprise Java Beans
Geographic Information System
Hypertext Transfer Protocol
International Organization for Standardization
Java 2 Enterprise Edition with EJB
Joint Warrior Interoperability Demonstrator
Last Time Information Of Value
PHP Hypertext Processor
Request for Information
Simple Object Access Protocol
Service & Interfaces Technical Panel (DGIWG)
Structured Query Language
Standard Agreement (NATO)
Unified Modelling Language
Uniform Resource Identifier
Uniform Resource Locator
Extensible Markup Language
UML notations
The diagrams that appear in this International Standard are presented using the Unified Modelling
Language (UML) static structure diagram with the ISO Interface Definition Language (IDL) basic
type definitions and the UML Object Constraint Language (OCL) as the conceptual schema
language. The UML notations used in this International Standard are described in Figure 2.
Figure 2. UML notation
5.3
UML model relationships
5.3.1 Associations
An association is used to describe a relationship between two or more classes. UML defines
three different types of relationships, called association, aggregation and composition. The three
7
RFI Service Specification Draft Standard Version 2.0
17 November 2006
types have different semantics. An ordinary association shall be used to represent a general
relationship between two classes. The aggregation and composition associations shall be used to
create part-whole relationships between two classes. The direction of an association must be
specified. If the direction is not specified, it is assumed to be a two-way association. If one-way
associations are intended, the direction of the association can be marked by an arrow at the end
of the line. An aggregation association is a relationship between two classes in which one of the
classes plays the role of container and the other plays the role of a containee. A composition
association is a strong aggregation. In a composition association, if a container object is deleted,
then all of its containee objects are deleted as well. The composition association shall be used
when the objects representing the parts of a container object cannot exist without the container
object.
5.3.2 Generalization
A generalization is a relationship between a superclass and the subclasses that may be
substituted for it. The superclass is the generalized class, while the subclasses are specified
classes.
5.3.3 Instantiation/Dependency
A dependency relationship shows that the client class depends on the supplier class/interface to
provide certain services, such as:
 Client class accesses a value (constant or variable) defined in the supplier
class/interface;
 Operations of the client class invoke operations of the supplier class/interface;
 Operations of the client class have signatures whose return class or arguments are
instances of the supplier class/interface.
An instantiated relationship represents the act of substituting actual values for the parameters of
a parameterized class or parameterized class utility to create a specialized version of the more
general item.
5.4
Roles
If an association is navigable in a particular direction, the model shall supply a “role name” that is
appropriate for the role of the target object in relation to the source object. Thus in a two-way
association, two role names will be supplied. Figure 3 represents how role names and
cardinalities are expressed in UML diagrams.
8
RFI Service Specification Draft Standard Version 2.0
17 November 2006
Figure 3. UML roles
5.5
UML model stereotypes
A UML stereotype is an extension mechanism for existing UML concepts. It is a model element
that is used to classify (or mark) other UML elements so that they in some respect behave as if
they were instances of new virtual or pseudo metamodel classes whose form is based on existing
base metamodel classes. Stereotypes augment the classification mechanisms on the basis of the
built-in UML metamodel class hierarchy. Below are brief descriptions of the stereotypes used in
this International Standard, for more detailed descriptions consult ISO/TS 19103.
In this International Standard the following stereotypes are used:
a. <<Type>> class used for specification of a domain of instances (objects), together with
the operations applicable to the objects. A type may have attributes and associations.
b. <<Enumeration>> data type whose instances form a list of named literal values. Both the
enumeration name and its literal values are declared. Enumeration means a short list of
well understood potential values within a class.
c. <<DataType>> a descriptor of a set of values that lack identity and whose operations do
not have side effects. Data types include primitive pre-defined types and user-definable
types. Pre-defined types include numbers, string, and time. User-definable types include
enumerations.
d. <<CodeList>> used to describe a more open enumeration. <<CodeList>> is a flexible
enumeration. Code lists are useful for expressing a long list of potential values. If the
9
RFI Service Specification Draft Standard Version 2.0
17 November 2006
elements of the list are completely known, an enumeration should be used; if the only
likely values of the elements are known, a code list should be used.
e. <<Union>> describes a selection of one of the specified types. This is useful to specify a
set of alternative classes/types that can be used, without the need to create a common
super-type/class.
f. <<Abstract>> class (or other classifier) that cannot be directly instantiated. UML notation
for this to show the name in italics.
g. <<Metaclass>> class whose instances are classes. Metaclasses are typically used in the
construction of metamodels. A metaclass is an object class whose primary purpose is to
hold metadata about another class.
h. <<Interface>> named set of operations that characterize the behaviour of an element.
i. <<Package>> cluster of logically related components, containing sub-packages.
j. <<Leaf>> package that contains definitions, without any sub-packages.
5.6
Package abbreviations
Two letter abbreviations are used to denote the package that contains a class. Those
abbreviations precede class names, connected by a “_”. A list of those abbreviations follows:
RF
RC
RA
RP
5.7
RFI Form
RFI Change
RFI Attribute Retrieval
RFI Product Retrieval
UML model/data dictionary relationships
Table 2 illustrates the relationship between the terminology of the UML models and the data
dictionary.
Table 2. Relationship between UML model and data dictionary
UML Model
Package
Generalized Class
Specified Class
Class
Attribute
Association
6
Data Dictionary
Section
Entity
Entity
Entity
Element
Element
Service Requirements
The requirement for an RFI Service Specification originates from a series of Joint Warrior
Interoperability Demonstrator (JWID) exercises, where Canada undertook the development of the
Intelligence Collection Environment Common Access Portal (ICECAP), which included the RFI
Manager component. Coalition operation staff tested the RFI Manager within various operational
scenarios offered with the JWID exercises. Testing included the capability of transmitting RFI
information between RFI systems in a distributed, net-centric environment. This transmission was
enabled by open, service interfaces. Reviews provided information for a continual refinement of
the RFI capability to a point where Canada decided to produce an open specification for an RFI
service, which would allow multiple RFI systems, beyond those involved in the JWID exercises, to
interoperate through adherence to the interface specifications. While this specification intends to
serve national requirements, these requirements stipulate interoperability within coalition
environments. Hence, Canada has contributed this specification to the international military
10
RFI Service Specification Draft Standard Version 2.0
17 November 2006
community via DGIWG so that this community may consider this specification appropriate for use
in all military coalitions and adopt this specification as an International Standard.
In this specification, the operational requirements for an RFI Service are depicted by actors and
the activities that these actors may undertake. This section introduces three actors – Originator,
Manager and Analyst. Only the Originator and Manager are important for the RFI Service
specification because Analysts only work internally within RFI systems and are not exposed in
any way in the interfaces between RFI systems. Analyst activities are shown here to indicate the
workflows that may occur both within an RFI system and between systems, thereby providing a
more complete description of all the processes that are needed to execute an RFI. In addition, not
all the activities shown in this section may form part of the RFI Service specification. For instance,
subscription and notification activities are independent of this specification but can be important to
enhance an RFI Service implementation with more powerful tracking and monitoring capabilities.
6.1
Actors and Associated Activities
6.1.1 Originator
This actor plays the role of initiating an RFI. This initial RFI will be referred to as the primary RFI.
There is only one Originator for a primary RFI. The following activities are typical of those that can
be conducted by the Originator:












Create primary RFI
Send primary RFI (as a new attribute set)
Change RFI attribute (such as modify and append)
Send changed RFI attribute
Receive changed RFI attribute
Get RFI attribute (note that status is an attribute; operates as a search/query)
Subscribe to receive notification of RFI attribute change (examples are status,
acknowledgement of receipt)
Receive subscription acknowledgement
Receive RFI attribute change notification
Receive RFI attribute (Such as NATO STANAG 2149 attributes; could be one or many
attributes for one or many RFIs)
Get RFI product
Receive RFI product
6.1.2 Manager (one or many)
A Manager is an actor who plays the role of managing all aspects of processing an RFI. One or
many Managers can be involved in the processing of a primary RFI and any spawned secondary
RFIs. One manager will form the interface with the Originator. The following activities are typical
of those that can be conducted by a Manager:







Receive RFI (primary or secondary; can be treated as a request, escalation, or task)
Receive changed RFI attribute
Review and validate the RFI
Resolve RFI (Decompose the request. Determine appropriate analysis)
Create RFI (secondary)
Send RFI (secondary; normally as a request or escalation to another Manager, or as a
task to an Analyst)
Change RFI attribute (such as modify and append)
11
RFI Service Specification Draft Standard Version 2.0



















17 November 2006
Send changed RFI attribute
Receive changed RFI attribute
Get RFI attribute (status is an attribute)
Subscribe to receive notification of RFI attribute change
Receive subscription acknowledgement
Receive RFI attribute change notification
Receive request for RFI attribute
Receive subscription for notification of RFI attribute change
Process subscription for notification of RFI attribute change
Add subscription to database
Send subscription acknowledgement
Send attribute change notification
Receive attribute change notification
Get RFI product
Receive request for RFI product
Receive RFI product
Evaluate the RFI product (This activity determines how well the product meets the RFI)
Compile RFI product (This activity may create a single product from multiple products
and this may involve some form of data fusion. Deconfliction between multiple products
may also occur.)
Send RFI product
6.1.3 Analyst (one or many)
An Analyst is an actor whose role is to process an RFI by attempting to create an information
product that satisfies the RFI. This RFI processing may require the Analyst to spawn further
secondary RFIs for himself or other Analysts in his unit to act upon. An Analyst may be tasked
directly by an RFI, or a Manager may decompose an RFI into secondary RFIs that serve as
Analyst tasks. The following activities can be conducted by an Analyst:

















Receive RFI (usually treated as a task)
Process RFI
Change RFI attribute (such as modify and append)
Send changed RFI attribute
Receive changed RFI attribute
Get RFI attribute (status is an attribute)
Subscribe to receive notification of RFI attribute change
Receive RFI attribute change notification
Receive RFI attribute
Create secondary RFI
Send secondary RFI (normally as a task to an Analyst)
Create RFI product
Subscribe to receive notification of RFI attribute change
Receive subscription acknowledgement
Send attribute change notification
Receive attribute change notification
Get RFI product
12
RFI Service Specification Draft Standard Version 2.0



6.2
17 November 2006
Receive request for RFI product
Receive RFI product
Send RFI product
Activity Diagrams, Services and Interfaces
Activity diagrams show the connectivity between activities organized by actors. While most of this
connectivity will occur internally within the actor’s unit, there are some that occur across units – it
is these connections that are the focus of the RFI service specification. Four RFI services, each
with their own set of operations are proposed:
 RFI Submission and Processing Service
 RFI Change Service
 RFI Information Retrieval Service
 RFI Product Retrieval Service
An activity diagram is presented for each service. The RFI service interface operations are shown
in bold italics for connections that occur across units. In essence, these connections occur at the
interfaces:
 Originator – Manager. Connections crossing the boundary between Originator and
Manager
 Originator – Analyst. Connections crossing the boundary between Originator and Analyst
 Manager – Manager. Only one Manager column is shown on these diagrams because
Manager-to-Manager connections are recursive. The transmission of information
between Managers is highlighted by interface operations.
 Analyst – Analyst connections occur but these are only internal within units, hence
outside the focus of this specification.
6.2.1 RFI Submission and Processing Service
This service has the following two types of operations and these are depicted on the activity
diagram (Fig. 4)
 SubmitRFI: Send RFI (primary or secondary) – Receive RFI (primary or secondary)
 SendRFIProduct: Send RFI product – Receive RFI product
13
RFI Service Specification Draft Standard Version 2.0
Originator
Manager
17 November 2006
Analyst
Create
Primary RFI
Send Primary
RFI
SubmitRFI
Receive RFI
Receive RFI
Review and
Validate RFI
Review and
Validate RFI
Resolve RFI
Resolve RFI
Create RFI
Create RFI
Send RFI
Send RFI
Process RFI
Create RFI
Product
Receive RFI
Product
SendRFIProduct
Send RFI
Product
Evaluate RFI
Product
Compile RFI
Product
Receive RFI
Product
SendRFIProduct
Send RFI
Product
Figure 4. RFI Submission and Processing Activity diagram
14
RFI Service Specification Draft Standard Version 2.0
17 November 2006
6.2.2 RFI Change Service
This service has one type of operation as depicted on the activity diagram (Fig. 5):
 ChangeRFIAttribute: Send changed RFI attribute – Receive changed RFI attribute
Originator
Manager
Change RFI
Attribute
Change RFI
Attribute
Send Changed
RFI Attribute
Send Changed
RFI Attribute
ChangeRFIAttribute
ChangeRFIAttribute
Receive Changed
RFI Attribute
Process Changed
RFI Attribute
Analyst
Change RFI
Attribute
Send Changed
RFI Attribute
Receive Changed
RFI Attribute
Process Changed
RFI Attribute
Figure 5. RFI Change Activity diagram
6.2.3 RFI Information Retrieval Service
This service has the following two types of operations and these are depicted on the activity
diagram (Fig. 6):
 GetRFIAttribute: Get RFI attribute – Receive request for RFI attribute
 SendRFIAttribute: Send RFI Attribute – Receive RFI Attribute
15
RFI Service Specification Draft Standard Version 2.0
Originator
Manager
Get RFI
Attribute
Get RFI
Attribute
GetRFIAttribute
17 November 2006
Analyst
Get RFI
Attribute
GetRFIAttribute
Receive Request
for RFI Attribute
Process RFI
Attribute
Send RFI
Attribute
SendRFIAttribute SendRFIAttribute
Receive RFI
Attribute
Receive RFI
Attribute
Receive RFI
Attribute
Figure 6. RFI Information Retrieval Activity diagram
16
RFI Service Specification Draft Standard Version 2.0
17 November 2006
6.2.4 RFI Product Retrieval Service
This service has the following two types of operations and these are depicted on the activity
diagram (Fig. 7):
 GetRFIProduct: Get RFI product – Receive request for RFI product
 SendRFIProduct: Send RFI product – Receive RFI product
Originator
Manager
Get RFI
Product
Get RFI
Product
GetRFIProduct
Analyst
Get RFI
Product
GetRFIProduct
Receive Request
for RFI Product
Process Request
for RFI Product
Send RFI
Product
SendRFIProduct
Receive RFI
Product
SendRFIProduct
Receive RFI
Product
Receive RFI
Product
Figure 7. RFI Product Retrieval Activity diagram
6.3
Packages
6.3.1 Package and entity relationships
See Annexes A and B.
6.3.2 Package descriptions
See Annexes A and B.
6.4
Unified Modelling Language (UML) diagrams
Annex A provides the RFI service schemas in the form of Unified Modelling Language (UML)
diagrams. These diagrams, in conjunction with the data dictionary presented in Annex B, serve to
fully define the total abstract model for the RFI services.
17
RFI Service Specification Draft Standard Version 2.0
6.5
17 November 2006
Data dictionary
Annex B contains the element and entity definitions for the RFI service schemas. This dictionary,
in conjunction with the diagrams presented in Annex A, serve to fully define the total abstract
model for RFI services. Code lists and their values provided in this International Standard are
normative.
7
Service Functionality
This section describes the functionality of the RFI service at certain levels of interoperability and
functionality. Levels of interoperability and functionality may be mixed in a coalition environment;
therefore, they are not mutually exclusive.
7.1
Non-Digital Interoperability
This level of interoperability is one that is paper form-based where forms can be transferred by
paper, fax or as email attachments. All information on the forms must be manually interpreted and
processed. The major constraint for implementing the RFI Service specification at this level of
interoperability is the volume of data that can be reasonably handled manually.
7.2
Web Services-based Interoperability
This level of interoperability is fully Web services based, where all parties have fully automated
service interfaces. The RFI Service specification is written to accommodate this level of
interoperability.
7.3
Limited Tracking and Monitoring
When the RFI Service specification is implemented alone, tracking and monitoring of the status of
RFI processing and products across RFI systems are limited. Tracking capabilities can be
provided in the following ways:
 All RFIs hold the identity of its Primary Originator as a mandatory obligation. Tracking is
then possible from any RFI back to the person or agency that created the original RFI.
 An RFI can optionally hold the identity of its Secondary Originator, an intermediate
person or agency that creates a Secondary RFI – one that is spawned from another RFI.
Tracking is then possible to the direct person or agency that created this Secondary RFI.
 An RFI can optionally hold the identity of a parent RFI if it was created by this parent.
Tracking to an RFI’s direct parent is then possible.
 An RFI can optionally hold the identity of one or more child RFIs that it creates. Tracking
to an RFI’s direct children is then possible.
 An RFI can optionally provide an indication whether it is a Primary or Secondary RFI.
This information would help in tracking by indicating that the RFI was created by another
RFI.
 An RFI can optionally hold the identity of the Secondary Manager – the Manager that is
responsible for the Secondary RFI. Tracking is then possible to this Manager.
7.4
Full Tracking and Monitoring
Full tracking and monitoring of the status of RFI processing and its products across RFI systems
can be achieved when the RFI Service specification is implemented in the following manner:
 Implementation of all optional entities as listed in Section 7.3
 Linkage with an independent subscription and notification service in manner similar to
that described in Annex E.
18
RFI Service Specification Draft Standard Version 2.0
7.5
17 November 2006
Implementation Options
The RFI Submission and Processing Service forms the core of this specification and is mandatory
for implementation by any RFI system wishing to conform to this specification at a minimum level.
The remaining services – RFI Change, RFI Information Retrieval and RFI Product Retrieval – are
optional and depend on the functionality that the RFI system wishes to support.
8
Service Operations
Figure 8 shows the general structure of a service specification on the left, which addresses the
Computational Viewpoint. The Engineering Viewpoint reflects this specification from an
engineering perspective where it is bound to a specific Distributed Computing Platform (DCP) to
be realized as a service with service ports.
Figure 8. The general model of a service specification and its realization as a service port.
The UML notation for operations according to ISO 19103 is:
[<<stereotype>>] [visibility] name [(parameter-list)] [:return-type] [{property-string}]
[(parameter-list element)] ::=
[direction] name : type [= default-value]
[direction] ::= in | out | inout
19
RFI Service Specification Draft Standard Version 2.0
8.1
17 November 2006
RFI Submission Service Specification
Figure 9. RFI submission service specification
8.1.1 SubmitRFI Operation
The SubmitRFI Operation submits an RFI Form. The data that is transmitted by this operation is
described in the data dictionaries in Annex B, Sections 2.1-2.5. The UML notation for this
operation is:
+submitRFI (in RF_RFIForm):
There is no return type.
20
RFI Service Specification Draft Standard Version 2.0
8.2
17 November 2006
RFI Change Service Specification
RC_Service
+name [1] = RFIChangeService
+opModel
RC_Interface
+typeName
+changeRFIAttribute() : RC_ChangeRFI
RC_ChangeRFIAttributeOperation
+operationName [1] = changeRFIAttribute
Figure 10. RFI Change Service specification
8.3
RFI Change Service specification
8.3.1 ChangeRFIAttribute Operation
The ChangeRFIAttribute Operation sends a parameter set. The data that is transmitted by this
operation is described in the data dictionary in Annex B, Section 2.7.1. The UML notation for this
operation is:
+changeRFIAttribute (in RC_ChangeRFI):
There is no return type.
21
RFI Service Specification Draft Standard Version 2.0
8.4
17 November 2006
RFI Attribute Retrieval Service specification
RA_Service
+name [1] = RFIAttributeRetrievalService
+opModel
RA_Interface
+typeName
+getRFIAttribute() : RA_GetAttribute
+sendRFIAttribute() : RA_SendAttribute
RA_GetRFIAttributeOperation
+operationName [1] = sendRFIAttribute
RA_SendRFIAttributeOperation
+operationName [1] = getRFIAttribute
Figure 11. RFI Attribute Retrieval Service specification
8.4.1 GetRFIAttribute Operation
The GetRFIAttribute Operation sends a parameter set. The data that is transmitted by this
operation is described in the data dictionary in Annex B, Section 2.8.1. The UML notation for this
operation is:
+sendRFIAttribute (in RA_SendAttribute):
There is no return type.
8.4.2 SendRFIAttribute Operation
The SendRFIAttribute Operation sends a parameter set. The data that is transmitted by this
operation is described in the data dictionary in Annex B, Section 2.8.2. The UML notation for this
operation is:
+getRFIAttribute (in RA_GetAttribute):
There is no return type.
22
RFI Service Specification Draft Standard Version 2.0
8.5
17 November 2006
RFI Product Retrieval Service specification
RP_Service
+name [1] = RFIProductRetrievalService
+opModel
RP_Interface
+typeName
+getRFIProduct() : RP_GetProduct
+sendRFIProduct() : RP_SendProduct
RP_GetRFIProductOperation
+operationName [1] = getRFIProduct
RP_SendRFIProductOperation
+operationName [1] = sendRFIProduct
Figure 12. RFI Product Retrieval Service specification
8.6
GetRFIProduct Operation
The GetRFIProduct Operation sends a parameter set. The data that is transmitted by this
operation is described in the data dictionary in Annex B, Section 2.9.1. The UML notation for this
operation is:
+getRFIProduct (in RP_GetProduct):
There is no return type.
Metadata about information products produced from an RFI are to be handled by catalogue
services and are outside the scope of the RFI Service specification.
8.7
SendRFIProduct Operation
The SendRFIProduct Operation sends a parameter set. The data that is transmitted by this
operation is described in the data dictionary in Annex B, Section 2.9.2. The UML notation for this
operation is:
+sendRFIProduct (in RP_SendProduct):
There is no return type.
23
RFI Service Specification Draft Standard Version 2.0
9
17 November 2006
Service Metadata
Service metadata records can be managed and searched using a catalogue service as is done
for dataset metadata. A schema is provided in ISO 19119 for describing a service. The metadata
elements for a service provide sufficient information to allow a client to invoke the service based
on the metadata record. In order to place the Service Metadata in context three types of entities
are described:
 Service Instance: a service instance is the service itself, hosted on a specific set of
hardware and accessible over a network.
 Service Metadata: a service metadata record describes a service instance including a
description of the services operations and an "address" to access the specific service
instance.
 Service Type: in some cases, a service metadata record will describe a service instance
that is of a "well known type". By well-known type, it is meant that the service conforms to
a published definition of a service type, i.e., a platform-specific service specification.
Some clients will be able to access only services of well-known type. A user could search
the service metadata catalogue to find instances of a specific well-known service type. A
service registry is defined to be the service that provides details on service types.
Figure 13 compares the structure of a service specification with service metadata. A service
specification describing a service type includes an aggregation of interfaces. Interfaces are an
aggregation of operations. The aggregation of operations in an interface, and the definition of
interface, is for the purpose of software reusability. To describe a service instance, the
aggregation associated with an interface is not needed. A service instance is described by
SV_ServiceIdentification and SV_OperationMetadata. SV_ServiceIdentification describes the
functionality provided by the service. SV_OperationMetadata describes the operations by which
the service instance can be invoked.
Figure 13. Services and service metadata
24
RFI Service Specification Draft Standard Version 2.0
17 November 2006
When the RFI Service specification is implemented as an operational service, service metadata
will need to be developed and made available to a catalogue service. RFI systems can discover
the RFI services of other systems and determine the capabilities of these services by accessing a
service metadata document. An RFI system could use a getCapabilities operation as described in
the OGC Web Services Common Specification Version 1.0 [OGC 2005] or similar specification.
10 Engineering Solutions
This section describes various approaches that can be used to engineer implementations of the
RFI Service specification.
10.1 Engineering solution for non-digital interoperability
This engineering approach passes RFI information as a text document either by fax or as an
email attachment. Because this approach is manually-intensive, the amount of information may
be need to be stripped down to only mandatory data.
10.2 Engineering solution for Web services-based interoperability
The RFI Service specification is written to accommodate fully automated interfaces between RFI
systems. Fig. 14 depicts the collaboration of multiple coalition RFI systems over coalition
networks using Web services.
Figure 14. Net-centric RFI management
The engineering approach is based on the HTTP request-response model, where a client sends a
request to a server using HTTP and expects to receive a response message. Request and
25
RFI Service Specification Draft Standard Version 2.0
17 November 2006
response messages are encoded in XML and transmitted between RFI systems using Simple
Object Access Protocol (SOAP) [W3C 2003].
An XML profile of the RFI Service specification will eventually need to be written.
10.3 Engineering solution for full tracking and monitoring
This solution has the engineering solution for Web services-based interoperability as a
prerequisite. Section 7 Service Functionality describes various levels of capabilities for tracking
and monitoring of RFIs. For full tracking and monitoring, subscription and notification services,
similar to that described in Annex E will need to be implemented and linked to implementations of
the RFI Service. Subscription and notification services ideally should be based on standards that
already exist. The OASIS ebXML Registry Information Model v2.5 [OASIS 2003] provides a
registry schema, which includes classes that enable subscription to and notification of events that
occur with registry objects. If this concept is extended to RFI services, metadata on RFIs can be
managed within registries, and events that occur on these registries can be tracked. Actors can
subscribe to registries to receive notification of events.
Note that the ebXML Registry Services Specification is used within the OGC Catalogue Services
ebRIM profile of Catalogue Services for the Web [OGC 2004].
10.4 Abstract Test Suite
An abstract test suite is required for the engineering solution for Web services-based
interoperability and this test suite will need to be extended to test for full tracking and monitoring.
An XML profile of the RFI Service specification must be written first before a test suite can be
devised.
26
RFI Service Specification Draft Standard Version 2.0
17 November 2006
Annex A. (normative) UML model
The UML model consists of packages of four services (Figure 15). The RFI Submission Service is
further broken down into four sub-packages (Figure 16). Each package consists of UML classes.
Figures 17-22 shows the composition of classes with subclasses. Figures 23-30 show the
attribute contents of each class.
RFI Submission
Service
RFI Attribute
Retrieval Service
RFI Change
Service
RFI Product
Retrieval Service
Figure 15. RFI Service packages
Form General
Form
Identification
Form Info
Request
Form Info
Product
Form
Restrictions
Figure 16. RFI Form packages contained within the RFI Submission Service package
A1
RFI Service Specification Draft Standard Version 2.0
17 November 2006
<<DataType>>
RF_UniqueID
<<DataType>>
RF_PartyID
(from Form Identification)
(from Form Identification)
<<DataType>>
RF_RFIDestinationID
(from Form Identification)
RF_InformationRequest
RF_Target
(from Form Info Request)
(from Form Info Request)
<<DataType>>
RF_SourceConsulted
RF_ProductRequirements
(from Form Info Product)
(from Form Info Request)
RF_RFIForm
(from Form General)
<<DataType>>
RF_ProductIdentity
<<DataType>>
RF_Comment
(from Form Info Product)
(from Form General)
<<Enumeration>>
RF_RFITypeCode
<<DataType>>
RF_Security
(from Form General)
(from Form Restrictions)
<<Enumeration>>
RF_RFICategoryCode
<<CodeList>>
RF_StatusCode
<<Enumeration>>
RF_PriorityCode
<<CodeList>>
RF_MediaCode
(from Form General)
(from Form General)
(from Form General)
(from Form General)
Figure 17. Class composition of RF_RFIForm class
A2
RFI Service Specification Draft Standard Version 2.0
17 November 2006
<<DataType>>
RF_Comment
+commentSource [1] : RF_PartyID
+commentDate [1] : DateTime
+commentText [1] : CharacterString
(from Form Identification)
<<DataType>>
RF_PartyID
<<CodeList>>
RF_CountryCode
(from Form Identification)
<<DataType>>
RF_UniqueID
(from Form General )
<<CodeList>>
RF_LocationTypeCode
RF_Target
(from Form Info Request)
(from Form Info Request)
<<DataType>>
RF_GeoLocationData
(from Form Info Request)
<<DataType>>
RF_ReferenceSystemIdentifier
(from Form Info Request)
<<CodeList>>
RF_LocationCategory
(from Form Info Request)
Figure 18. Class composition of RF_Comment, RF_UniqueID and RF_Target classes
A3
RFI Service Specification Draft Standard Version 2.0
17 November 2006
<<DataType>>
RF_PartyID
<<DataType>>
RF_RFIDestinationID
(from Form Identification)
(from Form Identification)
<<DataType>>
RF_Contact
<<CodeList>>
RF_MediaCode
(from Form Identification)
(from Form General)
<<DataType>>
RF_Telephone
<<DataType>>
RF_Address
(from Form Identification)
(from Form Identification)
RF_InformationRequest
(from Form Info Request)
<<DataType>>
RF_Question
(from Form Info Request)
<<CodeList>>
RF_ReportingFrequencyCode
(from Form Info Request)
Figure 19. Class composition of RF_Contact, RF_RFIDestinationID and
RF_InformationRequest classes
A4
RFI Service Specification Draft Standard Version 2.0
17 November 2006
RF_ProductRequirements
(from Form Info Product)
<<CodeList>>
RF_MediaCode
<<CodeList>>
RF_ContentTypeCode
(from Form General)
(from Form Info Product)
<<DataType>>
RF_ProductIdentity
(from Form Info Product)
<<DataType>>
RF_ProductFusionSource
<<DataType>>
RF_Security
(from Form Info Product)
(from Form Restrictions)
<<DataType>>
RF_LegalConstraints
(from Form Restrictions)
<<Enumeration>>
RF_ProtectMarkingCode
<<CodeList>>
RF_SecurityCaveatCode
<<Enumeration>>
RF_RestrictionCode
(from Form Restrictions)
(from Form Restrictions)
(from Form Restrictions)
Figure 20. Class composition of RF_ProductRequirements, RF_ProductIdentity,
RF_Security and RF_LegalConstraints classes
A5
RFI Service Specification Draft Standard Version 2.0
17 November 2006
RC_ChangeRFI
(from RFI Change Service)
<<DataType>>
RF_UniqueID
<<DataType>>
RF_PartyID
<<DataType>>
RA_Attribute
(from Form Identification)
(from Form Identification)
(from RFI Attribute Retrieval Service)
RA_GetAttribute
(from RFI Attribute Retrieval Service)
<<Enumeration>>
RA_AttributeCode
(from RFI Attribute Retrieval Service)
<<DataType>>
RA_ResultDestination
(from RFI Attribute Retrieval Service)
<<CodeList>>
RF_MediaCode
(from Form General)
RA_SendAttribute
(from RFI Attribute Retrieval Service)
<<Enumeration>>
RA_AttributeRequestStatusCode
(from RFI Attribute Retrieval Service)
Figure 21. Class composition of RC_ChangeRFI, RA_GetAttribute, RA_ResultDestination,
RA_Attribute and RA_SendAttribute classes
A6
RFI Service Specification Draft Standard Version 2.0
17 November 2006
RP_GetProduct
(from RFI Product Retrieval Service)
<<DataType>>
RF_ProductIdentity
<<DataType>>
RF_PartyID
(from Form Info Product)
RP_SendProduct
(from RFI Product Retrieval Service)
<<Enumeration>>
RP_ProductRequestStatusCode
(from RFI Product Retrieval Service)
Figure 22. Class composition of RP_GetProduct and RP_SendProduct classes
A7
RFI Service Specification Draft Standard Version 2.0
17 November 2006
RF_RFIForm
+rfiUniqueID [1] : RF_UniqueID
+versionNum [1..*] : Integer = 1
+formPreparationDate [1] : DateT ime
+primaryOriginator [1] : RF_PartyID
+secondaryOriginator [0..1] : RF_PartyID
+parentRFI [0..1] : RF_UniqueID
+childRFI [0..*] : RF_UniqueID
+rfiType [1] : RF_RFITypeCode
+rfiCategory [1] : RF_RFICategoryCode
+subject [0..1] : CharacterString
+responseDestination [0..1] : RF_PartyID
+primaryManager [1] : RF_PartyID
+secondaryManager [0..1] : RF_PartyID
+forAction [1..*] : RF_RFIDestinationID
+forInformation [0..*] : CharacterString
+status [1] : RF_StatusCode
+priority [1] : RF_PriorityCode
+target [1] : RF_Target
+informationRequest [1..*] : RF_InformationRequest
+justification [1..*] : CharacterString
+sourcesConsulted [0..*] : RF_SourceConsulted
+comments [0..*] : RF_Comment
+mediaRFIAttributes [0..1] : RF_MediaCode
+requestSecurity [1] : RF_Security
+productRequirements [0..1] : RF_ProductRequirements
+productIdentity [0..*] : RF_ProductIdentity
+rfiSystem [0..1] : CharacterString
+militaryAction [0..1] : CharacterString
<<Enumeration>>
RF_RFITypeCode
+primary
+secondary
<<Enumeration>>
RF_RFICategoryCode
+geospatial
+imagery
+analystInformation
<<DataType>>
RF_Comment
+commentSource [1] : RF_PartyID
+commentDate [1] : DateTime
+commentText [1] : CharacterString
<<CodeList>>
RF_StatusCode
+inDevelopment
+submitted
+received
+validatedInProgress
+invalid
+partialProductBeingValidated
+partialProductReady
+completeProductBeingValidated
+completeProductReady
+stopped
+cancelled
<<Enumeration>>
RF_PriorityCode
+routine
+priority
+immediate
+flash
<<CodeList>>
RF_MediaCode
+inPersonVerbally
+inPersonOnPaper
+inPersonOnDigitalFile
+byVoiceTelephone
+byFacsimile
+byMailOnPaper
+byMailOnDigitalFile
+byEmail
+bySystemApplication
<<CodeList>>
RF_CountryCode
Figure 23. RFI Form general information
A8
RFI Service Specification Draft Standard Version 2.0
17 November 2006
<<DataType>>
RF_UniqueID
+rfiCountry [1] : RF_CountryCode
+rfiCountryUniqueID [1] : CharacterString
<<DataType>>
RF_PartyID
+individualName [0..1] : CharacterString
+organisationName [0..1] : CharacterString
+positionName [0..1] : CharacterString
+contactInfo [0..1] : RF_Contact
<<DataType>>
RF_RFIDestinationID
+mediaRFISubmission [0..1] : RF_MediaCode
+applicationRFISubmission [0..1] : CharacterString
<<DataType>>
RF_Contact
<<DataType>>
RF_Address
+phone [0..1] : RF_Telephone
+address [0..1] : RF_Address
+hoursOfService [0..1] : CharacterString
+contactInstructions [0..1] : CharacterString
+locationAddress [0..1] : CharacterString
+ci ty [0..1] : CharacterString
+administrativeArea [0..1] : CharacterString
+postalCode [0..1] : CharacterString
+country [0..1] : CharacterString
+electronicMai lAddress [0..*] : CharacterString
<<DataType>>
RF_Telephone
+voice [0..*] : CharacterStri ng
+facsimil e [0..*] : CharacterString
Figure 24. RFI Form identification information
A9
RFI Service Specification Draft Standard Version 2.0
17 November 2006
RF_Target
+targetCountry [1] : RF_CountryCode
+locationType [0..1] : RF_LocationTypeCode
+referenceSystemIdentifier [0..1] : RF_ReferenceSystemIdentifier
+locationCategory [0..1] : RF_LocationCategory
+geographicalLocationData [0..*] : RF_GeoLocationData
+geographicalLocationDescription [0..1] : CharacterString
<<CodeList>>
RF_LocationCategory
+airfields
+missilesAndArtillerySystems
+electronicInstallations
+militaryHeadquartersAndBarracks
+storageAndRepairInstallations
+militaryActivity
+obstacleCrossing
+shipping
+routeReconnaissance
+terrainReconnaissance
+coastalReconnaissance
+bridges
+waterControlInstallations
+portInstallations
+railInstallations
+industrialInstallations
+powerInstallations
+urbanAreasHabitation
+specificStructure
<<CodeList>>
RF_LocationTypeCode
+pinpoint
+multiple
+line
+circular
+rectangular
+elliptical
<<DataType>>
RF_ReferenceSystemIdentifier
+codeSpace [0..1] : CharacterString
+version [0..1] : CharacterString
<<DataType>>
RF_GeoLocationData
+x-coordinate[1] : Non-Negative Integer
+y-coordinate[1] : Non-Negative Integer
RF_InformationRequest
+informationRequired [1..* ] : RF_Question
+frequencyOfReporting [0..1] : RF_ReportingFrequencyCode
+startCollection [0..1] : DateTime
+endCollection [0..1] : DateTime
+lastTimeInfoOfValue [1] : DateTime
+lastReportDate [1] : DateTime
+locationAccuracy [0..1] : CharacterString
<<DataType>>
RF_Question
+question [0..1] : CharacterString
<<DataType>>
RF_SourceConsulted
+sourceDescription [0..1] : CharacterString
+sourceLocation [0..1] : URI
<<CodeList>>
RF_ReportingFrequencyCode
+once
+everyHour
+twiceDaily
+daily
+weekly
+monthly
Figure 25. RFI Form information request information
A10
RFI Service Specification Draft Standard Version 2.0
17 November 2006
RF_ProductRequirements
+mediaInformationProduct [0..1] : RF_MediaCode
+productContentT ype [0..1] : RF_ContentTypeCode
+productTechnicalInstructions [0..1] : CharacterString
+productLanguage [0..1] : CharacterString
<<DataT ype>>
RF_ProductIdentity
+productName [0..1] : CharacterString
+productDescription [0..1] : CharacterString
+productLocation [0..1] : URI
+productFusion [0..*] : RF_ProductFusionSource
+productMaximumSecurity [1] : RF_Security
+productLegalContraints [0..1] : RF_LegalConstraints
+originatorMaximumSecurity [1] : RF_Security
<<DataT ype>>
RF_ProductFusionSource
+productDescription [0..1] : CharacterString
+productLocation [0..1] : URI
<<CodeList>>
RF_ContentTypeCode
+text
+picture
+imagery
+map
Figure 26. RFI Form information product information
A11
RFI Service Specification Draft Standard Version 2.0
17 November 2006
<<DataT ype>>
RF_Security
+protectiveMarking [1] : RF_ProtectMarkingCode
+securityCaveat [0..*] : RF_SecurityCaveatCode
<<Enumeration>>
RF_ProtectMarkingCode
+topSecret
+secret
+confidential
+restricted
+unclassified
+notAssigned
<<Enumeration>>
RF_RestrictionCode
+copyright
+patent
+patentPending
+trademark
+license
+intellectualPropertyRights
+restricted
+otherRestrictions
<<CodeList>>
RF_SecurityCaveatCode
<<DataT ype>>
RF_LegalConstraints
+accessContraints [0..*] : RF_RestrictionCode
+useConstraints [0..*] : RF_RestrictionCode
+otherConstraints [0..*] : CharacterString
Figure 27. RFI Form restrictions information
A12
RFI Service Specification Draft Standard Version 2.0
17 November 2006
RC_ChangeRFI
+rfiUniqueID[1] : RF_UniqueID
+versionNum [0..1] : Integer
+changeOriginator [1] : RF_PartyID
+manager[1] : RF_PartyID
+transmissionDate [1] : DateTime
+changedAttribute [0..*] : RA_Attribute
Figure 28. RFI change information
A13
RFI Service Specification Draft Standard Version 2.0
17 November 2006
RA_GetAttribute
+rfiUniqueID [1] : RF_UniqueID
+versionNum [0..1] : Integer
+attributeRequestor [1] : RF_PartyID
+manager [1] : RF_PartyID
+transmissionDate [1] : DateTime
+queryStatement [1..*] : Query
+resultDestination [1] : RA_ResultDestination
RA_SendAttribute
+rfiUniqueID [1] : RF_UniqueID
+versionNum [0..1] : Integer
+attributeRequestor [1] : RF_PartyID
+transmissionDate [1] : DateTime
+resultDestination [1] : RA_ResultDestination
+manager [0..1] : RF_PartyID
+attributeRequestStatus [1] : RA_AttributeRequestStatusCode
+attributeResult [0..*] : RA_Attribute
<<DataType>>
RA_ResultDestination
+resultDestinationID [1] : RF_PartyID
+resultMedia [0..1] : RF_MediaCode
<<Enumeration>>
RA_AttributeRequestStatusCode
+successful
+unauthorized
+invalidRequest
+unsuccessful
<<DataType>>
RA_Attribute
+rfiAttribute [1] : RA_AttributeCode
+rfiAttributeValue [0..1] : CharacterString
<<Enumeration>>
RA_AttributeCode
Figure 29. RFI attribute retrieval information
A14
RFI Service Specification Draft Standard Version 2.0
17 November 2006
RP_GetProduct
+productRequestor [1] : RF_PartyID
+forAction [1] : RF_PartyID
+transmissionDate [1] : DateTime
+productDestination [1] : RF_PartyID
+productIdentity [1] : RF_ProductIdentity
RP_SendProduct
+productIdentity [1] : RF_ProductIdentity
+transmissionDate [1] : DateTime
+manager [0..1] : RF_PartyID
+productRequestor [1] : RF_PartyID
+productDestination [1] : RF_PartyID
+productRequestStatus [1] : RP_ProductRequestStatusCode
+attachedProduct [0..*] : File
<<Enumeration>>
RP_ProductRequestStatusCode
+successfulProductAttached
+successfulProductToBeDelivered
+unauthorizedRequest
+invalidRequest
+unsuccessful
Figure 30. RFI product retrieval information
A15
RFI Service Specification Draft Standard Version 2.0
17 November 2006
Annex B (normative) Data dictionary
1
Data dictionary overview
The data dictionary describes the characteristics of the data transmitted by the RFI services. The
dictionary is categorized by the UML model packages are described in Annex A: RFI Form
General, RFI Form Identification, RFI Form Information Request, RFI Form Information Product,
RFI Form Restrictions, RFI Change, RFI Attribute Retrieval and RFI Product Retrieval. The
clause titles of several of the tables have been expanded to reflect class specification within the
respective diagram. Each model diagram from Annex A has a section within the data dictionary.
Each UML model class equates to a data dictionary entity. Each UML model class attribute
equates to a data dictionary element. The shaded rows define entities. The entities and elements
within the data dictionary are defined by six attributes (those attributes are listed below and are
based on those specified in ISO/IEC 11179-3 for the description of data element concepts, i.e.
data elements without representation).
1.1
Name
The name assigned to an entity or element. Entity names start with an upper case letter. Spaces
do not appear in an entity name. Instead, multiple words are concatenated, with each new
subword starting with a capital letter (example: XnnnYmmm). Entity names are unique within the
entire data dictionary of this International Standard. Element names are unique within an entity,
not the entire data dictionary of this International Standard. Element names are made unique,
within an application, by the combination of the entity and element names
(example: RF_RFIForm: rfiUniqueID).
1.2
Definition
The entity/element description.
1.3
Obligation/Condition
This is a descriptor indicating whether an entity or element must always be documented in
the RFI service or sometimes be documented (i.e. contains value(s)). This descriptor may have
the following values: M (mandatory), C (conditional), or O (optional).
1.3.1 Mandatory
The entity or element must be documented.
1.3.2 Conditional
Specifies an electronically manageable condition under which at least one entity or
element is mandatory. ‘Conditional’ is used for one of the three following possibilities:
 Expressing a choice between two or more options. At least one option is mandatory and
must be documented.
 Documenting an entity or element if another element has been documented.
 Documenting an element if a specific value for another element has been documented.
To facilitate reading by humans, the specific value is used in plain text; however, the code shall
be used to verify the condition in an electronical user interface. If the answer to the condition is
positive, then the entity or the element shall be mandatory.
B1
RFI Service Specification Draft Standard Version 2.0
17 November 2006
1.3.3 Optional
The entity or element may be documented or may not be documented. Optional entities and
optional elements have been defined to provide a guide to those looking to fully document their
data. (Use of this common set of defined elements will help promote interoperability among RFI
Originator and Managers within military coalitions.) If an optional entity is not used, the elements
contained within that entity (including mandatory elements) will also not be used. Optional entities
may have mandatory elements; those elements only become mandatory if the optional entity is
used.
1.4
Maximum Occurrence
Specifies the maximum number of instances the entity or element may have. Single occurrences
are shown by “1”; repeating occurrences are represented by “N”. Fixed number occurrences other
than one are allowed, and will be represented by the corresponding number (i.e. “2”, “3”…etc).
1.5
Data Type
Specifies a set of distinct values for representing elements; for example, integer, real, string,
DateTime, and Boolean. The data type attribute is also used to define entities, stereotypes, and
associations. Note: Data types are defined in ISO/TS 19103, 6.5.2.
1.6
Domain
For an entity, the domain indicates the line numbers covered by that entity. For an element, the
domain specifies the values allowed or the use of free text. “Free text” indicates that no
restrictions are placed on the content of the field. Integer-based codes shall be used to represent
values for domains containing code lists.
B2
RFI Service Specification Draft Standard Version 2.0
2
RFI service data dictionaries
2.1
2.1.1
RFI form general information
General information
ID
Name
Definition
1.
RF_RFIForm
2.
rfiUniqueID
Form used to record all information about the
Request For Information
A unique identifier for the RFI
3.
versionNum
4.
formPreparationD
ate
primaryOriginator
5.
6.
17 November 2006
secondaryOrigina
tor
Obligation/
Condition
M
Maximum
occurrence
1
Data type
Domain
Class
Lines xxx-xxx
M
1
RF_UniqueID<<Dat
aType>>
The version number for the RFI form. This facility
provides a capability for an RFI system to track and
access histories of changes within any field.
Date and Time at which the RFI form was
completed.
The Originator of the Primary RFI.
O.
N
Class
<<DataType>
>
Integer
M
1
Date
DateTime
M
1
Class
The Originator of this RFI if it is a Secondary RFI.
C. Required
only if RFI
tracking
between
systems is
desired, and
if the RFI is a
secondary
RFI.
1
Class
RF_PartyID
<<DataType>>
RF_PartyID
<<DataType>>
1..N
B3
RFI Service Specification Draft Standard Version 2.0
ID
Name
Definition
7.
parentRFI
The unique identifier of the parent RFI that created
this RFI.
8.
childRFI
Unique identifiers of the RFIs that were directly
created by this RFI.
17 November 2006
Obligation/
Condition
C. Required
only if RFI
tracking
between
systems is
desired and
where this
tracking must
include a
capability for
child RFIs to
know their
parent RFIs.
C. Required
only if RFI
tracking
between
systems is
desired and
where this
tracking must
include a
capability for
parent RFIs
to know their
child RFIs.
Maximum
occurrence
1
Data type
Domain
Class
RF_UniqueID<<Dat
aType>>
N
Class
RF_UniqueID<<Dat
aType>>
B4
RFI Service Specification Draft Standard Version 2.0
ID
Name
Definition
9.
rfiType
Indication whether the RFI is the primary RFI or a
secondary one.
10.
rfiCategory
11.
17 November 2006
Maximum
occurrence
1
Data type
Domain
Class
RF_RFITypeCode
<<Enumeration>>
A general categorization of RFIs.
Obligation/
Condition
C. Required
only if RFI
tracking
between
systems is
desired and if
an indication
is required
whether an
RFI is
Primary or
Secondary.
In absence of
this field, it is
assumed that
the RFI is a
Primary RFI.
M
1
Class
subject
Brief statement on the subject area of the RFI.
M
1
12.
responseDestinat
ion
O
1
13.
primaryManager
The identity of the location where the information
product that is generated as a result of this RFI is
to be sent. If this field is not filled out, the
information product will not be automatically sent to
the Originator.
The identity of the Manager responsible for the
Primary RFI – its receipt, validation, processing,
and product validation, and product dissemination.
The Primary Manager is responsible for the
interface with the Primary Originator.
CharacterStrin
g
Class
RF_RFICategoryCo
de
<<Enumeration>>
Free Text
M
1
Class
RF_PartyID
<<DataType>>
RF_PartyID
<<DataType>>
B5
RFI Service Specification Draft Standard Version 2.0
17 November 2006
ID
Name
Definition
Obligation/
Condition
C. Required
only if RFI
tracking
between
systems is
desired and if
this tracking
requires the
identity of the
Secondary
Manager.
M
Maximum
occurrence
1
Data type
Domain
14.
secondaryManag
er
The identity of the Manager responsible for this
RFI, if it is a Secondary RFI – its receipt, validation,
processing, and product validation, and product
dissemination.
Class
RF_PartyID
<<DataType>>
15.
forAction
16.
forInformation
17.
status
The parties requested to provide a response to this
RFI.
The parties who, according to the Originator, may
have an interest in the information product from
this RFI.
Indicates the current status of the RFI.
N
Class
O
N
Character
String
RF_DestinationID
<<DataType>>
Free Text
M
1
Class
18.
priority
Priority for execution of the RFI.
M
1
Class
19.
target
Describes the geographical target area to which
the RFI pertains.
Describes the information requested.
M
1
Class
20.
21.
informationReque
st
justification
M
N
Class
Describes the justification for the request and why
it is being requested
Describes the sources of information already
consulted by the Originator.
Additional comments offered by any party.
Additional comments can be appended at any time.
Identifies the communication media for returning
information about the RFI. If left blank, the media is
selected at the discretion of the Manager.
Security Classification to which the RFI must be
protected.
Describes the technical requirements for the
information product.
M
N
O
N
CharacterStrin
g
Class
22.
sourceConsulted
23.
comment
O
N
Class
24.
mediaRFIAttribut
es
O
1
Class
25.
requestSecurity
M
1
Class
26.
productRequirem
ent
O
1
Class
RF_StatusCode
<<CodeList>>
RF_PriorityCode
<<Enumeration>>
RF_Target
RF_InformationReq
uest
Free Text
RF_SourceConsulte
d <<DataType>>
RF_Comment
<<DataType>>
RF_MediaCode
<<CodeList>>
RF_Security
<<DataType>>
RF_ProductRequire
ment
B6
RFI Service Specification Draft Standard Version 2.0
17 November 2006
ID
Name
Definition
27.
productIdentity
28.
rfiSystem
Identifies the information product produced through
the execution of this RFI.
Identifies the system that is processing the RFI
29.
militaryAction
2.1.2
A designation of a specific military plan, order or
operation to which the RFI corresponds
Maximum
occurrence
N
Data type
Domain
Class
RF_ProductIdentity
O
1
Free Text
O
1
CharacterStrin
g
CharacterStrin
g
Obligation/
Condition
Maximum
occurrence
Data type
Domain
M
1
Class
M
1
Date
RF_PartyID <<Data
Type>>
DateTime
M
1
CharacterStrin
g
Free Text
RF_Comment <<DataType>>
ID
Name
Definition
30.
31.
RF_Comment
commentSource
A statement of information regarding the RFI Form.
The source of the comment.
32.
commentDate
33.
commentText
Date and Time at which comment was added to
the RFI Form
Comment statement
2.1.3
Obligation/
Condition
O
Free Text
RF_StatusCode <<CodeList>>
ID
34.
35.
36.
37.
38.
39.
Name
RF_StatusCode
inDevelopment
submitted
received
validatedInProgress
invalid
40.
partialProductBeingValidated
41.
partialProductReady
Domain Code
Definition
A code indicating the current status of the RFI
The RFI form is under development but not yet submitted.
The RFI form has been submitted by the Originator to the Manager.
The Manager acknowledges receipt of the RFI form.
The Manager has validated the RFI and its execution is underway.
The Manager has determined that the RFI is invalid and the RFI will
not proceed to execution. See Manager’s comments.
The RFI is being executed and a partial information product has been
produced but is being validated by the Manager. The RFI execution
may yield further information products.
The RFI is being executed and a partial information product has been
produced, validated by the Manager, and is ready to access. The RFI
execution may yield further information products.
B7
RFI Service Specification Draft Standard Version 2.0
ID
42.
Name
completeProductBeingValidated
43.
completeProductReady
44.
stopped
45.
cancelled
2.1.4
ID
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
Domain Code
17 November 2006
Definition
The RFI execution is complete and the information product is being
validated by the Manager.
The RFI execution is complete and a validated information product is
ready to access.
The RFI has been stopped either by the Originator or Manager. See
comments. The RFI could be restarted in the future.
The RFI has been cancelled either by the Originator or Manager. See
comments.
RF_MediaCode <<CodeList>>
Name
RF_MediaCode
inPersonVerbally
inPersonOnPaper
inPersonOnDigitalFile
byVoiceTelephone
byFacsimile
byMailOnPaper
byMailOnDigitalFile
byEmail
bySystemApplication
Domain Code
Definition
Code identifying the type of communication media.
2.1.5 RF_CountryCode <<CodeList>>
Country codes are not included in this version of the specification because the structure and definition of these codes remain under
debate within the military community.
ID
Name
Domain Code
Definition
56.
RF_CountryCode
Code identifying the country name according to STANAG 1059 INT
(Distinguishing Letters for Geographic Entities for use in NATO) and from
AAP-15 (NATO Glossary of Abbreviations used in NATO Documents).
B8
RFI Service Specification Draft Standard Version 2.0
2.1.6
ID
57.
58.
59.
2.1.7
ID
60.
61.
62.
2.1.8
RF_RFITypeCode <<Enumeration>>
Name
RF_RFITypeCode
primary
secondary
Domain Code
Definition
Code identifying whether the RFI is primary or secondary.
This RFI is a primary RFI.
This RFI is a secondary RFI and is related to a primary RFI.
RF_RFICategoryCode <<Enumeration>>
Name
RF_RFICategoryCode
geospatial
imagery
Domain Code
Definition
Code identifying the category of RFI.
The RFI relates to a request for geospatial information
The RFI relates to a request for imagery information
RF_PriorityCode <<Enumeration>>
ID
63.
64.
65.
66.
67.
Name
RF_PriorityCode
routine
priority
immediate
flash
2.2
RFI form identification information
2.2.1
17 November 2006
Domain Code
Definition
Code identifying the priority to be given to RFI execution.
Unique identifier information
ID
Name
Definition
68.
69.
RF_UniqueID
rfiCountry
A unique identifier for the RFI.
Country from which the RFI form originates
70.
rfiCountryUniqueI
D
An identification of the RFI that is unique within the
Country
Obligation/
Condition
Maximum
occurrence
Data type
Domain
M
1
Class
M
1
CharacterStrin
g
RF_CountryCode
<<CodeList>>
Free Text
B9
RFI Service Specification Draft Standard Version 2.0
2.2.2
17 November 2006
Party identification information
ID
Name
Definition
71.
RF_PartyID
72.
individualName
Describes the party being an individual, position or
agency.
Name of the party person – surname, given name,
title separated by delimiter.
73.
organisationNam
e
Name of the party organization.
74.
positionName
Role or position of the party.
75.
contactInfo
Information required enabling contact with the
party.
2.2.3
Obligation/
Condition
Maximum
occurrence
Data type
Domain
C. Required if
there are no
entries
in
Organization
Name
or
Position
Name
C. Required if
there are no
entries
in
Individual
Name
or
Position
Name
C. Required if
there are no
entries in
Individual
Name or
Position
Name
O
1
CharacterStrin
g
Free Text
1
CharacterStrin
g
Free Text
1
CharacterStrin
g
Free Text
1
Class
RF_Contact
<<DataType>>
Obligation/
Condition
Maximum
occurrence
Data type
Domain
RFI destination identification information
ID
Name
Definition
76.
RF_RFIDestinati
onID
Describes the destination to which the RFI is being
sent for action.
Subclass
to
RF_PartyID
B10
RFI Service Specification Draft Standard Version 2.0
17 November 2006
ID
Name
Definition
77.
mediaRFISubmis
sion
applicationRFISu
bmission
Identifies the communication media by which the
RFI form is sent to the destination.
Identifies the name of the system application, if
any, used by the Originator to submit the RFI Form
to the destination.
78.
2.2.4
Maximum
occurrence
1
Data type
Domain
Class
O
1
CharacterStrin
g
RF_MediaCode
<<CodeList>>
Free Text
Obligation/
Condition
Maximum
occurrence
Data type
Domain
O
1
Class
O
1
Class
O
1
O
1
CharacterStrin
g
CharacterStrin
g
RF_Telephone
<<DataType>>
RF_Address
<<DataType>>
Free Text
Obligation/
Condition
Maximum
occurrence
Data type
Domain
O
1
Character
String
Character
String
Character
String
Character
String
Free Text
Contact information
ID
Name
Definition
79.
RF_Contact
80.
phone
81.
address
82.
hoursOfService
83.
contactInstruction
s
Information required enabling contact with the
party.
Telephone numbers at which the organization may
be contacted.
Physical and email address at which the
organization or individual may be contacted.
Time period (including time zone) when individuals
can contact the organization or individual.
Supplemental instructions on how and when to
contact the individual or organization.
2.2.5
Obligation/
Condition
O
Address information
ID
Name
Definition
84.
RF_Address
85.
locationAddress
Physical and email address at which
organization or individual may be contacted.
Address line for the location.
86.
city
City of the location
O
1
87.
administrativeAre
a
postalCode
State, province of the location.
O
1
ZIP or other postal code
O
1
88.
Free Text
the
Free Text
Free Text
Free Text
B11
RFI Service Specification Draft Standard Version 2.0
ID
Name
Definition
89.
country
90.
electronicMailAdd
ress
2.2.6
17 November 2006
Country of the physical address
Obligation/
Condition
O
Maximum
occurrence
1
Address of the electronic mailbox of the party.
O
N
Obligation/
Condition
Name
Definition
91.
RF_Telephone
92.
voice
93.
facsimile
Telephone numbers at which the organization may
be contacted.
Telephone number by which individuals can speak
to the party.
Telephone number of a facsimile machine for the
party.
2.3.1
Domain
Character
String
Character
String
Free Text
Maximum
occurrence
Data type
Domain
O
N
Free Text
O
N
Character
String
Character
String
Obligation/
Condition
Maximum
occurrence
Data type
Domain
M
1
Class
C. Required if
RFI is
geospatial.
1
Class
RF_CountryCode
<<CodeList>>
RF_LocationTypeCo
de <<CodeList>>
C. Required if
RFI is
geospatial.
1
Class
Free Text
Telephone information
ID
2.3
Data type
Free Text
RFI form information request information
Target information
ID
Name
Definition
94.
RF_Target
95.
targetCountry
Describes the geographical target area to which
the RFI pertains.
Identifies the country to which the RFI pertains.
96.
locationType
97.
referenceSystemI
dentifier
Identifies the type of geospatial feature that best
represents the spatial extent of the target location.
The target location is the area of interest to which
the RFI pertains.
Identifies the spatial reference system used in the
Geographical Location Data field.
RF_ReferenceSyste
mIdentifier
<<DataType>>
B12
RFI Service Specification Draft Standard Version 2.0
ID
Name
Definition
98.
locationCategory
99.
geographicalLoca
tionData
The category of the target as defined by the most
appropriate “category” code within STANAG 3596
AR (Air Reconnaissance Requesting and Target
Reporting Guide).
Geospatial coordinates that define the boundary of
the location Type.
100.
geographicalLoca
tionDescription
2.3.2
17 November 2006
A geographical description of the target location.
Obligation/
Condition
C. Required if
RFI is
geospatial.
Maximum
occurrence
1
Data type
Domain
Class
RF_LocationCategor
y<<CodeList>>
C. Required if
RFI is
geospatial.
N
Class
C. Required if
RFI
is
geospatial.
1
CharacterStrin
g
RF_GeoLocationDat
a <<DataType>>
Follows NATO
STANAG 2433:
AIntP-3 (Military
Intelligence Data
Exchange
Standard).
Free Text.
Obligation/
Condition
Maximum
occurrence
Data type
Domain
O
1
CharacterStrin
g
Free Text.
O
1
CharacterStrin
g
Free Text.
Reference system identifier information
ID
Name
Definition
101.
Identifies the spatial reference system.
102.
RF_ReferenceSy
stemIdentifier
codeSpace
103.
version
Name or identifier of the person or organization
responsible for the namespace of the reference
system.
Version identifier for the namespace of the
reference system.
B13
RFI Service Specification Draft Standard Version 2.0
2.3.3
17 November 2006
Geographical location data information
ID
Name
Definition
104.
RF_GeoLocation
Data
105.
x-coordinate
Geospatial coordinate pair describing a single
location (point) in coordinate space. The coordinate
pair corresponds to the coordinate reference
system identified in RF_ReferenceSystemIdentifier.
The resolution of the coordinates depends on the
resolution of the locationType but must be
sufficient to roughly define the boundary of the
location Type.
x-coordinate
106.
y-coordinate
2.3.4
y-coordinate corresponding to the coordinate
reference system identified in
RF_ReferenceSystemIdentifier
Name
Definition
107.
RF_InformationR
equest
informationRequir
ed
frequencyOfRepo
rting
Describes the information requested.
109.
Maximum
occurrence
Data type
Domain
M
1
Non-Negative
Integer
M
1
Non-Negative
Integer
Valid integer within
the coordinate
reference system.
Valid integer within
the coordinate
reference system.
Obligation/
Condition
Maximum
occurrence
Data type
Domain
M
N
Class
O
1
Class
RF_Question
<<DataType>>
RF_ReportingFrequ
encyCode
<<CodeList>>
Information request information
ID
108.
Obligation/
Condition
A set of one or more questions that describes the
information that the Originator requires.
Description of frequency of collection reporting,
once or periodic. The information required by the
Originator may change due to evolving situations in
the target location; hence the Originator may wish
to receive information products updated on a
specific frequency. Updating information products
requires a new collection of situational information.
B14
RFI Service Specification Draft Standard Version 2.0
17 November 2006
ID
Name
Definition
110.
startCollection
111.
endCollection
Date and time to begin collection of situational
information for the information product. If frequency
is once, then collection will occur at this date and
time.
Date and time to end collection of situational
information for the information product.
112.
113.
lastTimeInfoOfVa
lue
lastReportDate
114.
locationAccuracy
2.3.5
Maximum
occurrence
1
Data type
Domain
Class
DateTime
C. Required if
frequencyOf
Reporting ≠
once.
M
1
Class
DateTime
1
Class
DateTime
M
1
Class
DateTime
C. Required if
RFI is
geospatial.
1
CharacterStrin
g
Free Text
Definition
Obligation/
Condition
Maximum
occurrence
Data type
Domain
The best possible narrative description of the
information that the Originator requires, in the form
of a question.
M
1
CharacterStrin
g
Free Text
Obligation/
Condition
Maximum
occurrence
Data type
Domain
O
1
O
1
CharacterStrin
g
Class
URI
Date and time when value of the information
product expires.
Date and time when the last version of the
information product is to be sent to the Destination
of Response. Must be on or before LTIOV.
Narrative description of the specific location
accuracy required, if appropriate.
Question information
ID
Name
115.
116.
RF_Question
question
2.3.6
Obligation/
Condition
M
Source consulted information
ID
Name
Definition
117.
RF_SourceCons
ulted
sourceDescriptio
n
sourceLocation
Describes one information source
consulted by the Originator.
A description of the information source.
118.
119.
The location of the information source.
already
B15
RFI Service Specification Draft Standard Version 2.0
2.3.7
RF_LocationTypeCode <<CodeList>>
ID
120.
Name
RF_LocationTypeCode
121.
122.
123.
124.
125.
126.
pinpoint
multiple
line
circular
rectangular
elliptical
2.3.8
Domain Code
Name
RF_LocationCategory
Domain Code
128.
129.
airfields
missilesAndArtillerySyst
ems
electronicInstallations
militaryHeadquartersAn
dBarracks
storageAndRepairInstall
ations
militaryActivity
obstacleCrossing
shipping
routeReconnaissance
terrainReconnaissance
coastalReconnaissance
bridges
waterControlInstallation
s
01
02
132.
133.
134.
135.
136.
137.
138.
139.
140.
Definition
Identifies the type of geospatial feature that best represents the spatial
extent of the target location. The target location is the area of interest to
which the RFI pertains.
Location Category<<CodeList>>
ID
127.
130.
131.
17 November 2006
Definition
The category of the target as defined by the most appropriate “category” code
within STANAG 3596 AR (Air Reconnaissance Requesting and Target
Reporting Guide).
03
04
05
06
07
08
09
10
11
12
13
B16
RFI Service Specification Draft Standard Version 2.0
ID
141.
142.
143.
144.
145.
146.
2.3.9
ID
147.
Name
portInstallations
railInstallations
industrialInstallations
powerInstallations
urbanAreasHabitation
specificStructure
Domain Code
14
15
16
17
18
19
Definition
RF_ReportingFrequencyCode <<CodeList>>
148.
149.
150.
151.
152.
153.
Name
RF_ReportingFrequenc
yCode
once
everyHour
twiceDaily
daily
weekly
monthly
2.4
RFI form information product information
2.4.1
17 November 2006
Domain Code
Definition
Code indicating the frequency of collection reporting.
Product requirements information
ID
Name
Definition
154.
RF_ProductRequ
irements
mediaInformation
Product
productContentT
ype
productTechnicalI
nstructions
productLanguage
Describes the technical requirements for the
information product.
The communication media through which the
information product should be sent.
The type of content for the information product.
155.
156.
157.
158.
Technical instructions about the types of product
being requested
Language of the product being requested. If left
blank, the default language is English.
Obligation/
Condition
Maximum
occurrence
Data type
Domain
O
1
Class
O
1
Class
O
1
O
1
CharacterStrin
g
CharacterStrin
g
RF_MediaCode
<<CodeList>>
RF_ContentTypeCo
de <<CodeList>>
Free Text
Free Text
B17
RFI Service Specification Draft Standard Version 2.0
2.4.2
Product identity information
ID
Name
Definition
159.
RF_ProductIdenti
ty
productName
productDescriptio
n
productLocation
productFusion
160.
161.
162.
163.
164.
165.
166.
2.4.3
17 November 2006
productMaximum
Security
productLegalCont
raint
originatorMaximu
mSecurity
Obligation/
Condition
Maximum
occurrence
Data type
Domain
The unique identity of an information product
produced in response to the RFI.
The name of the information product
O
1
Free Text
Describes the information product.
O
1
The URI location of the information product.
Indicates none-to-many sources from which the
product was created through fusion.
The maximum level of security classification for the
information product.
Restrictions and legal prerequisites for accessing
or using the information product.
The maximum level of security classification for
products that the Originator is allowed to receive.
O
O
1
N
CharacterStrin
g
CharacterStrin
g
Class
Class
M
1
Class
O
1
Class
M
1
Class
Obligation/
Condition
Maximum
occurrence
Data type
Domain
CharacterStrin
g
Class
Free Text
URI
RF_ProductFusionS
ource
RF_Security
<<DataType>>
RF_LegalConstraint
s <<DataType>>
RF_Security
<<DataType>>
Product fusion source information
ID
Name
Definition
167.
RF_ProductFusio
nSource
168.
productDescriptio
n
productLocation
Describes the source of an information product that
was used in the fusion of a final information
product
Describes the information product.
O
1
The URI location of the information product.
O
1
169.
Free Text
URI
B18
RFI Service Specification Draft Standard Version 2.0
2.4.4
RF_ContentTypeCode <<CodeList>>
ID
170.
171.
172.
173.
174.
175.
Name
RF_ContentTypeCode
text
picture
imagery
map
dataset
2.5
RFI form restrictions information
2.5.1
17 November 2006
Domain Code
Definition
The type of content for the information product.
Security information
ID
Name
Definition
176.
RF_Security
177.
protectiveMarking
178.
securityCaveat
Security Classification to which the entity must be
protected.
Identity of the security classification to which the
entity must be protected.
Identity of the security enclave.
2.5.2
Maximum
occurrence
Data type
Domain
M
1
Class
O
N
Class
RF_ProtectMarking
Code <<CodeList>>
RF_SecurityCaveat
Code <<CodeList>>
Obligation/
Condition
Maximum
occurrence
Data type
Domain
O
N
Class
RF_RestrictionCode
<<Enumeration>>
Product legal constraints information
ID
Name
Definition
179.
RF_LegalConstra
ints
accessContraint
Restrictions and legal prerequisites for accessing
or using the entity.
Access constraint applied to assure the protection
of privacy or intellectual property, and any special
restrictions or limitations on obtaining the entity.
180.
Obligation/
Condition
B19
RFI Service Specification Draft Standard Version 2.0
17 November 2006
ID
Name
Definition
181.
useConstraint
182.
otherConstraint
Constraint applied to assure the protection of
privacy or intellectual property, and any special
restrictions or limitations or warnings on using the
entity.
Other restriction or legal prerequisite for accessing
and using the entity.
2.5.3
ID
183.
Maximum
occurrence
N
Data type
Domain
Class
RF_RestrictionCode
<<Enumeration>>
O
N
CharacterStrin
g
Free Text
RF_ProtectMarkingCode <<CodeList>>
184.
185.
Name
RF_ProtectMarkingCod
e
topSecret
secret
186.
187.
188.
189.
confidential
restricted
unclassified
notAssigned
2.5.4
Obligation/
Condition
O
Domain Code
Definition
Identity of the security classification to which the entity must be protected.
Of the highest secrecy
kept or meant to be kept private, unknown, or hidden from all but a select group
of people
available for someone who can be entrusted with information
Not for general disclosure
Available for general disclosure
Protective marking not yet assigned
RF_RestrictionCode <<CodeList>>
ID
190.
191.
Name
RF_RestrictionCode
copyright
192.
patent
193.
194.
patentPending
trademark
Domain Code
Definition
Limitation(s) placed upon the access or use of the entity.
exclusive right to the publication, production, or sale of the rights to a literary,
dramatic, musical, or artistic work, or to the use of a commercial print or label,
granted by law for a specified period of time to an author, composer, artist,
distributor
government has granted exclusive right to make, sell, use or license an
invention
or discovery
produced or sold information awaiting a patent
a name, symbol, or other device identifying a product, officially registered and
legally restricted to the use of the owner or manufacturer
B20
RFI Service Specification Draft Standard Version 2.0
ID
195.
196.
197.
198.
Name
license
intellectualPropertyRigh
ts
restricted
otherRestrictions
Domain Code
2.5.5 RF_SecurityCaveatCode <<CodeList>>
The codes for security caveats are not defined in this specification.
ID
Name
Domain Code
199. RF_SecurityCaveatCod
e
2.6
2.6.1
17 November 2006
Definition
formal permission to do something
rights to financial benefit from and control of distribution of non-tangible property
that is a result of creativity
withheld from general circulation or disclosure
limitation not listed
Definition
Code identifying the security enclave
RFI changes information
Change RFI attribute information
ID
Name
Definition
200.
RC_ChangeRFI
201.
rfiUniqueID
Indicates to the Manager that a change has
occurred to an attribute in an existing RFI in the
registry.
A unique identifier for the RFI
202.
versionNum
The version number for the RFI
203.
changeOriginator
204.
manager
205.
transmissionDate
The identity of the party that has changed an
attribute in an existing RFI.
The identity of the Manager to whom this change
information is being sent and who is responsible for
the RFI.
The date and time of transmission of the operation.
Obligation/
Condition
Maximum
occurrence
Data type
Domain
M
1
RF_UniqueID<<Dat
aType>>
C. Required if
a version
number
exists.
M
1
Class
<<DataType>
>
Integer
1
Class
RF_PartyID
<<DataType>>
M
1
Class
DateTime
1..N
B21
RFI Service Specification Draft Standard Version 2.0
17 November 2006
ID
Name
Definition
206.
changedAttribute
The identification of a specific RFI attribute, whose
value has changed.
2.7
2.7.1
Obligation/
Condition
C. Required if
newForm=0
Maximum
occurrence
N
Data type
Domain
Class
RA_Attribute
<<DataType>>
Obligation/
Condition
Maximum
occurrence
Data type
Domain
M
1
RF_UniqueID<<Dat
aType>>
C. Required if
a version
number
exists.
M
1
Class
<<DataType>
>
Integer
1
Class
M
1
Class
M
M
1
N
Class
Class
RF_PartyID
<<DataType>>
RF_PartyID
<<DataType>>
DateTime
Query1
M
1
Class
RFI attribute retrieval information
Get attribute information
ID
Name
Definition
207.
RA_GetAttribute
208.
rfiUniqueID
Describes a request for attribute information from
an existing RFI.
A unique identifier for the RFI
209.
versionNum
The version number for the RFI
210.
211.
attributeRequesto
r
manager
212.
213.
transmissionDate
queryStatement
214.
resultDestination
The identity of the party making the request for
attribute information from an existing RFI.
The identity of the Manager who is responsible for
the RFI.
The date and time of transmission of the operation.
A structured query statement, which will be used to
select the requested attribute information.
The location where the result (attribute information)
is to be sent.
1..N
RA_ResultDestinatio
n <<DataType>>
1
Query as a data type is not formally defined in this specification. Query could conform to a specification such as OGC CQL/Filter, SQL-92, XPath, or
XQuery. It is recommended that conformance be made to OGC Filter to stay aligned with the implementation of query in the DGIWG profile of the
OGC Catalogue Service specification.
B22
RFI Service Specification Draft Standard Version 2.0
2.7.2
17 November 2006
Send attribute information
ID
Name
Definition
215.
216.
RA_SendAttribut
e
rfiUniqueID
Describes the requested result (attribute
information) from an existing RFI.
A unique identifier for the RFI
217.
versionNum
The version number for the RFI
218.
219.
220.
attributeRequesto
r
transmissionDate
resultDestination
221.
manager
222.
attributeRequest
Status
The identity of the party making the request for
attribute information from an existing RFI.
The date and time of transmission of the operation.
The location where the result (attribute information)
is to be sent.
The identity of the Manager who is responsible for
the RFI.
The status of the attribute request.
223.
attributeResult
2.7.3
Obligation/
Condition
Maximum
occurrence
Data type
Domain
M
1
RF_UniqueID<<Dat
aType>>
C. Required if
a version
number
exists.
M
1
Class
<<DataType>
>
Integer
1
Class
M
M
1
1
Class
Class
M
1
Class
M
1
Class
O
N
Class
RF_PartyID
<<DataType>>
DateTime
RA_ResultDestinatio
n <<DataType>>
RF_PartyID
<<DataType>>
RA_AttributeReques
tStatusCode
<<Enumeration>>
RA_Attribute
<<DataType>>
Obligation/
Condition
Maximum
occurrence
Data type
Domain
The identity of the result destination.
M
1
Class
The communication media to be used to send the
result to the destination.
O
1
Class
RF_PartyID
<<DataType>>
RF_MediaCode
<<Enumeration>>
The requested attribute information.
Result destination information
ID
Name
Definition
224.
RA_ResultDestin
ation
resultDestinationI
D
resultMedia
The location to which the result will be sent.
225.
226.
1..N
B23
RFI Service Specification Draft Standard Version 2.0
2.7.4
17 November 2006
Attribute information
ID
Name
Definition
Obligation/
Condition
Maximum
occurrence
Data type
Domain
227.
228.
RA_Attribute
rfiAttribute
Describes an RFI attribute.
The attribute name
M
1
Class
The attribute value
O
1
CharacterStrin
g
RA_AttributeCode
<<CodeList>>
Free Text
229.
rfiAttributeValue
2.7.5 RA_AttributeCode <<Enumeration>>
This code list contains all the attributes in the RFI service specification and would be created when the specification is implemented.
ID
Name
Domain Code
Definition
230. RA_AttributeCode
Code indicating the Attribute name
2.7.6
ID
231.
RA_AttributeRequestStatusCode <<Enumeration>>
232.
233.
234.
235.
Name
RA_AttributeRequestSt
atusCode
successful
unauthorized
invalidRequest
unsuccessful
2.8
RFI product retrieval information
2.8.1
Domain Code
Definition
Code indicating the status of the attribute request.
The execution of the request was successful.
The request is not authorized
The request is invalid
The execution of the request was unsuccessful.
Get product information
ID
Name
Definition
236.
RP_GetProduct
Describes a request for an existing information
product produced from an RFI.
Obligation/
Condition
Maximum
occurrence
Data type
Domain
B24
RFI Service Specification Draft Standard Version 2.0
17 November 2006
ID
Name
Definition
237.
productRequesto
r
manager
The identity of the party making the request for the
information product.
The identity of the Manager who is responsible for
the information product.
The date and time of transmission of the operation.
The identity of the destination to which the
information product must be sent.
The identity of the information product.
238.
239.
240.
241.
2.8.2
transmissionDate
productDestinatio
n
productIdentity
Obligation/
Condition
M
Maximum
occurrence
1
Data type
Domain
Class
M
1
Class
M
M
1
1
Class
Class
M
1
Class
RF_PartyID
<<DataType>>
RF_PartyID
<<DataType>>
DateTime
RF_PartyID
<<DataType>>
RF_ProductIdentity
<<DataType>>
Obligation/
Condition
Maximum
occurrence
Data type
Domain
M
1
Class
RF_ProductIdentity
<<DataType>>
DateTime
RF_PartyID
<<DataType>>
RF_PartyID
<<DataType>>
RF_PartyID
<<DataType>>
RP_ProductRequest
StatusCode
<<Enumeration>>
File
Send product information
ID
Name
Definition
242.
243.
RP_SendProduct
productIdentity
Describes the requested information product.
The identity of the information product.
244.
245.
transmissionDate
manager
M
M
1
1
Class
Class
246.
productRequesto
r
productDestinatio
n
productRequestS
tatus
The date and time of transmission of the operation.
The identity of the Manager who is responsible for
the information product.
The identity of the party making the request for the
information product.
The identity of the destination to which the
information product must be sent.
The status of the information product request.
M
1
Class
M
1
Class
M
1
Class
The information product.
O
N
Class
247.
248.
249.
2.8.3
ID
250.
attachedProduct
RP_ProductRequestStatusCode <<Enumeration>>
Name
RP_ProductRequestSta
tusCode
Domain Code
Definition
The code defining the status of the information product request.
B25
RFI Service Specification Draft Standard Version 2.0
ID
251.
252.
253.
254.
255.
Name
successfulProductAttac
hed
successfulProductToBe
Delivered :
unauthorizedRequest
invalidRequest
unsuccessful
Domain Code
17 November 2006
Definition
The execution of the information product request was successful and the
product is attached.
The execution of the information product request was successful and the
product will be delivered.
The request for the information product is unauthorized.
The request for the information product is invalid.
The request for the information product was unsuccessful.
B26
RFI Service Specification Draft Standard Version 2.0
3
3.1
17 November 2006
Externally referenced entities
Date
A date gives values for year, month and day. Figure 31 shows the Date type. Character encoding
of a date is a string that shall follow the format for date specified in ISO 8601. Encoding is further
discussed in ISO 19118 and ISO 19136. Principles for date and time are further discussed in ISO
19108. Example: 1998-09-18
Figure 31. Date and time data types
3.2
Time
A time is given by an hour, minute and second. Figure 31 shows the Time type. Character
encoding of a time is a string that follows the ISO 8601 format. Time zone according to UTC is
optional. Encoding is further discussed in ISO 19118 and ISO 19136. Principles for date and time
are further discussed in ISO 19108. Example:18:30:59 or 18:30:59+01:00. For the RFI
Specification, time will be reported as UTC/GMT.
3.3
DateTime
A DateTime is a combination of a date and a time type. Figure 31 shows the DateTime type.
Character encoding of a DateTime shall follow ISO 8601. Encoding is further discussed in ISO
19118 and ISO 19136. Principles for date and time are further discussed in ISO 19108.
3.4
Query
Query as a data type is not formally defined in this specification. Query could conform to a
specification such as OGC CQL/Filter, SQL-92, XPath, or XQuery. It is recommended that
conformance be made to OGC Filter to stay aligned with the implementation of query in the
DGIWG profile of the OGC Catalogue Service specification.
B27
RFI Service Specification Draft Standard Version 2.0
17 November 2006
Annex C. (normative) Security issues
Security issues exist across the various levels of implementation of the RFI Service specification;
however, they are more complicated in a Web services-based implementation. In the RFI
Manager implementation (see Annex D), the following security issues are addressed [xwave
2005]:




Agent authentication, where all entities (e.g. users and systems) require to be
authenticated on the RFI system before any interaction can occur. Authentication abides
by portal-specific standards for user login information, but future versions may use the
Security Assertion Markup Language (SAML).
Business-to-business authentication, where federated RFI systems require authentication
before they can interact. Because RFI processes originate with users, the user
authentication information is with all collaborating RFI systems. Future handling of this
authentication can be in SAML or MS Active Directory Services, or all authentications can
be handled by a central server.
Internal security, which constrains access to specific components of the RFI system,
using a security API, which defines roles and privileges. Roles are assigned by actor.
Permissions can be field-defined, system logic-defined, service operation-defined, or
user-defined.
Database security, which restricts database access to RFI system administrators.
As shown in the RFI example in Fig. 1, RFIs may cross over multiple levels of security and thus
create a number of security issues:
 Tracking and monitoring may be broken when information gets passed to a destination
system that operates at a higher level of security.
 An RFI may be classified at a level higher than is permissible by an RFI system meaning
that it cannot be sent to that system.
 An RFI’s classification may be raised to a higher level by a manager of an RFI system,
further constraining its processing.
 An RFI information product’s classification may differ from that of the RFI, meaning that
product distribution will be constrained, even to the Originator, at least until the product
can be modified to a pass at a lower level.
C1
RFI Service Specification Draft Standard Version 2.0
17 November 2006
Annex D. (informative) RFI Service examples
1
Canadian DND RFI Manager
J2 Information Management (IM) of Canadian Department of National Defence (DND) started the
development of an RFI Manager application in 2001 in direct response to capability requirements
expressed through annual Joint Warrior Interoperability Demonstrator (JWID) exercises. This
development was based on some early work undertaken by the US National Imagery and
Mapping Agency (NIMA) to provide some RFI capabilities using MS Access, Cold Fusion and
HTML. The new RFI Manager tool coordinates requests from international users via a single
virtual Web site for all geospatial and imagery information requests. This application was
integrated into the Intelligence Collection Environment Common Access Portal (ICECAP) and
demonstrated at JWID 2001. New versions of the RFI application and ICECAP have been
demonstrated at subsequent JWID exercises. Version 2.0 of the RFI Manager [Fowler 2004] was
been tested at the JWID 2004 Exercise. This version includes technologies such as Postnuke,
PHP, MySQL and Elvin Server/Sticker. It is currently in operational use by the Collection
Coordination and Intelligence Requirements Management (CCIRM) in DND [Fowler 2005i]. The
CCIRM deals with strategic requests for information from users at commands across Canada,
and deployed operations. The system is used at the Secret level to track requests for all
classification levels.
The objectives of Version 3.0 [Fowler 2005i] are:
 To improve the interoperability of the dissemination of requests and products between
disparate RFI serves
 To accommodate differences in the business processes of handling RFIs across
agencies
 To accommodate differences in the organizational structures of agencies because they
affect the assignment and flow of RFI activities within these agencies.
 To conform to standards in information exchange, specifically this RFI Service
specification, and standards in architecture, security and technologies.
 To improve life cycle management of the RFI systems.
Version 3.0 was developed as a portlet on the ICECAP portal [Fowler 2005ii]. ICECAP is based
on a Java 2 Enterprise Edition (J2EE) platform. The RFI portlet is able to operate under any J2EE
portal including ICECAP and BEA WebLogic. The LifeRay open source software was used for
portal development. MySQL is used for database management. All data transmitted across
service interfaces are encoded in XML and transported using SOAP. Version 3.0 complies with
the RFI Service specification at the “Limited Tracking and Monitoring” level of interoperability and
functionality.
RFI Manager Version 3.0a was tested at Coalition Warrior Interoperability Demonstrator (CWID)
2005 [DND 2005ii]. The trial objectives were:
 To validate the business processes for a better understanding of how the RFI system
should/should not work, and determine where adaptability in the software is required.
 To test the feasibility of federated services in an RFI process.
 To gain user feedback on the user interface.
The trial was successful and generated high interest from a number of coalition nations.
D1
RFI Service Specification Draft Standard Version 2.0
2
17 November 2006
NATO RFIMS
The NATO Request for Information Management Service (RFIMS) is web-enabled centralized,
unclassified system to support the preparation, distribution, and management of NATO requests
for information and their corresponding replies [NATO 2006]. It addresses the NATO intelligence
community's need for an automated intelligence requirements and management system capable
of operating in the common desktop ADP environment. RFIMS serves as a crisis management
tool, which provides the ability to register, validate, de-conflict, and track RFI's and their
associated replies to facilitate faster responses, preventing duplication and promoting effective
utilization of scarce resources.
RFIMS was developed by the Operations Research Division of NC3A and Version 4.0 is operated
by NATO SHAPE.
The RFI Form used within RFIMS for RFI submission follows NATO STANAG 2149. The system
will be integrated with NATO’s All Source Analyst System (ASAS). It will comply with the NATO
intelligence metadata standard, which is the Intelligence Projects Integrated Working Group
(IPIWG) Metadata Standard Version 3.0. RFIMS is under consideration for use with the BICES
network.
After discussion with NC3A about RFIMS and the RFI Service specification, it was determined
that both elements are complimentary and an opportunity exists to add RFI Service interface to
RFIMS so that it can be interoperable with any other RFI system that conforms to the RFI Service
interface, such as the CAN DND RFI Manager system. An interoperability test could be
conducted on the BICES network.
D2
RFI Service Specification Draft Standard Version 2.0
17 November 2006
Annex E. Considerations for Linking Subscription and Notification Services
to the RFI Service
This annex provides some information about the operation of subscription and notification
services in conjunction with RFI services. The subscription and notification services are notional
meaning that while there may be a number of possible approaches, one approach is used as an
example.
1
RFI Subscription Service
This service has the following two types of operations and these are depicted on the activity
diagram (Fig. 32):
 SubscribeRFI: Subscribe to receive notification of RFI attribute change – Receive
subscription for notification of RFI attribute change
 AcknowledgeRFISubscription: Send Subscription Acknowledgement – Receive
Subscription Acknowledgement
Originator
Manager
Subscribe for
Notification of Change
Subscribe for
Notification of Change
Analyst
Subscribe for
Notification of Change
SubscribeRFI
Receive
Subscription
Process
Subscription
SubscribeRFI
Forward to
Other Manager ?
Add Subscription
to Database
Send Subscription
Acknowledgement
AcknowledgeRFISubscription
Receive Subscription
Acknowledgement
AcknowledgeRFISubscription
Receive Subscription
Acknowledgement
Receive Subscription
Acknowledgement
Figure 32. RFI Submission activity diagram
E1
RFI Service Specification Draft Standard Version 2.0
4
17 November 2006
RFI Change and Notification Service
This service has the following two types of operations and these are depicted on the activity
diagram (Fig. 33):
 ChangeRFIAttribute: Send changed RFI attribute – Receive changed RFI attribute
 NotifyRFIChange: Notify of RFI attribute change – Receive RFI attribute change
notification
Originator
Change RFI
Attribute
Send Changed
RFI Attribute
ChangeRFIAttribute
Manager
Change RFI
Attribute
Send Changed
RFI Attribute
ChangeRFIAttribute
Receive Changed
RFI Attribute
Process Changed
RFI Attribute
Generate Attribute
Change Notification
Send Attribute
Change Notification
NotifyRFIChange
NotifyRFIChange
Receive Attribute
NotifyRFIChange
Change Notification
Receive Attribute
Analyst
Change RFI
Attribute
Send Changed
RFI Attribute
Receive Changed
RFI Attribute
Process Changed
RFI Attribute
Generate Attribute
Change Notification
Send Attribute
Change Notification
Receive Attribute
Change Notification
Change Notification
Figure 33. RFI Change and Notification activity diagram
E2
RFI Service Specification Draft Standard Version 2.0
5
17 November 2006
RFI Subscription Service Specification
RS_Service
+name [1] = RFISubscriptionService
+opModel
RS_Interface
+typeName
+subscribeRFI() : RS_Subscription
+acknowledgeRFI() : RS_AcknowledgeSubscription
RS_SubscribeRFIOperation
+operationName [1] = subscribeRFI
RS_AcknowledgeRFIOperation
+operationName [1] = acknowledgeRFI
Figure 34. RFI Subscription Service specification
5.1
SubscribeRFI Operation
The SubscribeRFI Operation sends a parameter set. The data that is transmitted by this
operation is described in the data dictionaries below under section, RFI Subscription Information.
The UML notation for this operation is:
+subscribeRFI (in RS_Subscription):
There is no return type.
5.2
AcknowledgeRFISubscription Operation
The AcknowledgeRFISubscription Operation sends a parameter set. The data that is transmitted
by this operation is described in the data dictionary in section, Acknowledge Subscription
Information. The UML notation for this operation is:
+acknowledgeRFI (in RS_AcknowledgeSubscription):
There is no return type.
E3
RFI Service Specification Draft Standard Version 2.0
6
17 November 2006
RFI Change and Notification Service Specification
RC_Service
+name [1] = RFIChange&NotificationService
+opModel
RC_Interface
+typeName
+changeRFIAttribute() : RC_ChangeRFI
+notifyRFIChange() : RC_ChangeRFI
RC_ChangeRFIAttributeOperation
+operationName [1] = changeRFIAttribute
RC_NotifyRFIChangeOperation
+operationName [1] = notifyRFIChange
Figure 35. RFI Change & Notification Service specification
6.1
NotifyRFIChange Operation
Notifications can occur when a new RFI is submitted and when any changes occur to the RFI
data fields. The NotifyRFIChange Operation sends a parameter set. The data that is transmitted
by this operation is described in the data dictionary below in section, Notify RFI Attribute
Information. The UML notation for this operation is:
+notifyRFIChange (in RC_ChangeRFI):
There is no return type.
E4
RFI Service Specification Draft Standard Version 2.0
17 November 2006
RS_Subscription
+subscriptionID [1] : RF_SerialNum
+transmissionDate [1] : Date
+subscriberID [1] : RF_PartyID
+notificationDestination [1] : RS_NotificationDestination
+manager [1] : RF_PartyID
+subscriptionAction [1] : RS_SubscriptionActionCode
+subscriptionToChanges [0..*] : RS_SubscriptionToChanges
+subscriptionToExistence [0..*] : RS_SpecificAttribute
<<DataType>>
RS_NotificationDestination
+notificationDestinationID [1] : RF_PartyID
+notificationMedia [0..1] : RF_MediaCode
RS_SubscriptionToChanges
+serialNum [1] : RF_FormSerialNum
+versionNum [0..1] : Integer
+allAttributes [1] : Boolean
+specificAttributes [0..*] : RS_SpecificAttribute
<<Enumeration>>
RS_SubscriptionActionCode
+subscribe
+unsubscribe
<<DataType>>
RS_SpecificAttribute
+specificAttribute [0..*] : RA_AttributeCode
RS_AcknowledgeSubscription
+subscriptionID [1] : RF_SerialNum
+transmissionDate [1] : Date
+subscriberID [1] : RF_PartyID
+notificationDestination [1] : RS_NotificationDestination
+subscriptionAction [1] : RS_SubscriptionActionCode
+subscriptionToChanges [0..*] : RS_SubscriptionToChanges
+subscriptionToExistence [0..*] : RS_SubscriptionToExistence
+subscriptionStatus [1] : RS_SubscriptionStatusCode
<<Enumeration>>
RS_SubscriptionStatusCode
+successful
+unsuccessful
+forwarded
+invalid
+unauthorized
Figure 36. RFI subscription information
E5
RFI Service Specification Draft Standard Version 2.0
17 November 2006
RC_ChangeRFI
+serialNum [1] : RF_FormSerialNum
+versionNum [0..1] : Integer
+changeOriginator [1] : RF_PartyID
+manager[1] : RF_PartyID
+transmissionDate [1] : Date
+changedAttribute [0..*] : RA_Attribute
RC_NotifyRFI
+serialNum [1] : RF_FormSerialNum
+versionNum [0..1] : Integer
+manager : RF_PartyID
+transmissionDate [1] : Date
+newRFI [1] : Boolean
+changedAttribute [0..*] : RA_Attribute
+notificationDestination [1] : RS_NotificationDestination
+newRFIForm [0..*] : RF_RFIForm
Figure 37. RFI change and notification information
RFI Change & Notification
Service Specification
E6
RFI Service Specification Draft Standard Version 2.0
7
7.1
17 November 2006
RFI subscription information
General information
ID
Name
Definition
Obligation/
Condition
Maximum
occurrence
Data type
Domain
256.
RS_Subscription
subscriptionID
Describes the information for a subscription to
enable notification about the existence of an RFI or
any changes made to RFI attributes.
A unique identifier the subscription.
257.
M
1
Class
258.
259.
transmissionDate
subscriberID
The date and time of transmission of the operation.
The identity of the subscriber.
M
M
1
1
Class
Class
260.
notificationDestin
ation
The location where the notification is to be sent.
M
1
Class
261.
manager
M
1
Class
262.
subscriptionActio
n
The identity of the Manager who is the custodian of
the subscription registry and who is responsible for
execution of the subscription.
The action that this subscription will undertake
when executed.
RF_UniqueID<<Dat
aType>>
DateTime
RF_PartyID
<<DataType>>
RS_NotificationDesti
nation <<Data
Type>>
RF_PartyID
<<DataType>>
M
1
Class
263.
subscriptionToCh
anges
O
N
Class
264.
subscriptionToExi
stence
Identifies the specific RFI and the attributes of
interest in order to receive notification of any
changes to these attributes.
Identifies the RFI attributes and the specific codes
for these attributes in order to receive notification of
the existence of any new RFIs that contain these
codes.
O
N
Class
RS_SpecificAttribute
<<DataType>>
Obligation/
Condition
Maximum
occurrence
Data type
Domain
7.2
RS_SubscriptionActi
onCode
<<Enumeration>>
RS_SubscriptionTo
Changes
Notification destination information
ID
Name
Definition
265.
RS_NotificationD
estination
The location where the notification is to be sent.
E7
RFI Service Specification Draft Standard Version 2.0
ID
Name
Definition
266.
notificationDestin
ationID
notificationMedia
The identity of the location where the notification is
to be sent.
The communication media to be used when
sending the notification.
267.
7.3
Name
Definition
268.
RS_Subscription
ToChanges
269.
rfiUniqueID
Identifies the specific RFI and the attributes of
interest in order to receive notification of any
changes to these attributes.
A unique identifier for the RFI
270.
versionNum
The version number of the RFI.
271.
allAttributes
272.
specificAttributes
An indication whether the subscription pertains to
changes to any attribute for the RFI.
The identification of the specific RFI attribute to
which any change in the attribute value will trigger
a notification of the change.
Maximum
occurrence
1
Data type
Domain
Class
O
1
Class
RF_PartyID
<<DataType>>
RF_MediaCode
<<CodeList>>
Obligation/
Condition
Maximum
occurrence
Data type
Domain
M
1
RF_UniqueID<<Dat
aType>>
C. Required if
a version
number
exists.
M
1
Class
<<DataType>
>
Integer
1
Boolean
C. Required if
allAttributes=
0.
N
Class
1=yes
0=no
RS_SpecificAttribute
<<Datatype>>
Obligation/
Condition
Maximum
occurrence
Data type
Domain
O
1
Class
RA_AttributeCode
<<CodeList>>
1..N
Specific attribute information
ID
Name
Definition
273.
RS_SpecificAttrib
ute
specificAttribute
A specific RFI attribute.
274.
Obligation/
Condition
M
Subscription to changes information
ID
7.4
17 November 2006
The identification of a specific RFI attribute.
E8
RFI Service Specification Draft Standard Version 2.0
7.5
17 November 2006
Acknowledge subscription information
ID
Name
Definition
Obligation/
Condition
Maximum
occurrence
Data type
Domain
275.
RS_Acknowledge
Subscription
subscriptionID
Describes the information for the
acknowledgement of the execution of an RFI
subscription.
A unique identifier for the subscription.
276.
M
1
Class
277.
278.
transmissionDate
subscriberID
The date and time of transmission of the operation.
The identity of the subscriber.
M
M
1
1
Class
Class
279.
notificationDestin
ation
The location where the notification is to be sent.
M
1
Class
280.
subscriptionActio
n
The action that this subscription will undertake
when executed.
M
1
Class
281.
subscriptionToCh
anges
O
N
Class
282.
subscriptionToExi
stence
O
N
Class
RS_SpecificAttribute
<<DataType>>
283.
subscriptionStatu
s
Identifies the specific RFI and the attributes of
interest in order to receive notification of any
changes to these attributes.
Identifies the RFI attributes and the specific codes
for these attributes in order to receive notification of
the existence of any new RFIs that contain these
codes.
The status of the subscription execution.
RF_UniqueID<<Dat
aType>>
DateTime
RF_PartyID
<<DataType>>
RS_NotificationDesti
nation <<Data
Type>>
RS_SubscriptionActi
onCode
<<Enumeration>>
RS_SubscriptionTo
Changes
M
1
Class
RS_SubscriptionStat
usCode
<<Enumeration>>
7.6
RS_SubscriptionActionCode <<CodeList>>
ID
284.
Name
RS_SubscriptionAction
Code
285.
subscribe
Domain Code
Definition
Code indicating the action that this subscription will undertake when executed.
A new subscription will be added to the subscription registry.
E9
RFI Service Specification Draft Standard Version 2.0
ID
286.
Name
unsubscribe
Domain Code
7.7
RS_SubscriptionStatusCode <<CodeList>>
ID
287.
288.
289.
290.
Name
RS_SubscriptionStatus
Code
successful
unsuccessful
forwarded
291.
292.
invalid
unauthorized
7.8
Notify RFI attribute information
Domain Code
17 November 2006
Definition
An existing subscription, which is identified by subscriptionID, will be removed
from the subscription registry.
Definition
Code indicating the status of the subscription execution.
The subscription was added to the subscription registry.
The subscription was not added to the subscription registry.
The subscription was forwarded to another Manager who is the custodian of
registry pertinent to the subscription.
The subscription is invalid.
The subscription is not authorized to be included in the subscription registry.
ID
Name
Definition
293.
RC_NotifyRFI
294.
rfiUniqueID
Describes the notification to a subscriber about a
new RFI or about changed values to attributes in
an existing RFI.
A unique identifier for the RFI
295.
versionNum
The version number for the RFI
296.
manager
297.
notificationDestin
ation
The identity of the Manager who is responsible for
the RFI and who is issuing the notification.
The location where the notification is being sent.
298.
transmissionDate
The date and time of transmission of the operation.
Obligation/
Condition
Maximum
occurrence
Data type
Domain
M
1
RF_UniqueID<<Dat
aType>>
C. Required if
a version
number
exists.
M
1
Class
<<DataType>
>
Integer
1
Class
M
1
Class
M
1
Class
RF_PartyID
<<DataType>>
RS_NotificationDesti
nation
<<DataType>>
DateTime
E10
1..N
RFI Service Specification Draft Standard Version 2.0
17 November 2006
ID
Name
Definition
299.
newRFI
Indication whether the RFI is new or already exists.
300.
newRFIForm
The new RFI form.
301.
changedAttribute
The identification of a specific RFI attribute, whose
value has changed.
Obligation/
Condition
M
Maximum
occurrence
1
Data type
Domain
Boolean
C. Required if
newForm=1
C. Required if
newForm=0
1
Class
1=yes
0=no
RF_RFIForm
N
Class
E11
RA_Attribute
<<DataType>>
RFI Service Specification Draft Standard Version 2.0
17 November 2006
Annex F. Bibliography
DND. 2005. CWID 2005 After Action Report on IT 5.19 Request For Information Services
Interoperability. Canada Department of National Defence report to CWID 2005.
Fowler, C. 2004. RFI Manager Reference Manual Version 2.0. J2 Information Management,
Canada Department of National Defence, 18 February 2004. Draft.
Fowler, C. 2005i. Intelligence Collection Environment Common Access Portal and Request for
Information Manager Version 3 – Business Case. J2 Information Management, Canada
Department of National Defence. 16 August 2005.
Fowler, C. 2005ii. Intelligence Collection Environment Common Access Portal and Request for
Information Manager Version 3 – System Requirements Specification, Version 1.0.3. J2
Information Management, Canada Department of National Defence. 26 August 2005.
Fusaro, LTC N. 2005. Request for Information Management Service (RFIMS). PowerPoint
presentation by NATO BICES Agency to 19th BICES Intelligence User Group. Antalya, Turkey,
06-10 June 2005.
IETF RFC 1738, Uniform Resource Locators (URL)
IETF RFC 2056, Uniform Resource Locators for Z39.50
ISO 8601:2000, Data elements and interchange formats — Information interchange —
Representation of dates and times
ISO/TS 19103: Geographic information ― Conceptual schema language. Draft
NATO. 2006. User Guide for RFIMS V4.0. NATO CIS Services Agency. April 2006.
OASIS. 2003. OASIS/ebXML Registry Information Model v.2.5. OASIS/ebXML Registry Technical
Committee Approved Specification. June 2003.
OGC. 2004. OGC Catalogue Services – ebRIM (ISO/TS 15000-3) profile of CSW. Version 0.9.1.
OGC 04-017r1. 14 Sept 2004.
OGC. 2005. OGC Web Services Common Specification, Version 1.0. OGC 05-008.Open
Geospatial Consortium. 10 May 2005.
W3C. 2003. SOAP Version 1.2. World Wide Web Consortium. http://www.w3.org/TR/2003/RECsoap12-part0-20030624/
F1