Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Keith Moore said: it could be argued that the best thing to do is to remove ALL of the rules from the ABNF spec, leaving only the language definition and examples. While I don't support this, it does remind me of a problem. I've had various people tell me in the past that ABNF includes Appendix B and, therefore, it is neither necessary to cite the appendix or to define basic concepts yourself. I know that section 1 says that appendix B is separate from its formal status, but I suggest that the introduction to the appendix should make it clear that citing ABNF does *not* include these rules by reference; such inclusion by reference needs to be explicit. -- Clive D.W. Feather | Work: [EMAIL PROTECTED] | Tel:+44 20 8495 6138 Internet Expert | Home: [EMAIL PROTECTED] | Fax:+44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc|| ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
On Thu, 17 May 2007, John C Klensin wrote: After all CRLF Thing SPACECRLF could case similar problems if some construction permitted it ... This is not news. There have for a long time been problems with significant trailing space, which is why CRLF 1*WSP CRLF in a header is part of the obs- syntax of 2822, and why quoted-printable encodes WSP at the end of a line. ... and defining a grammar that would prohibit any SPACECRLF construction isn't easy in ABNF for reasons that have nothing to do with LWSP. This is simply incorrect. It's trivial to define a whitespace construction that only allows CRLF at the beginning of a sequence: NTWSP = [CRLF] 1*WSP ; non-trailing white space Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ SHANNON: SOUTHWEST VEERING WEST 7 TO SEVERE GALE 9, PERHAPS STORM 10 LATER. VERY ROUGH OR HIGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
--On Friday, 18 May, 2007 09:00 +0100 Tony Finch [EMAIL PROTECTED] wrote: On Thu, 17 May 2007, John C Klensin wrote: After all CRLF Thing SPACECRLF could case similar problems if some construction permitted it ... This is not news. There have for a long time been problems with significant trailing space, which is why CRLF 1*WSP CRLF in a header is part of the obs- syntax of 2822, and why quoted-printable encodes WSP at the end of a line. ... and defining a grammar that would prohibit any SPACECRLF construction isn't easy in ABNF for reasons that have nothing to do with LWSP. This is simply incorrect. It's trivial to define a whitespace construction that only allows CRLF at the beginning of a sequence: NTWSP = [CRLF] 1*WSP ; non-trailing white space Sure. Except that much, if not most, of our textual descriptions of these protocols describes lines, and line-like, constructions as _ending_ in CRLF. Moving to starting in CRLF creates a conceptual difference between prose definition and formal syntax, which strikes me as a bad idea. Of course, in the above, since [CRLF] is optional, 1*WSP alone satisfies the production as written and still does not prevent CRLF space space space CRLF unless _all_ productions are written CRLF first... or one relies on the comment as a restriction. And a comment as the restriction --in the prose-- is exactly what has been suggested, IMO. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
On Fri, 18 May 2007, John C Klensin wrote: On Friday, 18 May, 2007 09:00 +0100 Tony Finch [EMAIL PROTECTED] wrote: NTWSP = [CRLF] 1*WSP ; non-trailing white space Sure. Except that much, if not most, of our textual descriptions of these protocols describes lines, and line-like, constructions as _ending_ in CRLF. Moving to starting in CRLF creates a conceptual difference between prose definition and formal syntax, which strikes me as a bad idea. Don't do that then. The suggestion I made above was for a no-trailing- whitespace variant of 2822's FWS, and as such it would be used in a grammar inside a logical line, not at either end. You seem to be inventing problems that might occur in badly-designed grammars, and as such these are bugs in the grammars and not due to limitations of ABNF (which, after all, is equivalent to any other notation for describing context-free grammars). Of course, in the above, since [CRLF] is optional, 1*WSP alone satisfies the production as written and still does not prevent CRLF space space space CRLF Um, no, because WSP = SP / HTAB Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ SOUTHEAST ICELAND: CYCLONIC, BECOMING NORTHERLY GALE 8 OR SEVERE GALE 9, DECREASING 6 OR 7. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Keith == Keith Moore [EMAIL PROTECTED] writes: Keith it could be argued that the best thing to do is to remove Keith ALL of the rules from the ABNF spec, leaving only the Keith language definition and examples. (actually I think I did Keith argue this sometime around 1996, but I'm too lazy to search Keith through old email to find it. I think this would be too big of a change going from draft to full given our experience. If we had huge tracts of problems with the rules, it might be a different situation. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
--On Tuesday, 15 May, 2007 11:27 -0700 Dave Crocker [EMAIL PROTECTED] wrote: Were we to deprecate every feature in IETF specifications that get mis-implemented a couple of times over 10 years, I suspect much of our technology would be deprecated... IMO, and at the risk of again agreeing with Dave, this is the issue for me. If we have inconsistent uses of terminology across documents that are supposed to be using the same, standardized, term, then that is a problem with our review process. If the term is explicitly standardized in one of the documents, that is the definition; things that use the term incorrectly should be candidates for fixing. By contrast, if we consider misused sometimes or ambiguous with other uses as a sufficient condition for deprecating the term itself, then we have a long list of terms to deprecate in front of us, almost certainly starting with IP, which refers to several different protocols, a protocol layer, and something that often involves lawyers. I think some warning language about safe and unsafe contexts may be in order for this construction but I expect that everyone who is arguing for deprecating it entirely (or inserting a strong don't use this statement) will be making a case for similar language the next time an IPv6 document comes up for review. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
John == John C Klensin [EMAIL PROTECTED] writes: John --On Tuesday, 15 May, 2007 11:27 -0700 Dave Crocker John [EMAIL PROTECTED] wrote: Were we to deprecate every feature in IETF specifications that get mis-implemented a couple of times over 10 years, I suspect much of our technology would be deprecated... John IMO, and at the risk of again agreeing with Dave, this is John the issue for me. John If we have inconsistent uses of terminology across documents John that are supposed to be using the same, standardized, term, John then that is a problem with our review process. If the term John is explicitly standardized in one of the documents, that is John the definition; things that use the term incorrectly should John be candidates for fixing. I don't see why the standardized definition is the obvious right place to fix things. I thought we were committed to running code. To me, one implication of that commitment is that sometimes the right fix is for the spec to change rather than the implementations. In a terminology conflict, this often involves moving away from the term that has two conflicting uses to terms that are more clear. Ultimately cases like this should be evaluated based on whether the final result is more clear overall. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Sam, Ultimately cases like this should be evaluated based on whether the final result is more clear overall. What about protecting the installed base for the existing spec? In other words, your based on contains a single criterion, for an environment that typically requires multiple. And the current situation is certainly one of those. Changing the specification makes sense when it does not yet have much momentum, or when the problem is basic and severe. For technology that has been in widespread use for 10-30 years, and an extremely small number of problem reports, changing the specification looks like exactly the wrong decision. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
--On Thursday, 17 May, 2007 12:42 -0400 Sam Hartman [EMAIL PROTECTED] wrote: I don't see why the standardized definition is the obvious right place to fix things. I thought we were committed to running code. To me, one implication of that commitment is that sometimes the right fix is for the spec to change rather than the implementations. In a terminology conflict, this often involves moving away from the term that has two conflicting uses to terms that are more clear. Ultimately cases like this should be evaluated based on whether the final result is more clear overall. Sam, Two observations; I hope you don't think they are contradictory. (1) We regularly get ourselves into intellectual and procedural difficulties by treating specifications about how protocol specifications are written as if they were protocol specifications. When we try to avoid that, we get ourselves into worse problems. Using rules that are more or less arbitrary, we make some of these documents Proposed Standards and then try to progress them, we make others into BCPs and, now, we make still others into IONs. If we are going to standardize a definitional requirement or method -- whether it is ABNF or IPR boilerplate or something -- we need to get it right as a self-contained definition and then live with it. We should certainly revise and replace it if it turns out to be unworkable (as has happened with IPR work) or if the definition turns out to be inadequate to permit an unambiguous interpretation (that issue spills over into my second observation, below). But, once other specifications start to depend on the definitions that are there, and show those definitions to be adequate, we should not be talking about deprecating definitions unless we are prepared to that was wrong, we need to start over (even though some of the older material may still be useful).Again, please note the similarity to the IPR work. (2) If we pretend that the ABNF metalanguage and definitions are actually a protocol specification, then we need to evaluate it as one. Then, we have the following criteria (which we usually don't state quite this precisely): (i) Is the definition good enough that interoperable implementations are possible? (ii) Do people care enough about the construct to actually use it in ways that show it is useful? Now, neither of those rules prevents non-conforming implementations. We may notice that those exist, but our concern is only about implementations that appear to conform to the spec and are (or are not) interoperable. If non-conforming implementations happen by accident because the text isn't clear enough, we try to clarify the text. But we don't say well, there are non-conforming implementations, so the spec is broken. That would make no sense at all, at least to me. The answer to (i) appears to be yes. There are lots of conforming cases. And the answer to (ii) is, as Dave as pointed out repeatedly, about 30 years worth. Is this construction dangerous if used in inappropriate contexts? Sure. Does that justify a warning note to the unwary? Probably. Is it possible to implement other things and call them by the same name (i.e., create a non-conforming implementation)? Of course. Should that invalidate the definition? Not if we want to have anything left if the principle were applied broadly. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
On Thu, 17 May 2007, John C Klensin wrote: Is this construction dangerous if used in inappropriate contexts? Sure. Does that justify a warning note to the unwary? Probably. Is it possible to implement other things and call them by the same name (i.e., create a non-conforming implementation)? Of course. Should that invalidate the definition? Not if we want to have anything left if the principle were applied broadly. +1 Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ ROCKALL: SOUTHWEST 6 TO GALE 8, INCREASING SEVERE GALE 9, PERHAPS STORM 10 LATER. VERY ROUGH OR HIGH. SHOWERS. GOOD. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
John == John C Klensin [EMAIL PROTECTED] writes: John If we are going to standardize a definitional requirement or John method -- whether it is ABNF or IPR boilerplate or something John -- we need to get it right as a self-contained definition John and then live with it. We should certainly revise and John replace it if it turns out to be unworkable (as has happened John with IPR work) or if the definition turns out to be John inadequate to permit an unambiguous interpretation (that John issue spills over into my second observation, below). But, John once other specifications start to depend on the definitions John that are there, and show those definitions to be adequate, John we should not be talking about deprecating definitions John unless we are prepared to that was wrong, we need to start John over (even though some of the older material may still be John useful). Again, please note the similarity to the IPR John work. Right. Here, I don't think the definition is wrong, I just think the term being defined is wrong. We proposed a definition for a useful concept. The word we chose (LWSP) stuck in some places but not in others. IN fact other people used the same word for a different although related concept. sufficiently so that the definition we proposed in ABNF is not the most common definition in our standards. Clearly we should not invalidate existing uses of that term. Clearly we do need a definition for the term: it is being used usefully. I think that in this instance, the value of future clarity justifies coming up with a new term that will unambiguously mean what LWSP means in ABNF today. That term will have to start at proposed standard. LWSP will need to continue in ABNF. I see a desire to document our operational experience with the word: many people took this word and used it to mean something else. Perhaps to avoid confusion you should consider whether your use of the word is a good idea. I think there is significant harm in choosing not to document this operational experience when advancing standards. After all, we both agree that it is this experience with running code that gives the IETF value. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Sam, with one small exception, I think we are in complete agreement. The exception is noted below... --On Thursday, 17 May, 2007 15:32 -0400 Sam Hartman [EMAIL PROTECTED] wrote: Right. Here, I don't think the definition is wrong, I just think the term being defined is wrong. We proposed a definition for a useful concept. The word we chose (LWSP) stuck in some places but not in others. IN fact other people used the same word for a different although related concept. sufficiently so that the definition we proposed in ABNF is not the most common definition in our standards. Counting uses in this way so as to determine what is or is not the most common definition is as tricky in our environment as counting votes. For the same reason, I'd rather that we avoid it when we can. However, if we do need to count, I think we have to use some sort of system that attributes more weight to documents that use the terminology that have been, effectively, at full standard before some of the specifications that use different definitions were even dreamt of. I don't know how to assign those weights, which, recursively, is why I don't like counting. But I don't think you can count up a handful of recent misuses and then make an inference that the base definition needs to be retired (which you haven't done, but several others have), or even that it is not appropriately common. I think that in this instance, the value of future clarity justifies coming up with a new term that will unambiguously mean what LWSP means in ABNF today. That term will have to start at proposed standard. Pragmatically, perhaps yes. But what I keep coming back to is that it appears to me to be perfectly clear and unambiguous what LWSP means in ABNF today. That is what is written into the spec. As far as I can tell, we are having a discussion about two other things: (1) Other specifications that use the term LWSP to refer to something different from what is unambiguously defined in the ABNF spec. (2) Places where people might be tempted to use LWSP but where they have discovered that LWSP is either inappropriate or risky. The second group clearly needs new and appropriate terminology for what they do need and use. The first group is, IMO, just broken. LWSP will need to continue in ABNF. I see a desire to document our operational experience with the word: many people took this word and used it to mean something else. Perhaps to avoid confusion you should consider whether your use of the word is a good idea. I think there is significant harm in choosing not to document this operational experience when advancing standards. After all, we both agree that it is this experience with running code that gives the IETF value. Again, I have no problems with making carefully-considered comments about use and misuse. I think it is a fine idea as long as those comments do not imply that the misuses are a failure in the base specification. And I think everyone should consider a stopping rule, lest, as I indicated in my deliberately extreme example, we discover that we want to retire, replace, or update IP because of some use in the legal community that precedes the use in network protocols by many years. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
--On 17. mai 2007 15:32 -0400 Sam Hartman [EMAIL PROTECTED] wrote: Right. Here, I don't think the definition is wrong, I just think the term being defined is wrong. We proposed a definition for a useful concept. Actually we defined a concept (LWSP) in a way that turned out to be much more troublesome in several contexts than we thought it would be (because it allowed two different versions of blank lines to have different semantics). The word we chose (LWSP) stuck in some places but not in others. IN fact other people used the same word for a different although related concept. sufficiently so that the definition we proposed in ABNF is not the most common definition in our standards. Clearly we should not invalidate existing uses of that term. Clearly we do need a definition for the term: it is being used usefully. I don't agree with the meaning I get from this statement. The problem is that the construct that ABNF calls LWSP causes problems in protocols that use it. This problem is independent of the name of the construct; the problem is in defining a grammar where the sequence CRLFCRLF has a different meaning than CRLFSPACECRLF. Some protocols have addressed this problem by defining their own construct, and have used the term LWSP to refer to it - something that is legal by ABNF rules, but can cause people who read multiple specs to become confused. There seems to be some reason to think that it's useful to warn people that there's reasons not to use the construct that is defined as LWSP in the ABNF spec. The revised version of the ABNF spec is one possible place to put that warning. I think that in this instance, the value of future clarity justifies coming up with a new term that will unambiguously mean what LWSP means in ABNF today. That term will have to start at proposed standard. LWSP will need to continue in ABNF. I agree with the last statement. I see a desire to document our operational experience with the word: many people took this word and used it to mean something else. Perhaps to avoid confusion you should consider whether your use of the word is a good idea. I think there is significant harm in choosing not to document this operational experience when advancing standards. After all, we both agree that it is this experience with running code that gives the IETF value. Fully agree with this statement too, but since I don't agree with your interpretation (as given above) of what the problem is, I can't be sure that my agreement with this statement means anything Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Harald, I'm happy to accept your interpretation of the problem. However it also leads me to the conclusion that documenting possible reasons not to use ABNF's LWSP concept, or documenting implications of that rule would be a good idea. I also believe that documenting experience with a spec in future versions of that spec as it advances is reasonable. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Dave == Dave Crocker [EMAIL PROTECTED] writes: Dave Sam, Ultimately cases like this should be evaluated based on whether the final result is more clear overall. Dave What about protecting the installed base for the existing Dave spec? I think that is not a useful criteria when we are talking about an informative note. I think that criteria matters somewhat more when we are talking about depricating a feature but retaining it, although even then I think the bar would be reasonably low. The installed base will continue to work. I think that criterian is very important if we were talking about removing a rule. For that reason I do not favor removing the LWSP rule. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Sam Hartman wrote: Ultimately cases like this should be evaluated based on whether the final result is more clear overall. Dave What about protecting the installed base for the existing Dave spec? I think that is not a useful criteria when we are talking about an informative note. I think that criteria matters somewhat more when we are talking about depricating a feature but retaining it, although even then I think the bar would be reasonably low. The installed base will continue to work. I think you are assuming a more constrained discussion than what I've been seeing on this thread. The thread has discussed everything from removing the rule, to redefining it, to declaring it deprecated, to adding some commentary text. It appears you are only talking about the last, although I for one missed that. (For reference, when I said change the specification I mean normative change.) Although I've seen some postings against even having a comment added to the text, my own reading of the postings is that there is a reasonable consensus that it would be ok. My own view is that comments can be helpful and are, at worst, typically rather benign. Indeed, the IETF approach towards specification writing is rather friendly towards including whatever comments folk feel might be helpful, modulo the obvious danger that too many comments can wind up obscuring a document. (And, no, I do not think that that is a danger here.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
I think redefining the rule would require recycling at proposed. I think it would be confusing and harmful to do so. I think removing the rule would is allowed by the process (and would require updates in referencing specs as they advance but would not break anything). I think doing so would be harmful and is not supported by consensus. I do not object to deprecating the rule although I'm not completely convinced doing so is a great idea.I think it is clearly allowed if there is consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
On Thu, 17 May 2007, John C Klensin wrote: (1) Other specifications that use the term LWSP to refer to something different from what is unambiguously defined in the ABNF spec. [This] group is, IMO, just broken. I agree with your sentiment but sadly there's a lot of old stuff that's broken by this criterion. RFC 733 defined LWSP-char to mean what RFC 2234 calls WSP, and linear-white-space to mean what is now LSWP. Fortunately these old definitions have fallen out of use. There's also HTTP and SIP which call the problematic production LWS instead of LWSP. MEGACO uses ABNF with its own terminal definitions instead of referring to ABNF appendix B. CGI uses its own ABNF variant. It would be nice if the progression of ABNF to a full standard reduces this Babel. This implies that (a) ABNF should be used to describe syntax in preference to any other BNF-alike, to avoid anomalies like CGI; (b) specifications should not define a production with the same name as one in appendix B but with a different expansion, to avoid anomalies like MEGACO; (c) specifications should not define a production with the same expansion as one in appendix B but with a different name, to avoid anomalies like HTTP and SIP; (d) any production like LWSP should be discouraged because of problems with lossage related to trailing whitespace. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ ROCKALL: SOUTHWEST 6 TO GALE 8, INCREASING SEVERE GALE 9, PERHAPS STORM 10 LATER. VERY ROUGH OR HIGH. SHOWERS. GOOD. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
On May 17, 2007, at 2:27 PM, Dave Crocker wrote: I think you are assuming a more constrained discussion than what I've been seeing on this thread. The thread has discussed everything from removing the rule, to redefining it, to declaring it deprecated, to adding some commentary text. I think that only the later was suggested. Declaring the macro deprecated would not remove the definition or redefine it. Any additional comments should simply indicate this construct should be used with caution and defined locally with a different mnemonic. On the bright side, this does not impact the ABNF definition. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
--On Thursday, 17 May, 2007 21:52 +0200 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: I don't agree with the meaning I get from this statement. The problem is that the construct that ABNF calls LWSP causes problems in protocols that use it. This problem is independent of the name of the construct; the problem is in defining a grammar where the sequence CRLFCRLF has a different meaning than CRLFSPACECRLF. ... Interesting. I don't think that is a problem with the grammar, and think it would be rather hard to define a grammar that would not permit that situation. After all CRLF Thing SPACECRLF could case similar problems if some construction permitted it and defining a grammar that would prohibit any SPACECRLF construction isn't easy in ABNF for reasons that have nothing to do with LWSP. Instead, I see the problem as using the grammar to define situations equivalent to LWSP [ optional-stuff ] CRLF as compared to LWSP AtLeastOneRequiredThing CRLF or [ LWSP optional-stuff ] CRLF I don't see either of the latter as problematic. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
it could be argued that the best thing to do is to remove ALL of the rules from the ABNF spec, leaving only the language definition and examples. (actually I think I did argue this sometime around 1996, but I'm too lazy to search through old email to find it. I'm actually surprised that a problem with one of those definitions has taken this long to crop up.) the rules could then be moved to a separate document, probably with status informational. I don't personally see any problem with an informational document being used to define terms that are referenced in standards track publications - so long as the document being referenced is not subject to change.the referencing document should be evaluated as if the definitions were incorporated into that document. IMHO, sometimes we try too hard to make things fit into the standards track. application of the proposed/draft/full criteria to ABNF has always been a bit odd, because ABNF defines a notation rather than a protocol. at one time we thought about evaluating interoperability of ABNF by seeing if there were multiple implementations (i.e. parser generators) that when given the same grammar, recognized the same language. but this would be kind of meaningless given that ABNF is (in my experience) almost never used as input to a parser generator for the purpose of generating a protocol implementation. which might be quite unfortunate. I think redefining the rule would require recycling at proposed. I think it would be confusing and harmful to do so. I think removing the rule would is allowed by the process (and would require updates in referencing specs as they advance but would not break anything). I think doing so would be harmful and is not supported by consensus. I do not object to deprecating the rule although I'm not completely convinced doing so is a great idea.I think it is clearly allowed if there is consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Add a warning note Bill Oxley Messaging Engineer Cox Communications 404-847-6397 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 3:03 PM To: Tony Hansen Cc: Apps Discuss; IETF General Discussion Mailing List; [EMAIL PROTECTED] Subject: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call Lisa Dusseault wrote: I share your concerns about removing rules that are already in use -- that would generally be a bad thing. However I'm interested in the consensus around whether a warning or a deprecation statement would be a good thing. LWSP has a valid meaning and use, and its being misapplied somewhere doesn't make that meaning and usage invalid. I could see a note being added. However, anything more than that is totally inappropriate. Full agreement with Tony here. Ned ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Harald Alvestrand wrote: Removing features that have proved to be a Bad Idea has always been listed as one of the possible changes from Proposed to Draft - Draft to Full happens so rarely that I would be hesitant to claim that there's tradition for such changes there. The question is the proved to be criterion. The consensus call was triggered by one documented problem in 10 years. We've had a posting claiming one additional problem (although my own recollection of that bit of history was the the list construct was the issue, rather than LWSP.) So that is a total of at most 2 documented cases in 10-30 years. And keep in mind that the issue is not that the rule does not work but that it is very rarely mis-used. Were we to deprecate every feature in IETF specifications that get mis-implemented a couple of times over 10 years, I suspect much of our technology would be deprecated... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
On Tue, 15 May 2007, Dave Crocker wrote: So that is a total of at most 2 documented cases in 10-30 years. And keep in mind that the issue is not that the rule does not work but that it is very rarely mis-used. Did you miss my post linking to a description of LWSP-related interop problems in HTTP? http://www.and.org/texts/server-http#implicit-lws Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FORTH TYNE DOGGER: WEST 4 OR 5, BECOMING VARIABLE 2, THEN SOUTHERLY 3 OR 4. SLIGHT OR MODERATE. SHOWERS THEN MAINLY FAIR. GOOD OCCASIONALLY MODERATE AT FIRST. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Tony Finch wrote: On Tue, 15 May 2007, Dave Crocker wrote: So that is a total of at most 2 documented cases in 10-30 years. And keep in mind that the issue is not that the rule does not work but that it is very rarely mis-used. Did you miss my post linking to a description of LWSP-related interop problems in HTTP? http://www.and.org/texts/server-http#implicit-lws No. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
