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

(this is a re-post, correcting an error in the addressing to the mailing
list.  /d)

Greg,

Thanks for the detailed review.


VGMG> Second sentence in the summary does not parse correctly. 
VGMG> Is there a missing word after "with the same"?

VGMG> I am unclear about the intent of the last paragraph in
VGMG> section 1 and section 3.3.  Do I read correctly that if the next
VGMG> hop does not support conperm, then the message must be failed?

yes.


VGMG>  I
VGMG> believe that failing a message for non-support of an optional
VGMG> ESMTP extension is a drastic step, and I believe unprecedented.

Is there is technical deficiency with the specification?  Is there some
reason the specification will not work?

The folks who are interested in using this option want it to effect and
end-to-end enforcement of conversion capabilities. If that end-to-end
support cannot be sustained, the folks want to transmission to be
failed.

New specs are always guilty of doing something... new.  Is there
something particularly "risky" about this mechanism that threatens its
ability to satisfy its stated goal?


VGMG> Can you justify why you are not using a DSN-style method where the
VGMG> options are to request conperm, and/ request notificaiton if no
VGMG> conperm is available?

The justification is simple: What you suggest is not what the folks who
are interested in consuming this option wanted.

What makes that decision unable to be performed correctly?


VGMG>  Is a absolute failure better than a notice  that failure is a possiblity?

It's what they preferred.


VGMG> An uninitiated reader may question the advantage for the
VGMG> added complexity of Conneg.  If the next hop knows the
VGMG> capabilities of the recipient, why not let it do the conversion?

There is a very big difference between having a copy of some parameters,
versus being able to perform data conversions.

If a site prefers to perform the conversion, rather than notify the
up-stream sender of the capabilities, it is free to declare that it
supports conperm, and to *not* notify the upstream of the capabilities.
It will then receive the message and can perform the conversion itself.


VGMG> The appendix A suggests that the true intent is to facilitate
VGMG> direct negotiation between directly connected sender and recipient
VGMG> SMTP systems.

"True intent"?  I don't know what you mean.

The specification defines a rather complete mechanism. It was elaborated
substantially, to provide for concerns about relayed conversion
permission.  We believe the specification will work, as stated, and that
it can be quite useful in its full form.

The appendix describes a streamlined use, for a particular
configuration.


VGMG>   Without the direct connect use case, the conneg
VGMG> extension has little value, since the relay with recipient
VGMG> capability can do the conversion itself.

Sorry, no.  See above.


VGMG> It seems this document can be made more clear by
VGMG> identifying the two common cases in the introduction and later
VGMG> clearly stating the algorithm for an SMTP sender to use.

I do not understand what you are saying.

1.  How does it make the specification more clear?

2.  What "two common cases"?

3.  What is it about the text concerning the "SMTP sender" that is
unclear?


VGMG>   If
VGMG> directly connected from the sender to the recipient, use CONNEG. 
VGMG> That is, if the first hop gets CONNEG info, it can encode
VGMG> correctly upon submission.  If it does not get CONNEG, then it
VGMG> send in least-common denominator format or use CONPERM, and leave
VGMG> the conversion to the destination.

This specification does not offer that guidance and does not imply it.

An implementation well might choose such a scheme, but it goes beyond
the details of this specification. (In other words, that guidance is
outside the scope of this specification. Hence, the specification is
entirely neutral with respect to the scheme you describe.)


VGMG> I would separate the processing rules for the
VGMG> content-conversion relay in section 3.2 and place them in a
VGMG> generalized section 3.3 (might even introduce the term
VGMG> content-conversion relay as that special case where a device
VGMG> supports both conperm and conneg)

Any site that takes in a message under the conperm option is responsible
for ensuring that conversion be performed, if the recipient capabilities
are provided.  Hence, I do not know what you mean that 'content
conversion relay' is a special case.


VGMG> It is worth mentioning that the
VGMG> content-conversion relay may know the capabilities of the
VGMG> recipient directly, via LDAP, or via CONNEG.  The processing rules
VGMG> should be stated independently of how the knowledge is gained.  

In section 1:

     Conversions are performed by the first ESMTP host that
     can obtain both the sender's permission and the
     recipient's capabilities.

In section 3:

          An intermediary MAY be given CONPERM direction
     when receiving a message, and MAY be given CONNEG
     guidance, before sending the message. CONPERM and
     CONNEG operate on a per-message basis.  Therefore they
     are issued through the ESMTP MAIL-FROM request.  CONNEG
     response information is provided on a per-recipient
     basis, through the response to ESMTP RCPT-TO.
     
          Conversion MUST be performed by the first CONPERM
     intermediary that obtains CONNEG recipient capability
     information.  When an intermediary obtains different
     capability information for different recipients of the
     same message, it MAY either:

The phrase "that obtains CONNEG recipient capability information" refers
to the information, but does not mandate that it be obtained through
CONNEG. It is fine to perform a conversion when the CONNEG information
is received through a non-Conneg mechanism.

     
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>