The term “package” can mean different things in different file transfer situations.

“Installation package” – A file that contains all the executables, installation scripts and other data needed to install a particular application. This file is usually a compressed file and is often a self-extracting compressed file.

“Package sent to another person” – Very similar in scope to email’s “message with attachments”. This is a term that has rapidly gained acceptance (since about 2008) to describe what gets sent in “person-to-person” transmission. A package may contain zero or more files and a plain or richly formatted text message as its payload. A package will also always contain system-specific metadata such as sender/receiver identity, access control attributes, time-to-live information and quality of service information.

“Installation package” is the earlier context of the term “package” ; if you’re dealing with server teams or transmission specialists who deal primarily with system-to-system transfers then “installation package” is probably what they mean when they say “package”.

“Package sent to another person” has evolved as file transfer vendors gradually align the terminology of person-to-person file transfers with physical parcel transfers like those done by UPS or FedEx. In physical parcel transfers, individual packages may contain a variety of things but each is specifically addressed, guaranteed to be delivered safely and intact and each has its own level of service (e.g., 2nd day vs. overnight). The term “packages” is similarly used with many person-to-person file transfer solutions to help non-technical people understand the concept in a different context.

PCI stands for “Payment Card Industry”. In file transfer, “PCI compliance” frequently refers to a deployed system’s ability to adhere to the standard outlined in “PCI DSS” – a security regulation for the credit card industry. “PCI certification” is achieved when a PCI compliant system is audited by a PCI Council-approved firm and that third-party firm agrees that it is in compliance.

Like Sterling Commerce’s proprietary NDM file transfer protocol, PeSIT has now been written into the standard communication specifications of several industry consortiums and government exchanges, thus ensuring a high degree of long-term dependence on Axway technology. PeSIT is required far more often in Europe than in the United States due to Axway’s French roots and home turf advantage.

Also like NDM, PeSIT is normally used in internal (or trusted WAN) transfers; other protocols are typically used for transfers across the Internet.

PeSIT stands for “Protocol d’Echanges pour un Systeme Interbancaire de Telecompensation” and was designed to be a specialized replacement for FTP to support European interbank transactions in the mid-1980′s. One of the primary features of the protocol was “checkpoint restart”.

BEST PRACTICE: PeSIT, NDM and other protocols should be avoided in new deployments unless specifically mandated by industry rule or statute. The interesting capabilities these protocols offer (e.g., checkpoint restart, integrity checks, etc.) are now also available in vendor-neutral protocols, and from vendors who allow wider and less expensive licensing of connectivity technology than Axway and Sterling Commerce (now IBM).

Provisioning is the act of adding access to and allocating resources to end users and their file transfer workflows. It is often used interchangeably with the term “onboarding“.

The act of provisioning should always be audited, and the audit information should include the identity of the person who authorized the act and any technical actions the system took to provision the user.

Most file transfer servers today allow administrators to chain up to Active Directory (AD), LDAP or RADIUS or other external authentication to allow centralized management (and thus provisioning) of authentication and access. However, provisioning of customer-specific workflows is often a manual procedure unless standard workflows are associated with provisioning groups.

Automated provisioning of users through import capabilities, APIs and/or web services is a competitive differentiator across different file transfer servers, and varies widely from “just establish credentials”, through “also configure access” and on to “also configure workflows”.

Use of external authentication usually makes migration from one file transfer technology to another much easier than when proprietary credential databases are in use. When external authentication is in use, end users usually do not need to reset their current passwords. However,when proprietary credential databases from two different vendors (or sometimes two different products from the same vendor) are involved, it is common that every end user will have to change his or her password during migration.

BEST PRACTICE: Whenever possible, implementers of file transfer technology should use an external authentication source to control access and privileges of end users. When an external authentication source is used to control authentication in this manner, provisioning on the file transfer server can occur at any moment after the user is created or enabled on the central authentication server.