Re: draft-ietf-fax-esmtp-conneg-10.txt

Ted,


TH> Apparently there has been some miscommunication on
TH> the DISCUSS position I entered for this draft.

MANY thanks for contributing to this exchange.  It's always useful to
get source material...


TH> working group; after a few rounds Scott and I asked the Chairs to take
TH> the issue to the working group, as the scope of the discussed fixes would need
TH> WG approval.

Consulting the working group is, of course, fine.

However it would be helpful to get answers to the questions I sent you,
since they were targeted at getting enough detail to permit formulating
text to resolve your concerns.
.
Forgive me for noting the continuing of a response to requests for
details about the requirements being imposed on the working group.


TH> raised.  Dave agreed that a reference to the OPES docs would be useful,

Given the difficulties obtaining clarity in this process, I must take
exception to your assertion.

I think that incorporating the analytic _concerns_ of the OPES work is
useful, not the addition of a citation to OPES. We incorporated the
concerns long ago. In fact I believe there is no significant utility to
the citation, but it does not hurt anything to add it. It does, however,
hurt things to have our interactions misunderstood.


TH> but does not see the need for any text elucidating the mechanisms in this
TH> light.

The specification has an obligation to be clear.  It does not have an
obligation to include a tutorial on a general topic.   In fact such
material is more likely to distract the implementor.


TH> The "copy of a copy" problem I mentioned above might be
TH> better called "transform of a transform".  ...
TH>   I did not see a way around that problem with the
TH> mechanisms provided nor did I see a description of it for those who might
TH> deploy this mechanism.

That's why I said that adding a generic reference to the issue is
reasonable.


TH> The third issue was around whether the group was using the
TH> standard SMTP methods for recipient splitting or using new methods; Dave
TH> has assured me that the standard mechanisms are intended.

Not "intended", Ted.  The specification has no "intention" to modify or
comment on standard SMTP practise. And, indeed, is therefore has no text
on the matter.

It does not help a specification to includes text saying all the things
it is NOT specifying.

This is, apparently, another example of your wanting tutorial text on
SMTP basics in the specification.


TH> An explicit pointer to them in the text might be useful, but I am
TH> happy to drop the point.

Thank you.


TH> The last issue is that the document does not describe how the
TH> SMTP service gets CONNEG data in the first place (even at the example
TH> level),

You have yet to explain why a specification for a couple of components
for an overall service is expected to describe the rest of the service.

For that matter, Ted, was there something incomplete or inaccurate about
my own response to the hypothetical scenario that you sent me before?


TH> Since there is no description of which system is expected
TH> to be the point of injection, there seems to be a possibility that MTA3 might
TH> get a direct injection via relationship with MUA2 and also data from the MDA.
TH> What does it do in that case?  A mention of the problem in the text would
TH> be valuable, and at least *a* solution (though not necessarily the 
TH> only solution)

Really?  It helps to have a specification for one part of a system
provide a partial specification to another part of the system that
really should be done fully in an independent effort?

This is an example of the slippery slope that bloats a specification
with material that is frankly out of its scope.


TH>  I have suggested that
TH> Experimental status might be appropriate,

And it might not.

It would help if you responded to my observation that this mechanism
does not create any new capabilities for mis-behavior.

Intermediaries can (and do) already mess things up.


TH>  I have also suggested using an applicability
TH> statement (essentially, porting Appendix A to that role)

Appendix A is a tailored technical specification, not an applicability
statement.

And you have not actually said what needs to be in the applicability
statement or why.

For example, to know how to constrain applicability, it is necessary to
have a description from you of the mis-applications of this mechanism
that are to be avoided.

Please note that I have been asking you for such detail.


TH>  Dave
TH> seems concerned that I have not made what it takes to satisfy the issue--any
TH> of the above would.

And that is why I have bothered to re-hash my detailed points about the
_lack_ of sufficient detail from you.

Forgive me, but none of "the above" that you cite actually has much
substance with respect to the specification. So responding to it is
really an effort at guessing.


TH>  If the working group chose to make no changes, I would
TH> suggest an IESG note highlighting the issues before publication

Or you could write the text now, thereby showing us what will satisfy
you, and then the working group can decide whether to include it.  (I'll
make a prediction that the answer will be yes.)


TH> ; that might or
TH> might not be the consensus  position of the IESG if I proposed it.

If there is anyone else on the IESG who share your specific concerns,
they have not voiced them.

I offered text intended to respond to the concerns documented from other
ADs and have not yet been told that those formulations are unacceptable.



d/
--
 Dave Crocker <mailto:[email protected]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>