Header self-refs should use anchor names chosen by the author

[asbjornu]

Describe the issue

As pointed out by @royfielding in #1156 (comment):

It is not appropriate for the tools to override the anchor names chosen by the authors. We deliberately chose those names and expect them to appear in all section and ToC references. It is still a bug even if the old references work, since we do not want two or three alias names for every section ref. We only want the ones that are authored in the XML.

As an example, the Range Requests header in RFC 9110 points to the anchor #name-range-requests, while the appropriate anchor to point to would be #range.requests, as the presumably author-chosen identifier of the header's parent element:

<div id="range.requests">
  <section id="section-14">
    <h2 id="name-range-requests">
      <a href="#section-14" class="section-number selfRef">14. </a>
      <a href="#name-range-requests" class="section-name selfRef">Range Requests</a>
    </h2>
    <p id="section-14-1">…</p>
    <p id="section-14-2">…</p>
    <div id="range.units">…</div>
    <div id="field.range">…</div>
    <div id="field.accept-ranges">…</div>
    <div id="field.content-range">…</div>
    <div id="partial.PUT">…</div>
    <div id="multipart.byteranges">…</div>
  </section>
</div>

Code of Conduct

• I agree to follow the IETF's Code of Conduct

[reschke]

This is bad in particular as the document author has only limited control about what goes into the "slugifiedName" (as the algorithm for generating it is undefined).

[kesara]

As noted by @reschke, name-range-requests anchor comes from slugifiedName.
The preptool step adds the following line:

<name slugifiedName="name-range-requests">Range Requests</name>

But I'm not sure this counts as a bug since internal references still use the author-provided (range.requests) anchor.

The table of contents uses the slugifiedName according to RFC 7992 ¹.

Footnotes

1. https://www.rfc-editor.org/rfc/rfc7992.html#section-6.6 ↩

[reschke]

It's a bug, as we want the author-provided anchors to be used. Those should be used by default (stability across revisions), and thus need to be what the readers see in the address bar (for bookmarking etc).