Subject: RFC 3965 errata

From: Alfred Hönes <[email-masked]>
Date: Tue, 4 Jan 2005 12:03:57 +0100 (MEZ)

Hello,
please let me note the textual issues I found with the newly
published RFC 3965 authored by you.

Obviously -- cf. the heading of Appendix B in the text -- there
has been a very substantial delay in the publication process of
this revision to RFC 2305. Nevertheless, many textual issues from
RFC 2305 have not been corrected with this updated version.

Please comment on the items below, and decide which of these
should be submitted to the RFC Editor for inclusion on the
RFC Errata web page.

I have emphasized below proposed textual changes by a change bar,
'|', in the first column.

(1) Issues with 'References' :
    ========================

a) Reference [3] is outdated and not used in the text.

   References [1] and [2] from RFC 2305 have been updated, from
   pointers to RFC 821 and RFC 822, to pointers to RFC 2821 and
   RFC 2822, respectively.
   The (normative) updates to RFC 821 and RFC 822 contained in
   STD 3, RFC 1123 [3], have been incorporated into RFC 2821
   and RFC 2822, respectively, which obsolete their predecessors.
   Hence, the reference to RFC 1123 is no more needed in RFC 3965,
   and in fact it is not mentioned in the textual body any more.

   Thus, the Normative Reference [3] should be deleted from section
   6.1., on page 10.

b) 'Oracle' in Reference [5].

   The Normative Reference [5] on page 10 contains a predicted
   publication month and year for RFC 3949, which is not correct.
   It should be updated to name the true publication month and
   year of RFC 3949, as soon as RFC 3949 really gets published
   -- it isn't yet  :-)  .

c) Reference [19] is outdated.

   RFC 2633 has been obsoleted by RFC 3851, published 5 months
   before RFC 3965.
   The Informative Reference [19], on page 11, should be updated
   accordingly.

(2) Textual corrections and enhancements :
    ====================================

a) Change the first sentence of section 2.1.3, on page 4, from:

  "An offramp gateway that operate as an MTA serving multiple users
   SHOULD use SMTP;" ...

to:

| "An offramp gateway that operates as an MTA serving multiple users
   SHOULD use SMTP;" ...

b) Change the first sentence of section 2.2.4, on page 4, from:

  "A single multi-page document SHOULD be sent as a single multi- page
   TIFF file, even though recipients MUST process multipart/mixed
   containing multiple TIFF files."

to:

| "A single multi-page document SHOULD be sent as a single multi-page
   TIFF file, even though recipients MUST process multipart/mixed
   containing multiple TIFF files."

c) Change section 5.1. on page 6 from:

  "This specification is based on use of existing Internet mail.  To
   maintain interoperability with Internet mail, any security to be
   provided should be part of the of the Internet security
   infrastructure, rather than a new mechanism or some other mechanism
   outside of the Internet infrastructure."

to:

| "This specification is based on the use of existing Internet mail.
   To maintain interoperability with Internet mail, any security to be
|  provided should be part of the Internet security infrastructure,
   rather than a new mechanism or some other mechanism outside of the
   Internet infrastructure."

d) Change the final sentence of section 5.2, on page 6, from:

                 ... "This section reviews relevant concerns about
   Internet mail for IFax environments, as well as considering the
   potential problems which can result of integrating the existing G3Fax
   service with Internet mail."

to:
                 ... "This section reviews relevant concerns about
   Internet mail for IFax environments, as well as considering the
|  potential problems which can result from integrating the existing
   G3Fax service with Internet mail."

e) Change the first paragraph of section 5.2.1, on page 6, from:

   "The actual sender of the message might not be the same as that
   specified in the Sender or From fields of the message content headers
   or the MAIL FROM address from the SMTP envelope."

to:

   "The actual sender of the message might not be the same as that
   specified in the Sender or From fields of the message content headers
|  or the MAIL FROM address in the SMTP envelope."

f) Change the second-to-last paragraph of section 5.2.2, on page 7,
from:

  "Originator authentication entails the use of weak or strong
   mechanisms, such as cleartext keywords or encryption-based
   data-signing, respectively, to determine and validate the identify
   of the sender and assess permissions accordingly."

to:

  "Originator authentication entails the use of weak or strong
   mechanisms, such as cleartext keywords or encryption-based
|  data-signing, respectively, to determine and validate the identity
   of the sender and assess permissions accordingly."

g) Change the first sentence of the last paragraph of section 5.2.3,
on page 8, from:

  "Typically authorization needs to be associated to specific senders
   and specific messages, in order to prevent a "replay" attack which
   causes and earlier authorization to enable a later dial-out by a
   different (and unauthorized) sender." ...

to:

| "Typically authorization needs to be associated with specific senders
   and specific messages, in order to prevent a "replay" attack which
|  causes an earlier authorization to enable a later dial-out by a
   different (and unauthorized) sender." ...

Best Regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+