Subject: [Ltru] Re: HTAB

From: "Doug Ewell" <[email-masked]>
Date: Tue, 15 May 2007 21:38:03 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> record     = 1*( field-name *SP ":" *SP field-body CRLF )
> 
> You could remove the second *SP now, but keeping it is okay.

Pardon me for asking, but why do we allow a space after the field-name?

>> field-body = *([[*SP CRLF] 1*SP] 1*ASCCHAR)
>
> +1 (no more mandatory SP after the colon as in -06)

And why do we allow a field-body to begin with CRLF?

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

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

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 15 May 2007 21:43:34 -0700

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> If we *must* send the form to IANA, let us not fall into the trap of 
> sending two things. Let us fix the form to be suitable and be done with 
> it.

All right, if we agree to fix the form in such a way that IANA has NO 
character-wise editing to do, only copying and pasting of whole lines, then 
I can get on board with this.

---

From: Addison Phillips <[email-masked]>
Date: Wed, 16 May 2007 20:10:30 -0700

> Pardon me for asking, but why do we allow a space after the field-name?

We allow whitespace after the colon. Most record-jar implementations are 
likely to do the same. It's more pleasing visually and it really isn't 
that big an implementation problem. Basically, after joining lines 
(eating whitespace as we go), we can do a trim() on the field-body. It's 
not that remarkably odd.

I regret not having spent the time between 4646 and now getting 
draft-phillips-record-jar done. It would be much easier to just 
reference that than maintaining all of our own cruft.

> And why do we allow a field-body to begin with CRLF?

We always have and it isn't that big a problem. See above: you join the 
lines anyway and then trim the results. It's not a big deal at 
implementation time.

In practice, of course, the registry will most likely never contain a 
field-body starting with CRLF. However, it is imaginable that the first 
word in the field-body might be very long--perhaps it uses a long 
sequence of Unicode escapes--violating the 72 character limit and thus 
necessitating wrapping down.

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

Internationalization is an architecture.
It is not a feature.

---

From: John Cowan <[email-masked]>
Date: Wed, 16 May 2007 23:51:02 -0400

Addison Phillips scripsit:

> We allow whitespace after the colon. 

Sure.  But why *before* the colon?

-- 
If you have ever wondered if you are in hell,         John Cowan
it has been said, then you are on a well-traveled     http://www.ccil.org/~cowan
road of spiritual inquiry.  If you are absolutely     [email-masked]
sure you are in hell, however, then you must be
on the Cross Bronx Expressway.          --Alan Feuer, NYTimes, 2002-09-20

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 16 May 2007 23:21:40 -0700

Sorry about re-sending this message with no added content; it's about an 
Outlook Express UI bug.

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> that big an implementation problem. Basically, after joining lines (eating 
> whitespace as we go), we can do a trim() on the field-body. It's not that 
> remarkably odd.

I'm not asking about the whitespace after the colon, I'm asking about the 
whitespace before the colon.  I suppose that would be a French style:

    Subtag : example

> word in the field-body might be very long--perhaps it uses a long sequence 
> of Unicode escapes--violating the 72 character limit and thus 

That seems contrived, especially since the Reviewer wants to avoid Unicode 
escapes altogether, but I suppose it's conceivable and I won't argue that 
one further.

---

From: Addison Phillips <[email-masked]>
Date: Wed, 16 May 2007 23:33:11 -0700

> Sure.  But why *before* the colon?

Sweet blue muffins! For beauty. And, for that matter, because RFC 4646 
says so and someone may have implemented it by now.

Addison

---

From: Addison Phillips <[email-masked]>
Date: Thu, 17 May 2007 00:00:01 -0700

Doug Ewell wrote:
> 
> I'm not asking about the whitespace after the colon, I'm asking about 
> the whitespace before the colon.  I suppose that would be a French style:
> 
>    Subtag : example

I replied to John already: the space before the colon is already with 
us. And it is simple whitespace with no wrapping permitted.

>> We always have and it isn't that big a problem. See above: you join 
>> the lines anyway and then trim the results. It's not a big deal at 
>> implementation time.
>>
>> field-body starting with CRLF. However, it is imaginable that the 
>> first word in the field-body might be very long--perhaps it uses a 
>> long sequence of Unicode escapes--violating the 72 character limit and 
>> thus necessitating wrapping down.
> 
> That seems contrived, especially since the Reviewer wants to avoid 
> Unicode escapes altogether, but I suppose it's conceivable and I won't 
> argue that one further.

The reviewer is courting appeals, in my opinion, on that issue.

And it isn't that far fetched. For a comments line, at 8 characters per 
code point, I get just 7 before you're forced to wrap:

72 - 10 (length of Comments:) / 8 (length of &#x@@@@;) = 7.75

Any script encoded above U+1000 can generate such a comment.

Okay, maybe it is far-fetched that we wouldn't just wrap mid-word.

Really, though, there is a subtlety in constructing the ABNF that way. 
While CRLF is allowed at the start and just never happens to occur 
there, by not putting the construct at the end, you can never have extra 
space at the end. The end of the record *must* be a character. That is, 
there is no "invisible" and yet significant whitespace in the file 
(wrapping whitespace is insignificant).

Addison

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 17 May 2007 21:00:22 +0200

Doug Ewell wrote:

 [s/after/before/]
> I'm not asking about the whitespace after the colon, I'm asking
> about the whitespace before the colon.  I suppose that would be
> a French style:

>     Subtag : example

Yep.  Removing optional spaces before the colon is okay, it's an
anachronism inherited from RFC (2)822.  RFC 2822 obsoleted this:

| optional-field  =       field-name ":" unstructured CRLF
[...]
| 4.5.8. Obsolete optional fields
|
| obs-optional    =       field-name *WSP ":" unstructured CRLF

Nobody moved to reintroduce this ugly construct in 2822upd, we
could get rid of it for 4646bis.

I'm less sure about the record-jar format, aligning the colons
in a fixed column could make sense.

 [initial folding after the colon]
> That seems contrived, especially since the Reviewer wants to
> avoid Unicode escapes altogether

The personal tastes of folks on the review list are just that,
their personal tastes, requesters are free to differ.  We have
"comment:" (8 char.s) or "description:" (12 char.s), and your
personal taste is to add two spaces after the colon.  With that
you get a limit of 72-8-2=62 or 72-12-2=58 ASCII characters for
the first space delimited word.

For a description inherited from some source standard 58 isn't
excessively contrived, with &#x12345; (9 char.s) we're talking
about 6..7 Unicode points outside of the BMP.  With an initial
folding right after the colon we can handle 7..8 Unicode points
above u+FFFF without running into our own limit 72.

Maybe we should remove the limit, and keep the folding only for
bulk updates as by 4645bis (if done "within" I-D constraints).

Folding is simple, but with ordinary readers trying to "unfold"
the registry, who knows, if there's a way to screw up somebody
will explore it sooner or later.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 17 May 2007 21:17:05 +0200

> (wrapping whitespace is insignificant).

In theory you can get that effect without starting the list with [FWS].

example1A = "Example:" *([FWS] non-empty) CRLF

example2A = "Example:" [*WSP non-empty *([FWS] non-empty)] CRLF

Less ugly if you're free to decree that all fields must have a non-empty
field body - a famous exception would be the BCC field in email:

example1B = "Example:" 1*([FWS] non-empty) CRLF

example2B = "Example:" *WSP non-empty *([FWS] non-empty) CRLF

IMO we want 1A or actually 1B, we have no empty field-bodies.  But for
the record-jar format 1A is more flexible.

Frank

---

From: [email-masked]
Date: Thu, 17 May 2007 17:49:38 -0700

Actually, I'd say the space before the colon is not a question of taste. 
It's what the English language requires and this work is in English. The 
number of spaces afterward is more debatable.

Karen Broome

Frank Ellermann <[email-masked]> 
05/17/2007 12:00 PM

To
[email-masked]
cc

Subject
[Ltru] Re: HTAB

Doug Ewell wrote:

 [s/after/before/]

Frank

---

From: Addison Phillips <[email-masked]>
Date: Thu, 17 May 2007 20:42:10 -0700

This isn't English: it's a data format. Typically there are *no* spaces 
in this format. Nonetheless, I don't favor changing the grammar to 
prohibit spaces.

Addison

[email-masked] wrote:
> *Frank Ellermann <[email-masked]>*
> 
> 05/17/2007 12:00 PM
> 
> 	
> To
> 	[email-masked]
> cc
> 	
> Subject
> 	[Ltru] Re: HTAB
> 
> 
> 	
> 
> 
> 
> 
> 
> Doug Ewell wrote:
> 
> [s/after/before/]
> ------------------------------------------------------------------------
>