Subject: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call

From: Eric Allman <[email-masked]>
Date: Mon, 14 May 2007 12:46:54 -0700

I'm inclined to agree that there is a problem, and your proposed 
solution of keeping LWSP but depreciating it is probably correct. 
However, I recommended also adding a new, correct definition (for 
DKIM we used FWS from RFC 2822) and a discussion of the differences.

eric
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 14 May 2007 17:35:46 -0700

On May 14, 2007, at 3:55 PM, Dave Crocker wrote:

>
> Lisa Dusseault wrote:
>> The IESG reviewed <http://www.ietf.org/internet-drafts/draft- 
>> crocker-rfc4234bis-00.txt> for publication as Internet Standard  
>> and would like to know if there is consensus to recommend against  
>> the use of LWSP in future specifications,
>
> 1   This issue was initially raised in the IESG by Chris Newman,  
> who changed
> his Discuss, with a statement that he recommended inserting a  
> comment, along
> the lines that others are also recommending.  Unless I've misread  
> the record,
> all other votes on advancing ABNF from Draft to Full are positive  
> or neutral,.
> except for your own Discuss.  Is this correct?

The issue was initially raised by Frank Ellerman or by various in the  
DKIM WG depending on how you look at it -- Frank explicitly suggested  
possible changes to the draft, in his posting to the IETF list.

You're right about the voting situation but here's the background: I  
took on the DISCUSS myself as a placeholder for an issue that the  
IESG had consensus to investigate further (consensus to investigate  
what the consensus is).   I could have asked somebody else to hold  
the DISCUSS but this seemed most convenient as long as the rest of  
the IESG trusted me to investigate.

>
> 2.  The ABNF is a candidate for moving from Draft to Full.  Will  
> removing a
> rule (that is already in use?) or otherwise changing the semantics  
> of the
> specification, at this point, still permit the document to  
> advance?  I had the
> impression that moving to Full was based on some serious beliefs  
> about a
> specification's being quite stable.  Making this kind of change,  
> this late in
> the game, would seem to run counter to that.

Moving to Internet Standard is indeed something we do carefully, and  
of course that means investigating proposed changes to make sure  
they're appropriate, and setting a high bar for accepting them.  I  
believe that's what we're doing here, investigating carefully.

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.

Thanks,
Lisa

---

From: Tony Hansen <[email-masked]>
Date: Mon, 14 May 2007 23:20:28 -0400

Lisa Dusseault wrote:
> 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.

	Tony Hansen
	[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 15 May 2007 09:10:41 +0100

On Mon, 14 May 2007, Dave Crocker wrote:
>
>      "Could cause problems in other places"...  The DKIM hiccup was the first
> one I'd heard about.
>
>      By contrast, "linear-white-space" was defined in RFC733, in 1977, with
> RFC822 retaining that definition.  It is defined in those places as
> essentially the same as LWSP in the current ABNF Draft Standard specification.

The LWSP defined in ABNF is more like the one in HTTP than the message
format one, in that 4234 allows space-only lines (it allows multiple CRLFs
in LWSP) whereas 2822 does not (at most one CRLF in FWS).

There is some documentation of the interoperability problems arising from
the implied-LWS rule in HTTP here:
http://www.and.org/texts/server-http#implicit-lws

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER THAMES: NORTHWEST BACKING SOUTHWEST 4 OR 5, OCCASIONALLY 6
OR 7 AT FIRST. MODERATE, OCCASIONALLY ROUGH IN GERMAN BIGHT. RAIN OR SHOWERS.
MODERATE OR GOOD, OCCASIONALLY POOR.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 15 May 2007 20:21:06 +0200

Lisa Dusseault wrote:
>> rule (that is already in use?) or otherwise changing the semantics of 
>> the
>> specification, at this point, still permit the document to advance? I 
>> had the
>> impression that moving to Full was based on some serious beliefs about a
>> specification's being quite stable. Making this kind of change, this 
>> late in
> consensus around whether a warning or a deprecation statement would be 
> a good thing.
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.

Despite this, I agree with the people who think that a warning comment, 
rather than removal of the rule, is the Right Way.

Harald

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 May 2007 11:27:38 -0700

> 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
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 May 2007 20:46:09 +0200

Lisa Dusseault wrote:

> The issue was initially raised by Frank

Hi, a short explanation, initially I hoped that 4234 can be
promoted to STD "as is".  I missed the (now listed) errata
in the "pending errata mbox".

Some months later 4234bis-00 was posted, and if 4234 can't
be promoted as is, then that's an opportunity to address
this (known) LWSP issue.

Just removing it is an idea, but for the reasons stated by
Dave I felt that "just deprecating it" is good enough with
less undesirable side-effects.

After all it's simple to implement LWSP as specified.  But
unfortunately it's also simple to destroy critical white
space in an apparently empty line.  

Sorry for the confusion, I should have checked the pending
errata mbox before the proposal to promote RFC 4234 to STD.

Frank

---

From: [email-masked]
Date: Tue, 15 May 2007 12:03:04 -0700 (PDT)

> added. However, anything more than that is totally inappropriate.

Full agreement with Tony here.

				Ned

---

From: <[email-masked]>
Date: Tue, 15 May 2007 15:32:08 -0400

Add a warning note

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, May 15, 2007 3:03 PM
To: Tony Hansen
Cc: Apps Discuss; IETF General Discussion Mailing List;
[email-masked]
Subject: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call

> > consensus around whether a warning or a deprecation statement would
be a

				Ned

---

From: Tony Finch <[email-masked]>
Date: Tue, 15 May 2007 22:54:18 +0100

> 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-masked]>  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.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 May 2007 15:52:40 -0700

> problems in HTTP? http://www.and.org/texts/server-http#implicit-lws

No.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Wed, 16 May 2007 09:25:56 -0700

On May 15, 2007, at 1:10 AM, Clive D.W. Feather wrote:

> Tony Hansen said:
> +1
> Frank's text in
> <http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html>
> would be fine:
>
>   Authors intending to use the LWSP (linear white space) construct
>   should note that it allows apparently empty lines consisting only
>   of trailing white space, semantically different from really empty
>   lines.  Some text editors and other tools are known to remove any
>   trailing white space silently, and therefore the use of LWSP in
>   syntax is not recommended.
>
> However, it doesn't belong in "security considerations".

Discarding of lines is likely in response to some type of exploit.   
The consideration for not using LWSP would be in regard with how  
security requirements may create incompatibilities.  This is the  
correct section.

> What about moving LSWP, and this text, to a separate section of  
> Annex B:
> "B.3 Deprecated constructs"?

Agreed. That would also be appropriate.

Another problem regarding LWSP is in regard to _many_ differing  
definitions.  A profusion of differing definitions alone becomes a  
valid reason to deprecate the mnemonic.  This definition represents a  
poor practice as related to security which should not be facilitated  
through standardization.  By removing this problematic construct,  
better solutions are more likely to be found.  At least (ab)use of  
the mnemonic will have been discouraged.  Any continued use of this  
mnemonic should be discouraged and the note added should clarify one  
of the reasons for this mnemonic being deprecated is specifically due  
to its varied and checkered meanings in other drafts.

-Doug

---

From: Tony Finch <[email-masked]>
Date: Thu, 17 May 2007 18:48:07 +0100

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-masked]>  http://dotat.at/
ROCKALL: SOUTHWEST 6 TO GALE 8, INCREASING SEVERE GALE 9, PERHAPS STORM 10
LATER. VERY ROUGH OR HIGH. SHOWERS. GOOD.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tony Finch <[email-masked]>
Date: Thu, 17 May 2007 18:48:07 +0100

: <[email-masked]>

+1

Tony.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tony Finch <[email-masked]>
Date: Thu, 17 May 2007 18:48:07 +0100

: <[email-masked]>

+1

Tony.

---

From: Tony Finch <[email-masked]>
Date: Thu, 17 May 2007 18:48:07 +0100

: <[email-masked]>

+1

Tony.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 17 May 2007 21:52:45 +0200

--On 17. mai 2007 15:32 -0400 Sam Hartman <[email-masked]> 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 <CRLF><CRLF> has a different meaning 
than <CRLF><SPACE><CRLF>.

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

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 May 2007 00:38:15 +0100

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.

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 May 2007 21:35:43 -0400

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.
>
>

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 18 May 2007 04:35:59 +0200

John C Klensin wrote:

>     LWSP AtLeastOneRequiredThing CRLF
> or
>     [ LWSP optional-stuff ] CRLF

> I don't see either of the latter as problematic.

Depends on the protocol.  Your constructs match
      SP CRLF SP CRLF SP AtLeastOneRequiredThing CRLF
      SP CRLF SP CRLF SP optional-stuff CRLF
.........^^^^^^^^^^^^
If you do this e.g. in a mail or HHTP header, where
CRLF CRLF means "end of header", then any tool like
a text editor or other UA trying to reuse the header
field "as is" while silently removing trailing white
space would end up with
      CRLF CRLF SP AtLeastOneRequiredThing CRLF
      CRLF CRLF SP optional-stuff CRLF
......^^^^^^^^^

Frank

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 May 2007 09:00:43 +0100

On Thu, 17 May 2007, John C Klensin wrote:
>
> After all <CRLF> Thing <SPACE><CRLF> 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 <SPACE><CRLF>
> 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-masked]>  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.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 18 May 2007 14:03:01 +0100

On Fri, 18 May 2007 00:38:15 +0100, Tony Finch <[email-masked]> wrote:

> this Babel.

Well do we know exactly how much Babel there is?

If we deprecate LWSP for future use, then the remaining problem is the set  
of existing standards that rely on it (plus a few that have redefined  
it/whatever, but those are not strictly relying on it).

So has anyone grepped through the the whole RFC databas to identify which  
current standards do rely on the definition? And of those that do, how  
many of them now contain (possibly not recognised) problems arising from  
its use?

The answers to those questions might throw some light on how we should now  
proceed.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 May 2007 14:34:28 +0100

On Fri, 18 May 2007, Charles Lindsey wrote:
> current standards do rely on the definition? And of those that do, how many of
> them now contain (possibly not recognised) problems arising from its use?

The only one is RFC 4646 in the syntax for the language tag registry.
Other RFCs that use LWSP include their own variant definition of it.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOLE LUNDY FASTNET IRISH SEA: WEST OR SOUTHWEST 5 TO 7, OCCASIONALLY GALE 8,
PERHAPS SEVERE GALE 9 IN IRISH SEA LATER. MODERATE OR ROUGH, OCCASIONALLY VERY
ROUGH LATER. OCCASIONAL RAIN, FOG PATCHES AT FIRST. MODERATE OR GOOD,
OCCASIONALLY VERY POOR AT FIRST.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 May 2007 15:23:12 +0100

On Fri, 18 May 2007, John C Klensin wrote:
> On Friday, 18 May, 2007 09:00 +0100 Tony Finch <[email-masked]>
> wrote:
> >
> 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-masked]>  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.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 May 2007 09:37:54 -0700

> Well do we know exactly how much Babel there is?

John Leslie published this list on the IETF reflector:

rfc0733 obs-by rfc0822
rfc0822 defs LWSP-char = SPACE / HTAB   obs-by rfc2822
rfc0987 refs rfc0822
rfc1138 refs rfc0822
rfc1148 refs rfc0822
rfc1327 refs rfc0822
rfc1486 refs rfc0822
rfc1505 refs rfc0822
rfc1528 refs rfc0822
rfc1848 defs <LWSP-char> ::= SPACE / HTAB
rfc2017 refs rfc0822
rfc2045 refs rfc0822
rfc2046 refs rfc0822
rfc2110 refs rfc0822
rfc2156 refs rfc0822
rfc2184 refs rfc0822
rfc2231 refs rfc0822
rfc2234 defs LWSP = *(WSP / CRLF WSP)   obs-by rfc4234
rfc2243 refs rfc0822
rfc2378 defs LWSP-char = SP | TAB
rfc2530 refs rfc2234
rfc2885 defs LWSP = *(WSP / COMMENT / EOL)
rfc3015 defs LWSP = *(WSP / COMMENT / EOL)
rfc3259 defs LWSP = *(WSP / CRLF WSP)
rfc3501 refs rfc2234
rfc3525 defs LWSP = *(WSP / COMMENT / EOL)
rfc3875 defs LWSP = SP | HT | NL
rfc4234 defs LWSP = *(WSP / CRLF WSP)
rfc4646 refs rfc2434

> If we deprecate LWSP for future use, then the remaining problem is  
> the set of existing standards that rely on it (plus a few that have  
> redefined it/whatever, but those are not strictly relying on it).

Deprecating LWSP would not _remove_ or _redefine_ this macro.  The  
deprecation note could simply state this construct often is  
problematic when addressing security issues or when dealing with  
trailing whitespace.  Any future use of this construct should be  
locally defined with a different mnemonic, and preferably employ a  
different construct where possible.   Any existing standard would  
simply reference a deprecated, existing, and unchanged definition  
that has been deprecated by such a note.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 18 May 2007 22:02:33 +0200

> The only one is RFC 4646 in the syntax for the language tag registry.

Yes, fixed in the 4646bis-06 draft.  Not used in the 4646 registries:

<http://article.gmane.org/gmane.ietf.ltru/558/match=lwsp>
<http://article.gmane.org/gmane.ietf.ltru/1318/match=lwsp>

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 21 May 2007 10:34:38 +0100

> John Leslie published this list on the IETF reflector:

Of which only the following three make normatice use of LWSP as defined in  

> rfc2530 refs rfc2234

The reference is exceedingly vague as to how the LWSP is to be used

> rfc3501 refs rfc2234

which just says "don't use LWSP here"

> rfc4646 refs rfc2434

which is apparently about to be 'bis'ed.

I think we are agreed that future use of LWSP is, at the very least, to be  
deprecated. The above analysis is almost sufficient to go further and  
remove it entirely, on the grounds of non-use together with problematic  
effects.

> Deprecating LWSP would not _remove_ or _redefine_ this macro.

Indeed. However, we could follow the lead of RFC 2822 and remove the  
defiition of LWSP to a separate "obsolete" section, with the provision  
that its use MUST be accepted (by existing RFCs, which is at most the  
three above), but MUST NOT be generated (by new RFCs).

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 21 May 2007 20:15:15 +0200

Charles Lindsey wrote:

> we could follow the lead of RFC 2822 and remove the defiition of
> LWSP to a separate "obsolete" section, with the provision that
> its use MUST be accepted (by existing RFCs, which is at most the

No obs-LWSP, please, it's already bad enough.  RFC 2822 was only a
"treat as immature" PS, 4234bis will be a STD, no new requirements.

And a MUST NOT is overkill for the LWSP.  My first attempt to get
rid of it in 4646bis promptly resulted in the same problem without
LWSP.  Authors need to check their syntax, mechanically replacing
LWSP by something else might be still wrong, and then it's also
not more obvious.

Frank

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 22 May 2007 16:29:55 -0700

Thanks for everybody's input on this.  I interpret the discussion as  
showing consensus for a comment with a warning near the definition of  
LWSP.

Details:  I counted 18 opinions.  I couldn't see anybody arguing for  
"no comment or text whatsoever".  I saw arguments against treating  
this as a Security Consideration.  I saw opinions in favour of  
"deprecating" the construct, but I am not sure if that's an opinion  
for or against the health warning (since the definition of  
deprecation is loose here).  In any case, even if you count those as  
"votes against" , I still see rough consensus.

Lisa

> crocker-rfc4234bis-00.txt> for publication as Internet Standard and  
> would like to know if there is consensus to recommend against the  
> use of LWSP in future specifications, as it has caused problems  
> recently in DKIM and could cause problems in other places.
>
> Some discussion on this point already:
>  - http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html
>  - http://www1.ietf.org/mail-archive/web/discuss/current/msg00463.html
>  - http://mipassoc.org/pipermail/ietf-dkim/2007q1/007295.html
>  - https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=view_comment&id=66440  (in this tracker comment, Chris  
> Newman recommended to remove LWSP, but for backward-compatibility  
> it's probably better to keep it and recommend against use)
>
> Thanks for your input,
> Lisa Dusseault
>
>