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

At 6:12 PM +0700 7/10/04, Dave Crocker wrote:
>
>SH> Ted Hardie:
>SH> Discuss:
>SH> [2004-07-06] In general, this does not seem adequately specified 
>for general
>SH> use.
>
>In general, it is not possible to remedy such a concern without
>hearing the detail behind it. Unfortunately, that was not supplied.
>

More details are below, but the primary question is:

Would you consider putting this forward with an applicability statement
that described in more detail the use cases for which this was
expected to be useful and the cases in which it is not expected
to be useful?

>
>SH>   Among the issues are:  the document allows for the
>SH> conversions
>SH> to happen off the message path,
>
>That is not what the specification says.  It says that conversions do
>not HAVE to happen "along" the message path.
>
>The point is that CONPERM is a way of stating conversion restrictions
>and that having that proscription carried all the way to the recipient
>is useful, even if no conversions are done along the path.
>

Here's the text from 2.1:

      Successful use of CONPERM does not require that
      conversion take place along the message transfer path.
      Rather, it requires that conversion take place whenever
      a next-hop server reports recipient capabilities,
      through CONNEG, and those capabilities do not include
      support for the current representation of the content.
     
      It is acceptable to have every SMTP server -- including
      the last-hop server -- support CONPERM, with none
      offering CONNEG.  In this case, the message is
      delivered to the recipient in its original form.  Any
      possible conversions to be performed are left to the
      recipient.  Hence the recipient is given the original
      form of the content, along with an explicit list of
      conversions that the originator deems acceptable.

If the intent is only to describe a use case in which CONPERM
passes from the originator to the recipient, I suggest deleting
the first paragraph above.  If the intent is to describe a
mechanism in which an MTA passes the message to
a (non-MTA) server for conversion and then along the message
path, more text on how this expected to work is needed.

>SH>  but has not dealt with the issues raised
>SH> by the IAB in the context of OPES;
>
>On the contrary, we reviewed IAB and OPES draft documents that were
>available at the time the specification was written and we factored
>those concerns in.
>
>If there are specific omissions or problems, we cannot resolve them
>unless we are told what they are.

There is no citation of RFC 3238, and I do not see any discussion of the
issues it raises in the text.  draft-ietf-opes-iab-05, currently in the
RFC Editor's queue, contains a description of how the OPES working group
saw their work in the light of the requirements it put forward. 

>By the way: Is that IAB material now a requirement for all related
>specifications to satisfy? When was this mandated?

As far as I know, it is not "mandated", and I am glad to hear that the FAX
working group needed no such mandate to consider the issues.  Text
in the document which describes the choices made in light of the
point raised in 3238 would help the reader understand the architectural
implications of the choices made.


>
>SH>  the document allows for conversion
>SH> and continuation of the use of CONPERM so that a later conversion may
>SH> take place--creating the classic "copy of a copy" syndrome;
>
>What does this mean and what is the "problem" with it?

Would "transform of a transform" be clearer?  I.e, I allow conversion from
PDF to HTML and POSTSCRIPT but prefer POSTSCRIPT; you  transform it
to HTML, then next MTA along transforms the HTML to POSTSCRIPT.  This is not
likely to produce the same result as transforming the PDF to postscript.

>
>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?

I send a message to [email protected], [email protected], and [email protected].
The message is split according to the capabilities, and one message is sent
to [email protected], and a different message sent to [email protected], and
[email protected].  What in the split message to [email protected] shows the
original recipient list included foo and baz?


>
>
>SH> the document punts completely how the SMTP
>SH> service
>SH> gets the CONNEG data in the first place, putting a critical part of the
>SH> security story out of reach.
>
>That is correct.  The document specifies a particular mechanism, not a
>complete "system".  It states the security implication of this in the
>opening lists of the security section.
>
>By way of comparative example, note that the BGP specification does
>not say how a BGP speaker obtains the list of hosts it announces paths
>to? The BPG spec just refers to "local policies".
>

This isn't a close parallel, as BGP peers are limited to ASes with whom
an AS has a peering agreement--a shared understanding of where and
how the two parties trade traffic.  At the moment, MTAs may speak to other MTAs
on an as-needed basis, and they have no such shared understanding
outside of the standards themselves.


>The fact that portions of a larger system remain unspecified ought not
>to invalidate having a public portion of such a service.

With an applicability statement that limited the expected use to a 
private service,
I would agree.  If you expect this to work generally for all SMTP 
speakers, though,
having at least an example of how an SMTP speaker *might* derive
this data without doing violence to the SMTP service model seems
to me like a useful addition.

			regards,
				Ted Hardie