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@brandenburg.com> Brandenburg InternetWorking <http://www.brandenburg.com> tel +1.408.246.8253; fax +1.408.850.1850