Catching up with some relations defined in HTML5:

• Relation Name: external
• Description: refers to a resource that is not part of the same site as the current context
• Reference: https://html.spec.whatwg.org/multipage/links.html#link-type-external

• Relation Name: modulepreload
• Description: refers to a module that the user agent is to preemptively fetch and store for use in the current context
• Reference: https://html.spec.whatwg.org/multipage/links.html#link-type-modulepreload

• Relation Name: noopener
• Description: indicates that any newly created top-level browsing context which results from following the link will not be an auxiliary browsing context
• Reference: https://html.spec.whatwg.org/multipage/links.html#link-type-noopener

• Relation Name: opener
• Description: indicates that any newly created top-level browsing context which results from following the link will be an auxiliary browsing context
• Reference: https://html.spec.whatwg.org/multipage/links.html#link-type-opener

@annevk, please review. I've modified the descriptions a bit to fit better into the conventions of the registry. I'm not entirely sure about noopener and opener, but I think they'll suffice.

Note that I've used the WHATWG links here; as I read this, they're the most up-to-date links for HTML. @wseltzer / @annevk, is that correct?

If so, we should update other links in the registry too.

Please confirm that:

• You have read and understood the requirements for registration.
• You have checked the registry and found no current link relation types that meet your needs.
• Your specification reference URL is stable; ideally, managed by a widely-recognised standards development organisation (e.g., published as an RFC). Otherwise, please give additional information.

If so, please enter the details of the link relation type below:

• Relation Name: sipTrunkingCapability
• Description: A capability document that defines parameters or configuration requirements for automated peering and communication channel negotiation of the Session Initiation Protocol (SIP).
• Reference: https://datatracker.ietf.org/doc/html/draft-engi-siptrunkingcapability-link

Any additional information (this will not be included in the registry)?
The ASAP working group has been chartered to standardize a configuration workflow to enable enterprise Session Initiation Protocol (SIP) networks to solicit the capability set of a SIP service provider network. The capability set can subsequently be used to configure features and services on the enterprise edge element, such as a Session Border Controller (SBC), to ensure smooth peering between enterprise and service provider networks. The basis of this channel negotiation relies on the exchange of a capability set document between devices to streamline configuration requirements gathering for the peering process. We are requesting the registration of a "sipTrunkingCapability" link type that would contain parameters and configuration requirements to allow this level of automated peering. Please let us know if there is any technical rigor that we can provide or proposed changes to the reference draft.

For further reference, the ASAP draft for automating SIP trunking is available here: https://datatracker.ietf.org/doc/html/draft-ietf-asap-sip-auto-peer

Relation Name

me

Description

Used to indicate profile equivalence and for identity-consolidation.

Reference

https://microformats.org/wiki/rel-me and https://gmpg.org/xfn/11

Additional Information

rel="me" is used on hyperlinks from one page about a person to other pages about that same person. rel="me" is published by many personal websites, GitHub, Mastodon, and more. Mastodon, personal websites, and more consume the standard, too.

The rel="me" specification was published in XFN and is maintained by the microformats community.

Relation Name

dns-prefetch

Requested Changes

The Reference field should be updated to list https://html.spec.whatwg.org/multipage/links.html#link-type-dns-prefetch

Relationship

I’m employed by the W3C and I am also a WHATWG member.

Additional Information

See w3c/whatwg-coord#6

Please confirm that:

• [Y] You have read and understood the requirements for registration.
• [Y] You have checked the registry and found no current link relation types that meet your needs.
• [Y] Your specification reference URL is stable; ideally, managed by a widely-recognised standards development organisation (e.g., published as an RFC). Otherwise, please give additional information.

If so, please enter the details of the link relation type below:

• Relation Name: application-figure
• Description: Refers to a resource with an available representation in the 'application' media type subtree suitable for rendering within the context.
• Reference: https://purl.org/net/figure-link-rels

Any additional information (this will not be included in the registry)?

It's not clear whether RFC 8288's injunction that link relations "MUST NOT constrain the available representation media types of the link target" refers to constraining to specific individual media types, or placing any restriction on media types. The figure-link-rels specification says that a resource has a representation in a specific subtree, but does not restrict other representations, nor does it restrict to any specific media types.

Please confirm that:

• [Y] You have read and understood the requirements for registration.
• [Y] You have checked the registry and found no current link relation types that meet your needs.
• [Y] Your specification reference URL is stable; ideally, managed by a widely-recognised standards development organisation (e.g., published as an RFC). Otherwise, please give additional information.

If so, please enter the details of the link relation type below:

• Relation Name: video-figure
• Description: Refers to a resource with an available representation in the 'video' media type subtree suitable for rendering within the context.
• Reference: https://purl.org/net/figure-link-rels

Any additional information (this will not be included in the registry)?

It's not clear whether RFC 8288's injunction that link relations "MUST NOT constrain the available representation media types of the link target" refers to constraining to specific individual media types, or placing any restriction on media types. The figure-link-rels specification says that a resource has a representation in a specific subtree, but does not restrict other representations, nor does it restrict to any specific media types.

Relation Name

micropub

Description

Used to create, update and delete posts on one's own domain using third-party clients.

Reference

https://www.w3.org/TR/micropub/

Additional Information

Micropub is a W3C Recommendation used to create, update and delete posts on one's own domain using third-party clients. There are multiple interoperable implementations of Micropub clients and servers on the web, with which people post content such as likes, posts, replies, and bookmarks to websites. More information about the Micropub protocol's use in the wild is documented on the IndieWeb wiki Micropub page.

Enter the details of the link relation type below:

• Relation Name: intervalAfter
• Description: If a proper interval T1 is intervalAfter another proper interval T2, then the beginning of T1 is after the end of T2.
• Reference: W3C OWL-Time clause 4.2.21

Any additional information (this will not be included in the registry)?

This is one of a set of 15 interval relations which have been adapted from Allen's work, and formalized in the W3C OWL-Time ontology:

I will refrain from submitting separate issue for the other 14 until this one has been commented on ;-)

Relation Name

indieauth-metadata

Description

Used to advertise the location of an IndieAuth authorization and token endpoint, and other information for clients.

Reference

https://indieauth.spec.indieweb.org/

Additional Information

IndieAuth was published as a W3C Note by the Social Web Working Group. Since being published as a note, the specification has been incubated by the IndieWeb community as a living standard and has received several revisions. One revision adds the indieauth-metadata rel value, used to discover authentication and token endpoints for use in domain-based authentication, and discovery of relevant attributes to facilitate said authentication (i.e. protocols supported by a server).

Relation Name

prerender

Requested Changes

1. Add a note to the Notes field, with this content:

   This relation is not part of any current standard, though support for it is implemented in Blink (the engine used by Google Chrome and other Chromium-based browsers).

2. The Reference field should be updated to list https://www.w3.org/TR/2023/DISC-resource-hints-20230314/.

   Completely remove the contents of the Reference field. (The current contents are “[Resource Hints]”, but https://www.w3.org/TR/resource-hints/ now redirects to https://html.spec.whatwg.org/#linkTypes, which now does not contain any definition for the prerender link relation.

Relationship

I’m employed by the W3C and I am also a WHATWG member.

Additional Information

See w3c/whatwg-coord#6

Relation Name

dns-prefetch

Requested Changes

The dns-prefetch link relation should be completely removed, because it’s not supported in the Link header.

Relationship

I’m employed by the W3C and I am also a WHATWG member.

Additional Information

See w3c/whatwg-coord#6 (comment)

Relation Name

prefetch

Requested Changes

The prefetch link relation should be completely removed, because it’s not supported in the Link header.

Relationship

I’m employed by the W3C and I am also a WHATWG member.

Additional Information

See w3c/whatwg-coord#6 (comment)

Site seems unrelated now. Contacted Amazon OpenSearch; they directed to this link.

If you wanted to offer JSON-LD as an export option, alongside the existing CSV, here is a script that converts the CSV to JSON-LD. Cf. mnot/I-D#140

#!/usr/bin/env python3
"""
Usage: ./rels.py link-relations-1.csv URL
URL should be e.g. 'http://www.example.org/assignments/relation/#'
"""

from typing import Any, Dict, Iterator, List

def fold(lines: Iterator[str]) -> Iterator[str]:
    next(lines)
    line: str
    buffer: List[str] = []
    for line in lines:
        line = line.rstrip("\n")
        if line.startswith(" "):
            buffer.append(line.lstrip(" "))
            continue
        if buffer:
            yield " ".join(buffer)
            buffer[:] = []
        buffer.append(line)
    if buffer:
        yield " ".join(buffer)


def fields(lines: Iterator[str]) -> Iterator[List[str]]:
    from re import Match, Pattern, compile

    quoted: Pattern[str] = compile(r'"((?:[^"]|"")*)"')
    def replace(m: Match[str]) -> str:
        value: str = m.group(1)
        value = value.replace('""', '"')
        value = value.replace(",", "\ud800")
        return value
    for line in lines:
        line = quoted.sub(replace, line)
        v: str
        yield [v.replace("\ud800", ",") for v in line.split(",")]


def main() -> None:
    from json import dumps
    from sys import argv

    filename: str = argv[1]
    data: Dict[str, List[Any]] = {
        "@context": [
            {"citation": "http://purl.org/dc/terms/bibliographicCitation"},
            {"description": "http://purl.org/dc/terms/description"},
            {"label": "http://www.w3.org/2000/01/rdf-schema#label"},
            {"note":"http://www.w3.org/2004/02/skos/core#note"}
        ],
        "@graph": []
    }
    with open(filename, encoding="utf-8", errors="replace") as f:
        for row in fields(fold(f)):
            if len(row) != 4:
                continue
            datum: Dict[str, str] = {
                "@id": "http://www.iana.org/assignments/relation/#" + row[0],
                "label": row[0],
            }
            if row[1]:
                datum["description"] = row[1]
            if row[2]:
                datum["citation"] = row[2]
            if row[3]:
                datum["note"] = row[3]
            data["@graph"].append(datum)
    print(dumps(data, indent="  "))


if __name__ == "__main__":
    main()

Relation Name

prerender

Requested Changes

The prerender link relation should be completely removed, because it’s not supported in the Link header.

Relationship

I’m employed by the W3C and I am also a WHATWG member.

Additional Information

See w3c/whatwg-coord#6 (comment)

Enter the details of the link relation type below:

• Relation Name: manifest
• Description: Refers to the JSON-based manifest file that provides metadata associated with the current document.
• Reference: https://www.w3.org/TR/appmanifest/

Please confirm that:

• [Y] You have read and understood the requirements for registration.
• [Y] You have checked the registry and found no current link relation types that meet your needs.
• [Y] Your specification reference URL is stable; ideally, managed by a widely-recognised standards development organisation (e.g., published as an RFC). Otherwise, please give additional information.

If so, please enter the details of the link relation type below:

• Relation Name: figure
• Description: Refers to a resource with an available representation suitable for rendering within the context.
• Reference: https://purl.org/net/figure-link-rels

Any additional information (this will not be included in the registry)?

Enter the details of the link relation type below:

• Relation Name: publication
• Description: Links to a publication manifest. A manifest represents structured information about a publication, such as informative metadata, a list of resources, and a default reading order.
• Reference: https://www.w3.org/TR/pub-manifest/#link-relation-type-registration

Any additional information (this will not be included in the registry)?

• the specification document is a W3C Candidate Recommendation, the plan is to have it as a Recommendation late spring or early summer 2020
• there is a stupid mistake in the note of the IANA section of the CR, there is already a PR to take care of that (w3c/pub-manifest#184)

Cc: @mattgarrish @TzviyaSiegman @wareid @GarthConboy

https://datatracker.ietf.org/doc/html/rfc8288#section-2.1.1 states the following:

Registered relation type names MUST conform to the reg-rel-type rule
(see Section 3.3) and MUST be compared character by character in a
case-insensitive fashion.

and https://datatracker.ietf.org/doc/html/rfc8288#section-3.3 includes the following definition for reg-rel-type:

reg-rel-type = LOALPHA *( LOALPHA / DIGIT / "." / "-" )

There are registered Link Relation types in https://www.iana.org/assignments/link-relations/link-relations.xhtml that do not appear to conform to reg-rel-type, i.e., they use ALPHA.

If the definition of reg-rel-type is correct, then there are registered types do not conform.

If the definition of reg-rel-type is incorrect, then the definition should be updated to use ALPHA instead of LOALPHA.

I was just about to report an errata about the definition of LOALPHA not being carried forward in later HTTP and ABNF specs, as well as not defined in RFC 8288, but have noticed that it was already "Reported" (but not yet "Verified") at https://www.rfc-editor.org/errata/eid5319 .

While accepting errata/eid5319 will correct RFC 8288, reg-rel-type may still need to be updated to use ALPHA to ensure that existing and future registrations conform to the spec. I can submit an errata if that makes sense.

• Relation Name:
• Requested Change(s):
• Your relationship to the original registrant:

Relation Name

logo-icon

Description

Refers to a logo icon distinct from the (fav)icon representing the link's context.

Reference

WICG/proposals#79

Additional Information

The reference URL describes the proposal, it is not a formal definition. Once approved, the formal definition will be published on https://developers.google.com/search/docs/appearance/publisher-logo-in-search.

Relation Name

hash

Description

Refers to a resource that contains the context's hash value. The resource content SHALL start with the first byte of the hexadecimal hash value. Any subsequent data (like a filename) which is optional SHALL be separated by at least one space.

Reference

https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#7115-requirement-15-rolie-feed

Additional Information

The OASIS Common Security Advisories Framework (CSAF) Technical Committee (TC) has been chartered to standardize the implementation and exchange of security advisories. The automatic and fast discovery of relevant as well as actionable security advisories is an important step in the process of effectively mitigating and ultimately removing vulnerabilities as they become apparent. We are requesting the registration of a "hash" link type that would contain parameters and configuration requirements to allow this level of automated discovery. Resource-Oriented Lightweight Information Exchange (ROLIE) is a standard to ease discovery of security content. ROLIE is built on top of the Atom Publishing Format and Protocol, with specific requirements that support publishing security content. Each ROLIE feed document MUST be a JSON file that conforms with [RFC8322]. Any existing hash file (requirement 18) MUST be listed in the corresponding entry of the ROLIE feed as an item of the array link having the rel value of hash.

For further reference, the CSAF version 2.0 OASIS Standard is always available at: https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html

ugc and sponsored. See https://webmasters.googleblog.com/2019/09/evolving-nofollow-new-ways-to-identify.html

Enter the details of the link relation type below:

• Relation Name: ‘tor’
• Description: Many organizations are beginning to offer hosted services and web sites that are only accessible via the TOR network. These TOR hidden services usually offer mirrored versions of the company’s products, but with the added benefit of anonymity of the user. These services can also often be accessed even in the case of censorship or blocking of the parent “open-web” site by state or telecom powers.

However, discovering which sites offer TOR alternatives, much less what the TOR URL even is, can be daunting and difficult. While the point of some .onion web addresses is security through anonymity, many of these sorts of sites are not. The companies themselves often highlight their offerings in blog posts and aggregate lists do exist for some services. Up to this point though there is no way to publish this standardized way; for instance, in a manner where canonical lists could be automatically generated and built into the TOR browser or other anti-censorship tools.

Allowing web-masters to publicize their TOR alternatives would allow tools to automatically redirect instead of ever accessing the open web, increasing security and anonymity with no extra work by the end user.

• Reference: No written references but implementation details follow:

Href links should be canonical to the current web address. For instance, the tag on a home page for the OCCRP organization at https://www.occrp.org would be:

For a subdirectory https://www.occrp.org/en/azerbaijanilaudromat:

Any additional information (this will not be included in the registry)?

No

Enter the details of the link relation type below:

• Relation Name: media-feed
• Description: Refers to a feed of personalised media recommendations relevant to the link context
• Reference: https://wicg.github.io/media-feeds/#discovery-of-media-feeds

Any additional information (this will not be included in the registry)?

Relation Name

signature

Description

Refers to a resource that contains the context's cryptographic signature.

Reference

https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#7115-requirement-15-rolie-feed

Additional Information

The OASIS Common Security Advisories Framework (CSAF) Technical Committee (TC) has been chartered to standardize the implementation and exchange of security advisories. The automatic and fast discovery of relevant as well as actionable security advisories is an important step in the process of effectively mitigating and ultimately removing vulnerabilities as they become apparent. We are requesting the registration of a "signature" link type that would contain parameters and configuration requirements to allow this level of automated discovery. Resource-Oriented Lightweight Information Exchange (ROLIE) is a standard to ease discovery of security content. ROLIE is built on top of the Atom Publishing Format and Protocol, with specific requirements that support publishing security content. Each ROLIE feed document MUST be a JSON file that conforms with [RFC8322]. Any existing signature file (requirement 19) MUST be listed in the corresponding entry of the ROLIE feed as an item of the array link having the rel value of signature.

For further reference, the CSAF version 2.0 OASIS Standard is always available at: https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html

Please confirm that:

• [Y] You have read and understood the requirements for registration.
• [Y] You have checked the registry and found no current link relation types that meet your needs.
• [Y] Your specification reference URL is stable; ideally, managed by a widely-recognised standards development organisation (e.g., published as an RFC). Otherwise, please give additional information.

If so, please enter the details of the link relation type below:

• Relation Name: audio-figure
• Description: Refers to a resource with an available representation in the 'audio' media type subtree suitable for rendering within the context.
• Reference: https://purl.org/net/figure-link-rels

Any additional information (this will not be included in the registry)?

It's not clear whether RFC 8288's injunction that link relations "MUST NOT constrain the available representation media types of the link target" refers to constraining to specific individual media types, or placing any restriction on media types. The figure-link-rels specification says that a resource has a representation in a specific subtree, but does not restrict other representations, nor does it restrict to any specific media types.

Relation Name

siptrunkingcapability

Requested Changes

Change the relation name from "siptrunkingcapability" to "sip-trunking-capability".

Relationship

Original registrant

Additional Information

After some debate with the registrants, the hyphen delimited suggestion is more visually appealing. Thanks!

Relation Name

prefetch

Requested Changes

The Reference field should be updated to list https://html.spec.whatwg.org/multipage/links.html#link-type-prefetch

Relationship

I’m employed by the W3C and I am also a WHATWG member.

Additional Information

See w3c/whatwg-coord#6

In working on the script in #25 to parse link-relations-1.csv I discovered that the current link-relations CSV is malformed. The profile entry is wrapped without indent.

Please confirm that:

• You have read and understood the requirements for registration.
• You have checked the registry and found no current link relation types that meet your needs.
• Your specification reference URL is stable; ideally, managed by a widely-recognised standards development organisation (e.g., published as an RFC). Otherwise, please give additional information.

If so, please enter the details of the link relation type below:

• Relation Name: acl
• Description: The relationship A acl B asserts that resource B provides access control description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.
• Reference: https://solidproject.org/TR/wac

Any additional information (this will not be included in the registry)? The W3C Solid Community Group is requesting registration of the "acl" link relation type on the basis of the Web Access Control (WAC) specification, as well as other specifications using the link relation. Implementations exist, are ongoing, and others can be expected as a result of the publication. The plan is to wrap up work on the draft and move to "final" publication. The specification reference URL is managed by the Solid Project and the versioned URLs are covered by the URI Persistence Policy: https://solidproject.org/terms#uri-persistence-policy .

Relation Name

preconnect

Requested Changes

The Reference field should be updated to list https://html.spec.whatwg.org/multipage/links.html#link-type-preconnect

Relationship

I’m employed by the W3C and I am also a WHATWG member.

Additional Information

See w3c/whatwg-coord#6. The former W3C Resource Hints spec (which had defined the preconnect link relation) has been retired, and preconnect is instead now defined in the HTML standard.

Enter the details of the link relation type below:

• Relation Name: news
• Description: This link provides news on the subject itself. No restrictions are placed on the content of the destination link; its contents may be structured (RSS/Atom) or unstructured.
• Reference: None yet -- if a draft is necessary we can write one 😉

Any additional information (this will not be included in the registry)?

For example, the link
https://www.iso.org/contents/data/standard/07/39/73906.detail.rss
provides updates to the ISO/IEC 27001 standard (about page: https://www.iso.org/standard/73906.html).

Please confirm that:

• You have read and understood the requirements for registration.
• You have checked the registry and found no current link relation types that meet your needs.
• Your specification reference URL is stable; ideally, managed by a widely-recognised standards development organisation (e.g., published as an RFC). Otherwise, please give additional information.

If so, please enter the details of the link relation type below:

authenticate

• Relation Name: authenticate
• Description: The "authenticate" can be used to link to a resource that hosts a
  page where a user can authenticate itself for the current resource.
• Reference: https://tools.ietf.org/html/draft-pot-authentication-link-01#section-2

authenticated-as

• Relation Name: authenticated-as
• Description: The "authenticated-as" link refers to a resource that describes the
  effective authenticated user for a HTTP response.
• Reference: https://tools.ietf.org/html/draft-pot-authentication-link-01#section-3

logout

• Relation Name: logout
• Description: The "logout" link refers to a resource where an authenticated user might
  end their session.
• Reference: https://tools.ietf.org/html/draft-pot-authentication-link-01#section-4

register-user

• Relation Name: register-user
• Description: The "register-user" Link Relation refers to a resource where a user
  might sign up for a service for the context URI.
• Reference: https://tools.ietf.org/html/draft-pot-authentication-link-01#section-5

Any additional information (this will not be included in the registry)?

We would like to pre-register the "ruleinput" link relation type. The specification for the use of this type will be available for review later this year.

• Relation Name:
  ruleinput

• Description:
  The resource identified by the link target provides an input value to an instance of a rule, where the resource which represents the rule instance is identified by the link context.

• Reference:
  OCF Core Specification, Open Connectivity Foundation
  https://openconnectivity.org/
  Candidate specification for publication, pending internal review, when available:
  https://openconnectivity.org/developer/specifications/draft-specifications

Please confirm that:

• You have read and understood the requirements for registration.
• You have checked the registry and found no current link relation types that meet your needs.
• Your specification reference URL is stable; ideally, managed by a widely-recognised standards development organisation (e.g., published as an RFC). Otherwise, please give additional information below.

If so, please provide the details of your request below.

Enter the details of the link relation type below:

• Relation Name: mercure
• Description: The Mercure Hub to use to subscribe to updates of this resource.
• Reference: https://datatracker.ietf.org/doc/draft-dunglas-mercure/

Any additional information (this will not be included in the registry)?

The Mercure is already widely used (see the Implementation Status section of the I-D) and is already listed in the List of /.well-known/ services offered by webservers Wikipedia page.
I plan to propose this I-D as a RFC soon.

The registration of well-known URI has also be started: protocol-registries/well-known-uris#4

Enter the details of the link relation type below:

• Relation Name: cite-as
• Description: A link with the "cite-as" relation type indicates that the link target is preferred over the link context for the purpose of referencing.
• Reference: Van de Sompel, H., Nelson, M.L., Bilder, G., Kunze, J., and Warner, S. (August 2017) cite-as: A Link Relation to Convey a Preferred URI for Referencing. https://datatracker.ietf.org/doc/draft-vandesompel-citeas/

Any additional information (this will not be included in the registry)?

This request to register "cite-as" is the result of a prior attempt to register "identifier". Significant concerns were voiced regarding "identifier" and, as a result, the co-authors of the I-D decided to settle on "cite-as", which was proposed during the discussions of "identifier".

The request to register "cite-as" on the basis of ID-00 is motivated by ongoing adoption of various patterns for using link relation types in scholarly communication, see http://signposting.org. As soon as "cite-as" is registered:

• Existing implementations will be asked to change their use of "identifier" to "cite-as"

• Documentation will be updated to reflect the change from "identifier" to "cite-as" at http://signposting.org/identifier/

Please confirm that:

• You have read and understood the requirements for registration.
• You have checked the registry and found no current link relation types that meet your needs.
• Your specification reference URL is stable; ideally, managed by a widely-recognised standards development organisation (e.g., published as an RFC). Otherwise, please give additional information below.

If so, please provide the details of your request below.

Enter the details of the link relation type below:

• Relation Name: linkset
• Description: The Target IRI of a link with the "linkset" relation type provides a set of links, including links in which the Context IRI of the link participates.
• Reference: https://datatracker.ietf.org/doc/draft-wilde-linkset/

Any additional information (this will not be included in the registry)? We are requesting registration of the "linkset" link relation type on the basis of the I-D (not yet RFC) because implementations exist (e.g. OJS - see the I-D), are ongoing (e.g. GS1 - see the I-D and dret/I-D#139 (comment)), and others can be expected as a result of the publication of the FAIR Signposting Profile. The plan is to wrap up work on the I-D and move to publication as an RFC asap.

• Relation Name: alternate
• Requested Change(s): The registry points to http://www.w3.org/TR/html5/links.html#link-type-alternate, but the definition is actually at https://html.spec.whatwg.org/multipage/links.html#rel-alternate. It looks like all the other HTML link types, while pointing to http://www.w3.org/TR/html5/links.html, have the right anchor, so the redirect to https://html.spec.whatwg.org/multipage/links.html works.
• Your relationship to the original registrant: None

• Relation Name: micropub
• Description: links to the context's Micropub endpoint
• Reference: https://www.w3.org/TR/micropub/#endpoint-discovery-p-1

Enter the details of the link relation type below:

• Relation Name: P3Pv1
• Description: refers to a P3P privacy policy for the context
• Reference: https://www.w3.org/TR/P3P/#syntax_link

Any additional information (this will not be included in the registry)?

• Relation Name: openid2.provider
• Description: refers to a resource which accepts OpenID Authentication protocol messages for the context
• Reference: https://openid.net/specs/openid-authentication-2_0.html#rfc.section.7.3.3

• Relation Name: openid2.local_id
• Description: refers to an OpenID Authentication server on which the context relies for an assertion that the end user controls an Identifier
• Reference: https://openid.net/specs/openid-authentication-2_0.html#rfc.section.7.3.3

Please confirm that:

• [x ] You have read and understood the requirements for registration.
• [x ] You have checked the registry and found no current link relation types that meet your needs.
• [ x] Your specification reference URL is stable; ideally, managed by a widely-recognised standards development organisation (e.g., published as an RFC). Otherwise, please give additional information.

If so, please enter the details of the link relation type below:

• Relation Name: base
• Description: provide a base url for use by other links.
• Reference: https://html.spec.whatwg.org/#the-base-element

Any additional information (this will not be included in the registry)?

For my use case, I would like have links of the form:

rel=base href="https://example.com/origin/of/api"
rel=item href="arguments/to/API"

or it could be a static file case:

rel=base href="https://example.com/a/b"
rel=item href="c/d.txt"

in the case of collections, there could be some reduction in bytes used by avoiding the need to repeat the base URL in each item. I chose item for the example, but many other relations could make use of a relative url scheme.
This is useful when link relations are not embedded in html, but in a JSON payload (my use case.) where the
html base element is not available.

Relation Name

down

Description

Refers to a child document in a hierarchy of documents.

Reference

https://www.rfc-editor.org/rfc/rfc8288.html

Additional Information

Opposite of the existing up relation.

Instead of up and down I would have preferred the synonyms parent and child, but I see that up already exists - so shouldn't down also exist?

Please confirm that:

• [Y] You have read and understood the requirements for registration.
• [Y] You have checked the registry and found no current link relation types that meet your needs.
• [Y] Your specification reference URL is stable; ideally, managed by a widely-recognised standards development organisation (e.g., published as an RFC). Otherwise, please give additional information.

If so, please enter the details of the link relation type below:

• Relation Name: image-figure
• Description: Refers to a resource with an available representation in the 'image' media type subtree suitable for rendering within the context.
• Reference: https://purl.org/net/figure-link-rels

Any additional information (this will not be included in the registry)?

It's not clear whether RFC 8288's injunction that link relations "MUST NOT constrain the available representation media types of the link target" refers to constraining to specific individual media types, or placing any restriction on media types. The figure-link-rels specification says that a resource has a representation in a specific subtree, but does not restrict other representations, nor does it restrict to any specific media types.

• Relation Name: manifest
• Description: links to a manifest file for the context
• Reference: https://www.w3.org/TR/appmanifest/#using-a-link-element-to-link-to-a-manifest

Enter the details of the link relation type below:

• Relation Name: amphtml
• Description: Used to reference alternative content that uses the AMP profile of the HTML format.
• Reference: https://amp.dev/documentation/guides-and-tutorials/learn/spec/amphtml/

Any additional information (this will not be included in the registry)?

Apple defines a few link relations:

• Relation Name: mask-icon
• Description: refers to a mask that can be applied to the icon for the context.
• Reference: https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/pinnedTabs/pinnedTabs.html#//apple_ref/doc/uid/TP40002051-CH18-SW1

• Relation Name: apple-touch-icon
• Description: refers to an icon for the context. Synonym for icon.
• Reference: https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html#//apple_ref/doc/uid/TP40002051-CH3-SW3

• Relation Name: apple-touch-startup-image
• Description: refers to a launch screen for the context.
• Reference: https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html#//apple_ref/doc/uid/TP40002051-CH3-SW3

Not sure how stable those links are. Any comments on the proposed descriptions?

Relation Name

webring

Description

Like the webring of the 1990's, this link rel would allow sites to link to each other based on topics, which would work in the background rather than displaying a Webring on-page. Webring isn't registered with an RFC, but it could come in handy for people who want to share resources such as metadata, CSS, media, or the same licenses.

Reference

https://binquasin.neocities.org/

Additional Information

As mentioned above, the link relation for webring is a way for two totally different websites to share metadata or share the same licenses, or even CSS/media, etc. But the webring link relation should only be allowed if the webmaster gives their permission to add the code, which should be done by the webmaster displaying the link rel code on-site, such as in a text area.

I haven't submitted the link rel to an RFC or standard body as my disabilities of dyslexia and Autism Spectrum Disorder (ASD Level I) impedes on my ability to do so.

Enter the details of the link relation type below:

• Relation Name: conformance
• Description: Refers to a resource that identifies the specifications that the link’s context conforms to.
• Reference: OGC API - Features - Part 1: Core, 5.2. Link relations

• Relation Name: data
• Description: Indicates that the link’s context is a distribution of a dataset that is an API and refers to the root resource of the dataset in the API.
• Reference: OGC API - Features - Part 1: Core, 5.2. Link relations

• Relation Name: items
• Description: Refers to a resource that is comprised of members of the collection represented by the link’s context.
• Reference: OGC API - Features - Part 1: Core, 5.2. Link relations

Any additional information (this will not be included in the registry)?

The link relation types are used in a Web API standard of the Open Geospatial Consortium (OGC). We have tried to re-use existing link relation types, where possible, but had to define three new types. We have tried to phrase the definitions in a general way so that they could be useful for other contexts, too.

• An example for the use of conformance and data: link
• An example for the use of items: link