OMA-TS-MMS_ENC-V1_3-20110913-A.pdf
MMS Protocol Data Units and Header Fields
Sending of Multimedia Message
The Send transaction of the MM consists of two messages: M-Send.req and M-Send.conf. The transaction identifier is created and used by the originating MMS Client and it is unique within the send transaction only.
Send Request
This chapter describes the header fields of the M-Send.req sent by the MMS Client to the MMS Proxy-Relay, and how these header fields may be modified by the sender’s MMS Proxy-Relay.
Header fields of M-Send.req PDU
| Field Name | Field Value | Necessity | Description |
|---|---|---|---|
| X-Mms-Message-Type | Message-type-value = m-send-req | Mandatory | Specifies the PDU type. |
| X-Mms-Transaction-ID | Transaction-id-value | Mandatory | A unique identifier for the PDU. This transaction ID identifies the M-Send.req and the corresponding reply only. |
| X-Mms-MMS-Version | MMS-version-value | Mandatory | The MMS version number. According to this specification, the version is 1.3. |
| Date | Date-value | Optional | Date and time of submission of the M-Send.req PDU. If the field was not provided by the sending MMS Client, the MMS Proxy-Relay SHALL insert the time of arrival of the M-Send.req PDU at the MMS Proxy-Relay. |
| From | From-value | Mandatory | Address of the originator MMS Client . The originator MMS Client MUST send either its address or an Insertaddress-token. In case of token, the MMS Proxy-Relay MUST insert the correct address of the originator MMS Client. |
| To | To-value | Optional | Address of the recipient. This header field MAY appear multiple times. |
| Cc | Cc-value | Optional | Address of the recipient. This header field MAY appear multiple times. |
| Bcc | Bcc-value | Optional | Address of the recipient. This header field MAY appear multiple times. |
| Subject | Subject-value | Optional | Subject of the MM. |
| X-Mms-Message-Class | Message-class-value | Optional | Class of the MM. Value Auto indicates a MM that is automatically generated by the client. If the field value is Auto, then the originating terminal SHALL NOT request Delivery-Report or Read-Report. If field is not present, the receiver interprets the message as personal. |
| X-Mms-Content-Class | Content-class-value | Optional | Classifies the content of the MM to the smallest content class to which the message belongs. |
| Content-Type | Content-type-value | Mandatory | The content type of the MM. |
The message body follows the MMS header.
Send Confirmation
When the MMS Proxy-Relay has received the M-Send.req PDU, it sends an M-Send.conf PDU back to the MMS Client indicating the status of the operation. The response PDU contains MMS header only.
Header fields of M-Send.conf PDU
| Field Name | Field Value | Necessity | Description |
|---|---|---|---|
| X-Mms-Message-Type | Message-type-value = m-send-conf | Mandatory | Specifies the PDU type. |
| X-Mms-Transaction-ID | Transaction-id-value | Mandatory | This transaction ID identifies the M-Send.conf and the corresponding M-Send.req only. |
| X-Mms-MMS-Version | MMS-version-value | Mandatory | The MMS version number. According to this specification, the version is 1.3. |
| X-Mms-Response-Status | Response-status-value | Mandatory | MMS specific status. |
| X-Mms-Response-Text | Response-text-value | Optional | Description which qualifies the Response-status-value. The description may be based on the status code names contained in RFC1893. |
| Message-ID | Message-ID-value | Optional | This is a unique reference assigned to the MM. This ID SHALL always be present after the MMS Proxy-Relay accepted the corresponding M-Send.req PDU. The ID enables a MMS Client to match delivery reports or read-report PDUs with previously sent MM. |
The MMS Proxy-Relay MUST always assign a Message-ID header field to the message when successfully received for delivery. The value of Message-ID shall be globally unique according to the needs of the MMS Proxy-Relay that receives the MM for delivery.
Multimedia Message Notification
MMS Notifications provide the MMS Client with information (e.g. message class and expiry time) about a MM located at the recipient MMS Proxy-Relay and waiting for retrieval. The purpose of the notification is to allow the client to automatically fetch a MM from the location indicated in the notification.
If the MMS Notification is resent at a later point in time - prior to receiving a corresponding M-Notify.Resp.ind - then this MMS Notification must be identical to the original MMS Notification.
Header fields of M-Notification.ind PDU
| Field Name | Field Value | Necessity | Description |
|---|---|---|---|
| X-Mms-Message-Type | Message-type-value =m-notification-ind | Mandatory | Specifies the PDU type. |
| X-Mms-Transaction-ID | Transaction-id-value | Mandatory | This transaction ID identifies the M-Notification.ind and the corresponding M-NotifyResp.ind |
| X-Mms-MMS-Version | MMS-version-value | Mandatory | The MMS version number. According to this specification, the version is 1.3. |
| From | From-value | Optional | Address of the last MMS Client that handled the MM, i.e. that sent or forwarded the MM. If hiding the address of the sender from the recipient is requested by the originating MMS Client and supported and accepted by the MMS Proxy-Relay, the MMS Proxy-Relay MUST NOT add this field to the M-Notification.ind PDU. The insert-address-token MUST NOT be used as the value of the field. |
| Subject | Subject-value | Optional | Subject of the message. |
| X-Mms-Message-Class | Message-class-value | Mandatory | Class of the message. The MMS Proxy-Relay MUST provide the Personal message class if the original submission did not include the X-Mms-Message-Class field. |
| X-Mms-Message-Size | Message-size-value | Mandatory | Size of the MM as defined in [TS23140] for 3GPP and [XS0016200] for 3GPP2. |
| X-Mms-Expiry | Expiry-value | Mandatory | Length of time the message will be available. The field has only one format, relative. The recipient client calculates this length of time relative to the time it receives the notification. |
| X-Mms-Content-Location | Content-location-value | Mandatory | This field defines the location of the MM to be retrieved. |
The M-Notification.ind PDU does not contain a message body.
Header fields of M-NotifyResp.ind PDU
| Field Name | Field Value | Necessity | Description |
|---|---|---|---|
| X-Mms-Message-Type | Message-type-value = mnotifyresp-ind | Mandatory | Specifies the PDU type. |
| X-Mms-Transaction-ID | Transaction-id-value | Mandatory | Identifies the transaction started by MNotification.ind PDU. |
| X-Mms-MMS-Version | MMS-version-value | Mandatory | The MMS version number. According to this specification, the version is 1.3. |
| X-Mms-Status | Status-value | Mandatory | Message status. The status Retrieved SHALL be used only after successful retrieval of the MM. |
| X-Mms-Report-Allowed | Report-allowed-value | Optional | Default: Yes. Indication whether or not the sending of delivery report is allowed by the recipient MMS Client. |
The M-NotifyResp.ind PDU has the purpose to acknowledge the transaction to the MMS Proxy-Relay.
M-NotifyResp.ind PDU doesn’t contain a message body.
Retrieval of Multimedia Message
A MMS Client SHALL request the retrieval of an MM by sending a WSP/HTTP GET request to the MMS Proxy-Relay containing a URI that indicates the location of the MM to be retrieved. The URI is the value of the X-Mms-Content-Location header field that can be received from different PDUs. Examples of such PDUs are M-Notification.ind, M-Send.conf, MForward.conf, M-Mbox-View.conf, M-Mbox-Upload.conf, M-Mbox-Store.conf.
When successful, the response to the retrieve request will be M-Retrieve.conf PDU containing MMS header and the MM.
Header fields of M-Retrieve.conf PDU
| Field Name | Field Value | Necessity | Description |
|---|---|---|---|
| X-Mms-Message-Type | Message-type-value = m-retrieve-conf | Mandatory | Specifies the PDU type. |
| X-Mms-Transaction-ID | Transaction-id-value | Conditional | Identifies either the transaction that has been started by M-Notification.ind PDU without M-Notify.Resp.ind PDU (immediate retrieval) or a new transaction when deferred retrieval was requested. This header field SHALL be present when the MMS Proxy relay seeks an acknowledgement for the MM delivered though M-Retrieve.conf PDU during deferred retrieval. This transaction ID is used by the MMS Client and MMS Proxy-Relay to provide linkage between the originated M-Retrieve.conf and the response M-Acknowledge.ind PDUs. |
| X-Mms-MMS-Version | MMS-version-value | Mandatory | The MMS version number. According to this specification, the version is 1.3. |
| Message-ID | Message-ID-value | Conditional | This is an unique reference assigned to the MM. The ID enables an MMS Client to match read report PDUs, cancel PDUs or Reply-MMs with previously sent or forwarded MM. This header field SHALL be present when the M-Retrieve.conf PDU includes the requested MM. |
| Date | Date-value | Mandatory | Date and time of latest submission or forwarding of the message by an MMS Client or reception of the MMS Proxy-Relay. |
| From | From-value | Optional | Address of the last MMS Client that handled the MM, i.e. that either sent or forwarded the MM. If hiding the address of the sender from the recipient is requested by the originating MMS Client and supported and accepted by the MMS Proxy-Relay, the MMS Proxy-Relay MUST NOT add this field to the M-Retrieve.conf PDU. The MMS Client MUST be able to process the From field if it is present, i.e. the originating MMS Client did not request address hiding. The insert-address-token MUST NOT be used as the value of the field. |
| To | To-value | Optional | Address of the recipient. This header field MAY appear multiple times. |
| Cc | Cc-value | Optional | Address of the recipient. This header field MAY appear multiple times. |
| Subject | Subject-value | Optional | Message subject |
| X-Mms-Retrieve-Status | Retrieve-status-value | Optional | MMS specific status. |
| X-Mms-Retrieve-Text | Retrieve-text-value | Optional | Description which qualifies the retrieve status value. The description may be based on the status code names contained in [RFC1893]. |
| Content-Type | Content-type-value | Mandatory | The content type of the MM. |
The message body follows the headers. In case the M-Retrieve.conf message carries the X-Mms-Retrieve-Status header field, the MMS Proxy-Relay SHALL also include a message body in the message, for backward compatibility reasons. The MMS Proxy-Relay may elaborate the description of the corresponding value of the header field in the message body. The description may be based on the status code names contained in [RFC1893].
Delivery Acknowledgement
A M-Acknowledge.ind PDU confirms the delivery of the MM to the MMS Proxy-Relay.
Header fields of M-Acknowledge.ind PDU
| Field Name | Field Value | Necessity | Description |
|---|---|---|---|
| X-Mms-Message-Type | Message-type-value = macknowledge-ind | Mandatory | Specifies the PDU type. |
| X-Mms-Transaction-ID | Transaction-id-value | Mandatory | This transaction ID identifies the M-Acknowledge.ind PDU and the corresponding M-Retrieve.conf PDU |
| X-Mms-MMS-Version | MMS-version-value | Mandatory | The MMS version number. According to this specification, the version is 1.3. |
| X-Mms-Report-Allowed | Report-allowed-value | Optional | Default: Yes. Sending of delivery report allowed to the user. |
M-Acknowledge.ind PDU does not contain a message body.
Forwarding of Multimedia Message
The forward transaction consists of the M-Forward.req message sent from the MMS Client to the MMS Proxy-Relay in order to request an MM to be forwarded that is located at the MMS Proxy-Relay and the corresponding confirmation message (M-Forward.conf) sent from the MMS Proxy-Relay to the MMS Client.
The MMS Client MUST include a unique transaction identifier in the M-Forward.req message.
Forward Request
This chapter describes the M-Forward.req message sent by the MMS Client to the MMS Proxy-Relay to request forwarding of an MMS message.
Header fields of M-Forward.req PDU
| Field Name | Field Value | Necessity | Description |
|---|---|---|---|
| X-Mms-Message-Type | Message-type-value = m-forward-req | Mandatory | Specifies the message type. |
| X-Mms-Transaction-ID | Transaction-id-value | Mandatory | A unique identifier for the forward transaction that provides linkage between the M-Forward.req and corresponding M-Forward.conf message. |
| X-Mms-MMS-Version | MMS-version-value | Mandatory | The MMS version number. According to this specification, the version is 1.3. |
| Date | Date-value | Optional | Date and time the M-Forward.req was sent to the MMS Proxy-Relay. The MMS Proxy-Relay will generate this field when not supplied by the MMS Client. |
| From | From-value | Mandatory | Address of the MMS Client that requests forwarding of the message. The forwarding MMS Client MUST send either its address or an Insert-address-token. In latter case, the MMS Proxy-Relay MUST insert the correct address of the MMS Client that forwards the message. |
| To | To-value | Optional | Address of the recipient. This header field MAY appear multiple times. |
| Cc | Cc-value | Optional | Address of the recipient. This header field MAY appear multiple times. |
| Bcc | Bcc-value | Optional | Address of the recipient.This header field MAY appear multiple times. |
| X-Mms-Content-Location | Content-location-value | Mandatory | This field specifies the location of the message to be forwarded, as received in the M-Notification.ind message. |
Forward Confirmation
When the MMS Proxy-Relay has received the Forward request (M-Forward.req message), it SHALL send a confirmation message (M-Forward.conf message) back to the MMS Client indicating the status of the operation.
Header fields of M-Forward.conf PDU
| Field Name | Field Value | Necessity | Description |
|---|---|---|---|
| X-Mms-Message-Type | Message-type-value = m-forward-conf | Mandatory | Specifies the PDU type. |
| X-Mms-Transaction-ID | Transaction-id-value | Mandatory | A unique identifier for the forward transaction that provides linkage between the M-Forward.req and corresponding M-Forward.conf PDU. It originates from the M-Forward.req PDU. |
| X-Mms-MMS-Version | MMS-version-value | Mandatory | The MMS version number. According to this specification, the version is 1.3. |
| X-Mms-Response-Status | Response-status-value | Mandatory | MMS specific status. |
| Message-ID | Message-ID-value | Optional | This is a unique reference assigned to message. This ID SHALL always be present when the MMS Proxy-Relay accepted the request to forward the MMS message. The ID enables an MMS Client to match delivery reports or read report PDUs with forwarded MMS messages. |
The MMS Proxy-Relay MUST always assign a message ID to the message when it successfully received the forwarding request. The message ID shall be globally unique according to the needs of the MMS Proxy-Relay that received the forwarding request.
Encoding Rules
In the encoding of the header fields, the order of the fields is not significant, except that X-Mms-Message-Type, X-Mms-Transaction-ID (when present) and X-Mms-MMS-Version MUST be at the beginning of the message headers, in that order, and if the PDU contains a message body the Content Type MUST be the last header field, followed by message body.
Header-field = MMS-header | Application-header
MMS-header = MMS-field-name MMS-value
Application-header = Token-text Application-specific-value
Token-text = Token End-of-string
MMS-field-name = Short-integer
Application-specific-value = Text-string
Header Field Values and Assigned Numbers
Bcc Field / Cc Field / To Field / Subject Field
Encoded-string-value
X-Mms-Content-Class Field
Content-class-value = text = <Octet 128> |
image-basic = <Octet 129> |
image-rich = <Octet 130> |
video-basic = <Octet 131> |
video-rich = <Octet 132> |
megapixel = <Octet 133> |
content-basic = <Octet 134> |
content-rich = <Octet 135> |
Date Field
Date-value = Long-integer
In seconds from 1970-01-01, 00:00:00 GMT.
Encoded-String-Value
Encoded-string-value = Text-string | Value-length Char-set Text-string
The Char-set values are registered by IANA as MIBEnum value.
UTF-8 character-set encoding SHOULD be supported in Encoded-string-value. If the MMS Client uses UTF-8 character-set encoding, the Char-set parameter SHOULD be used to indicate its usage.
Encoding according to [RFC2047] MAY be supported in the MMS Client and/or MMS Proxy-Relay. Encoding according to [RFC2047] SHOULD only be used without “Value-length Char-set” parameters. [RFC2047] encoding for UTF-8 characterset encoding MAY be supported in the MMS Client and/or MMS Proxy-Relay.
Note: The usage of Unicode character-set encoding is recommended. The supported set of actual character-sets in the MMS Client is up to the implementation. The MMS Client must not rely on the MMS Proxy-Relay doing any character-set transformation.
From Field
From-value = Value-length (Address-present-token Encoded-string-value | Insert-address-token)
Address-present-token = <Octet 128>
Insert-address-token = <Octet 129>
X-Mms-Message-Class Field
Message-class-value = Class-identifier | Token-text
Class-identifier = Personal = <Octet 128> |
Advertisement = <Octet 129> |
Informational = <Octet 130> |
Auto = <Octet 131> |
The token-text is an extension method to the message class.
X-Mms-Message-Count
Message-count-value = Integer-Value
Message-ID Field
Message-ID-value = Text-string
Encoded as in email address as per [RFC2822]. The characters “<” and “>” are not included.
X-Mms-Message-Type Field
Message-type-value = m-send-req | m-send-conf | m-notification-ind | m-notify.resp-ind | m-retrieve-conf | m-acknowledge.ind | m-delivery-ind | m-read-rec-ind | m-read-orig-ind | m-forward-req | m-forward-conf | m-mbox-store-req | m-mbox-store.conf | m-mbox-view-req | m-mbox-view-conf | m-mbox-upload-req | m-mbox-upload-conf | m-mbox-delete-req | m-mboxdelete-conf | m-mbox-descr | m-delete-req | m-delete-conf| m-cancel-req | m-cancel-conf
(from Octet 128 to Octet 151)
Unknown message types will be discarded.
X-Mms-Message-Size Field
Message-size-value = Long-integer
Message size is in octets.
X-Mms-MM-State Field
MM-state-value = Draft = <Octet 128> |
Sent = <Octet 129> |
New = <Octet 130> |
Retrieved = <Octet 131> |
Forwarded = <Octet 132> |
X-Mms-MMS-Version Field
MMS-version-value = Short-integer
The three most significant bits of the Short-integer are interpreted to encode a major version number in the range 1-7, and the four least significant bits contain a minor version number in the range 0-14. If there is only a major version number, this is encoded by placing the value 15 in the four least significant bits [WAPWSP].
X-Mms-Response-Status Field
When used in a PDU other than M-Mbox-Delete.conf and M-Delete.conf:
Response-status-value = Ok = <Octet 128>|
Error-unspecified = <Octet 129>|
Error-service-denied = <Octet 130>|
Error-message-format-corrupt = <Octet 131>|
Error-sending-address-unresolved = <Octet 132>|
Error-message-not-found = <Octet 133>|
Error-network-problem = <Octet 134>|
Error-content-not-accepted = <Octet 135>|
Error-unsupported-message = <Octet 136>|
Error-transient-failure = <Octet 192>|
Error-transient-sending-address-unresolved = <Octet 193>|
Error-transient-message-not-found = <Octet 194>|
Error-transient-network-problem = <Octet 195>|
Error-transient-partial-success = <Octet 196>|
Error-permanent-failure = <Octet 224>|
Error-permanent-service-denied = <Octet 225>|
Error-permanent-message-format-corrupt = <Octet 226>|
Error-permanent-sending-address-unresolved = <Octet 227>|
Error-permanent-message-not-found = <Octet 228>|
Error-permanent-content-not-accepted = <Octet 229>|
Error-permanent-reply-charging-limitations-not-met = <Octet 230>|
Error-permanent-reply-charging-request-not-accepted = <Octet 231>|
Error-permanent-reply-charging-forwarding-denied = <Octet 232>|
Error-permanent-reply-charging-not-supported = <Octet 233>|
Error-permanent-address-hiding-not-supported = <Octet 234>|
Error-permanent-lack-of-prepaid = <Octet 235>
X-Mms-Retrieve-Status Field
Retrieve-status-value = Ok = <Octet 128> |
Error-transient-failure = <Octet 192> |
Error-transient-message-not-found = <Octet 193> |
Error-transient-network-problem = <Octet 194> |
Error-permanent-failure = <Octet 224> |
Error-permanent-service-denied = <Octet 225> |
Error-permanent-message-not-found = <Octet 226> |
Error-permanent-content-unsupported = <Octet 227>
X-Mms-Status Field
Status-value = Expired = <Octet 128> |
Retrieved = <Octet 129> |
Rejected = <Octet 130> |
Deferred = <Octet 131> |
Unrecognised = <Octet 132> |
Indeterminate = <Octet 133> |
Forwarded = <Octet 134> |
Unreachable = <Octet 135> |
The value Unrecognised is reserved for version management purpose only.
X-Mms-Transaction-Id Field
Transaction-id-value = Text-string
Header Field Names and Assigned Numbers
Field Name Assignments
| Name | Assigned Number |
|---|---|
| Bcc | 0x01 |
| Cc | 0x02 |
| X-Mms-Content-Location | 0x03 |
| Content-Type | 0x04 |
| Date | 0x05 |
| X-Mms-Delivery-Report | 0x06 |
| X-Mms-Delivery-Time | 0x07 |
| X-Mms-Expiry | 0x08 |
| From | 0x09 |
| X-Mms-Message-Class | 0x0A |
| Message-ID | 0x0B |
| X-Mms-Message-Type | 0x0C |
| X-Mms-MMS-Version | 0x0D |
| X-Mms-Message-Size | 0x0E |
| X-Mms-Priority | 0x0F |
| X-Mms-Read-Report | 0x10 |
| X-Mms-Report-Allowed | 0x11 |
| X-Mms-Response-Status | 0x12 |
| X-Mms-Response-Text | 0x13 |
| X-Mms-Sender-Visibility | 0x14 |
| X-Mms-Status | 0x15 |
| Subject | 0x16 |
| To | 0x17 |
| X-Mms-Transaction-Id | 0x18 |
| X-Mms-Retrieve-Status | 0x19 |
| X-Mms-Retrieve-Text | 0x1A |
| X-Mms-Read-Status | 0x1B |
| X-Mms-Reply-Charging | 0x1C |
| X-Mms-Reply-Charging-Deadline | 0x1D |
| X-Mms-Reply-Charging-ID | 0x1E |
| X-Mms-Reply-Charging-Size | 0x1F |
| X-Mms-Previously-Sent-By | 0x20 |
| X-Mms-Previously-Sent-Date | 0x21 |
| X-Mms-Store | 0x22 |
| X-Mms-MM-State | 0x23 |
| X-Mms-MM-Flags | 0x24 |
| X-Mms-Store-Status | 0x25 |
| X-Mms-Store-Status-Text | 0x26 |
| X-Mms-Stored | 0x27 |
| X-Mms-Attributes | 0x28 |
| X-Mms-Totals | 0x29 |
| X-Mms-Mbox-Totals | 0x2A |
| X-Mms-Quotas | 0x2B |
| X-Mms-Mbox-Quotas | 0x2C |
| X-Mms-Message-Count | 0x2D |
| Content | 0x2E |
| X-Mms-Start | 0x2F |
| Additional-headers | 0x30 |
| X-Mms-Distribution-Indicator | 0x31 |
| X-Mms-Element-Descriptor | 0x32 |
| X-Mms-Limit | 0x33 |
| X-Mms-Recommended-Retrieval-Mode | 0x34 |
| X-Mms-Recommended-Retrieval-Mode-Text | 0x35 |
| X-Mms-Status-Text | 0x36 |
| X-Mms-Applic-ID | 0x37 |
| X-Mms-Reply-Applic-ID | 0x38 |
| X-Mms-Aux-Applic-Info | 0x39 |
| X-Mms-Content-Class | 0x3A |
| X-Mms-DRM-Content | 0x3B |
| X-Mms-Adaptation-Allowed | 0x3C |
| X-Mms-Replace-ID | 0x3D |
| X-Mms-Cancel-ID | 0x3E |
| X-Mms-Cancel-Status | 0x3F |
Content Type Assignments
| Name | Assigned Number |
|---|---|
| Push Application-ID | 4 |
| Application/vnd.wap.mms-message | Subject to IANA registration |
Parameter Name Assignments
| Token MMS Encoding | Version | Assigned Number | Expected BNF Rule for Value | Description |
|---|---|---|---|---|
| Type | 1.2 | 0x02 | Constrained-encoding | The type/format of the top level message content as provided by the WSP header field |
MMS Addressing Model
The MMS addressing model contains two addresses: the address of the MMS Proxy-Relay and the address of the recipient user and terminal. The address of the MMS Proxy-Relay shall be the URI of MMS Proxy-Relay given by the MMS service provider. Thus, the URI needs to be configurable in the terminal. A notation for the address of the recipient user in the terminal needs to be defined.
address = ( e-mail / device-address / alphanum-shortcode / num-shortcode)
e-mail = mailbox ; to the definition of mailbox as described in section 3.4 of [RFC2822], but
excluding the obsolete definitions as indicated by the “obs-“ prefix.
device-address = ( global-phone-number "/TYPE=PLMN" )
/ ( ipv4 "/TYPE=IPv4" )
/ ( ipv6 "/TYPE=IPv6" )
/ ( escaped-value "/TYPE=" address-type )
address-type = 1*address-char ; A network bearer address type [WDP]
address-char = ( ALPHA / DIGIT / "_" )
escaped-value = 1*( safe-char ) ; the actual value escaped to use only safe characters by replacing
; any unsafe-octet with its hex-escape
safe-char = ALPHA / DIGIT / "+" / "-" / "." / "%" / "_"
unsafe-octet = %x00-2A / %x2C / %x2F / %x3A-40 / %x5B-60 / %x7B-FF
hex-escape = "%" 2HEXDIG ; value of octet as hexadecimal value
global-phone-number = ["+"] 1*( DIGIT / written-sep )
written-sep =("-"/".")
ipv4 = 1*3DIGIT 3( "." 1*3DIGIT ) ; IPv4 address value
ipv6 = 4HEXDIG 7( ":" 4HEXDIG ) ; IPv6 address per RFC 2373
num-shortcode = [ ( “+” / “*” / “#”) ] 1*DIGIT
alphanum-shortcode = 1*(ALPHA / DIGIT)
Each value of a user-defined-identifier is a sequence of arbitrary octets. Some examples of the mechanism:
To: 0401234567/TYPE=PLMN
To: +358501234567/TYPE=PLMN
To: Joe User <joe@user.org>
To: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210/TYPE=IPv6
To: 195.153.199.30/TYPE=IPv4