--On Friday, May 27, 2011 17:51 -0400 John R Levine
<[email protected]> wrote:
> A lot of this stuff is advice that doubtless seemed reasonable
> in 1998, but not so much now.
>...
John,
I will do whatever the WG likes but a few observations:
* We went through a long and painful process to get the
pre-evaluation document to some sort of consensus in the WG (not
that long ago). Because of the way YAM is supposed to work, I'm
a little hesitant to start making major "we want to reevaluate
how the protocol works and what advice is given" changes to
things that were in the existing document (here 4409 for five
years now), that have drawn no errata, and that were neither in
the pre-evaluation document nor identified and required by some
IETF protocol work elsewhere (in this case, the EAI discussions
that concluded the 4409 wasn't clear enough about the ability of
an MSA to change/ adapt character encodings).
* 4409 (and 2476) were designed, fairly explicitly, around a
fairly traditional MUA submission model: software residing on a
client machine communicating with a submission server over SMTP
(I refer to this as "client-side MUA" below). It does not
address, e.g., the even older model of a user logging remotely
into a machine with server capabilities (such as the ability to
maintain message queues for transmission) and accessing MUA
software that prepares messages and then hands them off to the
SMTP client, usually via something we would now call an API or
IPC function. Whether, for example, such a client-side MUA
maintains tables by which outgoing messages can be correlated
with error messages and replies, it is a property of the
environments that a user is rarely going to see an error reply
or response code except through the intermediation of that MUA.
I have far less experience than I assume you and Ned do with
regard to web-based mail clients but I imagine them to have some
of the properties of the historic server-based NUA as well as
some of the properties of the newer MUA on a client machine that
communicates with an MSA as above.
If the things you have encountered with your web scripts and web
clients are different from the advice that the WG (in the
pre-evaluation document) and Ned's experience indicate that we
should probably still be giving classical client-side MUAs, it
suggests to me that it would be far better to prepare and sort
out a "message submission for web clients, scripts, and
services" document, rather than trying to revise and patch the
4409bis discussion on short notice, during WG Last Call, and in
a relatively inactive WG. I don't have an opinion, at least yet,
as to whether that document would be a slightly different
protocol spec, an update to certain aspects of 4409bis, or an
Applicability Statement discussing the implications of 4409bis
to particular environments and situations.
I think that, if there were a commitment to developing such a
document, it would make sense to modify 4409bis to make its
assumption of the client-side MUA model clear and to indicate
that subsequent documents might describe other kinds of
submission behavior.
best,
john
p.s. A general observation about the state of YAM... To me,
4409bis is not only worth doing in and of itself, it is a bit of
a test case as to whether we can actually open up documents and
clean them up as needed to advance them in the Standard Track
(or just clean them up) without taking the opportunity to
reexamine the protocol, various bits of advice, etc. If we
cannot do that with 4409bis, I think the WG will need to look
very carefully at the value proposition associated with other
specs, especially if a two-step standards process is adopted and
essentially just redefines all of the YAM document repertoire
into full standards.
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
