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

[Ted Hardie <hardie@xxxxxxxxxxxx>]

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

Here's the original comment:

> In general, this does not seem adequately specified for general use. 
> A limited use
> case might be made specifically for one class of devices using SMTP 
> in a specific
> way, but this is not the approach the authors have taken.
>
> Going through the draft point by point would be exhausting, and I'm not sure
> it would help.  Among the issues are:  the document allows for the conversions
> to happen off the message path, but has not dealt with the issues raised
> by the IAB in the context of OPES; the document allows for conversion
> and continuation of the use of CONPERM so that a later conversion may
> take place--creating the classic "copy of a copy" syndrome; the document
> permits a message intended for multiple recipients to be split according
> to the capabilities of the recipients and fails to specify whether 
> the recipient
> list is retained or split; the document punts completely how the SMTP service
> gets the CONNEG data in the first place, putting a critical part of the
> security story out of reach.

	After the IESG telechat in which this was discussed, Dave, Scott,
and I exchanged a couple of rounds of email on it.  During those Dave
made a point of saying that he was speaking for himself and not the
working group; after a few rounds Scott and I asked the Chairs to take
the issue to the working group, as the scope of the discussed fixes would need
WG approval.  I had thought a note was sent to Dave to let him know that
would be happening; it sounds like it did not get sent, and if that was
my fault, I apologize.
	On the substance of the problems as I raised:  the working group
apparently considered the OPES docs the IAB published, but the draft
has little explicit text on why and how the mechanisms chosen answer 
the concerns
raised.  Dave agreed that a reference to the OPES docs would be useful,
but does not see the need for any text elucidating the mechanisms in this
light.  I would like to know the working group's opinion on this point.
	The "copy of a copy" problem I mentioned above might be
better called "transform of a transform".  Imagine a document is issued
in postscript but might be transformed to html or pdf, with pdf preferred.
If the first MTA along the path transforms it to html, it might still be
transformed to pdf by a later MTA, but the result of a postscript->html->pdf
transformation is likely to have lost information compared to a postrcript->pdf
direct transformation.  I did not see a way around that problem with the
mechanisms provided nor did I see a description of it for those who might
deploy this mechanism.
	The third issue was around whether the group was using the
standard SMTP methods for recipient splitting or using new methods; Dave
has assured me that the standard mechanisms are intended.  An explicit
pointer to them in the text might be useful, but I am happy to drop the
point.
	The last issue is that the document does not describe how the
SMTP service gets CONNEG data in the first place (even at the example
level), so that someone building a system around this would have trouble
making it secure.  As a trivial example, let us imagine a message path
like this:


MUA1-->MSA---MTA1--MTA2--MTA3-MDA--MUA2

	Since there is no description of which system is expected
to be the point of injection, there seems to be a possibility that MTA3 might
get a direct injection via relationship with MUA2 and also data from the MDA.
What does it do in that case?  A mention of the problem in the text would
be valuable, and at least *a* solution (though not necessarily the 
only solution)
would be as well, if the working group knows of one.
	In the conversations prior to Scott and the Chairs asking for opinions
from the working group, the impression I got was that this document 
was primarily
intended for the use described in Appendix A, and that the dragons in 
the waters
around the other islands of use were largely unknown.  I have suggested that
Experimental status might be appropriate, with a later 
standards-track document updating
things when they are better known; I have also suggested using an applicability
statement (essentially, porting Appendix A to that role) to limit the described
use of this until we have better data.  Updates to the document, an 
experimental
status, or an applicability statement would all answer the issues I 
raised; Dave
seems concerned that I have not made what it takes to satisfy the issue--any
of the above would.  If the working group chose to make no changes, I would
suggest an IESG note highlighting the issues before publication; that might or
might not be the consensus  position of the IESG if I proposed it.
	As an aside, the OPES working group is now beginning to look
at the use of its framework with SMTP (a charter update on this has 
been discussed
in the working group), and those of you with further interest in this area may
wish to participate there as well.
			regards,
				Ted Hardie

PS.  I am not subscribed to the IETF Fax mailing list, so I would 
appreciate being
cc'ing on message which you would like me to respond to.