Re: Changes in CWFS location in 2821bis ABNF
John C Klensin <john@jck.com> Mon, 12 September 2005 18:37 UTC
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8CIbg3l002445; Mon, 12 Sep 2005 11:37:42 -0700 (PDT) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8CIbg8v002444; Mon, 12 Sep 2005 11:37:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8CIbetF002437 for <ietf-smtp@imc.org>; Mon, 12 Sep 2005 11:37:40 -0700 (PDT) (envelope-from john@jck.com)
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EEtBT-0004Yt-Rk; Mon, 12 Sep 2005 14:37:39 -0400
Date: Mon, 12 Sep 2005 14:37:39 -0400
From: John C Klensin <john@jck.com>
To: Frank Ellermann <nobody@xyzzy.claranet.de>, ietf-smtp@imc.org
Subject: Re: Changes in CWFS location in 2821bis ABNF
Message-ID: <3BD7891FAEA8C834A4B77026@scan.jck.com>
In-Reply-To: <43243D79.177@xyzzy.claranet.de>
References: <20050908153242.GC1587@ergens.op.het.net> <6.1.0.6.2.20050908172546.04c00828@lmail.pscs.co.uk> <2+nCMUzt5HRG/QfzySiO3Q.md5@bluegrass.trish.de> <20050908182902.GD1587@ergens.op.het.net> <4320B93C.2D99@xyzzy.claranet.de> <t4qCUIursYpcQMuThCAVrQ.md5@bluegrass.trish.de> <43222900.4D33@xyzzy.claranet.de> <200509100212.j8A2CFGf008879@turing-police.cc.vt.edu> <KBDxngu+5vP556mhlzKyHw.md5@bluegrass.trish.de> <90C01652A42F19E0D547F78E@scan.jck.com> <4323A6BB.3F59@xyzzy.claranet.de> <AC9AB60708ACB273AFD7F96A@scan.jck.com> <43243D79.177@xyzzy.claranet.de>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>
--On Sunday, 11 September, 2005 16:21 +0200 Frank Ellermann <nobody@xyzzy.claranet.de> wrote: Frank, FWIW, some of the positions you are taking seem to me to be pushing us toward the "WG needed before more drafts" position that you claim to dislike. Just my opinion, of course. > John C Klensin wrote: > >> someone persuaded me and at least one reviewer that the >> change would improve things, fix that bug, and not have >> any nasty side effects > > Yes, it only surprised me, the old ABNF was more "natural" > wrt. the position of the CFWS. The new ABNF is "ugly", > but for the purpose of allow-no-FWS-before-semicolon it's > probably necessary. >... FWIW, I used to do programming language standards, where the requirement --especially with formal and semi-formal definitions-- for quality, clarity, and precision of syntax definitions has historically been much higher than it has been in the IETF. I'm not, personally, a big fan of ABNF. I wasn't a fan of the version in the early 1980s. The current version is an improvement in a number of major respects, but adds enough metarules and metasyntax to make it unattractive to me on that dimension. However, DRUMS very clearly decided, with relative strong consensus (even if not unanimity) to use ABNF in 2821 rather than the BNF of 821 or some other system and to revise ABNF as it did. I didn't do the ABNF for 2821. Drawing me personally into a debate about whether one ABNF structure is aesthetically more pleasing than another is likely to result in rude analogies, but little progress. If something is an actual error, please point it out. Otherwise, please start writing a WG charter. > If we insist on this concept. I've no better idea, and I > tried to replace CFWS-as-separator for the References, > because <a@b>(c)<d@e> is odd, I'd expect <a@b> (c) <d@e>. Yeah. From my point of view, we had comments defined in 822 by a bit of handwaving that, generally, worked. We updated ABNF and tried to define comments by syntax and didn't get it quite right because of the character of ABNF. See "not a fan" above. > It's possible, but the resulting ABNF was so horrible that > it was never seriously considered. Here "From x(c)by y" > is the analogous issue. 2822 says: > > | received = "Received:" name-val-list ";" date-time CRLF > | name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)] > > That's different from both 2821 and 2821bis -00, it's exactly > the opposite of 2821: There can't be any CFWS before the ";". To review this bit of esoterica for those who are reading the thread, but not the spec, one of the key differences between 2821 and 2821 bit in this area is that 2821 used the productions Stamp = From-domain By-domain Opt-info ";" FWS date-time From-domain = "FROM" FWS Extended-Domain CFWS By-domain = "BY" FWS Extended-Domain CFWS Opt-info = [Via] [With] [ID] [For] Via = "VIA" FWS Link CFWS With = "WITH" FWS Protocol CFWS etc. The net effect of that sequence, which is not obvious unless one looks carefully at it, is to require white space or a comment before the semicolon. That was not the requirement of 821 and having the semicolon appear without leading white space is fairly common practice. 2821 moves the CFWS terms around, so we have Stamp = From-domain By-domain Opt-info [CFWS] ";" FWS date-time From-domain = "FROM" FWS Extended-Domain By-domain = CFWS "BY" FWS Extended-Domain Opt-info = [Via] [With] [ID] [For] Via = CFWS "VIA" FWS Link With = CFWS "WITH" FWS Protocol etc. That fixes the "required space before semicolon" problem. It's aesthetics? Well, don't ask me about ABNF aesthetics. And, yes, it seems obvious to me that whatever 2821 does in this area, either 2822 should do as well or we should be sure that everything permitted by 2821 is permitted by 2822 and that 2822 should contain an explanation of the difference. Either way, I'd claim this change needs coordination with 2822bis, which is another reason to move the documents forward together. To address this point in the context of another note of yours, "or its successor" doesn't work for me --it turns 2821bis into an unstable standard whose interpretation depends on knowing which version of 2822x is relevant at the time (or on the assumption that 2822* won't change in this area, but...). > And it's also incorrect, both 2821 and 2821bis -00 clearly say > "Received:" FWS Stamp CRLF, _not_ "Received:" [CFWS] Stamp CRLF Much as I think that difference, if 2822bis chooses to preserve it, should be justified in text there, the forms that 2822 permits are a superset of the forms that 2821 can produce, so this doesn't seem to me to be harmful. > The 'CFWS-everywhere' attitude of 2822 is a royal PITA, and at > least two of the six USEFOR-years were spent for fights with > some of these 2822-concepts... <sigh /> Then, IMnvHO, USEFOR made a poor strategic decision. It would have been far preferable to generate a "CFWS-everywhere in 2822 considered harmful and unprecedented" draft and to try to get it processed as a PS, updating 2822. Or, as a different option, you could have warped the generate/accept distinction in 2822 by saying in the USEFOR document "MUST NOT generate and MAY NOT accept" wrt some of these stranger insertions of comments. That said, "CWFS-everywhere" is not new to 2822: it is pretty much implicit in the "comments as delimiters" construction of 822 and hence should not have come as a surprise to USEFOR (again, see my fan club comment above -- I am trying to describe the situation, not to praise it). > I'd say stick to "Received:" FWS Stamp CRLF, it's fine. With > a time machine it's what I'd try for all header fields, in > news (instead of the ridiculous "magic SP") and mail (instead > of [CFWS]. That's an optional CFWS for those who don't see it > allowing e.g. Received:From x without any WSP after the colon, > or even Received:(c)From x, etc. plus all the funs of folding.) I've tried reading this several times and don't understand what you are proposing and/or complaining about. Perhaps that is because I haven't been following USEFOR. > [procedural questions about a WG and ADs] >> There is a judgment call as to whether adding in the >> equivalent of "Opt-info" somewhere would be a change >> compatible with going to Draft or not. > > Yes. In another thread you just told me that the "community" > should say what it wishes wrt. BCP and PS, because otherwise > the IESG is free to pick what they think is the best status. That isn't what I intended to say and I don't think it is what I said. The IESG interprets both the rules for document classification and the consensus of the community, doing that using whatever mechanisms it likes and subject only to appeal and/or recall if they get it wrong. I believe that the IESG usually acts with good intent and consistent with their perception of the position of the community. If the community has an opinion about these things, it needs to be clearly expressed. Otherwise, the IESG is _forced_ to use its own judgment (or to interpret silence as lack of strong community support and interest and just drop the relevant document into a black hole, which I wish they would do somewhat more often). > Here you tell me that DS vs. PS is something depending on the > ADs. Why is this different here ? From my POV it's simple, > 2821 needs to be fixed, it's not urgent, and if the outcome > is "only" a PS it's also okay (other folks _dream_ of PS for > what they have created in about two years). Of course you as > author strongly prefer DS. "Of course" has nothing to do with it. As an individual who has only a finite amount of time to devote to IETF work, I have regularly concluded that there are things I would rather do with my time than fuss with a 2821 rewrite. You might infer that from the fact that there has been a note on my personal task list since early May of 2001 to get this draft out and that I clearly didn't do so until recently. Left to my own devices, I might have continued to ignore it, or spent time working on more general ways to advance documents like this via a minimally-necessary list of corrections rather than full rewrites and replacement of the documents themselves (anyone who wants to assume that was the motivation for draft-ietf-newtrk-repurposing-isd-03 and its predecessors, feel free: while that conclusion would not be accurate, the experience with creating 2821 certainly figured into the formula). I was finally persuaded that it was time to do this by others, and others, notably Tony Hansen, assumed responsibility for one of the intermediate tasks that I had been using as an excuse to not do so. > Looking at 2396 and 3986 as an example the status is a lottery, > there are important differences between 1738 / 2396 / 3986. > And some bugs in 3986 appendix D.2, but that's another issue. To the extent to which you are correct, I wouldn't use terms like "lottery". Either the community disagreed with your interpretation of what would bar advancement in grade or some incompatible and inappropriate chance slipped through due to inadequate review (during Last Call or earlier). It is a little late in the game to appeal the approval of 3986 on that basis, but you (and others) clearly had that opportunity too. That sort of decision process turns into a lottery iff you assume that the IESG is required to be infallible about finding and interpreting problems with documents that are not identified to it by the community. I have very high, perhaps unreasonably high, expectations of the IESG, but infallibility is not on my list. >> if they had a "nope, would require a reset" reaction, trying >> to convince them otherwise would be, for me, prerequisite to >> changing the text. > > So you'd say status DS is more important than to get it right ? No, I'd say that, if we can't get to DS now and with this revision, I'd rather proceed with an "updating" document at PS, now, that identifies and fixes the errors, wait the requisite six months, and then fold those changes into 2821bis and move the two to DS together. There are three reasons for that approach; the third one highly personal: (i) We already have more than enough confusion about whether 2821 or 821 are authoritative on a number of issues. Issuing a 2821bis that doesn't clearly supercede 2821 in context and grade would, IMO, be a mistake. (ii) If we open 2821, we simultaneously opens up corrections of a number of small editorial matters (anyone think that the appearance of "with with" or "and and" due to editing errors undermines understanding of the document?), attempts to fix minor errors in the syntax and make it less ugly, substantive clarifications to existing text, general questions of theory, model, and requirements, and, like it or not, the need to coordinate a certain number of potential changes or clarifications with 2822[bis]. People have been pretty good about it so far, but there is also potential for revisiting and trying to second-guess decisions that were made, very painfully, during the DRUMS effort. The discussions of the last couple of weeks make those problems very clear. It just isn't, IMO, worth the effort to go through that more times than needed. (iii) If work is initiated on such an update PS, I won't feel any obligation to either edit it or to try to coordinate and balance comments. I could even take 2821bis off my calendar until a few months after that effort converged :-) >> While the image that discussion conjures up involves careless >> or sadistic ADs ignoring issues until the last possible >> moment so that they can then pounce on them, cackling with >> glee > [...] > > LOL. It's of course okay if you discuss 2821bis with say > Scott. > > But at the moment that's an individual contribution, you do it > because you want to fix and advance 2821 before somebody else > tries it (and besides the chances that anybody else gets this > "right" for any of your definitions of "right" would be slim.) I'm not that confident of my own infallibility. I feel some responsibility for this and obligation toward it, but, if someone were to come forward who wanted to do it who could convince the community (or at least the ADs) that he or she had adequate skill, perspective, and motivation --motivation that did not include axe-grinding about, e.g., spam or a particular product-- I'd hand it over with enthusiasm. >... >> some suggestions have been made already that I can't imagine >> trying to integrate without WG approval. > > Let's see how far we get with the less controversional points. > > In a difficult case like "at-least-one-dot" it might be also > possible to agree on a clear choice, either this <Domain> or > that <Domain>. In the worst case the hypothetical WG has then > at least a clear input document with all 2821 issues fixed or > outlined. Plus one or more showstoppers from your POV, where > some poor WG Chair has then to divine "consensus" in some way. I think we agree on that particular approach. john
- Re: Transparency Alex van den Bogaerdt
- Re: "More-stuff" in Received fields william(at)elan.net
- Re: "More Stuff" in Received header Frank Ellermann
- Re: Changes in CWFS location in 2821bis ABNF Tony Finch
- Re: Changes in CWFS location in 2821bis ABNF John C Klensin
- Re: "More Stuff" in Received header Tony Finch
- Re: "More-stuff" in Received fields John C Klensin
- Re: Changes in CWFS location in 2821bis ABNF (was… Tony Finch
- Re: Transparency Frank Ellermann
- Re: Transparency Arnt Gulbrandsen
- Re: Transparency Arnt Gulbrandsen
- Re: "More-stuff" in Received fields Frank Ellermann
- Re: Changes in CWFS location in 2821bis ABNF Frank Ellermann
- Transparency Tulsi Ram Mayala
- Changes in CWFS location in 2821bis ABNF (was: Re… John C Klensin
- "More-stuff" in Received fields (was: Re: Transpa… John C Klensin
- Re: Transparency John C Klensin
- Re: Transparency Frank Ellermann
- "More Stuff" in Received header John Leslie
- Re: Transparency John C Klensin
- Re: Transparency Arnt Gulbrandsen
- Re: Transparency Valdis.Kletnieks
- Re: Transparency Frank Ellermann
- Re: Transparency Arnt Gulbrandsen
- Re: Transparency Alex van den Bogaerdt
- Re: Transparency Frank Ellermann
- Re: Transparency Alex van den Bogaerdt
- Re: Transparency Arnt Gulbrandsen
- Re: Transparency Paul Smith
- Re: Transparency John Leslie
- Transparency Alex van den Bogaerdt
- RE: Transparency Paul Smith
- RE: Transparency Robert A. Rosenberg
- RE: Transparency Tulsi Ram Mayala
- RE: Transparency Tulsi Ram Mayala
- RE: Transparency John C Klensin
- Re: Transparency Alex van den Bogaerdt
- RE: Transparency Tulsi Ram Mayala
- RE: Transparency Tulsi Ram Mayala
- Re: Transparency Paul Smith
- Re: Transparency Alex van den Bogaerdt
- Re: Transparency Hector Santos
- RE: Transparency Tulsi Ram Mayala