Subject: Re: Mobile Multimedia Messaging Service

From: "James P. Salsman" <[email-masked]>
Date: Sat, 16 Sep 2000 17:44:56 -0700 (PDT)

Patrik,

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:
  http://www.overlan.com/pages/prod/rf11plus.html
(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.

Cheers,
James

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 17 Sep 2000 23:19:32 +0859 ()

James;

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

"End-to-end" means to do things at the end of the communication
as much as possible.

In this case of interactive multimedia communication, there is human
involvement. So, the end to select service is beyond mobile device
in human brain.

Users choose proper URL for his terminal capability.

Users do not want to be annoyed by the result of negotiation by
*INTELLIGENT* intermediate systems.

Users do not want to be annoyed by delay for the negotiation.

And, at the other side of the communication, users can't provide
so much variation of the content.

						Masataka Ohta

PS

Of course, people in telephone companies do not do it end to end
but may want to call it end to end.

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 17 Sep 2000 17:03:50 +0200

>serial cable PPP access for connected devices.)

I think this must be syncronized with the work of the PILC wg. See 
http://www.ietf.org/html.charters/pilc-charter.html.

    paf

---

From: Allison Mankin <[email-masked]>
Date: Sun, 17 Sep 2000 15:24:30 -0400

> http://www.ietf.org/html.charters/pilc-charter.html.

Patrik, thanks for drawing attention to this.  Other activities
in the same arena that TSV has going on are ROHC and a proto-working
group (we'll be airing a draft charter for it soon) about end2end
considerations in mobility.  It had a BOF (craps) in Pittsburgh, but the
scope of any WG will be more focuses than the BOF was.

ROHC: http://www.ietf.org/html.charters/rohc-charter.html

CRAPS: http://www2.ietf.org/proceedings/00jul/minutes/craps-00jul.txt

Allison

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 17 Sep 2000 21:00:55 -0500

Patrik and I had a rapid-fire in-room discussion after the MMMS BOF in
Washington. I walked away with the understanding that MMMS, or something
like MMMS, would have the same role in the APPS area as PILC has in TSV.

This was a sound-byte, of course, and not a charter, but it made sense to me
at the time.

And, just FYI, there is a certain amount of hand-waving in appendices of the
PILC ERROR document, for instance, about the limits of what PILC can
accomplish without a corresponding effort at the application level. Patrik's
example of application-level stop-and-wait protocols ("enter userid", "enter
password", etc.) shows the kind of interaction that TCP can't fix (if you
wait a full round-trip for an answer before asking the next question and
waiting some more, it doesn't really matter what TCP is trying to do
underneath you, and heaven forbid you are doing this over geosynchronous
satellite hops).

If there was an MMMS, we would definitely hand this text off to MMMS (we're
TSV weenies, after all).

Spencer, PILC co-chair

----- Original Message -----
From: Allison Mankin <[email-masked]>
To: Patrik Fältström <[email-masked]>
Cc: James P. Salsman <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Sunday, September 17, 2000 2:24 PM
Subject: Re: Mobile Multimedia Messaging Service

> -
> This message was passed through [email-masked], which
> is a sublist of [email-masked]. Not all messages are passed.
> Decisions on what to pass are made solely by Harald Alvestrand.

---

From: Mohsen BANAN-Public <[email-masked]>
Date: Mon, 18 Sep 2000 01:07:00 -0700 (PDT)

To: The Internet Technical Community

>>>>> On Sat, 16 Sep 2000 17:44:56 -0700 (PDT), "James P. Salsman" <[email-masked]> said:

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

  James> Scope:  Specifications and interoperability guidelines for 
  James> end-to-end mobile IP connection and transport services required 
  James> for support of standard Internet messaging ...

The beauty of the Internet End-to-End model is that people don't have
to wait for the IETF to create a working group, a charter, a chair,
, blessings, .... to move forward.

Remember the web (http, ...)? 
What was IETF's role in Internet's main modern application?

As far as the domain of Internet services for mobile devices go, the
key issue is "Efficiency".

Completely outside of the IETF but in the tradition of Internet
technical community which includes:

	- Stable and wide publication (RFC publication)
        - Patent-Free Specification
        - Open working group protocol development and maintenance

A large body of work exists which addresses the Mobile Messaging
area. 

It is called 
    
     LEAP: Lightweight and Efficient Application Protocol.

To fully describe our vision of the Mobile Messaging industry, there
is a 200 page document called:

     "The LEAP Manifesto"

The LEAP Manifesto addresses every topic so far touched on in this
thread -- and a great deal more.

Those who believe in the IETF's exclusivity in protocol development
can start from scratch and form yet another working group, write yet
another charter, and go and talk, ...

Those who want to build good things and move forward fast, can evaluate
the merits of LEAP and participate in its evolution and enhancement.

The starting point URL is: http://www.leapforum.org/

The main current areas of work for LEAP are:

    - Efficient Security Services
    - Compact Markup Languages
    - Portation of the reference implementation to additional
      platforms

Those interested are invited to join the relevant mailing lists.

In the early stages of formation of an industry, competition amongst
open protocols is healthy. 

...Mohsen.

---

From: "James P. Salsman" <[email-masked]>
Date: Mon, 18 Sep 2000 01:29:57 -0700 (PDT)

Patrik,

Thank you for your reply:

>>... guidelines for TCP operation during
>> indefinite wireless link downtime....
> 
> http://www.ietf.org/html.charters/pilc-charter.html

Yes, the next document milestone from PLIC seems to have been delayed:

 Done	Draft on asymmetric network paths.
 Oct 99	Draft of TCP Over Wireless document to the IESG as BCP
 Nov 99	Document on low bandwidth links to IESG for publication as BCP.

Does anyone know who is supposed to be working on the PLIC Wireless 
document?  The closest I could find was:

  http://iceberg.cs.berkeley.edu/papers/Ludwig-FlowAdaptive/index.html

Cheers,
James

---

From: "James P. Salsman" <[email-masked]>
Date: Mon, 18 Sep 2000 01:55:21 -0700 (PDT)

Mohsen,

Thank you for your message:

> area....
>... 

Would you confirm, please, that the LEAP Efficient Mail Submission and 
Delivery protocol (EMSD) is capable of MIME messages with multimedia 
content?

I am concerned that the string "multipart" does not appear on:

  http://www.emsd.org/dataCom/emsd/emsdRfcs/emsdp-rfc/split/node10.html

Cheers,
James

---

From: Mohsen BANAN-Public <[email-masked]>
Date: Mon, 18 Sep 2000 02:27:58 -0700 (PDT)

>>>>> On Mon, 18 Sep 2000 01:55:21 -0700 (PDT), "James P. Salsman" <[email-masked]> said:

  >> The starting point URL is: http://www.leapforum.org/

  James> Would you confirm, please, that the LEAP Efficient Mail Submission and 
  James> Delivery protocol (EMSD) is capable of MIME messages with multimedia 
  James> content?

Confirmed.

Please see sections 6.2.1 and 6.2.2 of RFC-2524, pages (58-62).

  James> I am concerned that the string "multipart" does not appear on:

  James>   http://www.emsd.org/dataCom/emsd/emsdRfcs/emsdp-rfc/split/node10.html

"multipart" as a string, is a value. 

Structure of the Body is through MIME.

...Mohsen.

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 18 Sep 2000 13:11:00 +0100 (BST)

> , blessings, .... to move forward.

well, sure, if you don't mind moving forward all by yourself.

> What was IETF's role in Internet's main modern application?

standardising TCP and MIME. Standardising HTTP (RFC2616 and earlier.)

Quite a lot, even if you think the web's just a convergence of
developments from SGML to GIF.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Sep 2000 17:44:05 -0700

> What was IETF's role in Internet's main modern application?

You mean aside from MIME?
--
Eliot Lear
[email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 19 Sep 2000 09:51:42 +0859 ()

Mohsen;

> , blessings, .... to move forward.

Yes, in this case, people are using different URLs already.

It is solved at the so far end of communication that it works
even with iMODE or WAP without the Internet end-to-end model.

> What was IETF's role in Internet's main modern application?

The role is to delay IANA resigtration trying to keep influential
power on application protocols but resulting only to make IANA
registration less important.

> key issue is "Efficiency".

No. It is wrong to assume that bandwidth for mobile devices is
limited forever.

Simplicity is the key issue.

						Masataka Ohta