Subject: [Ltru] draft-ietf-ltru-4646bis-05

From: Chris Newman <[email-masked]>
Date: Wed, 09 May 2007 23:55:15 -0700

Quick question:

Looking at the definition for "field-body":

   field-body = *(ASCCHAR/LWSP)

Was the actual intention:

   field-body = *([FWS] 1*ASCCHAR)

   FWS = [*WSP CRLF] 1*WSP

?

                - Chris

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Addison Phillips <[email-masked]>
Date: Thu, 10 May 2007 09:35:32 -0700

Hi Chris,

No, that's not a mistake. Your proposal would allow folding whitespace 
following the colon, but no spaces in the body of the value or (the main 
purpose of LWSP in the production) to wrap lines.

Also, FWS is not defined by RFC 4234, as LWSP is, and the effect is 
essentially the same.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

---

From: Chris Newman <[email-masked]>
Date: Thu, 10 May 2007 10:51:17 -0700

Please double-check your understanding of the RFC 2822-based ABNF I mentioned. 
It's a bit obscure, but it is semantically identical to the current ABNF except 
that it forbids whitespace-only folded lines because that's been an 
interoperability problem in some cases.  Specifically, this case (using < to 
indicate end-of-line):

Foo: bar<
 <
 baz<

Is permitted by LWSP, but not by FWS.  I do understand that the ABNF for FWS is 
a bit more obscure in order to eliminate that case, so perhaps it doesn't 
matter in for this document.  But I wanted to make sure it's intentional to 
allow whitespace-only folded lines.

                - Chris

---

From: Addison Phillips <[email-masked]>
Date: Thu, 10 May 2007 11:34:16 -0700

Hm... yes, I see it now. Yes, that makes sense.

Is FWS formally defined somewhere? Or should I just put the production 
into the ABNF?

Addison

Chris Newman wrote:
> Please double-check your understanding of the RFC 2822-based ABNF I 
> mentioned. It's a bit obscure, but it is semantically identical to the 
> current ABNF except that it forbids whitespace-only folded lines because 
> that's been an interoperability problem in some cases.  Specifically, 
> this case (using < to indicate end-of-line):
> 
> Foo: bar<
> <
> baz<
> 
> Is permitted by LWSP, but not by FWS.  I do understand that the ABNF for 
> FWS is a bit more obscure in order to eliminate that case, so perhaps it 
> doesn't matter in for this document.  But I wanted to make sure it's 
> intentional to allow whitespace-only folded lines.
> 
>                - Chris
>

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 11 May 2007 13:33:53 +0200

Addison Phillips wrote:
 
> FWS is not defined by RFC 4234, as LWSP is, and the effect is
> essentially the same.

It's not, LWSP can be harmful:  LWSP allows lines consisting of
only "trailing" white space with a semantical difference from
"really empty" lines.

Defining FWS without this undesirable "feature" is simple, just
pick the RFC 2822 definition and remove its <obs-FWS>:

| FWS = ([*WSP CRLF] 1*WSP)  ; Folding white space

After that s/LWSP/FWS/g = replace "all" LWSP by FWS, but that's 
only the one found by Chris in -05.  IOW you could also get rid
of LWSP by inserting the proper FWS directly:

-   field-body = *(ASCCHAR/LWSP)
+   field-body = *(ASCCHAR / ([*WSP CRLF] 1*WSP))

And if you hate TABs (with those "Unicadets" I never know... ;-) 
you could just say SP instead of WSP:

+   field-body = *(ASCCHAR / ([*SP CRLF] 1*SP))

Frank (certainly no fan of TABs in the language subtag registry)

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 11 May 2007 13:44:45 +0200

Chris Newman wrote:

> I wanted to make sure it's intentional to allow whitespace-only
> folded lines.

Thanks.  IIRC we discussed it for RFC 4646, but somehow we let it
slip through.  IMO a bug without a corresponding paragraph in the
security considerations, but we do NOT need pseudo-empty lines
for the purposes of the registry.  <FWS> is as always much better
than <LWSP>.

Frank

P.S. for 4234bis fans, I hope we'll get a caveat in the ABNF STD:
<http://permalink.gmane.org/gmane.ietf.general/24801>

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 11 May 2007 14:11:41 +0200

Addison Phillips wrote:
 
> Or should I just put the production into the ABNF?

With that approach some minutes ago I arrived at:

|   field-body = *(ASCCHAR / ([*SP CRLF] 1*SP))

But that's still not what we really want, it allows
adjacent ... FWS FWS ... with the same issue as LWSP.

What we really want are non-empty ASCCHAR sequences
separated by FWS:

|   field-body = *([FWS] 1*ASCCHAR)

Eliminating the FWS and TABs again this should be:

|   field-body = *( [[*SP CRLF] 1*SP] 1*ASCCHAR )

Frank

---

From: Addison Phillips <[email-masked]>
Date: Fri, 11 May 2007 06:46:18 -0700

> |   field-body = *( [[*SP CRLF] 1*SP] 1*ASCCHAR )

Yup. Got that subtlety on the second look: the field-body is followed by 
CRLF in the record production, so we want it to end with non-whitespace 
characters (especially of the empty line variety).

I'm not sure that LWSP rises all the way to the level of a bug. The only 
fields really affected are Comments or maybe some ridiculous 
Description, where excessive whitespace is merely ugly, not fatal. 
Still, I'm happy to have the correction.

Addison

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 11 May 2007 17:53:20 +0200

Addison Phillips wrote:
 
> I'm not sure that LWSP rises all the way to the level of a bug.

Nor me.  But looking in my awk script I find it as potential bug
(in my script):

#### unfold field body ############################################
/^[\t ]/       {    BODY = BODY " " STRIP( $0 )
                    next
               }
#### garbage ######################################################
               {    exit FATAL( $0 )
               }

A "really empty" line would end up in the catchall "garbage" case,
and not continue through the "unfold field body" blurb.  So IF we
would have a folded line consisting of only trailing white space,
as permitted in the 4646 syntax, and IF that trailing white space
wouldn't survive the IANA procedure creating records, THEN my awk
script would scream FATAL and give up.

Of course we don't do this in practice, but then it's also okay to
document what we mean.  If we kill the TABs all I've to do for 
4646bis is to delete some \t.  And I better do this today before
I forget it... ;-)

Frank

---

From: Chris Newman <[email-masked]>
Date: Thu, 10 May 2007 19:17:30 -0700

You could reference FWS from RFC 2822.  Although that's a bit more complex 
because it includes the obsolete grammar from 822.  Might be simpler to just 
include FWS if the WG chooses to make this change.

                - Chris

Addison Phillips wrote on 5/10/07 11:34 -0700:

> Is FWS formally defined somewhere? Or should I just put the production into
> the ABNF?
>
> Addison
>
> Chris Newman wrote:

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 12 May 2007 01:48:21 +0200

>>|   field-body = *( [[*SP CRLF] 1*SP] 1*ASCCHAR )
[...]
> Still, I'm happy to have the correction.

In -06 you say:

|     field-body = *(([*WSP CRLF] 1*WSP) 1*ASCCHAR)

ITYM square brackets [[*WSP CRLF] 1*WSP] here, or
do you want mandatory white space after the colon?

It might be actually a good idea...

Frank