├── ietf.json ├── .github ├── ISSUE_TEMPLATE │ ├── modification-request.yaml │ └── registration-request.yaml └── CONTRIBUTING.md └── README.md /ietf.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": "Link Relations Registry", 3 | "group_info": { 4 | "name": "Link Relations Registry" 5 | }, 6 | "repo_type": "registry", 7 | "issue_summary_to": ["mnot@mnot.net", "julian.reschke@greenbytes.de"] 8 | } -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/modification-request.yaml: -------------------------------------------------------------------------------- 1 | name: Modification Request 2 | description: 'Modify an existing registration.' 3 | title: 'Modification request: [relation name]' 4 | labels: modification 5 | body: 6 | - type: input 7 | id: name 8 | attributes: 9 | label: Relation Name 10 | description: The link relation name that you wish to modify. 11 | validations: 12 | required: true 13 | - type: textarea 14 | id: changes 15 | attributes: 16 | label: Requested Changes 17 | description: What needs to change in the registration. 18 | validations: 19 | required: true 20 | - type: input 21 | id: relationship 22 | attributes: 23 | label: Relationship 24 | description: What is your relationship to the original registrant? 25 | validations: 26 | required: true 27 | - type: textarea 28 | id: additional_info 29 | attributes: 30 | label: Additional Information 31 | description: Is there any additional information we should know? This will not be included in the registry. 32 | 33 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/registration-request.yaml: -------------------------------------------------------------------------------- 1 | name: Registration Request 2 | description: 'Request a new registration.' 3 | title: 'Registration Request: [ your link relation name ]' 4 | labels: new registration 5 | body: 6 | - type: markdown 7 | attributes: 8 | value: | 9 | Please confirm that: 10 | - You have read and understood the [requirements for registration](https://tools.ietf.org/html/rfc8288#section-2.1.1). 11 | - You have checked [the registry](https://www.iana.org/assignments/link-relations/) and found no current link relation types that meet your needs. 12 | - 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. 13 | - type: input 14 | id: name 15 | attributes: 16 | label: Relation Name 17 | description: The link relation name; must conform to the constraints in the RFC. 18 | validations: 19 | required: true 20 | - type: input 21 | id: description 22 | attributes: 23 | label: Description 24 | description: A description of the link relation; see the registry for examples. 25 | validations: 26 | required: true 27 | - type: input 28 | id: reference 29 | attributes: 30 | label: Reference 31 | description: A URL referring to the link relation's definition. 32 | validations: 33 | required: true 34 | - type: textarea 35 | id: additional_info 36 | attributes: 37 | label: Additional Information 38 | description: Is there any additional information we should know? This will not be included in the registry. 39 | 40 | -------------------------------------------------------------------------------- /.github/CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | ## Code of Conduct 2 | 3 | The [IETF Guidelines for Conduct](https://tools.ietf.org/html/rfc7154) apply 4 | to this repository. 5 | 6 | 7 | ## NOTE WELL 8 | 9 | Any submission to the [IETF](https://www.ietf.org/) intended by the Contributor 10 | for publication as all or part of an IETF Internet-Draft or RFC and any 11 | statement made within the context of an IETF activity is considered an "IETF 12 | Contribution". Such statements include oral statements in IETF sessions, as 13 | well as written and electronic communications made at any time or place, which 14 | are addressed to: 15 | 16 | * The IETF plenary session 17 | * The IESG, or any member thereof on behalf of the IESG 18 | * Any IETF mailing list, including the IETF list itself, any working group 19 | or design team list, or any other list functioning under IETF auspices 20 | * Any IETF working group or portion thereof 21 | * Any Birds of a Feather (BOF) session 22 | * The IAB or any member thereof on behalf of the IAB 23 | * The RFC Editor or the Internet-Drafts function 24 | * All IETF Contributions are subject to the rules of 25 | [RFC 5378](https://tools.ietf.org/html/rfc5378) and 26 | [RFC 3979](https://tools.ietf.org/html/rfc3979) 27 | (updated by [RFC 4879](https://tools.ietf.org/html/rfc4879)). 28 | 29 | Statements made outside of an IETF session, mailing list or other function, 30 | that are clearly not intended to be input to an IETF activity, group or 31 | function, are not IETF Contributions in the context of this notice. 32 | 33 | Please consult [RFC 5378](https://tools.ietf.org/html/rfc5378) and [RFC 34 | 3979](https://tools.ietf.org/html/rfc3979) for details. 35 | 36 | A participant in any IETF activity is deemed to accept all IETF rules of 37 | process, as documented in Best Current Practices RFCs and IESG Statements. 38 | 39 | A participant in any IETF activity acknowledges that written, audio and video 40 | records of meetings may be made and may be available to the public. 41 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Link Relation Type Registration Requests 2 | 3 | This repository's issues list manages requests to add and change entries in the [link relation type IANA registry](https://www.iana.org/assignments/link-relations/). Please note our [contribution terms](.github/CONTRIBUTING.md). 4 | 5 | Your [Experts](https://tools.ietf.org/html/rfc8126#section-4.6) are currently [@algermissen](https://github.com/algermissen), [@mnot](https://github.com/mnot), and [@reschke](https://github.com/reschke). 6 | 7 | To request registration of a new relation type (or a change to an existing one), you can: 8 | 9 | * [File an issue](https://github.com/protocol-registries/link-relations/issues/new/choose) (preferred), or 10 | * Send e-mail to [the link-relations mailing list](https://www.ietf.org/mailman/listinfo/link-relations). 11 | 12 | See [RFC8288](https://tools.ietf.org/html/rfc8288) for more information about link relations; in particular, the [requirements for registered relation types](https://tools.ietf.org/html/rfc8288#registered). Note that a [specification is required](https://tools.ietf.org/html/rfc8126#section-4.6). 13 | 14 | Once approved, your request will be incorporated into the IANA registry, whereupon it will be officially registered. 15 | 16 | ## Describing Link Relations 17 | 18 | There are many ways to fill out the `description` field, but in general it's good if it aligns with the terminology in [RFC8288](https://tools.ietf.org/html/rfc8288). Some examples: 19 | 20 | * Refers to a resource that can be used to `verb` the link's context. 21 | * The target IRI points to a resource where a `descriptor` resource for the link context can be obtained. 22 | * Refers to a resource providing `descriptor` about the link's context. 23 | 24 | ## Suitable Specification References 25 | 26 | This registry requires a stable reference for a specification document. Publication by a recognised open standards body is preferred; however, publication by established Open Source projects (i.e., those that demonstrate a community that's commited to ongoing support), community and commercial organisations are also accepted, provided that they have a reaonable plan to promote specification stability. 27 | 28 | ## When to Register 29 | 30 | Generally, a registration request should be made when your document is mature enough for wide review. 31 | 32 | If your reference is an Internet-Draft, that means when it's adopted by a stream (e.g., the IETF stream, the Independent stream), not beforehand. 33 | 34 | If your reference is in another standards body, a request can be made before the document is finalised. 35 | 36 | If your reference is from an Open Source project, community or commerical group, a request can be made once your document becomes public, but anticipatory requests are discouraged, and may be refused or delayed. 37 | --------------------------------------------------------------------------------