ietf-smtp
[Top] [All Lists]

Re: Issue list

2007-04-27 11:55:38
Hector Santos wrote:

http://www.isdg.net/public/ietf/drafts/rfc281bis-status.htm

Thanks, my browser was still not happy, I simplified the Excel
output, see below.

I miss two articles about other issues posted here:

Kari  (2007-04-20): "for" clause on Received: header field 
http://permalink.gmane.org/gmane.ietf.smtp/5708

Frank (2007-04-23): General Address Literal
http://permalink.gmane.org/gmane.ietf.smtp/5810

Frank

RFC 2821bis issues list

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"