John C Klensin writes:
d) The header and body problems are not so interdependent that
they must be solved together.
Despite the assertion of "clear", I don't think this has yet been
demonstrated. If it could be clearly demonstrated in some way, at least
a few of us would become instantly happier with a separate and parallel
effort.
There is no way to demonstrate it. I could float a proposal right now that we
solve the 822 8-bit header problem by abandoning 822 completely and instead
encoding header information in ASN.1. This would of course break RFC-XXXX,
since it assumes no major disturbance in 822 basics.
All I can demonstrate is the fact that out of the dozen-odd proposals that
have been made, not one of them has been heavily interdependent with what's
already in RFC-XXXX. Thus, as I have said before, if someone can come up with
a serious proposal that is interdependent then delay is worth considering. But
this has not happened, and I don't propose to cross this bridge until we
come to it. We have enough of a real agenda that we don't need to all this
time on what-might-be's.
But, even if there are no *technical* interdependencies (that isn't
quite "clear" to me yet either), we have been told repeatedly on this
list that people don't want to open mail systems and start upgrading
them unless they have a menu of desired features. I am concerned about
a vendor who opens its mail systems to provide RFC-XXXX support, changes
documentation, retrains people, and does all of the other expensive
things, and then closes them up again. Will that vendor see a
sufficient internationally-sensitive market to justify going through
those costs again. By contrast, if we can launch procedures for
extended (non-ASCII) characters in headers simultaneously with RFC-XXXX
(whether they are the same document is not important), I think we can
assume that vendors who are willing to upgrade their mail systems will
just do it all at once.
First of all, the entire nature of RFC-XXXX makes this argument invalid.
RFC-XXXX is a framework. If you plan to implement it in any real way an
essential feature of such implementations is that you have to pry the box open
and leave it open. A user agent that implements RFC-XXXX without considering
the fact that it is going to be extended almost immediately is in a bad way.
Open-endness drips out of every paragraph of RFC-XXXX.
Second, my motivation for closing RFC-XXXX has nothing to do with timing. It
has to do with getting some of the load off my plate and off of everyone
else's. This group has suffered and continues to suffer from a strong tendency
to reopen closed issues over and over and over again. The reason for this is
simple -- we haven't done anything yet but heap more and more and more stuff on
our agenda. We added a whole pile of stuff in Atlanta. We will probably
continue to add more stuff in the future. It is now time to clear some space so
that we stop spinning wildly in all directions.
This group is going to self-destruct if we don't reach some sort of closure
on some issues. We have done so, more or less, with the ones that are currently
in RFC-XXXX. Let's move on.
In fact, by insisting on dealing with more of the problems now rather than
deferring them, you are in effect causing the problem you are trying to avoid.
It is only by clearing RFC-XXXX that we'll be able to deal with header issues
in a timely manner. If we do as you suggest and hold off on issuing RFC-XXXX as
a draft, but in fact say that the issues that are there are closed, a lot of
people are going to go off and implement regardless of whether we issue it as a
draft standard or not. (I'm one of them.) We will then have to deal with all
the stuff that results from not having a draft done, which will slow down
the header work. If your prediction comes true we will then be in an even
worse mess.
Before someone says "if the market isn't there, they don't deserve
these features", let me suggest that there are several features of
RFC-XXXX that would not survive if asked to stand out there on their
own.
I don't know what this is supposed to mean.
e) While both problems are important, the body problem definitely
has priority.
Depends on your perspective, obviously. At least a few of the
participants in this list care much more about plain, ordinary, mail
extended to be suitable for international use and for non-English
communications, than we do (at least short-term) in multimedia, multiple
part mail.
And this is why we intend to address both. We simply have reached partial
closure on one set of issues before the other.
It is also an historical artifact of the fact that people on this
side of the water were much more agressive and much more able to easily
express themselves in great detail and at great length in English than
some of the other actors in the drama. The WG really was initiated, if
I recall, with "international characters" as a (if not "the") principal
agenda item, and no one was saying "except in the headers" at the time.
This is NOT true. See my earlier mail on this subject. While the initial
suggestion that led to this group dealt with international characters, the
group was not tasked with this issue exclusively. Please review the early
list messages and you will see what I mean.
But even if it were true, why on earth does it matter? We are NOT disbanding
the group, for heaven's sake.
The obvious response to the situation is to get XXXX out the door before
we settle in to the battle over the header problem. Agreed that it would
be best to solve both at once.
The other possibly obvious response is to push XXXX part-way out the
door and freeze it there, "battle over the header problem", then
review XXXX to see if it needs any further changes based on what we have
learned from the header enterprise, and then push them the last few
inches out the door together. Maybe pushing XXXX in the direction of
"proposed" and holding it there until the headers are done would
accomplish exactly that, but I'd be a lot happier about that strategy if
the separability of the two issues were as clear to me as it apparently
is to you.
And I am extremely unhappy with this proposal, for the reasons I have already
given. I think this has the best chance of causing all of your dire predictions
to come true, whereas moving on to draft standard solves a lot of problems for
us all.
Ned