[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


At 9:21 AM +0800 7/13/04, Dave Crocker wrote:
Ted,


If I thought that we were really certain of the use cases, and certain
of what would correctly and completely cover their analysis, then this
might make sense.

However...

There are always unknowns with using a mechanism that explores new
territory.  Conperm/Conneg certainly does that and, therefore, warrants
concerns.  The combined mechanisms are frankly more complicated than I
would have liked, but they are simple as we could make them while
dealing with the requirements for originator and recipient
communications to the unknown intermediary.


Because it is new, there are no experts. So I think it is useful for a
specification to mark the boundaries of what is significantly new and,
therefore, might carry unexpected consequences.


Scott Hollenbeck and I had a chance to chat about this early today,
and one question which came up was using Experimental
RFC status for this document, rather than trying to write an
applicability statement.  If, as you say, there is no clear
set of use cases or sense of where the dragons lie, an Experimental
RFC with a later revision that did include the results of
initial experience might be useful.  I had assumed from the
existing text that the directly connected Internet fax case
was the primary use case (and certainly would be *a* use case), but
if the intent of the larger project is to map out this territory,
Experimental might make sense.


However I think that attempts to have a specification include analytic
treatises about that new territory are not very helpful.  I think
their real purpose is to make us feel as if we have duly warned the
naive reader, but frankly that is a bit paternalistic.   After all, it
is not as if we know for certain what the real dangers are.

So I'm afraid that I think the actual effects of adding significant
amounts of cautionary analysis are to make the document bigger, to
distract the implementor with material that is not needed for
implementing, and to delay issuing the specification.


There is a difference, at least to me, from saying "you must be
this tall to implement this spec", which does sound paternalistic,
and "we built this tool for this purpose and that drove the following
design choices; if you are using it for some other purpose, you
might want to check if the same design constraints apply".  That
may be pedagogy, but it is also useful context for those
implementing the spec and those reading it outside the original
working group context.

<snip>

TH> There is no citation of RFC 3238, and I do not see any discussion of the
TH> issues it raises in the text.

Again, that is a question of what pedagogy to include, versus what
technical factors to consider in the design.  Conperm/Conneg very much
reflect the technical factors raised in the the IAB paper, but the
specification does not delve into analytic pedagogy about its
application, since this is a specification rather than a treatise.

So, the content of the IAB paper is reflected in the specification,
not the form of citing it.

As noted above, adding a citation is not unreasonable. 

The citation will help.    As I noted above, I believe that some further
context of the decisions made will help those outside the working
group understand how to implement and deploy this.




TH> Would "transform of a transform" be clearer?  I.e, I allow conversion from
TH> PDF to HTML and POSTSCRIPT but prefer POSTSCRIPT;

Ahh. Yes, now I understand. And yes, it should be a concern.

My own suggestion is to add another caution within the conperm
document about this.  Something along the lines of "this could be
dangerous" with a form of the exemplary implication you describe.

Any sort of cascading sequence of actions will tend to carry this
danger, so it needs to be stated as a "proceed at your own risk"
concern.

(I'd offer candidate text but it will be a full day before I can do
that and I wanted the iteration with you quicker than that.)


So, are the protocol mechanisms in place sufficient to indicate
that a transformation has already occurred? Or are there
other ways to indicate that so the later system knows the
possible consequence?


SH>  the document
SH> permits a message intended for multiple recipients to be split according
SH> to the capabilities of the recipients and fails to specify whether the
SH> recipient
SH> list is retained or split;

In what ways is "Each version is then sent separately, to an
appropriate subset of the recipients" unclear, imprecise, inaccurate
or incomplete?

TH> I send a message to foo@xxxxxxxxxxx, bar@xxxxxxxxxxx, and baz@xxxxxxxxxxxx
TH> The message is split according to the capabilities, and one message is sent
TH> to bar@xxxxxxxxxxx, and a different message sent to foo@xxxxxxxxxxx, and
TH> baz@xxxxxxxxxxxx What in the split message to bar@xxxxxxxxxxx shows the
TH> original recipient list included foo and baz?

Huh?  The TO and CC fields show the recipient list specified by the
originator.  The RCPT-TO list contains the current subset.

There is nothing unusual about this disparity. In fact it is at the
core of the aggregation/dis-aggregation methodology of Internet mail.
It is, in fact, why the distinction between envelope list and message
content address list is essential.

So if I've missed your point, please clarify.


It wasn't clear to me that this was the method you were using.  Again,
with new territory (content transformation), I could imagine other strategies
and other problems (some already evident in some back-to-back user
agent deployments).  A simple statement that this is all that is going
would solve this problem.

<elided text discussion of larger system/how servers get information>


Why? How does this affect the normative specification.


Let's say we have a simple system:

MUA1--MSA--MTA--MTA2--MDA--MUA2

If the User discloses CONPERM information via MUA2 to the MDA
and the MDA  discloses it as a walk up the single line, we have one
security story.  If MUA2 discloses it directly to MTA2 , we have a different
security story.   The text you're responding to read:

"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."

Perhaps badly, I was trying to get out not just that the mechanism wasn't
specified, but that the actors/network elements using the mechanism
don't seem to be.  That makes it hard even for local policy to be set.
While you seem to be discouraging any non-normative text, I believe
that some example of how to deploy it so it works would be useful,
even if that is not the only way it can work and is clearly marked as such.


			regards,
				Ted Hardie