|
Please wait ......
AICC Package Exchange Notification Services - Overview
Terms of use
X
Terms of use
These contents have been obtained from the AICC Web site and edited for presentation. Please refer to the AICC Web site for additional information on terms of use.
Print
Aviation Industry CBT Committee
|
The specification/guidelines Package Exchange Notification Services (PENS), developed by the AICC (CMI010), describes a protocol to support a notification service to announce the location of content package(s) that are available for transport. The intent is to automate the notification, transfer and delivery confirmation of content packages between tools or systems that generate content and systems that manage, publish or deliver content. |
Purpose and Scope
The purpose of this specification is to fill a gap that currently exists between the creation of content packages by “content authors” and the deployment of those content packages on LMSs by “LMS administrators” where learners may ultimately have access to them. Without a specification that addresses this gap, the concept of shared content is incomplete: LMSs do not have a means to obtain newly developed, revised or updated content.
The scope of the specification is specifically constrained to the notification request, package transfer and related responses. Specifically outside the scope of this specification are mechanisms for physical deployment of content packages, content management, version control, publication or revoca-tion of content.AICC Package Exchange Notification Services overview |
Terms of use
X
These contents have been obtained from the AICC Web site and edited for presentation. Please refer to the AICC Web site for additional information on terms of use.
Print
The AICC PENS specification aims to provide a mechanism whereby content that is capable of being shared can be deployed and thus actually shared in practice. It describes a notification scheme that will enable a content creator’s authoring system to announce that a content package is available and ready for transport from a location that it will provide.
The PENS data model may be extended in the future to include commands in addition to the current “collect” command, which is the first service to be defined. Data elements and value spaces can be extended as driven by needs and determined in the future by the community of users.
The scope of the specification is specifically constrained to the notification request, package transfer and related responses. PENS addresses neither version control nor content management; there are no PENS commands to require the recipient to remove, replace, or update existing packages or elements of packages. PENS provides a contact URI (e.g., email address) for the recipient to contact the requestor, but PENS does not prescribe a specific workflow for processing of the transferred package. PENS does not require notifications to the requestor, other than the specific obligatory confirmation. For illustrative purposes, consider a courier service as a conceptual model for PENS. Two parties may use the courier service as a means of requesting pick-up, performing transfer, and confirming delivery. However, it is not incumbent on the courier to enforce particular post-processing by the recipient. The recipient may decide to use the parcel as notification to remove something, add the parcel to stock, or replace existing stock. All post-delivery processing is determined by the recipient. The recipient sets its own policy and procedures, and may choose to notify the party that requested delivery of specific events as it sees fit to do.
Synopsis of the package exchange notification services (PENS) model:- A notification is sent from a content source (such as an authoring tool, CMS or LCMS) to a Target System (central deployment or repository system such as a CMS, LCMS or LMS).
- The notification announces the availability and location of a content package that is available for transport.
- The notification represents the first step in initiating the Target System workflow to transfer and import a content package.
|
Notification mechanism details:- Suggested notification mechanism binding: HTTP-GET or HTTP-POST of name-value pairs.
- Notification modes: can be server-to-server, or server via browser window to server (HTTP-GET only).
- Responsibilities of sender: The content source (herein referred to as the “Client”) shall arrange for the content package to be made available on a staging server. The Client shall be capable of specifying a URI that uses HTTP, or HTTPS (secure HTTP) protocols. The Client may optionally support specifying FTP and FTPS (secure FTP) protocols and the related access credentials. It is assumed that the particular configuration of the staging server may be determined by a third party and therefore is not controlled by the content developer (Client). It is further assumed that if content is staged on the server via FTP that it does not have to be retrieved via FTP, but could be retrieved via an HTTP alias. Such provisions allow cases such as the transfer to the staging location via FTP and retrieval via an HTTP equivalent or alias to the same location.
- Password: If required by the Client’s system, the notification may include a password needed to access the content package.
- Responsibilities of recipient of notification: The notification recipient (herein referred to as the “server”) shall be capable of sup-porting both HTTP and HTTPS protocols for the “pull” or “get” transfer of the content package from the URI provided by the Client. The server may optionally support the retrieval of packages specified with FTP or FTPS protocols and appropriate access credentials. In such cases where the server does not support one or more optional protocols, the server is obligated to return the appropriate error message regarding the requested protocol.
|
Terms of use
X
These contents have been obtained from the AICC Web site and edited for presentation. Please refer to the AICC Web site for additional information on terms of use.
Print
Title: CMI010 - Guidelines for Package Exchange Notification Services
Version: 1.0a
Release Date: 15 March 2006
Status: Final specification
Electronic version: Online available in PDF. |
Tracking of changes
Section 6.2:- The package-url-expiry message element requires a trailing 'Z' to comply with the intent of the PENS specification which specifies ISO 8601 format with UTC.
- In the CMI010 Revision 1.0 document, the field is described as ISO 8601 with UTC, but the example does not properly show the UTC time zone code ('Z').
|
Version 1.0
Title: CMI010 - Guidelines for Package Exchange Notification Services
Version: 1.0
Release Date: 28 June 2005
Status: Final specification
Electronic version: Online available in PDF. |
|