Eliot Lear wrote: > I would be curious as to what needs "fixing" before it > becomes a full standard The issues you find when you enter "2616" in the form at http://www.rfc-editor.org/errata.html That sends you to the outsourced http://purl.org/NET/http-errata > as you say for SMTP below, look in your browser My browser is much older than 2004 (the date of the last addition to these errata). Today we'd replace 2396 by 3986 (a tricky issue, because appendix D.2 in 3986 is a dark corner wrt "non-uric", but that's precisely the point needed elsewhere incl. the 2616 errata). Updating 2616 to state of the art 3986 is more difficult than 2396, but of course we'd now want 3986. The 1766 reference has to be fixed to state of the art 3066 (or rather 3066bis when that got its number, but the 2016-ABNF bug isn't affected by this transition). > it clearly works for a vast number of applications It "should" break for some registered 3066 language tags like de-CH-1996, because 1996 is not 8*ALPHA, as noted in these errata. Of course a minor point, and most 2821 errata are also rather harmless (once you know where they are). Maybe it's only me, I thought it's the purpose of the three- stage procedure to fix such issues. Because getting it right immediately is an exception, and getting it right in three steps is already optimistic. > Long hard work went into 2821 to correct known problems. Try the URL mentioned above and enter 2821. Some issues fixed in the 2821bis draft, some missing, others are not formally listed as errata, but you could find them in the SMTP list archive (some weeks in 2005). You've to read 2821 very often to find the most important point between the lines, not mentioned clearly: _Never_ accept mail unless you're sure that you can deliver it or bounce it to the originator (which is today rarely related to anything you see in the MAIL FROM). Otherwise, following the official 2821 rules, what you do would be net abuse by design: Either you drop accepted mail silently, or you bounce it to innocent bystanders. Unlike the old 821 SMTP, where it still worked as designed. Of course 2821 couldn't fix 1123 5.3.6(a) anymore, but at least 2821bis has to document it very clearly. Between the lines, "let's assume the MAIL FROM is related to the originator", won't fly, that's not true anymore for several years now. We could as well "assume" that sending passwords as plain text is no problem, because eavesdropping is cheating and out of scope for Internet standards. >> One of the submitted pending errata mentioned several >> RFCs which could now be moved to "historic", because >> they depend on RFCs cleaned up in the first "decruft" >> round. > Define "depend", please. For new RFCs I'd define it as "normative reference", but I can't tell what the submitter had in mind, you find his mail (among dozens from the same contributor) in the pending errata archive: ftp://ftp.rfc-editor.org/in-notes/pending-errata/pending-errata.msgs After I saw that he sent a CC: to the decruft-authors I did not check his details. Possibly his definition of "depend" won't match your or my definition. Frank _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf