John C Klensin wrote:
since the IESG apparently has at least one more <Surprise>
coming for this group (watch the list)
Watching...
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.
They didn't insist on fixing <dcontent>, I insisted on it ;-)
And while checking that your fix matches 2822upd I saw that
you already picked <qtextSMTP> in a similar case, and you
might like to stick to this style also for the <dtext>. Or
not, because <dcontent> was the name in RFC 2822.
we might have to insist on another IETF Last Call on such
changes
IIRC I reported the <dcontent> bug in both IETF Last Calls,
IMO you are perfectly entitled to fix it as you see fit. ;-)
| Updates: 1123
This has been done
Good, thanks.
| 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.
Also reported several times.
The existing ABNF is not broken and it is late to be making
changes.
We often disagree when it's about ABNF. I like it when I can
see a consistent "story" in different RFCs, provided that it
really is supposed to be the same story. In that case it's
propaganda for exactly the same idea of IPv6 literals.
That two RFCs ended up with two different interpretations of
the same RFC 3696 idea of a <toplabel> bothered me even before
you overruled your RFC with an erratum... ;-) Of course I had
no idea that something like RFC 952 exists, and that somebody
still considers it as relevant, or that it is a major part in
various political flame wars. [[But I understand the concept,
1032 vs. 3912 is a similar hair splitting exercise]]
I'd be especially reluctant to reference 3986
You could copy the ABNF, because it is KISS, and obvious, and
exactly expresses what you now have in a (convoluted) comment.
yet another normative reference
Not if you copy it, only if you import it.
it introduces some small amount of circularity (2821bis ->
3986 -> mailto -> 2821[bis]
RFC 2368 (mailto) is still based on 1738, and erroneously
used the 822 <mailbox> instead of the 821 <mailbox>, which
is the 2821(bis) <Mailbox> and not the 2822(upd) <mailbox>.
Mailto-bis will use 3986 and 2821bis, and I very much doubt
that it will talk about IPv6 literals in mailto addresses...
But if it does this having the same syntax could be a "Good
Thing" (tm).
If it were six months ago
<http://article.gmane.org/gmane.ietf.smtp/4482/match=ipvfuture>
| While you're at it grab also the other address literals
| from STD 66, they are simply better.
That was even *before* you posted -00 back in June 2005.
<http://article.gmane.org/gmane.ietf.smtp/5926>
| An IPv6 is an IPv6, and I think the 3986 folks got this right.
|
| It's potentially harmful for interoperability if 2821bis and
| 3986 have different ideas about the syntax of an IPv6 literal.
[...]
| SPF uses 3513 "syntax", and as far as I can tell it 3986 is
| the formal ABNF of what 3513 says in prose by example.
That was in April 2007, and the SPF remark was wrong: We used
3513, because 3513 obsoleted 2373; and we missed that the IPv6
*syntax* in 2373 went via 2732 into 3986. Meanwhile 3513 is
obsolete. Getting a consistent IPv6 "story" can be difficult.
in case there is ever an rfc2821ter.
For that somebody has to find a bug in 2821bis within, *WHAT*,
four months ?!? I didn't know that 2821bis will be STD 10 in
January 2009. July + two months for appeals + four months...
now that's fast, isn't it ?
Frank