Subject: [UM] Proposed LEMONADE Charter

From: Glenn Parsons <[email-masked]>
Date: Thu, 19 Sep 2002 10:39:34 -0400

Folks,

Its been a long week :-)   Attached is the proposed charter for LEMONADE.

It covers all the comments we have received to date.  Let us know if you
support this charter or if you have further comments.

It is still our hope that we can be approved as a WG in time for the Atlanta
meeting.

Cheers,
Glenn.

---

From: Pete Resnick <[email-masked]>
Date: Sat, 21 Sep 2002 11:19:50 -0500

On 9/19/02 at 10:39 AM -0400, Glenn Parsons wrote:

>Attached is the proposed charter for LEMONADE.
>
>It covers all the comments we have received to date.  Let us know if 
>you support this charter or if you have further comments.

I've got a few:

>2. Extend message deposit and retrieval to satisfy the requirements 
>for low-bit-rate transports and limited-processing devices, such as 
>mobile endpoints.

How about instead, "Extend and/or profile message deposit and 
retrieval...."? It may be enough to make requirements on servers and 
clients to satisfy some of these needs. In other cases, extension is 
likely necessary.

>5. Define, where appropriate, translation between Internet Mail and 
>other messaging systems to share a common Internet mailbox service.

"Wouldn't it be nice", Pete asks innocently, "if instead of defining 
gateways, people just use native Internet Mail instead of these other 
messaging systems?" It might be the case that gateways are necessary. 
However, it might also be the case that these "other messaging 
systems" could simply use real Internet Mail. I'd be inclined to 
something like:

5. Extend and/or profile Internet mail services (such as SMTP) for 
use in "unified messaging" environments. If it turns out that native 
Internet mail services can not be used in such environments, define, 
where appropriate, translation between Internet Mail and other 
messaging systems to share a common Internet mailbox service.

If I've missed the point of #5, please let me know.

>The BOF will coordinate its efforts with the 3GPP TSG T WG2 SWG3 
>Messaging <http://www.3gpp.org/TB/T/T2/T2.htm> and other appropriate 
>entities, such as the W3C Mulitmodal interaction Activity 
><http://www.w3.org/2002/mmi/> and the Open Mobile Alliance 
><http://www.openmobilealliance.org/>.

Personally, I wouldn't mind if you left out the specific list of 
"external entities", but if you do include it, I see no reason to 
leave out 3GPP2.

>If IMAP-EXT gets rechartered, then the BOF will coordinate the 
>LEMONADE requirements with IMAP-EXT.  Otherwise, this BOF will 
>consider extensions to IMAP for the purposes of LEMONADE support.

I'm inclined to leave this bit out. IMAPEXT is having enough trouble 
getting it current work done. Once it is done, my inclination is to 
close it down and take up any LEMONADE work in LEMONADE or (if need 
be) to charter a new IMAP-LEMONADE group.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
-
This list is maintained by Snowshore Networks - http://www.snowshore.com
All comments on this list are the comments of the message originators and
Snowshore is not to be held responsible for any actions or comments found
on this list. The archives for this list can be found at
http://flyingfox.snowshore.com/um_archive/maillist.html

---

From: Claudio Allocchio <[email-masked]>
Date: Sun, 22 Sep 2002 23:32:38 +0100

Hallo Pete!

> clients to satisfy some of these needs. In other cases, extension is 

Yes, I agree!

> If I've missed the point of #5, please let me know.

Point 5 was pobably intented to express the need to access the single 
mailbo by services like SMS and MMS and all the 3GPP devices, who do not 
use (or do not use YET) Internet Mail Services (such as SMTP). I also 
like the idea that SMTP, IMAP S/MIME etc... becomes the transport and 
accesse protocols for all messaging systems around, but I'm afraid that 
it is unrealistic to think of SMS or MMS using SMTP or IMAP (also because 
they're deployed already in millions of devices who use something else.
However your definition includes the possibility to build gateways fo 
these (and other) services, thus I like it!

> "external entities", but if you do include it, I see no reason to 

... "coordinate its efforts with external entities such as the 3GPP... 
3GPP2, ....

> be) to charter a new IMAP-LEMONADE group.

You're the IMAP-EXT chair, thus you know better than anybody else

:-)

Claudio
-

---

From: Randall Gellens <[email-masked]>
Date: Wed, 25 Sep 2002 23:15:25 -0700

I'd suggest replacing "low-bit-rate transports" with  "low-bit-rate 
or high-latency transports", since some wireless networks have decent 
bit-rates, but still have high latency.  In such environments, a few 
extra bytes doesn't matter, but extra round-trips does.

So, to fit this with Pete's suggestion, we'd have
	1.  Extend and/or profile message deposit and retrieval to
	    satisfy the requirements for low-bit-rate or high-latency
	transports and limited-processing devices, such as mobile
	endpoints.

The problem with
	4. Extend sender/recipient device capabilities discovery protocols to
	optimise message handling according to available recipient features.

Is that it runs counter to general IETF practices to have the server 
make decisions based on the client capability, rather than have the 
server offer a menu of services from which the client chooses, based 
on its knowledge of its own capabilities.  In general, this 
server-decides approach restricts the ability to take advantage of 
new client hardware or software capabilities, because the server must 
be upgraded in order to recognize the new capabilities.  In contrast, 
an IETF "smart client" approach allows you to roll out new clients 
without updating the server.

So, I'd like to see (4) rephrased, perhaps to something like:
	Extend message retrieval protocols to efficiently support
	limited-capability devices by offering data transformation
	services.

> use in "unified messaging" environments. If it turns out that 
> native Internet mail services can not be used in such environments, 
> define, where appropriate, translation between Internet Mail and 

Looking at MMS, for example, it seems to me that it could be 
implemented using SMTP and Internet Message facilities, with a few 
extensions.  Gateways can be defined for existing implementations, 
but the intent should be to advance to using standard Internet 
protocols.  Otherwise interoperability is very hard.

>  The BOF will coordinate its efforts ...

I agree with Pete.

-