Mercurial > hg > ietf

comparison emailcore-review.txt @ 9:052d25a9004a default tip

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
starting with section 8 and Appendices
author Henry S. Thompson <ht@inf.ed.ac.uk>
date Wed, 05 Feb 2025 15:56:31 +0000
parents
children
comparison
equal deleted inserted replaced
8:d4e5d6b079bc 9:052d25a9004a
1 Document: draft-ietf-emailcore-rfc5321bis-40
2 Intended RFC status: Proposed Standard
3 Review type: artart - Last Call review
4 Reviewer: Henry S. Thompson
5 Review Date: 2025-02-05
6 Result: Ready with minor issues
7
8 *Summary*
9
10 This is a non-trivial update to a major standard
11
12 *Substantive points*
13
14 *Minor points*
15
16 8.1.4:
17
18 I had to do some hunting to understand what was being referred to by
19 'Strings' in the last paragraph. Maybe expand this slightly to read
20
21 As new clauses are defined, they may, in principle, specify
22 creation of separate registries (specific to them) if the Strings
23 allowed by the syntax summary consist of reserved terms or keywords
24 rather than less restricted strings.
25
26 D:
27 I find the use of the word 'deprecated' in this appendix confusing
28 and, it seems to me, inconsistent.
29
30 In the first para., we find
31
32 "A few features of RFC 821 have proven to be problematic and SHOULD
33 NOT be used in Internet mail"
34
35 So far so good, in my experience of how 'deprecated' is used.
36
37 And in D.1 we find
38
39 "Its use is deprecated; SMTP systems SHOULD NOT use it unless ..."
40
41 Also OK by me.
42
43 But in D.4 we find
44
45 "It is deprecated and MUST NOT be used."
46
47 In my experience that amounts to a contradiction. Deprecation, I
48 thought, is meant for something which the spec. currently allows,
49 but is considered to be outdated and probably SHOULD NOT be
50 used. Support in future versions cannot be counted on.
51
52 Since the ABNF doesn't allow this, and it hasn't been supported for
53 a long time, it's way past time for deprecation, in my opinion. At
54 most a note back in 4.1.3 saying that #-literals haven't made sense
55 for a long time and MUST NOT be used.
56
57 Similarly in D.5 we find
58
59 "It is deprecated and MUST NOT be used."
60
61 Since the ABNF no longer allows anything other than 4-digit years,
62 deprecation is not appropriate IMO. It would make sense to me iff
63 back in 4.4.5 wording was added saying it SHOULD NOT be produced,
64 but MAY be accepted for backward-compatibility for the time being.
65
66 *Nits*
67
68 8.1.1.3 (1):
69 "EHLO Keyword: The textual name of the SMTP service extension"
70 Needs a full-stop.
71
72 8.1.3:
73 '"Additional Registered Clauses (keyword and
74 values)' Needs a close-quote.
75
76 8.3.3.2:
77 '"Additional verbs", "MAIL/RCPT Parameter Values" ...' reads
78 awkwardly to me, I'd prefer
79 '"Additional verbs" and "MAIL/RCPT Parameter Values" ...'
80
81 8.3.3.3:
82 'Note: Implementation support for VRFY is required in servers but
83 its listing in the EHLO response is optional".'
84 Either spurious close-quote or missing open-quote.
85
86 9:
87 "chetti contributed" and the long note that precedes it.
88 Would "chetti [sic] contributed ..." be a possible compromise? [If
89 not, nothing needs to be said, I certainly don't want to require any
90 further discussion of what has already consumed more time than it
91 deserves.]
92
93 C.1:
94 "by Smith at host bar.com, and to Jones ..."
95 Reads aqkwardly to me. Just
96 "by Smith at host bar.com to Jones ..."
97 seems OK to me.