At 03:25 PM 7/4/2002 -0400, John C Klensin wrote:
(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.
Well, no. Relative to this discussion, my concern with IDN is that the
technical specification has a gaping hole -- it is missing an essential
piece of specification detail -- and that that hole pertains specifically
to the most important immediate use. So IDN is not about scope.
By contrast -- ignoring the few postings from folk who have diligently
attended to writing details that need to be fixed -- the focus of concerns
from you and Keith has exclusively been about scope that might be or
misinterpretations that might me. Notably missing, in fact, has been
discussion of technical details, except for some forays into alternative
approaches or alternative problem spaces.
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.
Lest one miss the focus of my comment on this, let me repeat it: "If there
is relaying with CONNEG support, then CONNEG is used at each hop. Just like
for DSN."
In other words, we are not breaking any architectural ground here, contrary
to the claim that has been made.
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.
CONNEG already covers your concern. If the option is required, then the
receiving MTA must commit to supporting it. If it cannot make the
commitment, then the address must be failed. If the option is optional,
then the sender leaves handling outcome to the receiver.
If you have any other relaying concerns, please state them with enough
detail to permit technical analysis and response.
Otherwise, yours and Keith's concerns reduce to a statement that you have
generic fears, without any detailed basis, and that your fears should cause
the community to slow-roll this specification.
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.
Isn't it wonderful that we sometimes do something new in the IETF?
1. We have already done hop-by-hop options that have end-to-end effect.
2. We have already done CONNEG syntax and semantics.
3. We have already done email-based CONNEG exchanges, though the mysteries
of the IETF standardization process are causing that work of more than one
year ago to finally get approved by the IESG now.
4. We have already done third-party information disclosure
mechanisms. That is, how is this conceptually different from an LDAP
lookup? For that matter, how is is different from TCP MSS
"disclosure"? It, too, causes the other participant to change what is sent.
So,
A. Yes, we are defining a way to do something that you cannot do today,
B. But the components to that mechanism all have prior existence,
C. And the mechanism involved is pretty simple,
D. And no one has yet put forward a concrete scenario that demonstrates
that the specification is flawed.
(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.
And we are notably more lax when the change is optional and incremental
and, therefore, need not be implemented except by those wishing to play in
that sandbox.
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.
If you mean something other than have a "context" label in the portion of
the response pertaining to the context, then it was not in Ned's summary.
If you believe that identification of the need for that label is somehow
strategically meaningful, then it sounds as if you expect a degree of
perfection for a Proposed Standard that is at variance with IETF
norms. For that matter, it suggests that you believe that a Last Call that
uncovers the need for any changes automatically forces the specification to
go back to square one or be classed as experimental.
You will recall that I was not the author of that particular
text, and did not think it was necessary. Clearly I was wrong.
The nice thing about statements of philosophy is that they provide a
guiding framework. The not-so-nice thing about them is that they do not
provide specific detail. Invoke philosophy in decision making, without
having any attendant detail, and all you are doing is being religious.
When you produce some technical details that demonstrate how this proposal
fails -- or better still, how it damages SMTP operation -- then invoking
that higher bit of philosophy will be warranted.
d/
----------
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
tel +1.408.246.8253; fax +1.408.850.1850