[rfc-i] Adding line breaks to v3 [from xml2rfc]

Sean Leonard dev+ietf at seantek.com
Mon Jun 30 12:06:42 PDT 2014


On 6/30/2014 11:46 AM, Julian Reschke wrote:
> On 2014-06-30 20:30, Sean Leonard wrote:
>> Hello, I got a request from Paul Hoffman to discuss this proposal on
>> rfc-interest. This proposal was posted on the xml2rfc mailing list.
>>
>> ************************
>>
>>  From my experience with the current xml2rfc, there is no way (other
>> than <vspace>) to break a line with <t> or <list> elements, such that
>> there are no blank spaces between the resulting text blocks.
>
> Why is this even desirable inside paragraphs or list items?
>
> Can you give an example?
> [...]
> The HTML5 even says:
>
>> br elements must be used only for line breaks that are actually part 
>> of the content, as in poems or addresses.
> Do you have any use cases like that in xml2rfc? 

Line breaks are an integral part of the content, as are paragraphs. They 
are ways to delimit information in a way that is stronger than a space, 
but less strong than a full paragraph break. It is like saying that 
spaces or tabs are "formatting" and not "content". Something can have 
formatting qualities, but still be content. Sometimes xml2rfc generates 
two spaces after a period; other times it only generates one. This is a 
formatting difference that is also an integral part of the content: two 
spaces separate sentences; one space separates things like abbreviated 
words in the same sentence (e.g., "i.e.", "etc.", etc.).

You just gave two examples: poems and addresses. Poems occasionally show 
up in RFCs (sometimes they do-- RFC 1121, RFC 527--and although these 
examples may be humorous they are still part of IETF culture and ought 
to be respected). Addresses occur more often. Sometimes addresses are 
necessary outside of the prescribed template locations.

The use case that motivated me to work on this was 
draft-seantek-certspec 
<https://tools.ietf.org/html/draft-seantek-certspec-03>, where I wanted 
to include multiple protocol strings in table cells, where each protocol 
string was distinct and differentiable. The cells in the left column 
have a single protocol element--thus there is a 1-to-many association. I 
suppose I could have formatted it as a list, such as:

***
1. 2.5.4.3
   a. cn (CN)
   b. commonName
2. 2.5.4.7
   a. l (L)
   b. localityName
***

but, that would make the data run on for many pages, reducing its 
effectiveness. Additionally, it would be difficult or confusing for a 
reader to distinguish between the numbered list content and the list 
numbering at first glance. The current output of xml2rfc makes it worse:

***
1. 2.5.4.3

   a. cn (CN)

   b. commonName

2. 2.5.4.7

   a. l (L)

   b. localityName

***

In contrast, a compact table can relate the same information in 4 
content lines, instead of 12:
+----------------------------+-------------------------------+------+
    | OID                        | Names                         | RFC  |
+----------------------------+-------------------------------+------+
    | 2.5.4.3                    | cn (CN)                       | 4514 |
    |                            | commonName |      |
    | 2.5.4.7                    | l (L)                         | 4514 |
    |                            | localityName |      |

This is a 3x savings.

Sean



More information about the rfc-interest mailing list