2.1.20 Mobile Multimedia Messaging Service (mmms) bof

Current Meeting Report

Minutes from the Mobile Multimedia Messaging Service (mmms) BOF at IETF-46

Reported by: Jim Mathis

Approximately 90 people attended the BOF. The motivation for the BOF is the emerging third-generation cellular system's need for a multimedia replacement for short text messaging. It is clear that devices that are not the current traditional personal computer will greatly increase in number over the next few years. A significant number of these non-PC devices will be constrained wireless devices. The main goal is to ensure that these constrained, primarily wireless, devices are fully integrated into the Internet mail system of content and connectivity. This is a very complex area with several possible courses of action. What, if any, actions the IETF should undertake to ensure this integration is the first decision.

Significant discussion related to the question of whether the best approach is to gateway constrained devices into the Internet mail system (like was done in the past with legacy mail systems) or attempt a tighter integration. If gatewaying is desired, the protocols beyond the gateway to the client are likely not Internet-based and a case was made for using the Wireless Application Protocol (WAP) work. Alternately, he "end-to-end argument" could suggest making constrained devices an integral part of the Internet multimedia mail system and solve whatever network/device performance-related problems exist.

The mailing list for discussions related to this area is: ietf-mmms@imc.org. To subscribe, send an email with the word "subscribe: in the body to ietf-mmms-request@imc.org.

Specific discussions at the BOF includes the following topics:

What are the boundary constraints on the scope of work?
- Device constraints (memory available [RAM and ROM], processing ability, display size [small screen]) are important.
- Network constraints (link bandwidth, latency, cost) also play a factor.
- is the multimedia service streaming or store-and-forward?
- Is this inventing a new mail system?
- Many of these constraints can be derived from a requirements effort.

There are a variety of types of client restrictions, not just network bandwidth.

What should the relationship be to IMPP?
- IMPP will utilize MIME encoding and RFC 822-style content, but has a focus on real-time and not store-and-forward messaging.
- IMPP will do presence on a separate channel, including capabilities, and the presence channel could be used to invoke services other than "chat".
- IMPP presence mechanism not really suitable as a "new mail" notification mechanism.

Current protocols (e.g., SMTP) worked fine over 56Kbs
ARPANET links, what is the problem?
- In ARPANET days, mail content was relatively small text messages. Today there is an explosion in content size, such that the SMTP protocol overhead a small part of the total transfer size.
- Landline links have relatively low latencies, not posing a real problem to chatty protocols, like SMTP.
- SMTP & POP are typically used in batch operations where delays not readily apparent to human users.
- What is the performance of online protocols, such as IMAP in a high latency environment?

The Wireless Application Protocol (WAP) Forum's PUSH working group has already solved many of the problems:
- Content transcoding can be based on device capabilities as communicated in WAP's UAPROF which is derived from CC/PP work.
- Convergence of WAP and W3C will happen.
- WAP provides light weight notifications that can be used for new mail notifications.
- UDP/TCP ports for WAP notifications have been assigned.
- WAP over the air is not Internet protocols.
- The WAP URL is http://www.wapforum.org/what/technical.htm

Should the effort be to relook at the internet mail system from the perspective of wireless devices:
- SMTP is chatty (several round-trip exchanges required to transfer a message).
- MIME encoding is verbose.

Should we produce an improved mail system that works independent of the underlying simple transport mechanism and thus suitable for wireless-specific transports, such as short message.
- One option is to tailor SMTP/IMAP to wireless devices.
- Other task is to compress MIME or have a more compact (e.g., compressed binary) representation

One implementation experience (Palm Pilot) shows that the implementation (footprint) costs of MIME and HTML is acceptable. The access protocols (e.g., POP or IMAP) are the limitations: large and chatty.

Need Application-layer PILC (Performance Implications of Link Constraints) to guide implementers and protocol designers.
- Focus on a particular application (such as email) and not just all or any application. Not clear this could be generalized sufficiently.
- Performance constraints can be divided into those of the transport and down (e.g., link) and the application and up (e.g., content).
- 30% of wireless costs are spectrum related and wireless costs 10x-20x more than wire

Location-based services were brought up. This is a natural service for mobile wireless devices, but clearly beyond the scope of multimedia messaging.

What is the relationship with other groups doing content standards:
- VPIM
- VoxML and various text-speech
- W3C steaming multimedia work

What about streaming voice content, such as an Internet phone calls? While important to cellular-type devices, streaming media is outside the scope of multimedia messaging service.

What about various universal inbox efforts?
- On the content side, its just MIME.
- On the access side, extensions are needed for universal mailbox manipulation (e.g., server-server forwarding)

Do we just need a BCP that specifies an IMAP profile (IMAP has many optional ports and extensions) along with implementation hints?

We need an architectural reference defined before going into protocol details. Include assumptions about the protocol stack running on the client.
- Is IP running on the client?
- Is there a client proxy?
- Is the focus on content and name space integration rather than mail protocol commonality/integration/gatewaying?

Slides

None received.