W3C home > Mailing lists > Public > ietf-discuss@w3.org > September 2000

Re: Mobile Multimedia Messaging Service

From: James P. Salsman <bovik@best.com>
Date: Sat, 16 Sep 2000 17:44:56 -0700 (PDT)
Message-Id: <200009170044.RAA27040@shell9.ba.best.com>
To: paf@cisco.com
Cc: discuss@apps.ietf.org, ietf-mmms@imc.org, ietf@ietf.org

Thanks for your message:

>... I want a more specific list of documents that you are to create,

Two documents would probably make sense:

(1) End-to-End Internet Services for Mobile Devices

Scope:  Specifications and interoperability guidelines for 
end-to-end mobile IP connection and transport services required 
for support of standard Internet messaging (e.g., TCP, UDP, ICMP, 
with general descriptions of such wireless Internet services that 
already exist), along with guidelines for TCP operation during 
indefinite wireless link downtime, determining bandwidth and link 
conditions, and a very few hardware-level specifications (e.g., 
serial cable PPP access for connected devices.)

(2) Internet Multimedia Messaging Services for Mobile Devices

Scope:  Specifications and interoperability guidelines for 
multimedia messaging using MIME-based Internet messages and 
related services on mobile devices, including application and 
session services (e.g., IMAP and POP with guidelines for their 
use in a wireless context, SMTP to and from wireless devices), 
and specific guidelines for MIME message content types and 
encodings for interoperable, unencumbered media formats (such as 
the open formats in the RTP Profile RFC 1890.)

> and the list of issues you are to discuss should also say what 
> is _NOT_ in scope of the wg.

Not in scope:  No new protocols or formats will be created. No 
specifications with any intellectual property encumbrances will 
be incorporated. No content negotiation or preference-profile 
services will be defined (as those are already within the scope 
of the conneg and rescap working groups, and the W3C Content 
Capability and Preference Profile (cc/pp) working group), 
although of course those groups and their documents would all be 
cited in the Internet Multimedia Messaging Services for Mobile 
Devices document.

> You should by the way define a "mobile client"...

Good point.

> I felt the discussion at the BOF ended up with "a client which 
> have very limited bandwidth to the network, often connected to 
> many different internet providers, limited memory and screen"

The bandwidth limitations of wireless devices these days are 
often not too bad. Ricochet/Metricom is usually never more than 
twice as slow as a typical telephone modem. (By the way, at 
least one person thinks I'm affiliated with Ricochet/Metricom; 
I am not.) 

Some of the experimental 2.5 GHz IEEE 802.11 protocol variants 
work with cells many miles in radius and are capable of shared 
bandwidths many times greater than a T1 -- for example:
(I'm not affiliated with C-Spec/Overlan, either.)

The real bandwidth issue isn't the typical bit rate; instead, 
wireless devices will for many reasons have occasional sudden 
bandwidth dips or outright link failure for extended periods of 
time. TCP parameters need to be configured to be more forgiving 
of those situations; that would be addressed in detail in the 
End-to-End Internet Services for Mobile Devices document.
Memory limitations, while real, are still keeping pace with 
Moore's Law in general, and should be expected to continue for 
some time. It might make more sense to say that mobile devices 
are less likely to have any kind of mass storage, and rely upon 
existing email session mechanisms for rejecting messages of too 
great a length, or with components in unreadable formats. Those 
concerns would be well within the scope of the Internet 
Multimedia Messaging Services for Mobile Devices document.

Screen-size is a valid user interface concern, being addressed by 
the rescap, conneg, and W3C CC/PP working groups, and I would be 
very reluctant to suggest that topic for any MMMS specifications.

Received on Saturday, 16 September 2000 20:46:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:08:09 UTC