Sustainability of Digital Formats: Planning for Library of Congress Collections |
|
Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact |
Full name | CPIM Instant Message Format |
---|---|
Description |
CPIM, short for Common Presence and Instant Messaging, is the common data message format that must be used by any CPIM-compliant message transfer protocol including instant messaging. Standardized through RFC 3862, the design of the CPIM format is intended to enable security to be applied, while itself remaining agnostic about the specific security mechanisms that may be appropriate for a given application. This content format is intended to be used to exchange possibly-secured messages between different instant messaging protocols. Very strict adherence to the message format (including whitespace usage) may be needed to achieve interoperability. A Message/CPIM object is a two-part entity, where the first part contains the message metadata and the second part is the message content. The two parts are separated from the enclosing MIME header fields and also from each other by blank lines. The end of the message body is defined by the framing mechanism of the protocol used. Unlike SMS, CPIM messages do not have a character limit. See Notes for description of the file structure and for information about the Instant Message Protocol. |
Relationship to other formats | |
Affinity to | IMF, Internet Message Format. Similar header syntax. See Notes for details |
LC experience or existing holdings | |
---|---|
LC preference |
Disclosure | Fully documented. |
---|---|
Documentation | CPIM is documented through a set of related documents in the IETF Standards Track, specifically RFC 3862 and RFC 5438 which extends the header fields. See Format Specifications for details. |
Adoption | CPIM is the standard syntax defined by IETF for instant messages transfered through the message transfer protocol. As such, it is highly adopted and interoperable with many tool sets and applications. |
Licensing and patents | None |
Transparency |
Apart from when encrypted, CPIM files are usually simple text files and can be opened in Notepad or a web browser. |
Self-documentation | Metadata is available through the well-structured header fields. |
External dependencies | None |
Technical protection considerations | RFC 3862 states that CPIM "is designed with security in mind" in that "it is designed to be used with MIME security multiparts for signatures and encryption." |
Tag | Value | Note |
---|---|---|
Internet Media Type | message/CPIM |
Defined in RFC 3862. Other MIME headers may be used as appropriate for the message transfer environment. |
General |
The MIME headers for the overall message identifies the message as a CPIM-formatted message. This includes the required Message/CPIM header but also may include other MIME headers as appropriate for the message. The MIME header is followed by a blank separator line. The separator line is followed by message headers. Message headers carry information relevant to the end-to-end transfer of the message from sender to receiver. Other header syntax is similar to IMF including "From," "To," "cc," "DateTime," and "Subject." Header names and other text must be used as given, using exactly the indicated upper- and lower-case letters. One interesting difference is that IMF requires 7-bit ASCII which is problematic for encoding international character sets while CPIM requires UTF-8 character encoding though except for header names which require US-ASCII. Message headers must not be modified, reformatted or reordered in transit, but in some circumstances they may be examined by a CPIM message transfer protocol. Headers use UTF-8 character encoding throughout. CPIM is extended through RFC 5438 with new header fields that enable endpoints to request Instant Message Disposition Notifications. After the message header is the encapsulated MIME object containing the message content. MIME content headers MUST include at least a Content-Type header. Message content may be any MIME type. A message header may indicate a language for its value by including ";lang=tag" after the header name and colon, where "tag" is a language identifying token per RFC 3066. Finally, the message may close with MIME security multiparts for signatures as detailed in RFC 1847, appropriate security protocols (e.g., S/MIME or openPGP ), and encryption cryptographic schemes. Instant messaging, defined in RFC 2778, follows the Instant Message Protocol in which a sender provides instant messages to the instant message service which attempts delivery to a specific instant inbox address. The instant inbox address must have an Open status, indicating that the inbox is "available" or "open for business" for the instant message to be accepted. A Closed status means "unavailable" or "closed to business" and the instant message will not be delivered. |
---|---|
History |
|