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
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-
--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
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,
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
--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
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
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
--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
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
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
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
--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
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
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
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
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
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
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
--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
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
;
[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
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
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
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
25 matches
Mail list logo
