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

Brian E Carpenter brian.e.carpenter at gmail.com
Mon Jun 30 13:49:32 PDT 2014


On 01/07/2014 07:06, Ted Lemon wrote:
> On Jun 30, 2014, at 2:46 PM, Julian Reschke <julian.reschke at gmx.de> wrote:
>> Why is this even desirable inside paragraphs or list items?
> 
> It's desirable when list elements are brief.   If list elements are multi-line, you probably want the blank line, but a lot of times they are quite short, and it would be nice to be able to say "no blank space between elements."   This sounds more like an attribute than a tag, though.

Below is what I regard as a typical use of <vspace/> today. The question is
whether it's worth providing a new way of doing it. In HTML one would
traditionally just put <br><br>. And yes, sometimes I use
<vspace blankLines="0"/> when I really want to force a newline.

I think the real defect in xml2rfc v2 is the absence of <li>,
not the absence of <br>.

<t><list style="symbols">
<t>The "u/l" bit in a MAC address <xref target="IEEE802"/> is set to 0 to indicate universal scope
(implying uniqueness) or to 1 to indicate local scope (without implying uniqueness).
In an IID formed from a MAC address, this bit is simply known as the "u" bit and its
value is inverted, i.e., 1 for universal scope and 0 for local scope.
According to RFC 4291 and <xref target="RFC7042"/>, the reason for this was to make
it easier for network operators to manually configure local-scope IIDs.
<vspace blankLines="1"/>
In an IID, this bit is in position 6, i.e., position 70 in the complete IPv6 address.
</t>

<t>The "i/g" bit in a MAC address is set to 1 to indicate group addressing
(link-layer multicast).  The value of this bit is preserved in an IID, where it is
known as the "g" bit.
<vspace blankLines="1"/>
In an IID, this bit is in position 7, i.e., position 71 in the complete IPv6 address.
</t>
</list></t>


    Brian


More information about the rfc-interest mailing list