Subject: [xml2rfc-dev] New xml2rfc release: v2.32.0

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 04 Oct 2019 05:41:53 -0700

Hi,

This is an automatic notification about a new xml2rfc release, 
v2.32.0, generated when running the mkrelease script.

Release notes:

xml2rfc (2.32.0) ietf; urgency=medium

  * Adjusted print font sizes, which were in some cases overly large.  

  * Added CSS page-break settings to avoid PDF page breaks inside tables
    and references.

  * Tweaked the styling of <aside> to be more aligned with the W3C
    description of the element.

  * Added support for the --legacy-date-format when generating the
    boilerplate expiry date.

  * Fixed an issue with the text width in <aside> text rendering.

  * Improved the handling of U+2028 in text output, and fixed a bug in the
  * handling of U+2028 in the HTML output.

  * Changed default value for --id-is-work-in-progress to True

  * Fixed an issue with incorrect section links to appendices.

  * Fixed a misspelling of "don't".  Fixes issue #434.

  * Added styling to make HTML <dl> rendering of XML <ol type='%d'> more
    like the HTML <ol> and <ul> rendering.

 -- Henrik Levkowetz <[email-masked]>  04 Oct 2019 09:57:00 +0000

The preferred way to install xml2rfc is by doing 'pip install xml2rfc',
and 'pip install --upgrade xml2rfc' to upgrade.  If there are system-
installed python modules which pip will not upgrade, you may have to
use 'pip install --upgrade --no-deps xml2rfc' and install dependencies
manually.

The new version is also available through SVN checkout, with
  'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.32.0'

Regards,

	Henrik
	(via the mkrelease script)

---

From: Julian Reschke <[email-masked]>
Date: Fri, 4 Oct 2019 16:49:19 +0200

On 04.10.2019 14:41, Henrik Levkowetz wrote:
> ...
> ...

So U+2028 is Unicode "LINE SEPARATOR". What this means is that xml2rfc
now supports forced line breaks, just a few weeks (months?) after there
was a decision not to include the <br> element.

I think this is a really bad idea, as opposed to having an explicit <br>
element, because:

1. It's kind of obscure (hint: browsers do not process it as line break).

2. The grammar doesn't help people to understand where it is allowed.
Actually, where *is* it allowed? Anywhere?

So, AFAIC, if we identify cases where we want to allow forced line
breaks, we should allow them explicitly (and in the same way HTML does).

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Oct 2019 16:57:51 +0200

> 1. It's kind of obscure (hint: browsers do not process it as line break).

Hint2: Editors do not process it as a line break (typical rendering: a hair space)

There is a reason Unicode has deprecated U+2028.

Grüße, Carsten

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Fri, 4 Oct 2019 15:25:28 +0000

On 10/4/19, 10:49 AM, "xml2rfc-dev on behalf of Julian Reschke" <[email-masked] on behalf of [email-masked]> wrote:

    

    

I have always preferred having an explicit <br/> element (however it gets spelled). I fought in the design team to have support for it in at least some limited cases, and think removing it entirely was completely the wrong decision. I'm too much of a pragmatic engineer.

	Tony

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 4 Oct 2019 17:34:13 +0200

On 2019-10-04 17:25, HANSEN, TONY L wrote:
> I have always preferred having an explicit <br/> element (however it
> gets spelled). I fought in the design team to have support for it in
> at least some limited cases, and think removing it entirely was
> completely the wrong decision. I'm too much of a pragmatic engineer.

I'm strongly for having an explicit <br/> element.

Given a clearly expressed need from the RPC, I will always try to provide
tools to make it possible for them to do their work.  Without having <br/>
available, this was a fallback solution.  Continuing to ignore clearly
expressed needs of the RPC seems unproductive.

	Henrik

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Oct 2019 17:40:31 +0200

Something is not right with the process if we have a clear requirement and an obvious solution, but instead have to resort to using an obscure, widely shunned Unicode feature so we appear not to violate the specification.

Grüße, Carsten

> On Oct 4, 2019, at 17:34, Henrik Levkowetz <[email-masked]> wrote:
> 
> Signed PGP part
>

---

From: Miek Gieben <[email-masked]>
Date: Fri, 4 Oct 2019 16:43:27 +0100

[ Quoting <[email-masked]> in "Re: [xml2rfc-dev] <br> is back, was..." ]
>Something is not right with the process if we have a clear requirement and an obvious solution, but instead have to resort to using an obscure, widely shunned Unicode feature so we appear not to vio…

+1

---

From: Julian Reschke <[email-masked]>
Date: Fri, 4 Oct 2019 18:29:16 +0200

> expressed needs of the RPC seems unproductive.

I would like the RPC to actually raise these issues here, so that we can
discuss them.

In this case, I'd really like to understand in which contexts this was
considered to be needed.

And no, nobody is proposing to ignore the RPC.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 4 Oct 2019 19:06:36 +0200

On 2019-10-04 17:40, Carsten Bormann wrote:
> Something is not right with the process if we have a clear
> requirement and an obvious solution, but instead have to resort to
> using an obscure, widely shunned Unicode feature so we appear not to
> violate the specification.

I couldn't agree more.

My recollection is that the pushback from design team members against
permitting <br> generally when this was discussed in October 2018 was so
strong that it was not accepted.  Few other people participated in the
discussion:

https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/?q=subject%3A%2337

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Fri, 4 Oct 2019 19:23:15 +0200

> In this case, I'd really like to understand in which contexts this was

So in the current AUTH48 XML files, I see one case where U+2028 is used:
apparently, to force breaks line breaks into the content of a
<blockquote>. However, the content model for <blockquote> actually
allows multiple paragraphs; see
<https://greenbytes.de/tech/webdav/rfc7991.html#element.blockquote>. I
really like to understand why that approach did not work for the RPC.

Best regards, Julian

---

From: Sandy Ginoza <[email-masked]>
Date: Fri, 4 Oct 2019 12:00:58 -0700

Julian,

I believe the editor used U+2028 here to avoid additional blank lines within the quote.  This is what we get when we use <t> tags. 

   |  The packet PW appears as a single point-to-point link to the
   |  client layer.  Network-layer adjacency formation and maintenance
   |  between the client equipments will follow the normal practice
   |  needed to support the required relationship in the client layer.
   |
   |  ...
   |
   |  This packet pseudowire is used to transport all of the required
   |  layer 2 and layer 3 protocols between LSR1 and LSR2.

I don’t think &br; is needed here, but see the examples below. 

a) This issue has come up quite a bit when we were trying to update lists/sublists where the authors want no whitespace between the indented items (no bullets; just a line break).  For example, RFC 8668 (v3 files not yet posted) contains the following in the v2 text:

      L2 Bundle Member Attributes

         Type:  25
         Length:  Number of octets to follow

      Parent L3 Neighbor Descriptor

         L3 Neighbor System ID + pseudonode ID (7 octets)
         Flags: 1-octet field of the following flags:

We were able to replicate this spacing with the following XML, which seems bad because we have empty <dd/> to get the right spacing.  If there is a better way to do this, please let us know. 

<ul empty="true">
<li>
<dl spacing="compact"><dt>L3 Neighbor System ID + pseudonode ID (7 octets)               
</dt><dd></dd>
<dt>Flags: 1-octet field of the following flags:</dt><dd></dd>
</dl>

b) A similar example about trying to force a line break: Is there a better way to do this?

section 3 of https://www.rfc-editor.org/v3test/rfc8668_AR2.txt
https://www.rfc-editor.org/v3test/rfc8668_AR2.xml

Desired output:

         L2 Bundle Member Link Local Identifiers
         (4 * Number of L2 Bundle Member Descriptors octets)

How we forced the break in XML:

    <t>L2 Bundle Member Link Local Identifiers (4&nbsp;*&nbsp;Number&nbsp;of&nb\
sp;L2&nbsp;Bundle&nbsp;Member&nbsp;Descriptors&nbsp;octets)</t>

text output is good enough:
         L2 Bundle Member Link Local Identifiers
            (4 * Number of L2 Bundle Member Descriptors octets)

----
same thing as above, but with a different use of <ol>:

section 3 of https://www.rfc-editor.org/v3test/rfc8668_AR4.txt
https://www.rfc-editor.org/v3test/rfc8668_AR4.xml

text output:
      -  L2 Bundle Member Link Local Identifiers
         (4 * Number of L2 Bundle Member Descriptors octets)

c) Re: https://www.rfc-editor.org/authors/rfc8652.html#section-5

Uused two <artwork>s to get

Under /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/igmp-mld:igmp,

and

Under /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/igmp-mld:mld,

to appear w/ the (seemingly) desired line break. If it were considered running text, then <t> would be right, but there's no <br>.  
(Guess we could use <t> and a bunch of &nbsp; and &wj to prevent each 2nd line from breaking, but that seems not ideal.)

d) The most recent issue has been resolved by the adjustment of font size in the PDF, but the title of the RFC 8658 (also not yet posted) appeared ok in the .html and .txt files, but the PDF was breaking as follows:

RADIUS Attributes for Softwire
Mechanisms Based on Address plus Port (A
+P)

It has been a struggle to convert some of these files and Henrik has been kind enough to review cases and provide input. 

Thanks,
Sandy

> On Oct 4, 2019, at 10:23 AM, Julian Reschke <[email-masked]> wrote:
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Oct 2019 08:38:03 +1300

On 05-Oct-19 04:34, Henrik Levkowetz wrote:
...
> I'm strongly for having an explicit <br/> element.

I concur. My conclusion from 30+ years of using various markup languages is
that explicit line breaks are needed, even if they offend some ideal vision
of markup theory. Sometimes there is simply no alternative.

   Brian

---

From: Sandy Ginoza <[email-masked]>
Date: Fri, 4 Oct 2019 12:42:44 -0700

Just an additional point on this one.  Henrik has already suggested differently handling — looks like we haven’t implemented yet.  This one is included to show where a <br> could have been useful instead of looking for creative ways to workaround not having it.

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Fri, 4 Oct 2019 20:57:16 +0000

On 10/4/19, 3:01 PM, "Sandy Ginoza" <[email-masked]> wrote:

    Julian,

     . . .
 
On 10/4/19, 3:42 PM, "Sandy Ginoza" <[email-masked]> wrote:
    Just an additional point on this one.  Henrik has already suggested differently handling — looks like we haven’t implemented yet.  This one is included to show where a <br> could have been useful instead of looking for creative ways to workaround not having it.  
    . . .

Thank you, Sandy.

I think these examples are very creative and horrendous at the same time. What should be a simple thing instead has become a time sink figuring out workarounds. IMO, that is NOT the best use of the RFP's time.

If the RPC sees a continued need for this capability, I think it should be made easy.

	Tony

---

From: Julian Reschke <[email-masked]>
Date: Sat, 5 Oct 2019 06:08:59 +0200

On 04.10.2019 21:00, Sandy Ginoza wrote:
> ... > I believe the editor used U+2028 here to avoid additional blank lines
within the quote.  This is what we get when we use <t> tags.
> I don’t think &br; is needed here, but see the examples below.

My first reaction was that if the citation skips a paragraph, then
having the dots on a separate line would be the right thing.
Alternatively, if text inside a paragraph was skipped, I'd use inline "
... " or " (...) ".

So I checked the source of the citation and found that the first part is
from <https://tools.ietf.org/html/rfc6658#section-3>, while the second
part is extracted from the previous section. So I would argue that this
is a strange use of <blockquote>. These should be *two* <blockquote>s.

> <dt>Flags: 1-octet field of the following flags:</dt><dd></dd>

Well, the obvious answer is: don't. If it's not a definition list, don't
use <dl>.

In general, we really need to stop to focus on the TXT output. Bending
the vocabulary to get precisely a certain text output is the wrong path.
What's really relevant is getting proper *HTML* output.

I have my doubts that an extra blank line here is really a problem.

>              (4 * Number of L2 Bundle Member Descriptors octets)

But HTML will put it onto one line is the viewport is wide enough.

>           (4 * Number of L2 Bundle Member Descriptors octets)

I believe the answer is the same as above. Don't. Please really consider
whether this is worth the effort. In any case: do not try to add
workarounds to get a certain plain text output. Plain text is a
secondary output format.

The point of the xml2rfc vocabulary is to markup things based on their
semantics, not based on a certain desired plain text output.

If we can't get acceptable *HTML* output, let's consider the use case
and come up with a proper solution (which might be <br/>).

> (Guess we could use <t> and a bunch of &nbsp; and &wj to prevent each 2nd line from breaking, but that seems not ideal.)

Why do these need to be on separate lines? (I don't understand the
context yet...)

> Mechanisms Based on Address plus Port (A

If it breaks inside "A+P" instead of using the whitespace two characters
before than this looks like a bug in the formatter to me.

> It has been a struggle to convert some of these files and Henrik has been kind enough to review cases and provide input.

Understood.

I just don't think that re-introducing line breaks through the back door
is the right thing here. If they are needed, let's discuss them as as
part of the vocabulary.

(And yes, there was ample time to have this dicussion; RFC 7991 finished
three years ago).

Best regards, Julian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Oct 2019 17:36:40 +1300

Hi Julian,
On 05-Oct-19 17:08, Julian Reschke wrote:
...> The point of the xml2rfc vocabulary is to markup things based on their
> semantics, not based on a certain desired plain text output.

Fair enough; if we want to illustrate a point with a plain text example, then <artwork> seems appropriate. But I think we are talking about something else: cases where we *want* the text to stop here
and continue on the next line, whatever output format (including HTML) we are using.
 
> and come up with a proper solution (which might be <br/>).

It applies to PDF etc too.

<snip>

> Why do these need to be on separate lines? (I don't understand the

Ah, but a tool designer doesn't *need* to understand the context. If the author *wants* a line break, that's all we need to know.

> (And yes, there was ample time to have this dicussion; RFC 7991 finished

I'm a bit confused: https://tools.ietf.org/html/rfc7991#section-2.12

Regards
    Brian

---

From: Miek Gieben <[email-masked]>
Date: Sat, 5 Oct 2019 07:17:59 +0100

[ Quoting <[email-masked]> in "Re: [Rfc-markdown] [xml2rfc]  [xml2..." ]
>I'm a bit confused: https://tools.ietf.org/html/rfc7991#section-2.12

There was a long discussion on limiting <br> for use in table *only*, after that 
was written. More discussion ensued and <br> was outlawed in the entire 
document. And now we are here.

/Miek

--
Miek Gieben

---

From: Brian Carpenter <[email-masked]>
Date: Sat, 5 Oct 2019 19:40:21 +1300

Sorry, outlawed by who, in which RFC?

Regards
    Brian
    (via tiny screen & keyboard)

---

From: Miek Gieben <[email-masked]>
Date: Sat, 5 Oct 2019 07:59:46 +0100

[ Quoting <[email-masked]> in "Re: [Rfc-markdown] [xml2rfc] [xml2r..." ]
>Sorry, outlawed by who, in which RFC?

you have to read the thread, I think this:

https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#section-3.1.5

is the only thing that exist outside of that particular discussion.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 5 Oct 2019 09:05:43 +0200

> Sorry, outlawed by who, in which RFC?

That is a good summary of the discussion of the year so far.

(If anyone wonders why I’m so slow to pick up v3 in kramdown-rfc:
It is just too hard to guess what v3 actually is.
And it’s changing, while stability of the authoring format is the whole point of kramdown-rfc.
So generating v2-v3 and hoping that the RFC editor will bang the v3 derived from it into shape is the best transition strategy right now.)

Grüße, Carsten

---

From: Miek Gieben <[email-masked]>
Date: Sat, 5 Oct 2019 08:22:00 +0100

[ Quoting <[email-masked]> in "Re: [xml2rfc-dev] [Rfc-markdown] [x..." ]
>So generating v2-v3 and hoping that the RFC editor will bang the v3 derived from it into shape is the best transition strategy right now.)

I'm in the same boat with mmark. I do output xmlv3 but it's mostly what RFC7991 
specifies.

So what this triggers is the following situation: once xml2rfc is deemed OK for 
the RFC editor, both Carsten and I will try to convert markdown to xmlv3, which 
will likely tricker questions (which may lead to changes, etc.). 

Making these changes now, involves reading the xml2rfc *changelog*(!), and 
doesn't provide any stability guarantees.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 5 Oct 2019 09:36:35 +0200

> I'm a bit confused: https://tools.ietf.org/html/rfc7991#section-2.12

Yes, but see
<https://greenbytes.de/tech/webdav/rfc7991.html#rfc.section.2.12.p.2>:

"This element appears as a child element of <td> (Section 2.56) and <th>
(Section 2.58)."

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 5 Oct 2019 09:40:56 +0200

On 05.10.2019 08:17, Miek Gieben wrote:
> There was a long discussion on limiting <br> for use in table *only*,
> after that was written. More discussion ensued and <br> was outlawed in
> the entire document. And now we are here.
> ...

Hmm, no.

RFC 7991 only allows <br/> in table cells. The long discussion you are
referring lead to the removal of the element. See
<https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/37>.

Best regards, Julian

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 05 Oct 2019 07:46:38 -0700

> I would like the RPC to actually raise these issues here, so that we 

A big +1 to this. Otherwise, we will get solutions like the one just 
implemented that go against standards guidance like using U+2028, which 
is deprecated.

> In this case, I'd really like to understand in which contexts this was

Yes, that.

> And no, nobody is proposing to ignore the RPC.

We can't ignore them if we can't hear them.

--Paul Hoffman

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 6 Oct 2019 10:51:40 +1300

> <https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/37>.

Yes, well, as far as I know RFC7991 is the community consensus (it's an IAB stream document, formally). So I don't think we are done with the discussion, if the RPC is now saying there are cases where <br/> would avoid using a deprecated Unicode codepoint. Maybe issue 37 should be reopened.

    Brian

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 6 Oct 2019 23:01:41 +0200

On 2019-10-05 23:51, Brian E Carpenter wrote:
> Yes, well, as far as I know RFC7991 is the community consensus (it's
> an IAB stream document, formally). So I don't think we are done with
> the discussion, if the RPC is now saying there are cases where <br/>
> would avoid using a deprecated Unicode codepoint. Maybe issue 37
> should be reopened.

I concur.

	Henrik

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 7 Oct 2019 02:20:22 +0000

On 10/5/19, 12:36 AM, "xml2rfc-dev on behalf of Brian E Carpenter" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Julian,
    On 05-Oct-19 17:08, Julian Reschke wrote:
    ....> The point of the xml2rfc vocabulary is to markup things based on their

    
    
    <snip>

    

And one of the things that is SUPPOSED to happen post publication is for real use to provide feedback on how to fix any glitches that were found trying to use it.

Well, we're trying to use it for real now.

Sandy, does the RPC feel that the ability to add a line break is needed? If so, I think the answer is clear on what to do.

	Tony

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 7 Oct 2019 02:32:19 +0000

On 10/5/19, 2:17 AM, "xml2rfc on behalf of Miek Gieben" <[email-masked] on behalf of [email-masked]> wrote:

    
The reason it wound up being supported at all in that limited scope was because I did an analysis of tons of XMLv2 documents that used a line break to see 1) how and why it had been used before, and 2) where there was no other mechanism available via other language constructs. The biggest use I found that had no alternative was in tables. Unfortunately, I was swamped with other things when this topic came up in Oct 2018.

	Tony

---

From: Sandy Ginoza <[email-masked]>
Date: Tue, 8 Oct 2019 08:21:19 -0700

Hi Tony,

> On Oct 6, 2019, at 7:20 PM, HANSEN, TONY L <[email-masked]> wrote:
> 
> Sandy, does the RPC feel that the ability to add a line break is needed?

Yes, the RPC would appreciate being able to use <br>.

Thanks!
Sandy

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 8 Oct 2019 18:17:24 +0200

> Yes, the RPC would appreciate being able to use <br>.

Ok, I then propose that we permit <br> in body text, including lists and
tables, and in document and section titles.  More specifically, I propose to
permit <br> as a child element of these elements:

   blockquote
   dd
   dt
   em
   li
   name
   strong
   t
   td
   th
   title
   tt

(Should <sub> and <sup> be in that list?  If we compare with the places where
for instance <bcp14> is permitted, the answer would be 'yes'; but I'm not
sure it's the right thing to do.)

	Henrik

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Tue, 8 Oct 2019 16:19:25 +0000

From: Rfc-markdown <[email-masked]> on behalf of Sandy Ginoza <[email-masked]>
Date: Tuesday, October 8, 2019 at 11:22 AM
To: "HANSEN, TONY L" <[email-masked]>
Cc: Julian Reschke <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Brian E Carpenter <[email-masked]>
Subject: Re: [Rfc-markdown] [xml2rfc-dev] [xml2rfc] <br> is back, was: New xml2rfc release: v2.32.0

Hi Tony,

On Oct 6, 2019, at 7:20 PM, HANSEN, TONY L <[email-masked]<mailto:[email-masked]>> wrote:

Thanks!
Sandy

Thank you for that confirmation, Sandy.

Someone mentioned that they thought that <br> had been deprecated in HTML5. I’ve found no evidence that WhatWG has done so. The “living spec” calls out <br>’s use as “Line break, e.g. in poem or postal address”. (<https://html.spec.whatwg.org/multipage/indices.html#elements-3>)

Paul re-opened the issue in trac. I think the path is clear on what needs to be done. Can we call consensus?

                Tony

---

From: Julian Reschke <[email-masked]>
Date: Tue, 8 Oct 2019 18:37:59 +0200

> tables, and in document and section titles.  More specifically, I propose to

If we do allow it in titles, we'll have to specify and test what happens
when you have an <xref> with format="title" to those.

That said: what's the use case for titles? Is this to control line
breaking, or to introduce the concept of a secondary title? In the
latter case, we may want to do it differently.

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Oct 2019 16:55:10 +0000

> sure it's the right thing to do.)

This seems to go well beyond what the RPC asked for and significantly muddies the semantics of the v3 format.

The concern of the folks who contributed to the v3 design is that <br> everywhere would have authors thinking that they could put in line breaks for emphasis, or for making the output look "right" without any semantic meaning. In the original HTML semantics, <br> is a block-level break, not a character formatting break.

Given that, I would propose to instead allow <br/> in the following:

blockquote
dd
li
name
t
td
th

(I strongly dislike having <br/> in <name>, but we allow other formatting there, so this should be allowed as well.)

Sandy: Would that suit the needs of the RPC?

--Paul Hoffman

---

From: Julian Reschke <[email-masked]>
Date: Tue, 8 Oct 2019 19:20:19 +0200

> latter case, we may want to do it differently.

Also: how does the presence of a line break in a document title affect
how it gets cited?

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 8 Oct 2019 19:51:26 +0200

> Given that, I would propose to instead allow <br/> in the following:

So that removes dt, em, strong, title and tt.

<title> is one of the cases the RPC already ran into, so eliminating that
from the list will leave one of their cases unhandled.

The case I made in the original issue #37 still holds:  Limiting <br> too
strongly will result in a lot of surprises for authors, when they expect
to be able to use <br/>, but the validation fails.  I think this is
applicable for em, strong, and tt.

Additionally, the case Sandy mentioned where the author wanted a piece of
text set on two lines is very likely to come up for <tt>, so not permitting
<br> there seems wrong.

As for dt, it will have similar issues as <title> and <name>.  It will only
become an issue when the RPC runs into a case where there's a long <dt>
text which doesn't display well without <br>.

I think the right thing, both for the RPC and authors in general, is to have
<br> available everywhere they might end up using it, rather than restricting
it too strongly.

	Henrik

> xml2rfc-dev mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc-dev
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 8 Oct 2019 20:35:33 +0200

On 08.10.2019 19:51, Henrik Levkowetz wrote:
> ...
> ... > So that removes dt, em, strong, title and tt.
>

That may be true; but then, it would be awesome to understand whether
this was about:

   1. *not* breaking the title in a specific place when the title was
too long, or

   2. breaking the title because it really consists of two different parts.

For case 1) I think the "old" approach of just using &nbsp; between
words not to be broken apart is better. For 2) I'll claim that <br/> is
not the right thing to do; <subtitle> might be a better fit.

> applicable for em, strong, and tt.

No strong opinion here. I don't believe that we need them inside these
elements, though.

> text set on two lines is very likely to come up for <tt>, so not permitting

Would that be

   <tt>a<br/>b</tt>

? The same effect could still be achieved using:

   <tt>a</tt><br/><tt>b</tt>

> text which doesn't display well without <br>.

Are the expectations here the same for HTML and TXT output? Do we have
an example?

> <br> available everywhere they might end up using it, rather than restricting

Well, if we do, we need to define what happens when the content is
referenced somewhere else (xref, reference, ...).

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Oct 2019 21:08:03 +0000

> So that removes dt, em, strong, title and tt.

Another way to look at this is to say "it does not include them in a new design".
  
> from the list will leave one of their cases unhandled.

I agree with Julian: putting <br> in a title for various reasons can cause various bad side-effects.

Sandy: Can you tell the group what the specific need that the RPC saw for <br> in <title>?
  
> applicable for em, strong, and tt.

There is literally no way to avoid surprises for authors in v3, or in v2. Document formatting always has surprises.

> text set on two lines is very likely to come up for <tt>, so not permitting

<t>
<tt>This is the first line</tt><br>
<tt>This is the second line</tt>
</t>
... is exactly the right semantics for what a line break is meant to do.
  
> As for dt, it will have similar issues as <title> and <name>.  

It will also have the same problems.

> It will only

This is not about "display well", it is about semantics. One of the overarching goals of the v3 work was to have semantically sensible long-lived documents that can be displayed in a variety of formats on a variety of types of displays.

> <br> available everywhere they might end up using it, rather than restricting

We should hear directly from the RPC about their needs. Also, none of us in this conversation are good representatives of typical authors of RFCs because we are already too familiar with v2 and v3 and XML and so on.

--Paul Hoffman

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 8 Oct 2019 23:28:20 +0200

> Another way to look at this is to say "it does not include them in a new design".

My point was simply to list the ones we didn't agree on.  Does this really
need a quibble?

> cause various bad side-effects.

Yes, well, there's a need here.  I tried to say that already a year ago.

> There is literally no way to avoid surprises for authors in v3, or in
> v2. Document formatting always has surprises.

That doesn't mean we should do it harder than it needs to be.  We should
try to consider the needs of the users, not only principles of the design.

> .... is exactly the right semantics for what a line break is meant to do.

I'm sorry, but I really cannot see how that is more pure and right than

 <t>
   <tt>
      This is the first line<br/>
      This is the second line
   </tt>
 </t>

I think this is very much a difference in the eye of the beholder.

> This is not about "display well", it is about semantics. One of the
> overarching goals of the v3 work was to have semantically sensible
> long-lived documents that can be displayed in a variety of formats on
> a variety of types of displays.

Unfortunately, a complete semantic model for what RFC authors might want
to express in an RFC would be so complex that we'd probably never complete
it.  Providing escape hatches that lets authors generate text that
communicates their ideas is more important than sticking to a restricting
semantic model for unbounded semantic content.

> We should hear directly from the RPC about their needs. Also, none of
> us in this conversation are good representatives of typical authors
> of RFCs because we are already too familiar with v2 and v3 and XML
> and so on.

I'm very happy that in this round of comments more people have expressed
a viewpoint than in the previous round.

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 9 Oct 2019 07:58:17 +0200

> Yes, well, there's a need here.  I tried to say that already a year ago.

A need for something, yes. A need for a fixed line break, maybe not. It
would be great if somebody could actually answer my question, repeated
below:

--- snip ---

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Oct 2019 10:33:40 +0200

> not the right thing to do; <subtitle> might be a better fit.

Heather, Sandy, Alice,

Could you please provide some more information about the requirements here?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Oct 2019 20:01:12 +0200

> Yes, the RPC would appreciate being able to use <br>.

Just checking: absent <br/>, are you planning to use the Unicode escape
anytime soon? That would be a problem for the canonical XML, if we
decide to revert this change.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Oct 2019 12:36:48 +0200

> decide to revert this change.

I note that there is one XML in AUTH48 using this (RFC 8668), so this
really is a bit pressing.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Oct 2019 13:33:12 +0200

> really is a bit pressing.

This uses a &br; entity reference — we can easily change that entity into “<br />” later without touching the XML file :-)

(I’m not finding the “rfc2629-xhtml.ent”, so maybe that already is the case.)

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Oct 2019 13:42:16 +0200

> (I’m not finding the “rfc2629-xhtml.ent”, so maybe that already is the case.)

That's an interesting idea, but it would be in conflict with
<https://greenbytes.de/tech/webdav/rfc7998.html#dtd-removal>.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Oct 2019 13:56:12 +0200

Right.  I forgot that the XML file in /authors appears to be authoring-RFCXMLv3, not publishing-RFCXMLv3, so it is not indicative here.  (It still has &nbsp; which also needs to be expanded.(*))

Grüße, Carsten

(*) 7998 appears to be mute about native encoding vs. character references.

> On Oct 18, 2019, at 13:42, Julian Reschke <[email-masked]> wrote:
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Oct 2019 15:04:04 +0200

>> really is a bit pressing.

All of the entity references used during the RPC work are converted to
unicode code points when the prepped file is produced.  If you see an
entity reference in a prepped file it's either a bug or it has been added
manually.

> This uses a &br; entity reference — we can easily change that entity into
> “<br />” later without touching the XML file :-)
> 

It's been in the xml2rfc distribution for ages.  If it's desired to make it
more widely available, I'm sure we could do that.

	Henrik

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Oct 2019 16:49:12 +0200

Hi Henrik,

> On Oct 18, 2019, at 15:04, Henrik Levkowetz <[email-masked]> wrote:
> 
> Signed PGP part
> 

I think that was what Julian was afraid of: Having U+2028 in an immutable published RFC.

> It’s been in the xml2rfc distribution for ages.  

I have 424 files with that name on my laptop.
These fall into the following equivalence classes (grouped by md5sum):

 316 1205eb5efbbc8d9a734ba77055388d70
  88 1aa6d2431ef0219b231913c8fb3c9253
   2 234420ff1ceb61201fa41655b841513a
   3 46cad1ba9b921fe41a9102e912073d74
   2 7a013cd802f0df7e3d9000cd85b9749f
   2 a66a1389336402406e917908aa6e3255
   8 cc77bb83d0c9c7c19afd2da03140f1b7
   3 d2faa8069ff9e2ef2c7c097d2e17cbad

Of these, I find these in xml2rfc:

  22 1205eb5efbbc8d9a734ba77055388d70
   2 234420ff1ceb61201fa41655b841513a
   2 a66a1389336402406e917908aa6e3255
   8 cc77bb83d0c9c7c19afd2da03140f1b7

I didn’t diff all these combinations against each other, but one recent change seems to be:

<!-- Typographic help characters -->
<!ENTITY zwsp   "&#8203;"><!-- U+232A RIGHT-POINTING ANGLE BRACKET        -->
<!ENTITY br     "&#8232;"><!-- U+2028 LINE SEPARATOR                      -->
<!ENTITY wj     “&#8288;"><!-- U+2060 WORD JOINER                         -->

And more recently:

<!-- Typographic help characters -->
<!ENTITY zwsp   "&#8203;"><!-- U+200B ZERO WIDTH SPACE                    -->
<!ENTITY nbhy   "&#8209;"><!-- U+2011 NON BREAKING HYPHEN                 -->
<!ENTITY br     "&#8232;"><!-- U+2028 LINE SEPARATOR                      -->
<!ENTITY wj     "&#8288;"><!-- U+2060 WORD JOINER                         -->

> If it's desired to make it
> more widely available, I’m sure we could do that.

I was looking for a statement about the definitive source (and thus the definitive version), not a 425th copy…

(It also should be put into the RFC-editor’s /authors directory, so that the authoring-RFCXMLv3 files there can be validated.)

Grüße, Carsten

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Oct 2019 16:54:48 +0200

Hi Carsten,

> I think that was what Julian was afraid of: Having U+2028 in an

I'd be more than happy to move to <br/> if we could make that useful for
the RPC.

I think most people who voiced an viewpoint on that was for making it
generally available, but when I proposed how to do that, it seemed to
run into opposition again.

> I have 424 files with that name on my laptop.

I'm sorry.  I took the 'I’m not finding the “rfc2629-xhtml.ent”' at face
value.  And yes, it has been changing, it has not been static over time.
I'm sorry if I gave that impression.  I only wanted to point at how it
has been made available.

> (It also should be put into the RFC-editor’s /authors directory, so that the authoring-RFCXMLv3 files there can be validated.)

Agreed.

	Henrik

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Oct 2019 17:49:06 +0200

> run into opposition again.

There were some questions about line-breaking in titles in general (whether <br/> or U+2028).

I think that there is wide consensus about using <br/> in favor of U+2028.

The fact that unlike the former, the latter is not visible in the schemas makes U+2028 a great way to cheat around the consensus.
We should not do that.

As in the question about restricting Unicode character sets, I believe that — as long as the vocabulary has a meaning — the schema (mechanism) is not the place to make restrictions based on beauty, style etc. (policy).  So I would prefer to have <br/> in the places in the schema where it has well-defined semantics.  We can figure out later whether this is always, only exceptionally, or never good style.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Oct 2019 17:53:42 +0200

> run into opposition again.

I *am* opposed to make it available inside titles, because I think the
requirement here is different and might need a solution other than <br/>.

Still waiting for the production center's feedback on that.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Oct 2019 18:05:31 +0200

On 2019-10-18 17:49, Carsten Bormann wrote:
> The fact that unlike the former, the latter is not visible in the
> schemas makes U+2028 a great way to cheat around the consensus. We
> should not do that.
> 
> As in the question about restricting Unicode character sets, I
> believe that — as long as the vocabulary has a meaning — the schema
> (mechanism) is not the place to make restrictions based on beauty,
> style etc. (policy). So I would prefer to have <br/> in the places in
> the schema where it has well-defined semantics. We can figure out
> later whether this is always, only exceptionally, or never good
> style.

I agree with this.  So again, I propose to permit <br> as a child element
of these elements, where I think the semantics of a <br> would be well-
defined:

   blockquote
   dd
   dt
   em
   li
   name
   strong
   t
   td
   th
   title
   tt

Should <sub> and <sup> be in that list?  If we compare with the places where
for instance <bcp14> is permitted, the answer would be 'yes'; but I'm not
sure it's the right thing to do.

Coming back to Carsten's point about well-defined semantics, I'm not sure
that is the case for <sub> and <sup>.  Should that imply text stacking
within for instance the <sup>, or should the whole line be broken and the
superscript continued on the next line?  Does that even make sense?

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Oct 2019 18:09:11 +0200

Hi Carsten,

On 2019-10-18 16:49, Carsten Bormann wrote:
>> If it's desired to make it more widely available, I’m sure we could
>> do that.
> 
> I was looking for a statement about the definitive source (and thus
> the definitive version), not a 425th copy…

Ah. Ok.  This is always the latest version:

http://svn.tools.ietf.org/svn/tools/xml2rfc/trunk/cli/xml2rfc/templates/rfc2629-xhtml.ent

Best regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Oct 2019 18:41:13 +0200

> sure it's the right thing to do.

For <title>, I will continue to ask about the use case (line break
opportunity vs required line break vs title & subtitle), as this affects
what would happen if it occurs in a <reference>, or if there's an <xref>
with format="title".

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Oct 2019 18:53:54 +0200

> superscript continued on the next line?  Does that even make sense?

To me this sounds like any use cases would involve math, which should be handled separately.

If we are unsure about the semantics, we should not put that nesting in.
We can always amend the schema; we just don’t want to amend the existing instances that need to conform to any new version.

I share Julian’s curiosity about the use cases (really: intended semantics) for title/br.

The one example we can see in RFC-8668-to-be is

  <li><t>L2 Bundle Member Link Local Identifiers&br;
  (4 * Number of L2 Bundle Member Descriptors octets)</t>

where I think we already have consensus that this should go in.
(And, yes, defining the entity as <br/> is a nice way to make that transition.)

Grüße, Carsten

---

From: Sandy Ginoza <[email-masked]>
Date: Fri, 18 Oct 2019 10:33:33 -0700

Hi all,

> On Oct 18, 2019, at 9:41 AM, Julian Reschke <[email-masked]> wrote:
> 
> with format="title”.

I don’t think we'll need <br> in titles; it's sufficient to have wj, nbsp, and nbhy.  

If we come across examples where <br> would be useful in titles, we can revisit this discussion at that time. However, please note that if this case arises, it means publication of the document will be delayed until xml2rfc is updated.

Thanks,
Sandy

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Oct 2019 19:36:07 +0200

Hi Carsten,

> I share Julian’s curiosity about the use cases (really: intended semantics) for title/br.

I wrote about this last year.  But essentially, it's a matter of how to
break a long title; of making it possible to break a long title in at a
point that makes sense for a reader.  Two cases where the document title
is too long to display nicely, and line breaking helps/would help:

 1) https://www.ietf.org/id/draft-levkowetz-xml2rfc-v3-implementation-notes-10.html
    (or, if you prefer)
    https://www.ietf.org/id/draft-levkowetz-xml2rfc-v3-implementation-notes-10.txt

 2) In a PDF rendering received from the RPC, the title of RFC8648-to-be,
    "RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)"
    broke across lines as follows:

    which is less than perfect.  Having <br/> as a tool makes sense to me
    here too.

> where I think we already have consensus that this should go in.

Ack.

> (And, yes, defining the entity as <br/> is a nice way to make that transition.)

Ack.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Oct 2019 19:53:29 +0200

> what would happen if it occurs in a <reference>, or if there's an <xref>

Of course we'd have to decide how to handle this in <reference> and <xref>.

My first suggestion would be to replace it with a simple space for those
cases, and let the local rendering do its thing based on that.

And as for probably every case where <br/> would be used as a fallback, it
would also be possible to come up with a more sophisticated semantic model
and schema.

But that does not negate the usefulness of having the <br/> fallback until
we have decided to adopt that more sophisticated model and schema.

	Henrik

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 18 Oct 2019 17:55:19 +0000

> I don’t think we'll need <br> in titles; it's sufficient to have wj, nbsp, and nbhy.

Thanks. Do you feel the same about <name>, which has similar semantics?

--Paul Hoffman

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Oct 2019 20:12:39 +0200

Hi Sandy,

One question, below:

On 2019-10-18 19:33, Sandy Ginoza wrote:
> If we come across examples where <br> would be useful in titles, we
> can revisit this discussion at that time. However, please note that
> if this case arises, it means publication of the document will be
> delayed until xml2rfc is updated.

So, how would you handle the first of my two examples in an earlier message
in this thread:  The title of my implementation notes draft, which requires
more than one line both in text, html and pdf rendering:

                     Implementation notes for RFC7991,
                    "The 'xml2rfc' Version 3 Vocabulary"

Regards,

	Henrik

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 18 Oct 2019 18:29:18 +0000

>                      "The 'xml2rfc' Version 3 Vocabulary"

This question presupposes that where a title is broken in a particular rendering is important. RFCs 7792, 7794, and 7795 did not indicate any such importance in their discussion of titles. In particular, for the HTML rendering that most people focused on in the discussion that led to the v3 format, line breaks are explicitly unimportant because the rendering might be on a narrow screen. It sounds like this issue is being brought up despite the text in the relevant RFCs.

--Paul Hoffman

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Oct 2019 20:34:02 +0200

Hi Paul,

On 2019-10-18 20:29, Paul Hoffman wrote:
> This question presupposes that where a title is broken in a
> particular rendering is important. RFCs 7792, 7794, and 7795 did not
> indicate any such importance in their discussion of titles. In
> particular, for the HTML rendering that most people focused on in the
> discussion that led to the v3 format, line breaks are explicitly
> unimportant because the rendering might be on a narrow screen. It
> sounds like this issue is being brought up despite the text in the
> relevant RFCs.

Yes, well, I'm bringing this issue up because I ran smack into it with
the title of my implementation notes draft.  In real life, I think there
are cases where indicating a particular break point makes sense.  To me,
it is that simple.

	Henrik

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Oct 2019 20:51:06 +0200

>    which is less than perfect.  Having <br/> as a tool makes sense to me

The problem with <br/> here is that this really is conditional on a specific line length.
My screen does not have a problem with

  RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)

(Not sure you can see this, but this is all on one line.)

Binding things together more tightly works better here than providing fixed places for breaking things apart.

Line breaking in titles is sometimes weird when the original form is multiple semantically separate lines and one wants a form that fits on one line.  Typically, dashes are added, so

      Quantities and units
      Part 13: Information science and technology

becomes

      Quantities and units – Part 13: Information science and technology

Breaking this up again might lead to

      Quantities and units –
      Part 13: Information science and technology

Which is OK but not really what is wanted.
(Are document titles poetry?)

Grüße, Carsten

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Oct 2019 21:04:56 +0200

Hi Carsten,

> The problem with <br/> here is that this really is conditional on a specific line length.

Yes, of course.

> (Not sure you can see this, but this is all on one line.)

Sure, in this email, yes.  But there are width limitations with both our
HMTL rendering stylesheet and its print version (for PDF).

> places for breaking things apart.

Yes, this is right in some cases -- in others, not.  Eventually, I added
support for WORD JOINER, in order to make tighter binding possible explicitly
for the case above.  But please, if you're going to analyse this example,
also do the same for my first example.

> Line breaking in titles is sometimes weird when the original form is
> multiple semantically separate lines and one wants a form that fits
> on one line. Typically, dashes are added, so
> 
>       Quantities and units

So in a medium that does not permit that line to be shown full width,
would you prefer to not provide a break point, leading to for instance

	Quantities and units – Part
	13: Information science and
	technology

or

	Quantities and units –
	Part 13: Information science
	and technology

?

If you bind every word after the dash tightly to the following words,
then you'll get a line that is force broken in a middle of a word or
alternatively extends past the display width.  If you can indicate a
break point after the dash, the following line can be broken at a good
point.

In particular in the PDF and text output cases, we _do_ have width
limitations.  With the current style sheet, in HTML too, but the
title lines there are a bit longer.

> (Are document titles poetry?)

Maybe some of them are :-)

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Oct 2019 22:07:09 +0200

>      https://www.ietf.org/id/draft-levkowetz-xml2rfc-v3-implementation-notes-10.txt

This IMHO is a case of "this is a good place for a line break, but it's
not required here". <br/> is unconditional. Previously, the Production
Center has handled this by adding NBSPs in places where no line break
was wanted. (not ideal, I agree, but workable).

>      which is less than perfect.  Having <br/> as a tool makes sense to me

No. I'd question why the render breaks the line there, and not before
"(A+P)". This really looks like a bug to me.

Best regards, Julian

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 22 Oct 2019 08:52:11 +0100

I am trying to debug a problem where a co-author is getting different 
results from the kramdown system that I get.

We are using the online kramdown to rfc text system.

I have been sent their .xml file, and at the end it has the source in 
compressed format.

Presumably I can edit out the source into a file and then uncompress it, 
but I cannot seem to see anywhere what the compression format is in.

Please can someone tell me how to get the original source back from the 
compressed trailer in the .xml file.

Thanks

Stewart

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Oct 2019 09:57:56 +0200

On Oct 22, 2019, at 09:52, Stewart Bryant <[email-masked]> wrote:
> 
> I am trying to debug a problem where a co-author is getting different results from the kramdown system that I get.
> 
> I have been sent their .xml file, and at the end it has the source in compressed format.
> 
> Presumably I can edit out the source into a file and then uncompress it, but I cannot seem to see anywhere what the compression format is in.
> 
> Please can someone tell me how to get the original source back from the compressed trailer in the .xml file.

[CCing rfc-markdown:]

Install kramdown-rfc:

  gem install kramdown-rfc2629

Use this command:

  kramdown-rfc-extract-markdown xyz.xml

I don’t think anyone offers this as a web service at this point.
(Of course, you can simply mail me the file…)

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Tue, 22 Oct 2019 18:59:27 +0200

> Thanks. Do you feel the same about <name>, which has similar semantics?

I would think so (/me not Sandy, though).

Anyway, I think we *do* have consensus about introducing <br> in certain
places where prose is allowed. It would be good to implement that so
that the spec(s?) that is in AUTH48 can move forward.

We can always revisit this and add <br> in more places when the need
comes up, and we have looked at alternatives.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Oct 2019 06:50:07 +0100

> comes up, and we have looked at alternatives.

No feedback? One more week has passed, and this really looks like
something that should have top priority...

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Oct 2019 07:16:20 +0100

On Oct 29, 2019, at 06:50, Julian Reschke <[email-masked]> wrote:
> something that should have top priority…

Feedback from whom?
I didn’t reply to your summary because I thought we had a conclusion.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Oct 2019 07:20:53 +0100

> I didn’t reply to your summary because I thought we had a conclusion.

Well, either the RSE, the production center, or Henrik...

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Oct 2019 07:29:09 +0100

> Well, either the RSE, the production center, or Henrik...

We don’t have a WG chair here that is responsible for detecting and declaring consensus…

Grüße, Carsten

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 29 Oct 2019 07:31:49 +0100

> I didn’t reply to your summary because I thought we had a conclusion.

Here's what I've understood so far:

<br> generally available:

	Brian
	Miek
	Tony
	Henrik

Generally Available except maybe in title:

	Sandy

Available except in title and name:

	Julian

Limited availability (only in some named tags)

	Paul

Available in many places, but position on title unclear to me:

	Carsten

Regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Oct 2019 08:04:36 +0100

> Available in many places, but position on title unclear to me:

As a first step, I'd make it available exactly where the production
center needs it right now, so that the publication process can proceed.

(I think that means "in <t>" right now)

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Oct 2019 08:08:50 +0100

> Here’s what I've understood so far:

[…]

Right.  I thought we had a conclusion on the one(*) RFC-to-be that uses &br; (RFC 8668, which needs a break in a list item), I don’t think we have reached one for the whole issue.

> Available in many places, but position on title unclear to me:

Not sure I wrote this already, but in case I didn’t, let me point out:

— In many cases, people use breaks to express what actually are keeps.  
  Given varying widths, it is better to be able to express the actual keeps.

— Having said that, not having a break in a certain place may motivate putting in a dash, as in

      Quantities and units

  vs.

  To express this, one would need a <break-or-dash/> element.

  Maybe it is good enough to always keep the dash and just prefer breaking after it:

      Quantities and units —

  This could be coded as

      <keep>Quantities and units —</keep> <keep>Part 13: Information science and technology</keep>

Grüße, Carsten

(*) Hmm. RFC 8626?  This can be worked around by splitting the blockquote.  
I’m not sure I understand the relationship to RFC 8655, where this was done already.

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 29 Oct 2019 08:31:58 +0100

On 2019-10-29 08:08, Carsten Bormann wrote:
> Right. I thought we had a conclusion on the one(*) RFC-to-be that
> uses &br; (RFC 8668, which needs a break in a list item), I don’t
> think we have reached one for the whole issue.
>

Mmm.  I'm not sure what you mean by keeps.  However, I think there are
places where a preferred break-point -- call it maybe-break -- would be
more useful than <br/>.

>       <keep>Quantities and units —</keep> <keep>Part 13: Information science and technology</keep>

Oh, I see.  I think expressing that through maybe-break (<mbr/> ???) would
be easier for authors, but the functionality would be the same (I think).

Regards,

	Henrik

---

From: Sandy Ginoza <[email-masked]>
Date: Wed, 30 Oct 2019 07:37:08 -0700

Hi all,

> On Oct 28, 2019, at 11:31 PM, Henrik Levkowetz <[email-masked]> wrote:
> 

If possible, I’m in favor of allowing <br> generally — it’s not 100% clear to me that we won’t ever need <br> in <title> or <name>.  To help move us along and get <br> allowed in the less contentious areas, I’m ok with using the other entities available to us in <title> and revisiting this topic as needed.  

Sidenote: I am concerned that the ability to update the v3 vocabulary in the future will be tough and time consuming, especially with the RSE’s departure.

Thanks,
Sandy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2019 15:44:50 +0100

On 30.10.2019 15:37, Sandy Ginoza wrote:
> ...
> If possible, I’m in favor of allowing <br> generally — it’s not 100%
> clear to me that we won’t ever need <br> in <title> or <name>.  To help

IMHO, we shouldn't modify the vocabulary unless it's either trivial, or
there is a compelling use case. I don't think this is the case here.

> move us along and get <br> allowed in the less contentious areas, I’m ok
> with using the other entities available to us in <title> and revisiting
> this topic as needed.

+1 (if by that you mean using NBSP to bind words together).

> Sidenote: I am concerned that the ability to update the v3 vocabulary in
> the future will be tough and time consuming, especially with the RSE’s
> departure.
> ...

At this point, I'd be very surprised if we had a consolidated,
documented, tested and reviewed V3 vocabulary by the end of the year. So
we should make sure that in the transition period, we'll be able to
continue to work on that.

Best regards, Julian