Message Access Profile

Exchanged messages shall use the bMessage format. The bMessage object encapsulates the delivered message objects and additionally provides a suitable set of properties with helpful information. The general encoding characteristics as defined for vCards in Section 2 of [4] shall be applied. The formal BNF definition of the bMessage format is as follows:

<bmessage-object>::= { 
          "BEGIN:BMSG" <CRLF> 
          <bmessage-property> 
          [<bmessage-originator>]? 
          <bmessage-envelope> 
          "END:BMSG" <CRLF> 
} 
<bmessage-property>::=<bmessage-version-property> 
          <bmessage-readstatus-property> <bmessage-type-property> 
          <bmessage-folder-property> 

<bmessage-version-property>::="VERSION:" 
          <common-digit>*"."<common-digit>* <CRLF> 
<bmessage-readstatus-property>::="STATUS:" 'readstatus' <CRLF> 
<bmessage-type-property>::="TYPE:" 'type' <CRLF> 
<bmessage-folder-property>::="FOLDER:" 'foldername' <CRLF> 

<bmessage-originator>::= <vcard> <CRLF> 

<bmessage-envelope> ::= { 
          "BEGIN:BENV" <CRLF> 
          [<bmessage-recipient>]* 
          <bmessage-envelope> | <bmessage-content> 
          "END:BENV" <CRLF> 
} 
<bmessage-recipient> ::= <vcard> <CRLF> 

<bmessage-content>::= { 
          "BEGIN:BBODY"<CRLF> 
          [<bmessage-body-part-ID> <CRLF>] 
          <bmessage-body-property> 
          <bmessage-body-content>* <CRLF> 
          "END:BBODY"<CRLF> 
} 
<bmessage-body-part-ID>::="PARTID:" 'Part-ID' 
<bmessage-body-property>::=[<bmessage-body-encoding-property>] 
          [<bmessage-body-charset-property>] 
          [<bmessage-body-language-property>] 
          <bmessage-body-content-length-property> 

<bmessage-body-encoding-property>::="ENCODING:"'encoding' <CRLF> 
<bmessage-body-charset-property>::="CHARSET:"'charset' <CRLF> 
<bmessage-body-language-property>::="LANGUAGE:"'language' <CRLF> 
<bmessage-body-content-length-property>::= 
          "LENGTH:" <common-digit>* <CRLF> 

<bmessage-body-content>::={ 
          "BEGIN:MSG"<CRLF> 
          'message'<CRLF> 
          "END:MSG"<CRLF> 
} 

The following conventions shall be applied for the bMessage properties:

bmessage-version-property:

The value for this property shall be "VERSION:1.0 <CRLF>", which is the present bMessage version 1.0.

bmessage-originator:

This property includes a vCard identifying the originator (i.e., the original sender of the message (see also definition of 'vCard' property below)).

For an email, the following rules shall apply:

bmessage-recipient:

This property includes a vCard identifying the recipient of the messages (see also definition of 'vCard' property below).

In the case of an email, all the recipients in the MIME 'to:' field shall have their own bmessage-recipient property. When sending a message, the MSE shall also parse the MIME 'cc:' and 'bcc:' fields and apply the correct behavior for those recipients as defined in 5322 [14].

bmessage-readstatus-property:

The property value shall be either "READ" or "UNREAD", indicating whether a message has been read or not by the MCE. During a MAP session, the MCE shall be responsible for setting this status (see Sections 4.2 and 5.7). An MSE shall not change this status during a MAP session without initiation by the user or a connected MCE device. The initial status when starting a MAP session is 'read' if the message has already been read on the MSE.

bmessage-type-property:

The property value shall be one of the following:

bmessage-folder-property:

This is the folder name including the path where the bMessage is located in. Any folder within the MSE folder structure may be used for this property as described in Section 3.1.3.2 (e.g., "telecom/msg/inbox"). This property shall be restricted to 512 bytes. If the path and folder description exceeds this length, the name of the addressed folder and the highest possible folder layers above shall be delivered. If the bMessage is used for an upload (PushMessage function, see Section 5.8), the MCE should send an empty bmessage-folder-property and the MSE should discard this property to avoid redundancy with the ‘name’ header’ of the PushMessage function.

bmessage-body-part-ID:

This property shall be used if and only if the content of the related message cannot be delivered completely within one <bmessage-content> object (i.e., in case of a fragmented email). The part-ID of the first <bmessage-content> object shall be 0; the following <bmessage-content> objects shall have a part-ID incremented by 1 each. The range of this value shall be 0 to 65535 accordingly, restricting the number of fractions to this maximum.

bmessage-body-charset-property:

This is the character set used by the message object contained by <bmessage-body-content>. This property shall be used only if the message contains textual content. For detailed requirements, see description of the <bmessage-body-content property> below.

bmessage-body-encoding-property:

This is the encoding used by the message object contained by <bmessage-body-content>. The property shall have one of the following values:

For detailed requirements, see description of the <bmessage-body-content> property below.

bmessage-body-language-property:

This is the language of the message. This property may be used if the message includes textual content. The property shall have one of the following values:

vCard:

The allowed properties for a vCard [4], [5] in a bMessage shall be the following:

All the other vCard properties shall not be used. The properties may be empty if not known (e.g., N/FN in case of an SMS).

bmessage-envelope:

The maximum level of <bmessage-envelope> encapsulation shall be three. If the message originally received by the MSE has more than three encapsulation levels, the MSE shall deliver the upper three levels (i.e., the most recent ones).

Figure 3.1. bEnvelopes encapsulation in a bMessage

bmessage-body-content-length-property:

This is the overall length of the related <bmessage-body-content> objects(s) in bytes, where the length counting starts with the "B" of the first occurrence of "BEGIN:MSG" and ends with the <CRLF> of the last occurrence of "END:MSG"<CRLF>.

bmessage-body-content:

The <bmessage-body-content> shall be constructed according to the type of message contained therein as indicated by the mandatory <bmessage-type-property>. The conversion shall be done by the MSE according to the following requirements:

Hereunder is an example of a bMessage of the type EMAIL with status UNREAD:

BEGIN:BMSG 
VERSION:1.0
STATUS:UNREAD
TYPE:EMAIL
FOLDER:TELECOM/MSG/INBOX
     BEGIN:VCARD
          VERSION:2.1
          N:Mat
          EMAIL:ma@abc.edu
     END:VCARD
     BEGIN:BENV
          BEGIN:VCARD
               VERSION:2.1
               N:Tanaka
               EMAIL:tanaka@def.edu
          END:VCARD 
          BEGIN:BENV 
               BEGIN:VCARD 
                    VERSION:2.1 
                    N:Laurent 
                    EMAIL:laurent@ghi.edu 
               END:VCARD 
               BEGIN:BBODY
                    ENCODING:8BIT 
                    LENGTH:125 
               BEGIN:MSG 
                         Date: 20 Jun 96
                         Subject: Fish
                         From: tanaka@def.edu 
                         To: laurent@ghi.edu

                         Let's go fishing!
                         BR, Mat
                    END:MSG 
               END:BBODY
          END:BENV 
     END:BENV
END:BMSG

Below is an example of a bMessage embedded with a native SMS-Deliver PDU containing the message “Let’s go fishing!”.

BEGIN:BMSG 
        VERSION:1.0
        STATUS:UNREAD
        TYPE:SMS_GSM
        FOLDER:TELECOM/MSG/INBOX
        BEGIN:VCARD
                VERSION:2.1
                N:Joachim
                TEL:00498912345678
        END:VCARD
        BEGIN:BENV
                BEGIN:BBODY 
                         ENCODING:G-7BIT 
                         LENGTH: 96 
                         BEGIN:MSG 
                                 0191000E9100949821436587000011303231 
                                 12928211CC32FD34079DDF20737A8E4EBBCF21 
                         END:MSG
                END:BBODY
        END:BENV
END:BMSG 

Support for ‘Message Format Version 1.1’ is advertised in the MapSupportedFeatures bits (see Sections 7.1.1, 7.1.2, and 6.4.1). To support backward compatibility, none of the additional attribute names and values shall be included in a bMessage that is sent to an MCE or MSE device that does not advertise support for ‘Message format Version 1.1’ in its MapSupportedFeatures bits.

The MSE shall not return messages of type ’IM’ if the MCE does not claim support for ‘Message Format Version 1.1’ in its MapSupportedFeatures bits.

If the ‘Message Format Version 1.1’ MapSupportedFeatures bit is set on the MCE and MSE device, then the bMessage object shall be defined according to the following DTD (Document Type Definition [15]):

<bmessage-object>::= { 
     "BEGIN:BMSG" <CRLF> 
     <bmessage-property> 
     [<bmessage-originator>]? 
     <bmessage-envelope> "END:BMSG" <CRLF> 
} 
<bmessage-property>::=<bmessage-version-property> 
     <bmessage-readstatus-property> <bmessage-type-property> 
     <bmessage-folder-property> <bmessage-extendeddata-property> 

<bmessage-version-property>::="VERSION:" 
     <common-digit>*"."<common-digit>* <CRLF> 
<bmessage-readstatus-property>::="STATUS:" 'readstatus' <CRLF> 
<bmessage-type-property>::="TYPE:" 'type' <CRLF> 
<bmessage-folder-property>::="FOLDER:" 'foldername' <CRLF> 
<bmessage-extendeddata-property>::="EXTENDEDDATA:" 'extendeddata' <CRLF> 

<bmessage-originator>::= <vcard> <CRLF> 

<bmessage-envelope> ::= { 
     "BEGIN:BENV" <CRLF> 
     [<bmessage-recipient>]* 
     <bmessage-envelope> | <bmessage-content> 
     "END:BENV" <CRLF> 
} 
<bmessage-recipient> ::= <vcard> <CRLF> 

<bmessage-content>::= { 
      "BEGIN:BBODY"<CRLF> 
      [<bmessage-body-part-ID> <CRLF>] 
      <bmessage-body-property> 
      <bmessage-body-content>* <CRLF> 
      "END:BBODY"<CRLF> 
} 
<bmessage-body-part-ID>::="PARTID:" 'Part-ID' 
<bmessage-body-property>::=[<bmessage-body-encoding-property>] 
      [<bmessage-body-charset-property>] 
      [<bmessage-body-language-property>] 
      <bmessage-body-content-length-property> 

<bmessage-body-encoding-property>::="ENCODING:"'encoding' <CRLF> 
<bmessage-body-charset-property>::="CHARSET:"'charset' <CRLF> 
<bmessage-body-language-property>::="LANGUAGE:"'language' <CRLF> 
<bmessage-body-content-length-property>::= 
      "LENGTH:" <common-digit>* <CRLF> 

<bmessage-body-content>::={ 
      "BEGIN:MSG"<CRLF> 
      'message'<CRLF> 
      "END:MSG"<CRLF> 
} 

The conventions of ‘Message Format Version 1.0’ apply to ‘Message Format Version 1.1’ (see Section 3.1.3). The rest of this section defines only the additions to ‘Message Format Version 1.1’.

The following conventions shall be applied for the ‘bMessage Format Version 1.1’ properties:

bmessage-version-property:

The value for this property shall be "VERSION:1.1<CRLF>" if the MSE and MCE support the feature ‘Message Format Version 1.1’.

bmessage-type-property:

The property value ‘IM’ shall only be used if the MSE and MCE support the ‘Message Format Version 1.1’ feature.

vCard:

bMessage-extendeddata-property:

bmessage-body-encoding-property:

bmessage-body-content:

Example of a bMessage with the type IM:

BEGIN:BMSG
     VERSION:1.1
     STATUS:UNREAD
     TYPE:IM
     FOLDER:TELECOM/MSG/INBOX
     EXTENDEDDATA:0:3;
     BEGIN:VCARD
           VERSION:2.1
           N:L;Marry
           X-BT-UCI:whateverapp:497654321@s.whateverapp.net
     END:VCARD
     BEGIN:BENV
           BEGIN:VCARD
                VERSION:2.1
                N:S.;Alois
                X-BT-UCI:whateverapp:4912345@s.whateverapp.net
           END:VCARD
           BEGIN:BBODY
                ENCODING:8BIT
                LENGTH:
                BEGIN:MSG
                       Date: Fri, 1 Aug 2014 01:29:12 +01:00
                       From: whateverapp:497654321@s.whateverapp.net
                       To: whateverapp:4912345@s.whateverapp.net
                       Content-Type: text/plain;

                       Happy birthday
                END:MSG
           END:BBODY
     END:BENV
END:BMSG

The Messages-Listing object is defined according to the following DTD (Document Type Definition) [15]:

<!DTD for the MAP Messages-Listing Object-->

<!DOCTYPE MAP-msg-listing [

<!ELEMENT MAP-msg-listing ( msg )* >
<!ATTLIST MAP-msg-listing version CDATA #FIXED "1.0">

<!ELEMENT msg EMPTY>
<!ATTLIST msg
        handle CDATA #REQUIRED
        subject CDATA #REQUIRED
                datetime CDATA #REQUIRED
        sender_name CDATA #IMPLIED
        sender_addressing CDATA #IMPLIED
        replyto_addressing CDATA #IMPLIED
        recipient_name CDATA #IMPLIED
        recipient_addressing CDATA #REQUIRED
        type CDATA #REQUIRED
        size CDATA #REQUIRED
        text (yes|no) "no"
        reception_status CDATA #REQUIRED
        attachment_size CDATA #REQUIRED
        priority (yes|no) "no"
        read (yes|no) "no"
        sent (yes|no) "no"
        protected (yes|no) "no"
>
]>

where the parameters shall be used as described below:

At least one of these types shall be supported by the MSE.

The parameters above shall not occur in the Messages-Listing object if its delivery is suppressed actively by the parameter-mask attribute in the GetMessagesListing function (see Section 5.5). In particular, Messages-Listing parameters marked as REQUIRED in the DTD above may be masked out.

Example of Messages-Listing object:

<MAP-msg-listing version = "1.0">
    <msg handle = "20000100001" subject = "Hello" datetime = "20071213T130510" sender_name 
= "Jamie" sender_addressing = "+1-987-6543210" recipient_addressing = "+1-0123-456789" type 
= "SMS_GSM" size = "256" attachment_size = "0" priority = "no" read = "yes" sent = "no" 
protected = "no"/> 
    <msg handle = "20000100002" subject = "Guten Tag" datetime = "20071214T092200" sender_name 
= "Dmitri" sender_addressing = "8765432109" recipient_addressing = "+49-9012-345678" type 
= "SMS_GSM" size = "512" attachment_size = "3000" priority = "no" read = "no" sent = "yes" 
protected = "no"/> 
    <msg handle = "20000100003" subject = "Ohayougozaimasu" datetime = "20071215T134326" 
sender_name = "Andy" sender_addressing = "+49-7654-321098" recipient_addressing 
= "+49-89-01234567" type = "SMS_GSM" size = "256" attachment_size = "0" priority = "no" read 
= "yes" sent = "no" protected = "no"/> 
    <msg handle = "20000100000" subject = "Bonjour" datetime = "20071215T171204" sender_name 
= "Marc" sender_addressing = "marc@carworkinggroup.bluetooth" recipient_addressing 
= "burch@carworkinggroup.bluetooth" type = "EMAIL" size = "1032" attachment_size = "0" priority 
= "yes" read = "yes" sent = "no" protected = "yes"/> 
</MAP-msg-listing> 

Support for ‘Messages-Listing Format Version 1.1’ is advertised in the MapSupportedFeatures bits. To support backward compatibility, none of the additional attribute names and values shall be included in a Messages-Listing Object that is sent to an MCE device that does not advertise support for ‘Messages-Listing Format Version 1.1’ in its MapSupportedFeatures bits.

The MSE shall not include messages of type ’IM’ if the MCE does not claim support for ‘Message Format Version 1.1’ and ‘Messages-Listing Format Version 1.1’ in its MapSupportedFeatures bits.

If the ‘Messages-Listing Format Version 1.1’ MapSupportedFeatures bit is set on the MCE and MSE device, then the Messages-Listing Object shall be defined according to the following DTD (Document Type Definition) [15]:

<!DTD for the MAP Messages-Listing Object-->

<!DOCTYPE MAP-msg-listing [ 

<!ELEMENT MAP-msg-listing ( msg )* >
<!ATTLIST MAP-msg-listing version CDATA #FIXED "1.1">

<!ELEMENT msg EMPTY> 
<!ATTLIST msg 
        handle CDATA #REQUIRED
        subject CDATA #REQUIRED
        datetime CDATA #REQUIRED
        sender_name CDATA #IMPLIED
        sender_addressing CDATA #IMPLIED
        replyto_addressing CDATA #IMPLIED
        recipient_name CDATA #IMPLIED
        recipient_addressing CDATA #REQUIRED
        type CDATA #REQUIRED
        size CDATA #REQUIRED
        text (yes|no) "no"
        reception_status CDATA #REQUIRED
        attachment_size CDATA #REQUIRED
        priority (yes|no) "no"
        read (yes|no) "no"
        sent (yes|no) "no"
        protected (yes|no) "no"
        delivery_status CDATA #IMPLIED
        conversation_id CDATA #IMPLIED
        conversation_name CDATA #IMPLIED
        direction CDATA #IMPLIED
        attachment_mime_types CDATA #IMPLIED
>
]>

The attribute rules described in Messages-Listing Object Version 1.0 (see Section 3.1.6) apply as well as the following additional parameters and values:

If the parameter "type" with the value "IM" (Instant Message) will be used, then the "conversation_id" type is mandatory.

If the parameter "type" with the value "IM" (Instant Message) will be used, then the "direction" type is mandatory.

Below is an example of a Messages-Listing object to be used when the connected MCE supports ‘Extended Messages-Listing 1.1’.

<MAP-msg-listing version="1.1">
   <msg handle="20000100001" subject="Welcome Clara Nicole” datetime="20140706T095000-0400"
sender_name="Max" sender_addressing="4924689753@s.whateverapp.net"
recipient_addressing="" type="IM" size="256" attachment_size="0" priority="no" read="no" sent="no" 
protected="no" conversation_id=”E1E2E3E4F1F2F3F4A1A2A3A4B1B2B3B4” direction=”incoming” />  
   <msg handle = "20000100002" subject= "What’s the progress Max?" 
datetime="20140705T092200+0100" sender_name="Jonas" 
sender_addressing="4913579864@s.whateverapp.net" recipient_addressing = "" type="IM" 
size="512" attachment_size="8671724" priority="no" read="yes" sent="yes" protected="no" 
conversation_id=”E1E2E3E4F1F2F3F4A1A2A3A4B1B2B3B4” direction=”incoming” 
attachment_mime_types=”video/mpeg”/> 
</MAP-msg-listing>

The MAP-Event-Report object Version 1.0 is an XML defined according to the following DTD (Document Type Definition) [15]:

<!DTD for the OBEX MAP-Event-Report object--> 

<!DOCTYPE MAP-event-report [ 

<!ELEMENT MAP-event-report ( event ) > 
<!ATTLIST MAP-event-report version CDATA #FIXED "1.0"> 

<!ELEMENT event EMPTY> 
<!ATTLIST event 
        type CDATA #REQUIRED 
        handle CDATA #IMPLIED 
        folder CDATA #IMPLIED 
        old_folder CDATA #IMPLIED 
        msg_type CDATA #IMPLIED 
> 
]>  

The values of the attributes are described in Section 3.1.7.

Below is an example of a Message Event object to be used when the connected MCE does not support Extended Event Reports.

<MAP-event-report version = "1.0"> 
<event type = "NewMessage" handle = "12345678" folder = "TELECOM/MSG/INBOX" msg_type = 
"SMS_CDMA" /> 
</MAP-event-report> 

Support for Extended Event Reports 1.1 is advertised in the MapSupportedFeatures bits. To support backward compatibility, none of the additional attribute names and values shall be included in a MAP-Event-Report that is sent to an MCE device that does not advertise support for “Extended Event Reports 1.1” in its MapSupportedFeatures bits.

The MCE shall ignore all unknown attributes and values of a 'MAP-Event-Report' object.

If the ‘Extended Event Reports 1.1’ MapSupportedFeatures bit is set, then the MAP-Event-Report object shall be an XML defined according to the following DTD (Document Type Definition) [15]:

<!DTD for the OBEX MAP-Event-Report object-->  <!DOCTYPE MAP-event-report [
<!ELEMENT MAP-event-report ( event ) >
<!ATTLIST MAP-event-report version CDATA #FIXED "1.1">
<!ELEMENT event EMPTY>
<!ATTLIST event
type CDATA #REQUIRED
handle CDATA #IMPLIED
folder CDATA #IMPLIED
old_folder CDATA #IMPLIED
msg_type CDATA #IMPLIED
datetime CDATA #IMPLIED
subject CDATA #IMPLIED
sender_name CDATA #IMPLIED
priority CDATA #IMPLIED
>
]>

The values of the attributes are described in section 3.1.7.

Below is an example of Message Event object to be used when the connected MCE supports MAP event Reports 1.1.

<MAP-event-report version = "1.1">
<event type = "NewMessage" handle = "12345678" folder ="TELECOM/MSG/INBOX"
msg_type = "SMS_CDMA" subject = "Hello" datetime = "20110221T130510"
sender_name = "Jamie" priority = "yes" />
</MAP-event-report>

Support for Extended Event Reports 1.2 is advertised in the MapSupportedFeatures bits.

The MCE shall ignore all unknown attributes and values of a 'MAP-Event-Report' object.

If at least one of the features, ‘Participant Presence Change Reporting’ or ‘Participant Chat State Change Notification’ is supported by the MSE and MCE, then ‘Extended Event Reports 1.2’ shall be used (see Section 4).

If the ‘Extended Event Reports 1.2’ MapSupportedFeatures bit is set, then the MAP-Event-Report object shall be an XML defined according to the following DTD (Document Type Definition) [15]:

<!DTD for the OBEX MAP-Event-Report object--> <!DOCTYPE MAP-event-report[
<!ELEMENT MAP-event-report ( event ) >
<!ATTLIST MAP-event-report version CDATA #FIXED "1.2">
<!ELEMENT event EMPTY>
<!ATTLIST event
type CDATA #REQUIRED
handle CDATA #IMPLIED
folder CDATA #IMPLIED
old_folder CDATA #IMPLIED
msg_type CDATA #IMPLIED
datetime CDATA #IMPLIED
subject CDATA #IMPLIED
sender_name CDATA #IMPLIED
priority CDATA #IMPLIED
conversation_name CDATA #IMPLIED
conversation_id CDATA #IMPLIED
presence_availability CDATA #IMPLIED
presence_text CDATA #IMPLIED
last_activity CDATA #IMPLIED
chat_state CDATA #IMPLIED
read_status (yes|no) "no" #IMPLIED
participant_uci CDATA #IMPLIED
extended_data CDATA #IMPLIED
contact_uid CDATA #IMPLIED
>
]>

The values of the attributes are described in Section 3.1.7.

Below is an example of a Message Event object to be used when the connected MCE supports MAP Event Reports 1.2. The event was sent because the participant with the UCI 4916579564@s.whateverapp.net was added or removed from the conversation.

<MAP-event-report version = "1.2">
<event type = "ConversationChanged" msg_type="IM" sender_name="Mads"
conversation_name=”friends”
conversation_id=”A1A2A3A4B1B2B3B4C1C2C3C4D1D2D3D4”
participant_uci=”4916579864@s.whateverapp.net”/>
</MAP-event-report>

This header shall be used by the MSE to indicate the corresponding ‘MASInstanceID’ of the MAS Instance (see Sections 3.1.7.2 and 7.1). As only one MNS service connection can be established from the MSE device to the MCE, this parameter is required by the MCE to determine for which MAS Instance this event is delivered. For further details, see Section 6.3.1.

The MCE shall indicate the request for being notified by incoming message events using this parameter. The header shall have either of the values:

For further details, see Section 6.3.1.

This header may be used to indicate the maximum number of folders listed in the <x-obex/folder-listing> object. The maximum number of entries shall be 1024 if this header is not specified.

This header may be used to indicate the offset of the first entry of the returned Folder-Listing object compared to the first entry of the Folder-Listing object that would be returned if the ListStartOffset parameter was not specified in the request. For example, if ListStartOffset is 5, then the first five listing entries are not delivered. The offset shall be 0 if this header is not specified.

This application parameter shall be used in the response if the value of MaxListCount in the request is 0. In this case, the parameter shall report the actual number of accessible folders in the current folder of the MSE. If MaxListCount = 0, the MSE shall ignore all other application parameters that may be present in the request. The response shall not contain any Body header.

This header may be used to indicate the maximum number of messages listed in the Messages-Listing object. The number of messages in the list shall not exceed the limit specified by this parameter. The maximum number of entries shall be 1024 if this header is not specified. The MessageListing object shall contain MaxListCount entries if enough entries exist, starting from ListStartOffset. For example, a request with 'ListStartOffset' = 0 and 'MaxListCount'=100 delivers the 100 most recent messages in chronological descending order.

If 'MaxListCount'=0 is in the request, the MSE shall respond with the headers "NewMessage, MSETime”, "ListingSize", “DatabaseIdentifier”, and “FolderVersionCounter" only (see descriptions of these headers below) and shall not deliver a Messages-Listing object.

This header may be used to indicate the offset of the first entry of the returned MessagesListing object. For example, if ListStartOffset is 5, then the first five messages are not delivered. The offset shall be 0 if this header is not specified.

This header may be used to indicate the maximum string-length of the "subject" parameter in the entries of the Messages-Listing object. The value range shall be 1–255.

This header may be used to indicate the parameters contained in the requested Messages-Listing objects. The MCE can use this header to receive only the relevant content of the requested Messages-Listing objects.

If this header is not specified or carries the value 0, the MSE shall return all parameters of the Messages-Listing object DTD (see Section 3.1.6) labeled as "REQUIRED" and may return all other attributes. The message handle shall always be present.

Bit i=1 indicates that the parameter related to Bit i shall be present in the requested Messages-Listing. The reserved bits shall be set to 0 by MCE and discarded by MSE.

This application parameter may be used to filter the messages that are returned in the Messages-Listing object by message type.

These application parameters may be used to filter the messages that are returned in the Messages-Listing object by delivery date.

If the feature ‘UTC Offset Timestamp Format’ is supported, then the two parameters shall be formatted in accordance to Section 3.1.10. If the feature ‘UTC Offset Timestamp Format’ is not supported, then the two parameters shall be formatted in "YYYYMMDDTHHMMSS" as defined for the OBEX "time" header in Section 2.2 of [7] (Local Time time basis). If "FilterPeriodBegin" is not specified, the returned message listing shall include the messages older than "FilterPeriodEnd". If "FilterPeriodEnd" is not specified, the returned message listing shall include the messages from "FilterPeriodBegin" to current time.

If both parameters are not specified, no messages shall be filtered out by these parameters.

If the value of "FilterPeriodBegin" is larger than the value of "FilterPeriodEnd", no messages shall be delivered.

This application parameter may be used to filter the messages that are returned in the MessagesListing object by read-status. The parameter shall have a value of "read", "unread", or "no-filtering".

This application parameter may be used to filter the messages that are returned in the Messages-Listing object by message-recipient. A related bMessage shall be included in the listing if the delivered FilterRecipient string matches a sub-string of one of the vCard attributes "N", "TEL", and "EMAIL" of at least one <bmessage-recipient> contained by this message. This parameter shall not be used if the MCE intends to select messages with any recipient. The text string in this application parameter shall be coded in UTF-8.

This application parameter may be used to filter the messages that are returned in the Messages-Listing object by message-originator. A related bMessage shall be included in the listing if the delivered FilterOriginator string matches a sub-string of one of the vCard attributes "N", "TEL", and "EMAIL" of the <bmessage-originator> contained by this message. This parameter shall not be used if the MCE intends to select messages with any originator. The text string in this application parameter shall be coded in UTF-8.

This application parameter may be used to filter the messages that are returned in the Messages-Listing object by priority. The parameter shall have a value of "high", "non-high", or "no-filtering".

If the request has been successful, the MSE shall use this parameter to indicate the presence of unread messages in the listing using this parameter. The parameter shall have a value of "Off" (meaning no unread messages) or "On" (meaning unread messages are present). For further details, see Section 6.3.1.

If the request has been successful, this application parameter shall be used in the response to report the Local Time basis of the MSE and its UTC offset, so the MCE is supported in interpreting the timestamps of the messages listing entries. The format shall be "YYYYMMDDTHHMMSS±hhmm" (e.g., for Central European Time (CET), the offset is UTC+1h, so the delivered value is "YYYYMMDDTHHMMSS+0100" where "YYYYMMDDTHHMMSS" is the current CET timestamp of the MSE). If the MSE device has no information about the current UTC time, the offset value shall not be delivered, so the delivered parameter is "YYYYMMDDTHHMMSS". For further details, see Section 6.3.1.

If the request has been successful, this application parameter shall be used in the response to report the number of accessible messages in the corresponding folder fulfilling the filter parameters (if present) as described above. If MaxListCount = 0, the MSE shall ignore the request-parameters "ListStartOffset", "SubjectLength", and "ParameterMask". In this case, the response shall not contain the Body header with the <x-bt/msg-listing> object.

See Section 3.1.14.

This application parameter may be used to filter the messages that are returned in the MessagesListing object by conversation IDs.

If this application parameter holds a value, the MessageListing object in the response shall contain all messages with this specific conversation ID from all available folders. In the MessageListing object of the response, the direction attribute shall reflect the direction of that message (see Section 3.1.6).

If this application parameter holds a value, the name header shall not hold a value and shall be ignored by the MSE.

This application parameter shall only be returned if all of the conditions are fulfilled:

The application parameter is used to detect if something has changed in the selected virtual folder. The folder version counter shall increment on every completion of changes to any of the properties in the messages in the selected folder as well as on insertion or removal of entries. The counter shall not increment if there is no change to the content and shall not take filtering into account.

If for some reason the ‘Folder Version Counter’ rolls over or starts over, a new value of the Database Identifier shall be generated. More information can be found on the Database Identifier in Section 3.1.14.

This application parameter may be used to filter the messages that are returned in the MessagesListing object by a message handle.

If this application parameter holds a value, the MessageListing object in the response shall contain only the messages with this specific message handle. In the MessageListing object in the response, the direction attribute shall reflect the direction of that message (see Section 3.1.6.1).

If this application parameter holds a value, all other application parameters aside from ParameterMask and SubjectLength shall not be present.

If this application parameter holds a value, the name header shall not hold a value and shall be ignored by the MSE. The MSE shall consider the whole message repository to be independent of the current selected folder.

This application parameter shall be used to determine the transcoding of the textual parts of the delivered bMessage-content as described in Section 3.1.3. The value shall be either

As described in Section 3.1.3, the following requirements shall be fulfilled:

This application parameter shall be used if the attachment(s) (if any) of a message is to be included in the bMessage object returned by the MSE. The value of this parameter is "Off" (no attachments) or "On" (attachments to be delivered).

The following applies:

This application parameter may be used if the message is a fractioned email as applied for some push-email services (see also Section 3.1.6 "reception_status") and shall not be used otherwise. In this case, several requests are required to retrieve the overall bMessage object. The value shall be either:

The response of the MSE on a request with value <first> shall deliver a bMessage with all parameters as defined in Section 3.1.3 with exactly one bBody object containing the first fraction of the email.

The response of the MSE on a request with value <next> shall deliver only a bBody object as defined in Section 3.1.3 containing the next fraction of the email.

If the message affected is a fractioned email but this application parameter is not present in the request, the MSE shall load the overall message from the network and deliver the message completely.

To give the best user experience, an MCE should always use the FractionRequest with the value <first> for messages with "reception_status" different from "complete". This is to avoid fetching unneeded data from the network. The user should manually trigger any further download of the message.

The MCE should be aware that a request using the <next> value can fail for messages that cannot be directly concatenated after a download of the next part (e.g., if it leads to changes of the message parts already transferred). It is recommended to do a getMessage(FractionRequest) with the value <first> for the first part of the message, and a getMessage() with no FractionRequest value to get the entire message.

This application parameter shall be present if the 'Fraction Request' parameter has been present in the related GetMessage request and shall not be used otherwise. The value shall be one of the following:

This header shall be used to indicate which status information is to be modified. The parameter value shall be one of the following:

This header shall be used to indicate the new value of the status indicator to be modified. The parameter shall have one of the values depending on the StatusIndicator:

Changing the status of a message can initiate actions on the MSE. The following rules shall be applied after the modification:

The new value of the extended data. Please refer to Section 3.1.13 for additional information.

This application parameter shall only be present if the extendedData of a message shall be changed on the MSE and the StatusIndicator application parameter contains the value “SetExtendedData”.

This parameter may be used to indicate to the MSE that no copy of the message shall be kept in the 'Sent' folder after the message was sent. This is especially useful for telematics applications (e.g., frequent sending of car's speed and position for traffic measurements (floating car data)). This application parameter is optional. The value of this parameter is "OFF" (keep messages in 'Sent' folder) or "ON" (don't keep messages in 'Sent' folder). If this parameter is not defined in the request, the MSE shall use "OFF" as the default value.

This parameter may be used to indicate whether successive attempts at sending the message shall be carried out in case the cellular network is not accessible when the message is sent from the MCE to the outbox of the MSE. This application parameter is optional. The value of this parameter is "OFF" (don not retry) or "ON" (retry). If this parameter is not defined in the request, the MSE shall use "ON" as the default value.

This application parameter shall be used to determine the transcoding of the textual parts of the delivered bMessage-content as described in Section 3.1.3. The value shall be set to one of the following:

As described in Section 3.1.3, the following requirements shall be fulfilled:

This application parameter may be used to push a message to a specific conversation instead of sending the message to the recipients contained in the bMessage vCards.

The value of this application parameter shall be the conversation ID of the conversation to which the message is added.

If this application parameter is present:

If this application parameter is not present, it is up to the MSE implementation if a new conversation is created or if the message is added to an existing conversation with the same recipients as contained in the bMessage.

This Application Parameter shall contain the message handle of the original message that shall be sent/forwarded.

This Application Parameter shall be used to indicate if the attachment(s) of the original message on the MSE shall be attached when forwarding it.

The value of this parameter is one of the following:

This application parameter shall be included if the MessageHandle application parameter is present.

This Application Parameter shall be used to indicate if the MSE shall prepend or replace the textual content of the original bMessage with the bMessage in the Body.

The value of this parameter shall be one of the following:

This application parameter shall be included if the MessageHandle application parameter is present.

The identifier of the MAS-instance for which the information is requested.

The UCI of the MAS-instance for which the information is requested.

Example:

lync:x.why@whatever.com

This header may be used to indicate the presence availability of the owner. The value shall be one of the values defined in Section 3.1.11.

This header may be used to indicate the presence text of the owner. The value shall be a string that complies with the definition in Section 3.1.11.

This header may be used to indicate the datetime of the owner’s last activity. The value shall comply with the definition in Section 3.1.10.

This header may be used to indicate the chat state of the owner. The value shall be one of the values defined in Section 3.1.12.

This header may be used to indicate a specific conversation for which the chat state of the owner should change. If this header is not present in the request, the chat state should be regarded as a conversation that is independent of the chat state of the owner. Please refer to Section 3.1.16 for the format of the Conversation ID.

If the ConversationID is unknown to the MSE or the MSE is not able to handle the ConversationID for other reasons, the MSE shall answer with a ‘Not Found’ error response (see Section 6.3.3). In that case, the MSE shall dismiss all changes from the request.

This header may be used to request the owner status for a specific conversation. If this header is not present in the request, the chat state shall be regarded as a conversation that independent of the chat state of the owner. Please refer to Section 3.1.16 for the format of the Conversation ID.

If the ConversationID is unknown to the MSE or the MSE is not able to handle the ConversationID for other reasons, the MSE shall answer with a ‘Not Found’ error response (see Section 6.3.3). In that case, the response shall not contain any headers.

This header shall contain the presence availability of the owner. The value shall be one of the values defined in Section 3.1.11.

This header shall contain the presence text of the owner. The value shall be a string that complies with the definition in Section 3.1.11. If there is no user-defined status or it is unknown, the value shall be empty.

This header shall contain the datetime of the owner’s last activity. The value shall comply with the definition in Section 3.1.10.

This header shall contain the chat state of the owner. The value shall be one of the values defined in Section 3.1.12.

This header may be used to indicate the maximum number of conversations listed in the conversation-Listing object. The number of conversations in the list shall not exceed the limit specified by this parameter. The ConversationListing object shall contain MaxListCount entries if enough entries exist, starting from ListStartOffset. For example, a request with 'ListStartOffset'=0 and 'MaxListCount'=100 delivers the 100 most recent conversations in chronological descending order.

If 'MaxListCount'=0 in the request, the MSE shall respond with the headers “ConversationListingVersionCounter”, "ListingSize", “DatabaseIdentifier”, and, if the feature “UTC Offset Timestamp Format” is not supported, “MSETime” only (see description of these headers below) and shall not deliver a Conversation-Listing object.

This header may be used to indicate the offset of the first entry of the returned Conversation-Listing object. For example, if ListStartOffset is 5, then the first five conversations are not delivered. The offset shall be 0 if this header is not specified.

These application parameters may be used to filter the conversations that are returned in the Conversation-Listing object by LastActivity.

The two parameters shall comply with the definition in Section 3.1.10. If "FilterLastActivityBegin" is not specified, the returned Conversation-Listing shall include the conversations older than "FilterLastActivityEnd". If "FilterLastActivityEnd" is not specified, the returned Conversation-Listing shall include the messages from "FilterLastActivityBegin" to current time.

If both parameters are not specified, no conversations shall be filtered out by these parameters.

If the value of “FilterLastActivityBegin” is larger than the value of “FilterLastActivityEnd”, no conversations shall be delivered.

This application parameter may be used to filter the conversations that are returned in the Conversation-Listing object by readstatus. The parameter shall have one of the values defined in the Application Parameters in Section 6.3.1.

This application parameter may be used to filter the conversations that are returned in the Conversation-Listing object by conversation-recipient. A related conversation shall be included in the listing if the delivered FilterRecipient string matches a sub-string of participant element attributes, id, or name of at least one <participant> contained by this conversation. The text string in this application parameter shall be coded in UTF-8.

The matching routine is implementation specific but it shall be flexible in regards to interpreting the text string.

The MSE shall return the ConversationListingVersionCounter application parameters in successful responses, if and only if the ‘Conversation Version Counters’ MSE and MCE feature bits are both set and MaxListCount=0 is in the request.

The application parameter is used to detect if something has changed in the Conversation-Listing. Please refer to Section 3.1.15 for additional information.

If the request has been successful, this application parameter shall be used in the response to report the number of conversations in the Conversation-Listing and (if present) the filter parameters as described above. If MaxListCount = 0, the MSE shall ignore the request-parameters "ListStartOffset". In this case, the response shall not contain the Body header with the <x-bt/MAP-convo-listing> object.

See Section 3.1.14.

This application parameter may be used to filter the messages that are returned in the Conversation-Listing object by a conversation ID.

If this application parameter holds a value, the Conversation-Listing object in the response shall contain only the conversation with this specific conversation ID.

This application parameter may be used to indicate the parameters contained in the requested Conversation-Listing objects. The MCE can use this header to receive only the relevant content of the requested Conversation-Listing objects.

If this application parameter is not specified or carries the value 0, the MSE shall return all parameters of the Conversation-Listing object DTD (see Section 3.1.9) labeled as “REQUIRED” and may return all other attributes. The conversation id shall always be present.

Bit i=1 indicates that the parameter related to Bit i shall be present in the requested Conversation-Listing. The reserved bits shall be set to 0 by the MCE and discarded by the MSE.

If Bit 5 has the value 0, the Conversation-Listing in the response shall not contain any participant element and therefore the Bits 6–14 do not have any impact.

If Bit 5 has the value 1, then at least one of the Bits 6–14 shall also have the value 1.

If any of the Bits 6–14 has the value 1, Bit 5 shall have the value 1.

If the request has been successful and the “UTC Offset Timestamp Format” is not supported, this application parameter shall be used in the response to report the Local Time basis of the MSE and its UTC offset, so the MCE is supported in interpreting the timestamps of the conversation listing entries. The format shall be "YYYYMMDDTHHMMSS±hhmm" (e.g., for Central European Time (CET) during summer, the offset is UTC+1h so the delivered value is "YYYYMMDDTHHMMSS+0100", where "YYYYMMDDTHHMMSS" is the current CET timestamp of the MSE). If the MSE device is unaware of the current UTC time, the offset value shall not be delivered, so the delivered parameter is "YYYYMMDDTHHMMSS". For more details, see Section 6.3.1.

This header is used to indicate which notifications the MCE wants from the MSE when notifications are turned “on” or “off”.

Bit i=0 indicates that the MSE shall not send the notification related to bit i for the current MAS.