Subject: RE: [UM] Proposed LEMONADE Charter

From: "Eric Burger" <[email-masked]>
Date: Mon, 14 Oct 2002 08:02:47 -0400

inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Randall Gellens
> Sent: Thursday, September 26, 2002 2:15 AM
> To: Glenn Parsons; [email-masked]
> Subject: Re: [UM] Proposed LEMONADE Charter
>
>
> 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.

done.

> 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.

I think it may be worthwhile explicitly saying that we're talking about
server processing.

How about:

4. Extend message retrieval protocols to efficiently support
limited-capability devices, including data transformation services and other
appropriate server processing.

>
> >  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.
>
> 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.

OK.  Would this be acceptable to you & Pete?

5. Define, where appropriate, translation between Internet Mail and other
messaging systems to share a common Internet mailbox service during the
other messaging systems' transition to using full Internet protocols.

-
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: Randall Gellens <[email-masked]>
Date: Mon, 14 Oct 2002 17:24:00 -0700

>  appropriate server processing.

Works for me.

>  other messaging systems' transition to using full Internet protocols.

I'm happy with it.

-