--On Wednesday, 03 July, 2002 23:18 -0700 Dave Crocker
<dhc2@dcrocker.net> wrote:
> At 01:26 AM 7/4/2002 -0400, John C Klensin wrote:
>> That is a reasonable position. But I suggest that it implies
>> either that this material should go to Experimental, rather
>> than Proposed, or that the mechanism should be defined as
>> applicable to the cases that are understood and expanded only
>> when the implications of that expansion are better
>> understood. Or...
>
> As nearly as I can tell, your position is that folks can raise
> a spectre of myriad, unspecified, abstract and unlikely
> concerns and then use that as a claim that a specification
> should not go to Proposed... Until this long list of
> negatives has been disproved.
>
> That's very creative. It also is at considerable odds with
> typical IETF criteria for advancement, John. It is also a
> heck of a good way to make sure that no proposal ever goes to
> Proposed.
>
> So, please explain what prompts such unique and extraordinary
> criteria for this simple and mundane proposal?
Dave,
I think this has ceased to be constructive, so I'm going to drop
out before the serious name-calling starts. I would suggest,
however, that you consider three things:
(i) While there are clearly some differences in the two cases,
the notion of applying an option very broadly, more broadly than
the implications are understood, and then underspecifying it a
bit, is exactly one of the things that both of us are objecting
to in the IDN situation. Now, we disagree on whether or not the
relaying cases (in particular) are poorly understood. As I
understand your position, it is that we relay things all of the
time, so this is no different and relaying is well-understood.
Mine is that we have very few cases in which options, when
applied to relaying, more or less assume end-to-end knowledge
rather than hop-by-hop processing. And when we do, I suggest
the precedent is that we carefully work out exactly what is
supposed to happen, with 8BITMIME being a reasonably good
example.
(ii) Under any theory I can construct of what is going on here,
the capabilities inquiry is expected to yield, in the normal
case, a statement about the capabilities of the destination user
agent. Capabilities of the transport subsystem are not at
issue: unlike, e.g., 8BITMIME or various DSN options, these
capabilities have to do with message format and content, not
transport properties. Asking an MTA about the capabilities and
properties of an MUA to which it will channel mail (possibly
through some delivery intermediate) is something that, as far as
I know, we have never done before. In addition, it is arguably
a non-trivial layering violation. Whatever those
characteristics imply about this proposal -- as I trust you
know, I will not resort to arguments about architectural purity
when something legitimate needs to be accomplished and the only
plausible way of doing it is architecturally-impure -- I think
they don't permit it to be characterized as "simple and mundane".
(iii) My understanding of IETF precedents is that we are
typically very careful when changes are proposed to
widely-deployed and critical infrastructure and applications.
We commonly set the bar higher for such things -- publishing as
Experimental, requiring implementation experience and/ or much
more case analysis for Proposed, etc. -- than we do for now
protocols that can't have any spillover impact. Reasonable
people can disagree as to whether a new ESTMP option carries
with it sufficient interaction risk that it should get this
closer scrutiny. But I note that this review process has
already identified (and agreed to fix) on place where CONNEG was
underspecified relative to other SMTP options. And, of course,
RFC 1425, in laying the groundwork for these extensions, says:
It must be emphasized that any extension to the SMTP
service should not be considered lightly. SMTP's
strength comes primarily from its simplicity.
Experience with many protocols has shown that:
protocols with few options tend towards ubiquity, whilst
protocols with many options tend towards obscurity.
This means that each and every extension, regardless of
its benefits, must be carefully scrutinized with respect
to its implementation, deployment, and interoperability
costs. In many cases, the cost of extending the SMTP
service will likely outweigh the benefit.
You will recall that I was not the author of that particular
text, and did not think it was necessary. Clearly I was wrong.
And I am suggesting that this proposal be scrutinized in that
light and that, in that light, _no_ SMTP extension should be
added because it is "simple and mundane".
john