RE: [UM] RE: WG Review: Enhancements to Internet email to support diverse service environments (lemonade)

["Eric Burger" <eburger@snowshore.com>]

It is unquestionably true that the motivation for the work group is to enable "lesser" access methods to work with Internet e-mail.  One may reasonably argue that optimization for a particular access method is not the work of the IETF.  That is, we usually say, "Fix the lesser access method."

However, I would offer two reasons to go ahead with the work.  The first is volume.  If one believes the projections for wireless data access, very shortly there will be orders of magnitude more "lesser"-connected devices than traditional Internet devices.  Said differently, it will be the traditional devices that will be in the minority.  By sheer economics, this may result in the marginalization of IETF protocols in favor of the more ubiquitous (and closed-process developed), explicitly-wireless protocols.

The second reason is that almost all of the extensions and adaptations proposed in the charter improves Internet mail in general.  Here are some examples.

 o  Remote submission: In the wireless environment, nobody wants to download a 40KB message to forward it.  Likewise, when I'm dialed up on my conventional PC, I don't want to download a 1MB message to forward it, either.

 o  Streaming: In the wireless environment, the latency associated with fully downloading a voice message before playing it is unacceptable.  In the conventional environment, the latency and storage associated with fully downloading a video object is unacceptable, too.

 o  Multimodal access: In the wireless environment, we get a small GUI and a TUI.  In the conventional environment, we will shortly be seeing integrated GUI, SUI (Speech User Interface), and Ink (Stylus User Interface) clients.


Dave hits upon an important point.  The goal of the work group is not to create a set of protocol extensions for some odd combination of proprietary and "walled garden" devices and networks.  The goal is to improve the Internet e-mail infrastructure in general, with the immediate goal in incorporating devices and networks of lesser capability.  We have an example of such an activity in the U.S.  The ADA law had the (intended) consequence of making access easier for EVERYONE, as well as those that are disabled.  In the same manner, the idea of lemonade is to improve e-mail for everyone.

Logical conclusion of this concept is that lemonade must not break e-mail for anyone.  Examples of what we don't want to do are creating a non-interoperable profile of SMTP or increasing the complexity of IMAP.

> -----Original Message-----
> From: Dave Crocker [mailto:dcrocker@brandenburg.com]
> Sent: Tuesday, February 25, 2003 3:52 PM
> To: Ted Hardie
> Cc: Eric Burger; John C Klensin; ned.freed@mrochek.com; Pete Resnick;
> ietf@ietf.org; iesg@ietf.org; UM list
> Subject: Re: [UM] RE: WG Review: Enhancements to Internet email to
> support diverse service environments (lemonade)
> 
> 
> Folks,
> 
> First of all, I must apologize. Sure enough, I was looking at an older
> version of the charter, in spite of having tried to avoid that error.
> The versions that I had seen listed a couple of specifics, in the task
> list portion, but it was only partial and the overall 
> document seemed to
> me to leave blind cliffs over which a WG could easily drive.
> 
> The current version lists specific actions that are clear and concise,
> except perhaps the one about gatewaying to other services 
> (more on that
> inline)
> 
> I gather that the IAB is frankly dictating the current wording of the
> opening paragraph. I am seriously dismayed to hear that. From 
> an offline
> exchange, Ned mentions a desire to have the paragraph include 
> something
> like "link characteristics of concern are those of high 
> latency and low
> bandwidth, the device characteristics are limited memory and 
> processing
> power, and the service environments are environments are MMS/WAP." I
> very heartily concur. In fact it is exactly what I think is missing.
> 
> Keeping the IAB happy is always important, but I do not believe it
> should result in a working group charter -- and especially not an
> opening paragraph -- that is more obscure. However the fact that the
> remainder of the charter is so specific moves my concern from 
> immediate
> and strong, to relatively theoretical.
> 
> Still if there is a way to enhance the opening paragraph, it really
> would be nice. Something like:
> 
>       Internet mail devices often operate with limited memory or
>       processing power, or with links that have high latency 
> and/or low
>       bandwidth. Existing Internet mail protocols are inefficient in
>       such environments. The Lemonade working group is tasked 
> to provide
>       a set of email enhancements that permit efficient operation in
>       resource-constrained computing and communication 
> environments. The
>       resulting specification(s) will be a seamless enhancement to
>       existing Internet mail.
> 
> I have not said anything about MMS/WAP because I have no idea what
> specifics are intended for dealing with them, in spite of 
> your comments.
> (Hence, for this issue, we are back to my original concern.)   More on
> that, below.
> 
> 
> Tuesday, February 25, 2003, 11:37:10 AM, you wrote:
> TH> problem here is that there are a set of services which are being
> TH> contemplated or deployed in specific environments which 
> are based on
> TH> IETF protocols but do not interoperate with them, either 
> well or at all.
> 
> and i certainly agree that we should find a way to avoid that outcome.
> 
> 
> TH> The list you saw above:  link characteristics, device 
> characteristics,
> TH> or service environments are the differences cited by 
> those operating
> TH> those service environments as reasons for wanting "profiles" of
> TH> IETF protocols that meet their needs.
> 
> and I certainly agree that the current protocols work badly 
> in a number
> of environments.
> 
> Hence, unsolicited new mail notification and re-use of server-based
> content will be spiffy enhancements.
> 
> I suspect the changes to support streaming content enhancement are
> really something more general, and will "simply" do a graceful job of
> moving the specifics of content handling to non-email subsystems,
> tailored for the particular content. At any rate, yes of course that
> will be a good enhancement too.
> 
> 
> >>      "A primary goal of this work is to ensure that those 
> profiles and
> >>      enhancements continue to interoperate with the 
> existing Internet
> >>      email protocols in use on the Internet, so that these 
> environments
> >>      and more traditional Internet users have access to a seamless
> >>      service."
> >>
> >>No doubt I am misinterpreting this, but it sure sounds as 
> if the goal is
> >>to create some sort of new email service and try to make 
> sure it can be
> >>gatewayed to existing Internet email services?
> 
> TH> Actually, avoiding the need to gateway between services is one of
> TH> my own goals for this work.
> 
> I used the term "gateway" very carefully.  It is exactly what 
> I get from
> the current wording.
> 
> My world model of interconnection is very simple: either the 
> upper-level
> service is end-to-end and homogeneous, or the interface is between
> independent, heterogeneous services. Multi-hop handling for the former
> is relaying; for the latter is is gatewaying (ie, translating). Moving
> the same content over different *underlying* environments is relaying.
> 
> From the current charter, I have no idea what is really intended,
> concerning MMS/WAP, except that the style of the current language sure
> makes me lean towards expecting gatewaying. (I'm delighted 
> that you have
> the intent of avoiding gatewaying, but now perhaps you can 
> appreciate my
> confusion.)
> 
> Perhaps the way to clarify this is to focus on what will be 
> true of the
> end participants, rather than what will not be true at the interface
> between two parts of the service?  Hence, mentioning the interface
> service because a derivative rather than a focus.
> 
> (Glad to thrash this privately with you, in an effort to come up with
> alternate language. Again, I can't offer any yet, because I can't tell
> what the specific issues and goals are.)
> 
> All of the above acknowledges that Time Is Passing(c).  Still, I've
> become totally paranoid about charters that are vague.
> 
> d/
> -- 
>  Dave <mailto:dcrocker@brandenburg.com>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  t +1.408.246.8253; f +1.408.850.1850
> 
>