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

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Feb 2003 13:27:47 -0800

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:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850

-
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: Ted Hardie <[email-masked]>
Date: Tue, 25 Feb 2003 14:13:55 -0800

At 12:51 PM 2/25/2003 -0800, Dave Crocker wrote:
>opening paragraph.

I don't know if something I said gave you that impression, but
it should not have.  I contributed text during a previous round
of discussions on the charter (before the last Lemonade BoF);
among them was the text you cited.  This was not an action
of the IAB; it was my personal suggestion.  If that was confusing
to anyone, I'm sorry that they did not seek clarification at the time.

>I am seriously dismayed to hear that.

If it were true, it would be a concern. I hope this puts that concern
to rest.

>  From an offline

I think chartering the working group to look at the problem, rather
than over-specifying the details is the right way to go here.  If
you think just about link characteristics for a moment, I think
you'll see that there are situations where non-congestive
loss might be more important than the available capacity of
the link.  This doesn't mean we should change the charter
to include the language; it means we should let the working
group figure it out.

>the same content over different *underlying* environments is relaying.

I agree that gatewaying implies transformation.  I think there
is a large rathole in trying to describe "Moving the same content
over different *underlying* environments" because there are
different ways of understanding what "same content" means.
I'd like to see us avoid that rathole entirely.

>what the specific issues and goals are.)

Of the cc list of your message, I'd suggest "[email-masked]"
as the appropriate place to discuss the matter.

                                         regards,
                                                 Ted Hardie

-

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Feb 2003 16:19:42 -0800

Ted,

>>I gather that the IAB is frankly dictating the current wording of the
TH> I don't know if something I said gave you that impression, but

Dandy.  (I was working from explicit comments from others, but am
delighted that such forces have not been at work.)

TH> I think chartering the working group to look at the problem, rather
TH> than over-specifying the details is the right way to go here.

Sometimes it is helpful, or even necessary, to have the charter provide
details about the solution choices. But this does not appear to be one
of those times, and I am not suggesting otherwise.

However, the charter DOES need to make clear what problems are to be
solved. And it needs to say them with enough specificity to be
meaningful.  It simply is not enough to say that we will wander in the
space of "different" link characteristics, for example.  What kinds of
differences?

To put it even more simply, the charter should make clear what will be
possible AFTER the working group spends its millions of dollars that was
not possible -- or not acceptably efficient -- BEFORE.

(And, yes, millions -- -- even the most modest IETF standard carries an
aggregate cost in that range)

TH>  If
TH> you think just about link characteristics for a moment, I think
TH> you'll see that there are situations where non-congestive
TH> loss might be more important than the available capacity of
TH> the link.  This doesn't mean we should change the charter
TH> to include the language; it means we should let the working
TH> group figure it out.

It is fine for a chartered working group to figure out HOW to solve a
problem. However it is dangerous for a working group to be left to
decide WHAT problem to solve.  The first paragraph runs this risk.  Of
course, the task list, later, is nicely constraining, except for the
MMS/WAP reference.

TH> I agree that gatewaying implies transformation.  I think there
TH> is a large rathole in trying to describe "Moving the same content
TH> over different *underlying* environments" because there are
TH> different ways of understanding what "same content" means.
TH> I'd like to see us avoid that rathole entirely.

Can't.  Sorry.

I've just spent a couple of years helping the IMPP group get hopelessly
lost because it did not come to grips with this specific question -- in
writing -- before doing its specification work.

We need to be very, very clear about what interworking we are seeking.
I entirely agree that "same content" has a lot of gray area, but a
failure to delineate the specifics now will not make things any easier
later.  It is more likely to make things more difficult.

>>(Glad to thrash this privately with you, in an effort to come up with
TH> Of the cc list of your message, I'd suggest "[email-masked]"

The offer was for efficiency, not privacy. glad to make the sausage in
public.

d/

-

---

From: Randall Gellens <[email-masked]>
Date: Tue, 25 Feb 2003 17:11:46 -0800

At 1:27 PM -0800 2/25/03, Dave Crocker wrote:

>  "link characteristics of concern are those of high latency and low
>  bandwidth,

Links with high latency and/or low bandwidth (my understanding is 
that with 3G, bandwidth isn't as much of a concern as latency).

>   the device characteristics are limited memory and processing
>  power,

Indeed.

>   and the service environments are environments are MMS/WAP."

MMS looks like email with a few extra features, some of which are 
generally useful (such as forward without download, content 
transformation, streaming) and some of which are very 
telephony-specific (such as anonymous messaging and reply-charging). 
As currently defined, MMS client-server protocols run on WAP; MMS 
itself looks very much like Internet email, with a few major 
exceptions, including the use of X-MMS-* headers to carry information 
and requests that are normally carried in the SMTP envelope or within 
standard headers.  Also, delivery and disposition reports are 
specified as unstructured text messages. This is likely to cause 
serious interoperability issues, especially with Internet email.  If 
we had a way to deploy true Internet email that met most of the needs 
of MMS, it could become an alternative to the WAP method, an 
alternative that offered far superior interoperability.  It would 
also have those MMS features which are generally useful.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Frequently, people can tell you they've read a book and
liked it, but they can't tell you why.  We don't want the
reader to have to do the hard work of figuring that out.
                    --Duncan Smith, creator of NoveList.
-
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: Dave Crocker <[email-masked]>
Date: Tue, 25 Feb 2003 19:58:22 -0800

Randall,

>>   and the service environments are environments are MMS/WAP."

RG> MMS looks like email with a few extra features, some of which are 
RG> generally useful ... MMS
RG> itself looks very much like Internet email, with a few major 
RG> exceptions,

Ok.

So...

What IS it that Lemonade is suppose to do with MMS?

Again, my immediate assumption is to define a formal gateway semantic,
but apparently that's not what is planned?

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

-

---

From: Randall Gellens <[email-masked]>
Date: Tue, 25 Feb 2003 21:53:42 -0800

>  but apparently that's not what is planned?

I think a gateway is useful, likely essential short-term, but I think 
more useful long-term would be allowing use of real Internet email.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Implementation is the sincerest form of flattery.
-

---

From: Randall Gellens <[email-masked]>
Date: Tue, 25 Feb 2003 22:32:59 -0800

At 10:11 PM -0800 2/25/03, [email-masked] wrote:

>  A completely open-ended charter deliverable to "make
>  Internet mail into MMS" is simply not acceptable.

And I wouldn't want that either.  But if we can make Internet mail 
better in constrained environments, I think it gets better for 
everyone.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Justify my text?  I'm sorry but it has no excuse.
-

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Feb 2003 22:50:54 -0800

Randall,

Tuesday, February 25, 2003, 9:53:42 PM, you wrote:
>>  but apparently that's not what is planned?

RG> I think a gateway is useful, likely essential short-term, but I think
RG> more useful long-term would be allowing use of real Internet email.

Excellent.  This is exactly the type of issue that needs to be surfaced
BEFORE starting to do the work.

They are two different projects.

The might be done in parallel. They might be done in sequence. The first
might anticipate the second. But they are entirely different projects.

A gateway might benefit from cooperation by the MMS community, but it
does not strictly require it. However anything that changes the MMS
environment clearly DOES need critical-path cooperation from the MMS
community.

d/

-

---

From: "Milt Roselinsky" <[email-masked]>
Date: Wed, 26 Feb 2003 07:15:01 -0800

MMS has gone a long way to solve some of the
problems encountered by the combination of expensive
bandwidth and limited capability clients.  Within
the limitations of MMS' presentation and transcoding
capabilities, interoperability with Internet email
exists and works fairly well.

Others have taken the approach that with minor adaptations, Internet
email can be made "mobile network friendly".  Examples
of this are the messaging deployments in Japan.  

I would hope that LEMONADE will work on both better 
interoperability with existing mobile messaging solutions,
and required updates to adapt Internet email for mobile
applications.

Best regards,
Milt

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Dave Crocker
> Sent: Tuesday, February 25, 2003 7:58 PM
> To: Randall Gellens
> Cc: Dave Crocker; Ted Hardie; IETF LEMONADE (E-mail)
> Subject: Re: [UM] Re: WG Review: Enhancements to Internet email to
> support diverse service environments (lemonade)
> 
> 
> Randall,
> 
-

---

From: "Milt Roselinsky" <[email-masked]>
Date: Wed, 26 Feb 2003 09:21:11 -0800

> Sent: Tuesday, February 25, 2003 10:51 PM
> To: Randall Gellens

I agree that these are two projects, and that both would prove valuable.

Openwave has been very active in MMS in both 3GPP and OMA.  We're
eager to participate in the LEMONADE efforts.

The need for gateways has already been recognized in the MMS
community, and many MMSCs offer this option.  There are, of
course, some major billing challenges with the Internet email->MMS
path that keep many operators from opening up this interface.

Milt

-

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Feb 2003 21:47:38 -0600

Folks,

>> might anticipate the second. But they are entirely different projects.

nfmc> And both projects are already on the list of WG deliverables. We have
nfmc> deliverables intended to make Internet mail more usable in these
nfmc> sorts of environments and a deliverable intended to make Internet mail
nfmc> work better with MMS.
nfmc> I really don't see what the issue is here.

The last day's worth of email has provided quite a bit of essential
explanation and clarification, which I believe the current draft
charter is lacking.

In terms of basic goals, the recent discussion to describe two
different deliverable:

1.  Enhancements to Internet mail for better operation with
resource-constrained devices and with channels that are high latency
and/or low bandwidth

2.  Specification of a gateway between existing Internet mail and
other email services operating in such constrained environments.

I'm not quibbling about opening paragraph word-smithing, here.

I see this as a very basic and entirely essential distinction that
needs to be made explicit, so that participants can be crystal clear
about the two different activities of the working group.

The mere fact that it has taken this much work to get folks to
articulate the two different foci is reason enough to make sure the
charter is clear about the distinction.

d/

-

---

From: [email-masked]
Date: Wed, 26 Feb 2003 22:54:30 -0800 (PST)

> resource-constrained devices and with channels that are high latency

Deliverables 1, 2, and 3.

> other email services operating in such constrained environments.

Deliverable 5.

> about the two different activities of the working group.

They are completely separate deliverables already. I'm at a loss as to how they
could possibly be made more separate.

> charter is clear about the distinction.

I'm still not seeing the lack of clarity here.

				Ned
-

---

From: Ted Hardie <[email-masked]>
Date: Thu, 27 Feb 2003 10:14:12 -0800

Dave,
         I've followed up some of Ned's comments inline below.

> > about the two different activities of the working group.

Maybe I misunderstood you, but I thought you believed that the
deliverables were clear and constrained in the new version.  With
Ned's pointer to how the deliverables map to the two activities
of the group we've been discussing, I think we're back to the question
of the opening paragraph word smithing.  There's really only so
much that can be done there; we shouldn't try to include all the deliverables
in it any more than we should do the work of the working group while
drafting the charter.  About the only thing we could do more is have
an explicit forward pointer to the deliverables.  Given the strength
of the implicit forward pointer, that does not really seem needed to me.
I think we all share your desire to ensure that this group stays focused,
and we all understand the role the charter plays in helping the
chairs do that work.  I hope you share our view that the whole
charter plays that role, not just the working group description.

                         regards,
                                 Ted Hardie

-