Note: ??? Implies "issue
may still be open even though text has changed" or, with the stuff
assigned to Ned "waiting" cref is also marked ???
-03 Issue#
|
-02 Issue#
|
-01
|
Description
|
Status
|
Comments
|
closed
|
closed
|
0a
|
Remove "ignorant" from 7.1
|
Done - 02b
|
Promoting harmony
|
closed
|
closed
|
0b
|
MAIL FROM validation and EHLO
validity tests |
No action |
"Editorial judgment" |
closed |
1 |
1 |
Format of domain - trailing
period |
02c. Sufficient? ??? |
So far inconclusive, but leaning
toward "no dot, but some explanation about TLDs' - 20070328.
Bunch of ccTLDs have MX records.
Note sent to ICANN 20070329 to try to find
out what for.Draft text in -02c
20070413. |
2 |
2 |
2 |
Check VRFY/EXPN text in Section
3.5.3 |
Ned??? |
See Ned's note, 20070329.
Ned to send text, I hope.
Placeholder added -02c, 20070413. |
closed? |
3 |
3 |
EHLO validation in sect 4.1.4,
para 6 |
|
Tony Finch suggests MUST->
SHOULD, Hector has new language (some of which, IMO, goes too far).
Notes on 20070329).
Pulled text from 4.1.4 to eliminate
redundancy; added more xrefs. |
closed |
closed |
4 |
Sect
4.2.1 (Reply Codes 4yz 5yz) "encouraged" -> SHOULD |
Done 03b (see issue 16) |
Hector suggests (20070309) a
rewrite to MAY based on no enforcement. David Skoll suggests MUST NOT. Closed
4yz to SHOULD in -02, 5yz to SHOULD NOT in -03 (part of issue 16) |
5 |
5 |
5 |
Sect 4.4. Syntax of ID in trace |
Fixed -02c |
Leave alone or change
"string" to "atom".
Changed to Atom per consensus note.
Might need to be Dot-string, per Ellermann 20070403 |
closed |
closed |
6 |
Precedence error -- ABNF
technical problem w/ grouping |
Fixed -02b |
Editorial: need parens to group
alternatives |
7 |
7 |
7 |
Switch conformity language to
2119 form |
|
Added to list 20070328 |
closed |
8 |
8 |
Number of recipients/ number of
transactions per connection |
Dead? |
2821is clear on recipients needs
separate extension to do either definitively.
Guidance on transactions/ connection??
Probably dead - no text needed 20070416 |
closed |
closed |
9 |
Table of requirements and/or
index and/or more items as sections. |
Fixes in -02b.
Done |
4.5.3.1 and 4.5.3.2 lists
converted to sections in -02b. TOC directives patched to include these.
More would fall into the
"rework" category. |
10 |
10 |
10 |
Add discussion of mail rerouting
via 251/551 to Security Considerations |
Ned??? |
Ned's note, 20070329.
Ned to send text, I hope.
Placeholder inserted in 02c. |
closed |
closed |
11 |
Change instances of "A
RR" to language that is IPv6-inclusive) |
Fixed - 02b |
Discussed on list, number not
formally assigned. Seems like a
no-brainer. |
closed |
closed |
12 |
IPv6 issues with MX records |
New text inserted, 02c |
Discuss implications of MX
records with IPv6-only targets.
Handed off to ADs. Draft text
tentatively approved. |
closed |
closed |
13 |
Syntax for parameters that
contain email addresses. |
Done 02c |
Use xtext from RFC 3461 section
4: http://www.apps.ietf.org/rfc/rfc3461.html#page-6 |
closed |
closed |
14 |
Continuation lines for 220
Greeting? |
Inserted 02c |
Tony Finch 20070405.
Says 20070406 that multiline greetings are
common and cause no interop problems. |
closed |
closed |
15 |
Syntax change for reply lines to
allow for continuation? |
Fixed 02c |
Tony Finch 20070405.
Seems like clear bug. Note cref comment about Reply-text
production. |
closed? |
16 |
16 |
General use of "is
permitted", etc |
Done 03b |
Klensin note, 20070407.
General feeling is "should
edit". Get 02 posted first,
then do this. |
closed |
closed |
17 |
Should text
be clarified to single code in continuations |
Done 02c |
Hector et al 20070409-11.
After list discussions, text changed to
require one code 20070413. |
closed |
closed |
18 |
Should text be clarified to
prohibit 1yz codes without extensions |
Done 02c |
Hector et al 20070409-11.
After list discussions, text changed to
clearly prohibit 20070413.Put in:
Any unrecognized code SHOULD be treated as an error (4yz or 5yz under discussion
20070423) |
19 |
19 |
19 |
Comments on literals in EHLO -
remove either "Explained-literal" or the text in 4.1.1.1 that
describes it. |
|
Tony Finch/ Mark Mallett
20070412 |
20 |
20 |
20 |
RFC3552 and Security
Considerations |
|
Do we need to do anything? |
21 |
21 |
--- |
Bounce / reject improvements in
section 6.2 |
Collapse into issue 25 - section
6.2 isn't all that is affected |
Wasn't that debate ruled out of
order? |
22 |
22 |
--- |
May->Should, Should-> Must
changes for return-paths in 4.4 |
|
Conversation with Keith 20070426
- note to list. Change text to remove
apparent contradiction. |
23 |
23 |
--- |
Section 2.3.11 now defines
"reply". Should there be a
specific, numbered, definition for "command"?
If so, text welcome. |
|
Mark E Mallett 20070418 |
24 |
24 |
--- |
Revise all ABNF to make a closed
system starting with a definition for "command" or
"command-verb" |
|
Pro: It would be nicer.
Con: odds of being able to do this in a
reasonable amount of time and without introducing new errors are low to
none. Frank and Arnt to rework after
all substantive issues are concluded. |
25 |
25 |
--- |
Change all text that implies
non-delivery messages to prohibit them entirely or permit them only with
source authentication. |
|
Frank Ellerman, repeatedly.
This one needs to be definitively closed,
again, IMO (JcK). Make sure any
changes are reflected in 2821bis-03 6.2 and see Hector's "2821bis-03
comments" note of 20070426 |
closed? |
26 |
--- |
Revise description of
reverse-paths to prevent repeated citations of "server adds its
own" |
???Text in 03c |
I think this is a dead issue
(JcK) |
closed? |
27 |
--- |
Straighten out and define
terminology for talking about headers |
Done 03c |
Pete Resnick note 20070423.
Header section/ Header field/ Received
clause |
closed? |
28 |
--- |
Client behavior with
unrecognized code |
Text in 03c |
Proposed text posted to list and
inserted in 03c, 20070423 |
30 |
30 |
--- |
Should source route text be
removed entirely and systems prohibited from paying attention to them? |
|
Alternative to issue 26 |
31 |
--- |
--- |
Retain or drop new (03) FTP
comparison text? |
|
32 |
---- |
--- |
Is requirement in section 2.1
that server accept responsibility for messages appropriately stated as MUST? |
|
formerly "protocol requires
that a server accept" |