--On Tuesday, 08 July, 2008 08:15 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
Tony Hansen wrote:
dcontent = %d33-90 / ; Printable US-ASCII
%d94-126 ; excl. "[", "\", "]"
Renaming this beast to dtextSMTP consistent with qtextSMPT
is an option. 2822upd says:
dtext = %d33-90 / ; Printable US-ASCII
%d94-126 / ; characters not including
obs-dtext ; "[", "]", or "\"
Of course a matter of taste.
Frank, especially since the IESG apparently has at least one
more <Surprise> coming for this group (watch the list), I am
strongly disinclined to make any further changes that have not
already been signed off by them, or that are direct consequences
of things they have insisted on, and that are not the result of
absolute showstoppers. In order to maintain a consistent
position, I/we might have to insist on another IETF Last Call on
such changes, resulting in further delays that accomplish very
little. So, while I'm willing to be talked out of it, I prefer
to not see any more editorial suggestions right now.
What happened with two
suggestions at the begin and the end of this comment:
https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bi
s/comment/80585/
If you are referring to
FYI, to compare with previous RFC try this URI:
http://tools.ietf.org/rfcdiff?url2=http://www.ietf.org/interne
t-drafts/draft-klensin-rfc2821bis-10.txt&url1=http://www.ietf.
org/rfc/rfc2821.txt
To be consistent with RFC 2821, this needs a header:
Updates: 1123
This has been done and presumably should have been on Tony's
list. Tony, I've fixed the change log to call this out.
and
Suggestion: STD 66 (URI RFC 3986) defines an "IPv6address"
rule that could be referenced or copied. It got the ABNF
cleaner than we got it here (and yes, that ABNF was my fault
in RFC 2821 but I recognize when someone else does it better).
I considered this and decided to let it go and did not receive
any comments from Tony to the contrary. The existing ABNF is
not broken and it is late to be making changes. I'd be
especially reluctant to reference 3986 because (i) it introduces
yet another normative reference and document that people have to
have virtually open to read 2821bis and (ii) it introduces some
small amount of circularity (2821bis -> 3986 -> mailto ->
2821[bis]). If it were six months ago, I'd immediately make
this change.
Both of these remaining comments (renaming the production and
altering the IPv6address syntax) have been noted in case there
is ever an rfc2821ter. Please do not take that as
encouragement; I'll stop trying to keep that list if there are
many more additions to it.
john