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 09:59:49 -0800

Folks,

Thursday, January 30, 2003, 10:05:11 AM, you wrote:
EB> Executive Summary: Accept John's second proposal.  That is,
EB> take the charter as is, and insert a May 2003 deliverable of
EB> "lemonade Architecture, IESG and IETF Review, and Possible
EB> Rechartering".

I've waited to comment, because I was hoping to achieve some insight
that would allow a more directly constructive contribution. Alas, all
that has happened is time passing. Perhaps that is indicative of
something worth heeding by the WG...

With considerable regret, I find myself having to offer the following:

I believe Eric's suggestion is an excellent way to ensure that the
working group takes a long time, and is unproductive at the end of it.

        At base, the charter does not tell me what concrete problem this
        working group is solving or what use the output will be.

Here are the salient bits of text, from the opening paragraph of the
proposed charter -- and remember that the opening paragraph is
circulated independently, as the summary of the working group; therefore
it needs to summarize the problem and summarize the utility of the
output, if not also summarizing what will be done:

     "...facilitate operation in environments which use Internet-based
     technologies but which have link characteristics, device
     characteristics, or service environments that are significantly
     different from those common on the Internet..."

Excuse me, but I have not idea what this language means, and it does not
help that I was involved in the early lemonade discussions.  And, by the
way, I also do not know what link characteristics are "common" on the
Internet, what with FDDI, 10Mb ether, 802.11, cell phones, etc.,
nevermind not knowing what the new and different link characteristics
are.

So if the quoted text is supposed to refer to particular transmission
behaviors, it needs to state them clearly, and it should state what is
deficient in the existing set of specifications.

     "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?

(By the way, anyone seeking to define a gatewaying service should heed
the stellar history in the IMPP working group.)
     
So...

For this effort to be productive, the charter must be much, much more
clear and precise about the concrete, technical or operational problems
that exist and must give a concrete, constrained description of what is
going to be done to solve them.  And it must do this in simple, direct,
specific language.

Honest, I would offer some such language, but I have not succeeded at
figuring out what problems the group intends to solve or should solve.
        
d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.866-358-5301

---

From: Ted Hardie <[email-masked]>
Date: Tue, 25 Feb 2003 11:37:10 -0800

Hi Dave,
         Some comments in-line.

>      different from those common on the Internet..."

I think I contributed this text during a previous round of charter discussions;
sorry that it remains unclear.   From my point of view, the basic
problem here is that there are a set of services which are being
contemplated or deployed in specific environments which are based on
IETF protocols but do not interoperate with them, either well or at all.
The list you saw above:  link characteristics, device characteristics,
or service environments are the differences cited by those operating
those service environments as reasons for wanting "profiles" of
IETF protocols that meet their needs.  From my point of view,
we need to encourage them to do the protocol work in a way that
maintains interoperability with the core IETF protocols.  Hence

>gatewayed to existing Internet email services?

Actually, avoiding the need to gateway between services is one of
my own goals for this work.  As it stands, some of those developing
these extensions are presuming that they will be able to handle
any interoperability problem with a gateway that shifts between their
version and the big-I Internet version.   The intent of "seamless service"
was, I believe, trying to get that message across:  you should not have
to have independent application layer protocols because you have
different service environments.  Better text welcome, as always.
I personally believe that you may, however, have to describe how to
use a set of protocols in an interoperable way when there are different
service environments involved.  In so doing, you may find some
part of the set which needs update or extension.

>going to be done to solve them.  And it must do this in simple, direct,

While I would welcome this, we also have to be practical about
the scale of things we put into the charter.  I think John's proposal
was to make this an early work item, so that later work can
be more focused about the problems which give rise to
these profiles of IETF messaging standards and what we can
do solve them in an interoperable way.  I believe that knowing the
non-interoperable profiles exist is enough to identify the need
to go through that part of the exercise.
                         regards,
                                 Ted Hardie

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Feb 2003 12:51:38 -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.

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

---

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: Leslie Daigle <[email-masked]>
Date: Wed, 26 Feb 2003 10:54:45 -0500

Howdy,

> I gather that the IAB is frankly dictating the current wording of the

I don't know how you gathered this, but you'll be relieved
to know it isn't true.

There were concerns raised within the IAB and IESG with the
original phrasing of the charter, and the current text was
proposed as a revision back to the IAB and IESG as something
that addressed the concerns.  It did.  Presumably other formulations
would as well.  Your AD has the challenge of reconciling
concerns and revisions (in both directions).

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat 

Leslie Daigle
[email-masked]
-------------------------------------------------------------------