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(_at_)brandenburg(_dot_)com]
Sent: Tuesday, February 25, 2003 3:52 PM
To: Ted Hardie
Cc: Eric Burger; John C Klensin; ned(_dot_)freed(_at_)mrochek(_dot_)com; Pete
Resnick;
ietf(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)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(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
t +1.408.246.8253; f +1.408.850.1850