Hi Erik, I wrote: >> There seems to be an expectation that IANA will make >> https://iana.org/assignments/http-problem-types#foo resolvable. >> I'm not sure IANA is in a position to do this today. This is indeed a very terse statement. https://iana.org/assignments/http-problem-types#foo will indeed be resolvable in the sense that something is returned from https://iana.org/assignments/http-problem-types That registry doesn’t exist yet, so for an example, let’s look at https://www.iana.org/assignments/http-alt-svc-parameters Which currently redirects to https://www.iana.org/assignments/http-alt-svc-parameters/http-alt-svc-parameters.xhtml This has two id= attributes: alt-svc-parameters and table-alt-svc-parameters (The name of the actual registry on this page, and the name for a table inside that registry section (marked by an <h2, not a <section.) There are no fragment identifiers provided for the entries of the table. What my comment was trying to say is that it is unlikely that IANA will convert any registered type URI https://iana.org/assignments/http-problem-types#foo into an ID on that HTML page. So the fragment identifier points into thin air. Worse, there is no contract (specification/documentation) for the HTML format that IANA uses here, and they have been actively barring the RFC editor to put fragment identifiers into IANA references. So they might go ahead and put an id=“foo” on a later registration that points to a document called foo, or uses a footnote called foo, … E.g., on https://www.iana.org/assignments/cbor-tags you find an id=“Kris_Zyp” and an id=“note1”. I don’t think the registrant or the designated expert should be juggling fragment IDs in an attempt to avoid this kind of conflict. Grüße, Carsten -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
