Subject: Re: Mobile Multimedia Messaging Service

From: "James P. Salsman" <[email-masked]>
Date: Fri, 15 Sep 2000 14:52:03 -0700 (PDT)

If there has been no charter proposed for a MMMS working group, I 
intend to propose one as follows.  I would like to know how the 
Area Directors feel about the following ideas, many of which are 
informed by the comments of Patrik, Ned, and others in the Apps 
Discussion archives -- http://wilma.cs.utk.edu/mail-archive/discuss.1999-12

Proposed MMMS working group purpose:  The MMMS working group will 
produce a series of Internet-Drafts, and attempt to produce RFCs, 
describing the use of end-to-end Internet multimedia messaging and 
related services on mobile devices.  The specifications will concern 
application-level services as well as general end-to-end Internet 
service specifications and lower-level services such as non-wireless 
serial PPP access from mobile devices.  No new protocols will be 
created; only existing open Internet standards and protocols free from
any intellectual property encumbrance will be incorporated into MMMS 
specifications, along with specific implementation interoperability 
guidelines.

Proposed special document status and process for MMMS specifications:  
Recognizing that it may be impossible to achieve consensus on topics 
in which large and diverse corporate concerns have vested interests 
opposed to open standards, the MMMS working group will have a special 
goal to produce Internet-Drafts which will identified as "Frozen MMMS 
RFC-track Internet-Drafts."  These documents might never become RFCs 
because of an expected lack of consensus, but upon identification as 
such by the Working Group, they will be announced and archived as 
frozen documents.  Developers may rely on such documents as static 
and vendors and customers will be encouraged to refer to them in their 
procurement process.  The level of consensus required to designate 
Frozen MMMS RFC-track Internet-Drafts will be a simple majority of 
those working group participants who are not affiliated with 
organizations having direct or indirect financial interests in 
closed-protocol mobile services.  Any member of the working group not 
affiliated with organizations having direct or indirect financial 
interests in closed-protocol mobile services may call a vote on the 
designation of any Internet-Draft as a Frozen MMMS RFC-track 
Internet-Draft, and if after one week's time there are more such MMMS 
WG participants in favor than dissenting, the WG Chair, the author of 
the draft, or the participant calling the vote will then take steps to 
establish a permanent archive of the draft and publish an announcement 
of its availability to the IETF community.  Anyone affiliated with 
organizations having direct or indirect financial interests in 
closed-protocol mobile services may not call a vote or vote on such 
special designation, but all participants will have normal consensus 
rights in the traditional RFC process, and all Internet-Drafts must 
follow the existing IESG intellectual property disclosure process.  

Proposed milestones:  The goals of the MMMS WG will include the 
publication of specifications, as described above, on the following 
topics:  interoperable end-to-end Internet service access on mobile 
devices, including descriptions of existing end-to-end wireless 
Internet service arrangements; implementation guidelines for multimedia 
messaging services on mobile devices using existing Internet messaging 
standards; guidelines concerning performance implications of link 
constraints, including TCP behaviors during extended periods of 
wireless link downtime; and wired PPP access from mobile Internet 
devices.

Jim Mathis:  Would you be interested in chairing a MMMS working group 
charted as described above?  Would your organization's current apparent 
commitment to closed-protocol mobile messaging solutions make you an 
inappropriate chair for such a group?  If you would not want to, or do 
not feel you would be an appropriate chair, I would volunteer to serve 
as an interim chair.

Cheers,
James

> At the November meeting, about 90 people attended the Mobile 
> Multimedia Messaging Service BOF:
>
>  http://www.ietf.org/proceedings/99nov/46th-99nov-ietf-42.html
> 
> But the mailing list has been dead:
>
>  http://www.imc.org/ietf-mmms/mail-archive/threads.html
>
> MMMS-related topics seem to be fairly prevalent on the general 
> IETF discussion list, with a lot of general agreement that the 
> status quo has some real problems.
> 
> Has anyone started on a working group charter?
> 
> There needs to be an organized effort to provide explicit and 
> well-documented alternatives to the closed-protocol, 
> pseudo-internet mobile access consortia, who are a real barrier 
> to easy and reasonable mobile multimedia messaging services.  
> I for one would certainly contribute a great deal of time and 
> effort to the success of such a working group.

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 16 Sep 2000 09:35:53 +0200

At 14.52 -0700 00-09-15, James P. Salsman wrote:
>intend to propose one as follows.

I have no memory of a charter.

>wireless link downtime; and wired PPP access from mobile Internet

This is too open-ended. I want a more specific list of documents that 
you are to create, and the list of issues you are to discuss should 
also say what is _NOT_ in scope of the wg.

My personal interest is not so much in multimedia, but in a 
discussion on how one should design an application layer protocol 
(and maybe "how should one use existing protocols, like IMAP") so it 
works for "mobile" clients.

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

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", or 
something like that.

   paf

---

From: vint cerf <[email-masked]>
Date: Sat, 16 Sep 2000 08:12:13 -0400

patrik,

would it be useful, in the context of establishing peer-to-peer communications
(or even client/server communications) with limited-function mobile devices,
to use SIP as a framework for negotiating the parameters that should guide the
nature of the exchange? I'm thinking, for instance, of a web server that may
usefully discover the functional limits of a mobile before it starts to send
content to that device. The mobile uses SIP to report to the server that it
has X amount of memory, Y amount of display area, color or not, average 
data rate it can send or receive, and so on. This information would be used
by the server to configure what it sends to be compatible with the receiving
unit.

perhaps this is an idea that is already being pursued in an IETF working group?

Vint

At 09:35 AM 9/16/2000 +0200, Patrik Fältström wrote:
>This is too open-ended. I want a more specific list of documents that you are to create, and the list of issues you are to discuss should also say what is _NOT_ in scope of the wg.
>
>My personal interest is not so much in multimedia, but in a discussion on how one should design an application layer protocol (and maybe "how should one use existing protocols, like IMAP") so it works for "mobile" clients.
>
>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", or something like that.
>
>  paf

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 16 Sep 2000 15:41:16 +0200

At 08.12 -0400 00-09-16, vint cerf wrote:
>nature of the exchange?

Maybe. The rescap wg is looking into "capabilies" in a different way 
(I presume).

>I'm thinking, for instance, of a web server that may

I think "discovery" of capabilities is an interesting discussion, and 
of course it should be dealt with aswell. Some of this information 
can be handled by just looking att the tcp control block :-)

Now, I would like, to be honest, this wg to more look at what 
stupid(?) design flaws have been made in the existing protocols given 
certain capabilities than the actual discovery process. IMAP in 
disconnected mode is a good idea, maybe, but might be too chatty. 
I.e. long rtt makes chatty protocols like IMAP and SMTP (just as some 
examples) quite boring. Can something be done about that (batch 
smtp?).

Say we have a very fat pipe between earth and the moon (which current 
tcp should be able to handle). Should we run IMAP over that link 
which have quite some RTT?

What happens if we have only a 2.4k inmarsat sattelite phone with 
900ms rtt, can we still do useful stuff with normal applications 
given ppp (the solution is not to change ppp in this discussion)?

   paf

---

From: Dave Crocker <[email-masked]>
Date: Sat, 16 Sep 2000 09:23:08 -0700

>perhaps this is an idea that is already being pursued in an IETF working 

The Content Negotiation work would cover this sort of exchange, I believe.

d/

---

From: Leslie Daigle <[email-masked]>
Date: Sat, 16 Sep 2000 15:21:10 -0400

Howdy,

I think this is a Bad Idea -- particularly in conjunction with:

> procurement process.  

These documents would become de facto standards (although they won't
have had the standards-review) and they would break the paradigm
of Internet-Drafts (which is "don't implement").

If you want to get public documentation on how things are done,
it would be more suitable I think to go with traditional Informational
RFCs -- and you can label them as "Informal understanding of how to
do X", if you like.

Leslie.

-- 

-------------------------------------------------------------------
"Reality with a delicate splash of the imaginary... 
    ... or was that the other way around?"
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Leslie Daigle <[email-masked]>
Date: Sat, 16 Sep 2000 15:21:54 -0400

Howdy,

Yes, RESCAP should be doing this.  (Too many people with full
plates, not enough people poking -- so poke ;-)

Leslie.

-- 

Leslie Daigle
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 16 Sep 2000 21:49:05 -0400

Depending on the assumptions, it seems that either capability discovery
integrated with the actual protocol or a separate protocol (as in
rescap) makes sense. (Among other considerations, this depends on
requirements for setup delay, number of message exchanges or
restrictions on information access.) For interactive multimedia
communications, there is a nascent SDPng effort to describe
capabilities, with the current version of SDP being used in RTSP, SIP,
SAP and Megaco/MGCP. This work is still in the requirements stage, but
it may well borrow from the content negotiation work, but some
requirements differ somewhat.

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 16 Sep 2000 15:55:17 +0200

At 15.41 +0200 00-09-16, Patrik Fältström wrote:
>Say we have a very fat pipe between earth and the moon (which 
>current tcp should be able to handle). Should we run IMAP over that 
>link which have quite some RTT?

By the way, my examples with IMAP and SMTP might be simplistic, too simplistic.

Replace those with streaming media stuff over multicast or RTP 
or...and you get what I mean, I hope.

   paf

---

From: Graham Klyne <[email-masked]>
Date: Mon, 18 Sep 2000 09:24:19 +0100

>The Content Negotiation work would cover this sort of exchange, I believe.

See RFC 2506, RFC 2533, RFC 2534.

But also note...

There is work in W3C (CC/PP working group) that addresses exactly this 
area, from a perspective of data format.  Some initial public drafts are 
available for comment at http://www.w3.org/Mobile/CCPP/.

There was also a BOF held in Pittsburgh to garner interest in HTTP 
extensions to convey capability information described using CC/PP, and 
maybe other formats.

Both the CONNEG and CC/PP work have (rightly in my view) focused purely on 
formats for expression of capabilities.  Details of protocols for conveying 
such information may reasonably vary between applications (HTTP, SIP, 
e-mail, etc.).

#g

------------
Graham Klyne
([email-masked])

---

From: [email-masked]
Date: Mon, 18 Sep 2000 09:39:36 -0700 (PDT)

> of Internet-Drafts (which is "don't implement").

May I respectfully resubmit "don't implement" as:

"Please understand that any experience you gain implementing
this draft will be a valuable input to the standards process and
that your and others input may cause the protocol to change
substantially before it becomes a standard"

or, more succicently,

"Don't whine when this changes".

				regards,
					Ted