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
