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