[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>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.
In an IID, this bit is in position 6, i.e., position 70 in the complete IPv6 address.
<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.
In an IID, this bit is in position 7, i.e., position 71 in the complete IPv6 address.
More information about the rfc-interest