Full-mode Fax Profile for Internet Mail (FFPIM)
draft-ietf-fax-ffpim-08

[Note]: 'Returning because there aren''t enough positive ballots for approval.  All old discusses have been cleared.  NOTE: doc has been updated to -08 from -07 since the document was placed on the agenda.' added by Michelle Cotton

[Note]: 'Returning because there aren''t enough positive ballots for approval.  All old discusses have been cleared.  NOTE: doc has been updated to -08 from -07 since the document was placed on the agenda.' added by Scott Hollenbeck

[Ballot discuss]
The last paragraph of Section 4 says:
  >
  > Use of the ESMTP CONNEG option permits content transformation by an
  > intermediary, along the mail transfer path.  When the contents are
  > encrypted, the intermediary cannot perform the conversion, since it
  > is not expected to have access to the relevant secret keying
  > material.  When the contents are signed, but not encrypted,
  > conversion will invalidate the signature.  Therefore, permission to
  > convert SHOULD NOT normally be used with signed or sealed messages,
  > unless the transforming intermediary participates in the protection
  > mechanism and can assure its validity.
  >
  The last sentence causes me concern.  If an intermediary transforms
  a signed message, the original signature is clearly broken.  I assume
  that it would be replaced by a signature from the intermediary, but
  there is no mechanism to indicate the original signer.  If the keys
  are provided to an intermediary so that it can transform an encrypted
  message, I would expect t to encrypt the resulting message.  Together,
  these add a significant amount of complexity.  To resolve my concerns,
  one of two things must be done.  One choice is to delete the second
  part of the last sentence (beginning with "unless").  The other choice
  is to add discussion about the ramifications for signed messages and
  the ramifications for encrypted messages.  In this case, a description
  of the processing by the transforming intermediary related to the
  "protection mechanisms" must be included.

  Also, the paragraph contains two non-ASCII characters, which I removed.

[Ballot discuss]
The last sentence causes me concern.  If an intermediary transforms
  a signed message, the original signature is clearly broken.  I assume
  that it would be replaced by a signature from the intermediary, but
  there is no mechanism to indicate the original signer.  If the keys
  are provided to an intermediary so that it can transform an encrypted
  message, I would expect t to encrypt the resulting message.  Together,
  these add a significant amount of complexity.  To resolve my concerns,
  one of two things must be done.  One choice is to delete the second
  part of the last sentence (beginning with "unless").  The other choice
  is to add discussion about the ramifications for signed messages and
  the ramifications for encrypted messages.  In this case, a description
  of the processing by the transforming intermediary related to the
  "protection mechanisms" must be included.

  Also, the paragraph contains two non-ASCII characters, which I removed.

[Ballot discuss]
I originally said "Format conversions by intermediaries breaks S/MIME. 2305, on which this builds, specifically suggests using S/MIME and PGP."  The change to Section 4 does not adequately address this problem.  It speaks of the transforming intermediary "participating" in the the protection.  Read one way, that implies that this intermediary needs to have certain secret keys.  This is a bad idea; the text needs to be clarified to rule out such behavior.

Ted wishes to hold his dicsuss for a while because this document has a normative reference to the ESMTP conneg draft (draft-ietf-fax-esmtp-conneg).  Some issues with that draft need to be resolved before moving this one along.

[Ballot discuss]
This has a normative dependency on the ESMTP conneg mechanism, which I
believe is not ready for widespread deployment.  As it stands, this document
specifies the use of RFC3297 at a MUST level, and the proposed ESMTP
conneg mechanism as a MAY.  I believe it would be wiser to remove the
ESMTP conneg mechanism.

The note on "direct mode" (Appendix A), is very useful to framing the
discussion, and I believe that the CONNEG mechanism has many fewer
problems in "direct mode".  If there were a way to specify that the
CONNEG mechanism such that it would only be used in direct mode,
I believe the resulting interaction would meet the timeliness and feature
requirements set out.  Unfortunatley, the fundamentally "store-
and-forward nature of email might make that difficult to achieve

AD evaluation comments on -04 (not yet announced) before requesting last call:

Numerous occurances of a "Â" non-ASCII character must be removed.

Section 4: s/applies/apply/

Will request last call when -04 is announced.

Revised ID needed to remove non-ASCII characters, separating references into normative and information subsections, and (this is minor) "APPENDIX C û CONTACT" should be changed to "Authors' Addresses".