Copyright (C) 2008 Collabora Ltd. Copyright (C) 2008 Nokia Corporation

This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

 (draft version, not API-stable)

This interface extends the Text interface to support more general messages, including:

  • messages with attachments (like MIME multipart/mixed)
  • groups of alternatives (like MIME multipart/alternative)
  • delivery reports
  • any extra types of message we need in future

It also provides a hook for improved sent message status notification, to be used by the DeliveryReporting interface.

Although this specification supports formatted (rich-text) messages with unformatted alternatives, implementations SHOULD NOT attempt to send formatted messages until the Telepathy specification has also been extended to cover capability discovery for message formatting.

We intend to expose all rich-text messages as XHTML-IM, but on some protocols, formatting is an extremely limited subset of that format (e.g. there are protocols where foreground/background colours, font and size can be set, but only for entire messages). Until we can tell UIs what controls to offer to the user, it's unfriendly to offer the user controls that may have no effect.

If this interface is present, clients that support it SHOULD listen for the MessageSent and MessageReceived signals, and ignore the Sent and Received signal on the Text interface (which are guaranteed to duplicate signals from this interface).

 A list of MIME types supported by this channel, with more preferred MIME types appearing earlier in the list. The list MAY include "*/*" to indicate that attachments with arbitrary MIME types can be sent. If the list is empty, this indicates that messages may only include a single "text/plain" part. Flags indicating the level of support for message parts on this channel.

Flags indicating the level of support for message parts on this channel. They are designed such that setting more flags always implies that the channel has more capabilities.

It is assumed that messages containing a textual message body (only), like the messages the Text interface was designed for, are always supported.

There is no flag indicating support for alternatives. This is because the SendMessage implementation can always accept messages containing alternatives, even if the underlying protocol does not, by deleting all alternatives except the first (most preferred) that is supported.

Each of the flags 1, 2, 4 implies the previous flag, so we could have used a simple enumeration here; however, we've defined the message-part support indicator as a flag set for future expansion. SendMessage will accept messages containing a single part of any type listed in the SupportedContentTypes property, with no accompanying text. SendMessage will accept messages containing a textual message body, plus a single attachment of any type listed in the SupportedContentTypes property. It does not make sense for this flag to be set if Message_Part_Support_Flag_Data_Only is not also set (because the connection manager can trivially provide an empty text part if necessary). SendMessage will accept messages containing a textual message body, plus an arbitrary number of attachments of any type listed in the SupportedContentTypes property. It does not make sense for this flag to be set if Message_Part_Support_Flag_One_Attachment is not also set.

Part of a message's content. In practice, this mapping never appears in isolation - messages are represented by a list of Message_Part mappings.

An example of how a message might look, in a Python-like syntax:

[
  {
    'message-sender': 42,
    'message-sent': 1210067943,
    'message-received': 1210067947,
    'message-type': 0,
    'pending-message-id': 437,
  },
  { 'alternative': 'main',
    'type': 'text/html',
    'content': 'Here is a photo of my cat:<br />' +
               '<img src="cid:catphoto" alt="lol!" />' +
               '<br />Isn't it cute?',
  },
  { 'alternative': 'main',
    'type': 'text/plain',
    'content': 'Here is a photo of my cat:\n[IMG: lol!]\nIsn't it cute?',
  },
  { 'identifier': 'catphoto',
    'type': 'image/jpeg',
    'size': 101000,
    'needs-retrieval': True,
  },
]

The first part of the message contains "headers" which refer to the entire message.

It is an error for a connection manager to put keys referring to the message as a whole in the second or subsequent Message_Part, but clients MUST recover from this error by ignoring these keys in the second and subsequent parts.

Well-known keys for the message as a whole, and the corresponding value types, include:

message-sent (u - Unix_Timestamp)
The time the message was sent (if unavailable, the time it arrived at a central server MAY be used). Omitted if no reasonable approximation is available
message-received (u - Unix_Timestamp)
The time the message was received locally. SHOULD always be present.
message-sender (u - Contact_Handle)
The contact who sent the message. If 0 or omitted, the contact who sent the message could not be determined.
message-type (u - Channel_Text_Message_Type)
The type of message; if omitted, Channel_Text_Message_Type_Normal MUST be assumed. SHOULD be omitted for normal chat messages.
pending-message-id (u - Message_ID)
The incoming message ID. This MUST NOT be present on outgoing messages. Clients SHOULD NOT store this key - it is only valid for as long as the message remains unacknowledged.
interface (s - DBus_Interface)
This message is specific to the given interface, which is neither Text nor Messages. It SHOULD be ignored if that interface is not supported. (Note that an 'interface' key can also appear on the second and subsequent parts, where it indicates that that part (only) should be ignored if unsupported.)

The second and subsequent parts contain the message's content, including plain text, formatted text and/or attached files.

In any group of parts with the same non-empty value for the "alternative" key (which represent alternative versions of the same content), more faithful versions of the intended message MUST come before less faithful versions (note that this order is the opposite of MIME "multipart/alternative" parts). Clients SHOULD display the first alternative that they understand.

Specifying the preference order means that if the underlying protocol doesn't support alternatives, the CM can safely delete everything apart from the first supported alternative when sending messages.

Clients SHOULD present all parts that are not redundant alternatives in the order they appear in this array, possibly excluding parts that are referenced by another displayed part. It is implementation-specific how the parts are presented to the user.

This allows CMs to assume that all parts are actually shown to the user, even if they are not explicitly referenced - we do not yet recommend formatted text, and there is no way for plain text to reference an attachment since it has no concept of markup or references. This also forces clients to do something sensible with messages that consist entirely of "attachments", with no "body" at all.

For instance, when displaying the above example, a client that understands the HTML part should display the JPEG image once, between the two lines "Here is a photo of my cat:" and "Isn't it cute?"; it may additionally present the image in some way for a second time, after "Isn't it cute?", or may choose not to.

A client that does not understand HTML, displaying the same message, should display the plain-text part, followed by the JPEG image.

Well-known keys for the second and subsequent parts, and the corresponding value types, include:

identifier (s)
An opaque identifier for this part. Parts of a message MAY reference other parts by treating this identifier as if it were a MIME Content-ID and using the cid: URI scheme.
alternative (s)

If present, this part of the message is an alternative for all other parts with the same value for "alternative". Clients SHOULD only display one of them (this is expected to be used for XHTML messages in a future version of this specification).

If omitted, this part is not an alternative for any other part.

Parts of a message MAY reference the group of alternatives as a whole (i.e. a reference to whichever of them is chosen) by treating this identifier as if it were the MIME Content-ID of a multipart/alternative part, and using the cid: URI scheme.

type (s)

The MIME type of this part. See the documentation for ReceivedMessage for notes on the special status of "text/plain" parts.

Connection managers MUST NOT signal parts without a 'type' key; if a protocol provides no way to determine the MIME type, the connection manager is responsible for guessing it, but MAY fall back to "text/plain" for text and "application/octet-stream" for non-text.

Clients MUST ignore parts without a 'type' key, which are reserved for future expansion.

lang (s)
The natural language of this part, identified by a RFC 3066 language tag. XMPP allows alternative-selection by language as well as by content-type.
size (u)
The size in bytes (if needs-retrieval is true, this MAY be an estimated or approximate size). SHOULD be omitted if 'content' is provided. There's no point in providing the size if you're already providing all the content.
needs-retrieval (b)
If false or omitted, the connection manager already holds this part in memory. If present and true, this part will be retrieved on demand (like MIME's message/external-body), so clients should expect retrieval to take time; if this specification is later extended to provide a streaming version of GetPendingMessageContent, clients should use it for parts with this flag.
truncated (b)
The content available via the 'content' key or GetPendingMessageContent has been truncated by the server or connection manager (equivalent to Channel_Text_Message_Flag_Truncated in the Text interface).
content (s or ay)
The part's content, if it is available and sufficiently small to include here (implies that 'needs-retrieval' is false or omitted). Otherwise, omitted. If the part is human-readable text or HTML, the value for this key MUST be a UTF-8 string (D-Bus signature 's'). If the part is not text, the value MUST be a byte-array (D-Bus signature 'ay'). If the part is a text-based format that is not the main body of the message (e.g. an iCalendar or an attached XML document), the value SHOULD be a UTF-8 string, transcoding from another charset to UTF-8 if necessary, but MAY be a byte-array (of unspecified character set) if transcoding fails or the source charset is not known.
interface (s - DBus_Interface)
This part is specific to the given interface, which is neither Text nor Messages. It SHOULD be ignored if that interface is not supported. (Note that an 'interface' key can also appear on the first part, where it indicates that the entire message should be ignored if unsupported.)

It is an error for a connection manager to put these keys in the first Message_Part, but clients MUST be able to recover from this error by ignoring these keys in the first part.

 A key, which SHOULD be one of the well-known keys specified, if possible. The value corresponding to the given key, which must be of one of the types indicated.

An opaque token used to identify sent messages. As a special case, the empty string indicates that there is no particular identification for a message.

CM implementations SHOULD use an identifier expected to be unique, such as a UUID, if possible.

Some protocols can only track a limited number of sent messages in a small message-ID space. As a result, clients MUST NOT assume that message tokens will not be re-used, and SHOULD use some reasonable heuristic to assign delivery reports to messages, such as matching on message content or timestamp (if available), or assuming that the delivery report refers to the most recent message with that ID.

This is a hook for the DeliveryReporting interface, to avoid having to introduce a SendMultiPartMessageAndReturnToken method in that interface.

Submit a message to the server for sending. If this method returns successfully, the message has been submitted to the server and the MessageSent signal is emitted. A corresponding Sent signal on the Text interface MUST also be emitted.

If this method fails, message submission to the server has failed and no signal on this interface (or the Text interface) is emitted.

 The message content, including any attachments or alternatives Flags affecting how the message is sent. An opaque token used to match any incoming delivery or failure reports against this message, or an empty string if the message is not readily identifiable. The requested message is malformed and cannot be sent. Flags altering the way a message is sent. The "most usual" action should always be to have these flags unset. Provide a delivery report via the DeliveryReporting interface, if possible, even if this is not the default for this protocol. Ignored if delivery reports are not possible on this protocol. In some protocols, like XMPP, it is not conventional to request or send delivery notifications. Signals that a message has been submitted for sending. This MUST be emitted exactly once per emission of the Sent signal on the Text interface. This signal allows a process that is not the caller of SendMessage to log sent messages. The double signal-emission means that clients can safely follow the following rule: if the channel has the Messages interface, listen for Messages.MessageSent only; otherwise, listen for Text.Sent only. The message content (see Message_Part for full details). If the message that was passed to SendMessage has a formatted text part that the connection manager recognises, but no text/plain alternative, the CM MUST use the formatted text part to generate a text/plain alternative which is also included in this signal argument. An opaque token used to match any incoming delivery or failure reports against this message, or an empty string if the message is not readily identifiable. A list of incoming messages that have neither been acknowledged nor rejected. This list is a superset of the one returned by ListPendingMessages on the Text interface; its items can be removed using AcknowledgePendingMessages on that interface. The messages with the given IDs have been removed from the PendingMessages list. Clients SHOULD NOT attempt to acknowledge those messages. This completes change notification for the PendingMessages property (previously, there was change notification when pending messages were added, but not when they were removed). The messages that have been removed from the pending message list. Retrieve the content of one or more parts of a pending message. Note that this function may take a considerable amount of time to return if the part's 'needs-retrieval' flag is true; consider extending the default D-Bus method call timeout. Additional API is likely to be added in future, to stream large message parts. The ID of a pending message The desired entries in the array of message parts, identified by their position. The "headers" part (which is not a valid argument to this method) is considered to be part 0, so the valid part numbers start at 1 (for the second Message_Part).

The content of the requested parts. The keys in this mapping are positions in the array of message parts; the values are either of type 's' or 'ay' (UTF-8 text string, or byte array), following the same rules as for the value of the 'content' key in the Message_Part mappings.

If the one of the requested part numbers was greater than zero but referred to a part that had no content (i.e. it had no 'type' key or no 'content' key), it is simply omitted from this mapping; this is not considered to be an error condition.

 Either there is no pending message with the given message ID, or one of the part numbers given was 0 or too large. Signals that a message has been received and added to the pending messages queue. This MUST be emitted exactly once per emission of the Received signal on the Text interface. The double signal-emission means that clients can safely follow the following rule: if the channel has the Messages interface, listen for Messages.MessageReceived only; otherwise, listen for Text.Received only. The message content, including any attachments or alternatives