The 'knowledge-linkset' Well-Known URI for Publishing Knowledge Artefacts
draft-besleaga-agentic-knowledge-wellknown-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Andrei Nicolae Besleaga | ||
| Last updated | 2026-09-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-besleaga-agentic-knowledge-wellknown-00
Independent Submission A. N. Besleaga
Internet-Draft Independent
Intended status: Informational 30 September 2026
Expires: 3 April 2027
The 'knowledge-linkset' Well-Known URI for Publishing Knowledge
Artefacts
draft-besleaga-agentic-knowledge-wellknown-00
Abstract
This document defines the "knowledge-linkset" well-known URI, at
which a web origin publishes one link set describing the knowledge
artefacts it makes available: graph serializations, a JSON-LD
context, an agent-facing text file, a chunk export, a change ledger,
and related resources. Each artefact link may carry a SHA-256
digest, expressed with the syntax of HTTP digest fields, so that a
client can check that a retrieved artefact is the one the publisher
described. A profile URI identifies the conventions the link set
follows. The mechanism defines no new media type and no new link
relation type: a page points at the resource with the existing
"describedby" relation. This document requests one well-known URI
registration and records the fields of one profile URI registration
that is to be requested separately.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Besleaga Expires 3 April 2027 [Page 1]
Internet-Draft knowledge-linkset Well-Known URI September 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What this document does not do . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. The 'knowledge-linkset' Well-Known URI . . . . . . . . . . . 5
3.1. Media type and profile . . . . . . . . . . . . . . . . . 5
3.2. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Cross-origin access . . . . . . . . . . . . . . . . . . . 6
4. The Link Set . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Top-level structure . . . . . . . . . . . . . . . . . . . 6
4.2. Relations . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Target attributes . . . . . . . . . . . . . . . . . . . . 9
4.3.1. The digest attribute . . . . . . . . . . . . . . . . 9
4.3.2. Bundle-fact attributes . . . . . . . . . . . . . . . 9
4.3.3. Declaration attributes . . . . . . . . . . . . . . . 10
4.4. The reduced form . . . . . . . . . . . . . . . . . . . . 11
4.5. Related-system links . . . . . . . . . . . . . . . . . . 11
5. Discovery from a Page . . . . . . . . . . . . . . . . . . . . 11
5.1. Why 'describedby', and why no new relation . . . . . . . 12
6. The Profile URI . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. What the profile fixes . . . . . . . . . . . . . . . . . 12
6.2. Carriage and resolution . . . . . . . . . . . . . . . . . 13
6.3. Versions . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Fetch safety . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Following peers . . . . . . . . . . . . . . . . . . . . . 15
7.3. Untrusted content . . . . . . . . . . . . . . . . . . . . 16
7.4. Federation is client-side . . . . . . . . . . . . . . . . 16
8. Relationship to Other Work . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9.1. What a digest proves . . . . . . . . . . . . . . . . . . 18
9.2. Fetching . . . . . . . . . . . . . . . . . . . . . . . . 18
9.3. Content is data . . . . . . . . . . . . . . . . . . . . . 19
9.4. What is not claimed . . . . . . . . . . . . . . . . . . . 19
9.5. Exposure . . . . . . . . . . . . . . . . . . . . . . . . 19
9.6. Size . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.7. Tombstones . . . . . . . . . . . . . . . . . . . . . . . 20
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11.1. Well-Known URI Registration . . . . . . . . . . . . . . 20
11.2. Profile URI . . . . . . . . . . . . . . . . . . . . . . 21
Besleaga Expires 3 April 2027 [Page 2]
Internet-Draft knowledge-linkset Well-Known URI September 2026
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 22
13. Normative References . . . . . . . . . . . . . . . . . . . . 24
14. Informative References . . . . . . . . . . . . . . . . . . . 25
Appendix A. A Complete Example . . . . . . . . . . . . . . . . . 29
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction
Software agents that read the Web need two different things. They
need to find out _who can act_: which agent, tool server, or service
is reachable, under what name, with what capabilities. A survey of
that field is available in [I-D.jimenez-dawn-discovery-landscape].
They also need to find out _what is known_: which described,
versioned, checkable artefacts an origin publishes about its own
subject matter -- a graph, a vocabulary, an index, a text rendering,
a change ledger. The first question has many answers. The second
has had no common one: an origin that publishes a knowledge base in
several serializations has had no uniform place to list them, no
uniform way to say which serialization is which, and no uniform way
to let a client check that what it fetched is what was published.
This document defines that place. A web origin serves one resource
at /.well-known/knowledge-linkset [RFC8615]. The representation is a
link set [RFC9264]: a JSON document whose sole top-level member,
linkset, holds link contexts and their typed links. One link context
is used, anchored at the IRI ([RFC3987]) of the published knowledge
Bundle. Its links name the artefacts, each with a media type, and
each optionally with a digest target attribute whose value uses the
algorithm token and syntax of HTTP digest fields [RFC9530]. A
profile URI [RFC7284], carried either on the media type [RFC9264] or
in a Link header field [RFC6906], tells a client which conventions
the document follows.
The design reuses what already exists and adds nothing to it beyond a
path and a profile. The document served is an ordinary link set, so
a generic link set client reads it without knowing this
specification. The relation used to point at it from a page is
describedby, which is already registered. The integrity attribute
reuses an existing digest algorithm token and an existing structured-
field value syntax [RFC9651]. No media type is defined ([RFC6838]),
no URI scheme is defined, and no registry is created. The precedent
for this shape -- a well-known URI whose representation is a link set
identified by a profile URI -- is api-catalog [RFC9727], which
applies it to a different object, an origin's APIs.
Besleaga Expires 3 April 2027 [Page 3]
Internet-Draft knowledge-linkset Well-Known URI September 2026
The canonical, normative definition of the artefacts themselves, of
the Bundle that contains them, and of the byte-level forms their
digests cover, is the AgenticSystemCore Specification [AGSC-SPEC].
This document specifies the discovery resource: its location, its
media type, its structure, the conventions its profile URI names, and
the behaviour expected of a client that reads it. Everything a
publisher needs in order to serve a conformant discovery document,
and everything a client needs in order to read one, is stated here.
1.1. What this document does not do
This document defines no agent identity and no authentication of
fetchers; it defines no protocol, session, or transport between
agents; it defines no naming or resolution layer for agents; it
defines no expression of preferences about how content may be used;
it defines no read or write interface to an agent's memory; and it
does not define the formats of the artefacts it points at.
Publishing a discovery document grants no rights and no permissions
of any kind, and asserts no property of the artefacts other than that
the origin published them. Section 8 names the work that addresses
each of these topics.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Where a line in an example is too long to be shown whole, it is
folded with a trailing "\" as [RFC8792] describes, and the example
carries the note that specification requires.
Bundle: The set of items and generated artefacts that one origin
publishes under one anchor. The Bundle IRI is the origin's base
URL with a trailing solidus.
artefact: One retrievable representation that belongs to a Bundle: a
graph serialization, a JSON-LD context, a vocabulary file, a text
rendering, a chunk export, a search index, a change ledger, an
attachment.
discovery document: The link set served at the well-known URI
defined by this document.
profile: A profile in the sense of [RFC6906]: additional semantics
Besleaga Expires 3 April 2027 [Page 4]
Internet-Draft knowledge-linkset Well-Known URI September 2026
that a document follows without changing the semantics of its
media type for a client that ignores the profile. The profile URI
of this document's discovery document is given in Section 6.
node: An origin that serves a discovery document conforming to this
document.
peer: A node that another node names in its discovery document with
the peer extension relation of Section 4.2.
3. The 'knowledge-linkset' Well-Known URI
A node MUST serve its discovery document at the path /.well-known/
knowledge-linkset of its origin, over HTTPS. A node MUST serve
exactly one such document; it MUST NOT split the description of one
Bundle across several discovery resources, and it MUST NOT serve a
second, differently named manifest of the same artefacts. A copy of
the document MAY be distributed by other means, for example inside a
release archive, and a node MAY additionally serve the same bytes at
a path of its own choosing.
3.1. Media type and profile
The representation MUST be a JSON link set, media type application/
linkset+json [RFC9264]. The profile URI of Section 6 MUST be carried
in at least one of two ways:
* as the profile parameter of the media type ([RFC9264], Section 5),
which is the form a node uses by default:
NOTE: '\' line wrapping per RFC 8792
Content-Type: application/linkset+json; profile="https://w3id.\
org/agentic-system-core/profile/agentic-knowledge"
Figure 1: The profile carried on the media type
* or, where the hosting platform cannot attach a parameter to
Content-Type, as a response header field ([RFC6906]):
NOTE: '\' line wrapping per RFC 8792
Link: <https://w3id.org/agentic-system-core/profile/agentic-\
knowledge>; rel="profile"
Figure 2: The profile carried in a Link header field
Besleaga Expires 3 April 2027 [Page 5]
Internet-Draft knowledge-linkset Well-Known URI September 2026
A client MUST accept either form, and a client's conformance MUST NOT
differ according to whether it can read response header fields. A
client that can read only the media type, which is the case for a
browser-resident client reading a cross-origin response, therefore
never loses information.
3.2. Caching
A node MUST send an ETag on the discovery document. When the entity
tag is derived from the bytes served, it is the lowercase hexadecimal
SHA-256 of those bytes enclosed in double quotes ([RFC9110],
Section 8.8.3). A node MUST send Cache-Control: no-cache on the
discovery document, so that a client revalidates before reuse
([RFC9111], Section 5.2.2.4); the document names the current state of
a Bundle and is expected to change whenever the Bundle is rebuilt. A
client SHOULD make conditional requests ([RFC9110], Section 13).
3.3. Cross-origin access
The discovery document, and every artefact it names that the node
serves publicly, MUST be served with Access-Control-Allow-Origin: *
and Access-Control-Expose-Headers: Link, ETag, Content-Type, and MUST
NOT be served with Access-Control-Allow-Credentials. A node MUST NOT
require any request header field outside the CORS-safelisted set in
order to obtain the discovery document or any public artefact, so
that a client running in a browser can read them with a simple
request.
A node whose content is gated MUST still serve the discovery document
publicly and with the wildcard above; the discovery document carries
no content. Such a node declares itself with the agsc-visibility
attribute of Section 4.3.3 and names, with the access extension
relation of Section 4.2, where a reader obtains credentials. "Gated"
means that the node's content is not public, never that the node is
invisible.
4. The Link Set
4.1. Top-level structure
The document is a JSON object ([RFC8259]) whose sole top-level member
is linkset ([RFC9264], Section 4.2.1). No other top-level member may
be present. A node that produces canonical bytes serializes the
document with JSON Canonicalization Scheme [RFC8785]; a node that
does not MUST at least produce I-JSON. The canonical form matters
because a digest of the discovery document itself, taken by a third
party, is stable only if the bytes are.
Besleaga Expires 3 April 2027 [Page 6]
Internet-Draft knowledge-linkset Well-Known URI September 2026
The linkset array holds exactly one link context object. Its anchor
is the Bundle IRI: the origin's base URL with a trailing solidus, for
example https://example.org/. A client MUST ignore an additional link
context object it does not understand.
Within a link context object, the remaining members are relation
names, each holding an array of link objects ([RFC9264],
Section 4.2). Every link object MUST carry href, and every href MUST
be an absolute URI reference ([RFC3986]). Within one relation's
array, link objects are ordered by href in code point order, so that
two builds of the same Bundle produce the same bytes.
4.2. Relations
A relation name MUST be either a registered short name from the "Link
Relation Types" registry or an extension relation expressed as a URI
([RFC8288], Section 2.1.2). An unregistered short name MUST NOT be
used.
The registered short names used are describedby, alternate, license,
service-doc, and author. A node that also publishes related-system
links (Section 4.5) may in addition use related, service-desc,
service-meta, collection, item, and cite-as ([RFC8574]).
The extension relations form a closed set. Each is the URI
https://w3id.org/agentic-system-core/rel#<name> with <name> taken
from the following list, and each such URI dereferences, through
w3id.org, to the section of the published specification that
documents it (Section 6).
Besleaga Expires 3 April 2027 [Page 7]
Internet-Draft knowledge-linkset Well-Known URI September 2026
+=========================+===========================+
| Extension relation name | Target |
+=========================+===========================+
| graph | a further serialization |
| | of the Bundle's graph |
+-------------------------+---------------------------+
| ontology | the vocabulary the graph |
| | uses |
+-------------------------+---------------------------+
| context | the JSON-LD context of |
| | the graph |
+-------------------------+---------------------------+
| now | the generated state page |
| | of the Bundle |
+-------------------------+---------------------------+
| skills | the index of exported |
| | procedure packages |
+-------------------------+---------------------------+
| ledger | the derived change ledger |
| | of the Bundle |
+-------------------------+---------------------------+
| peer | another node's discovery |
| | document |
+-------------------------+---------------------------+
| surface | an agent-facing surface |
| | this node serves |
+-------------------------+---------------------------+
| contribute | an endpoint that accepts |
| | contributions |
+-------------------------+---------------------------+
| access | a page that says how to |
| | obtain credentials |
+-------------------------+---------------------------+
| signature | a detached signature over |
| | the discovery document |
+-------------------------+---------------------------+
| boards | the index of the Bundle's |
| | project boards |
+-------------------------+---------------------------+
Table 1: The closed set of extension relations
A client MUST ignore a relation name it does not recognize. A node
MUST NOT invent a further extension relation under the same base: the
set above is closed, and a new member is added only by a later
version of [AGSC-SPEC] (Section 6.3).
Besleaga Expires 3 April 2027 [Page 8]
Internet-Draft knowledge-linkset Well-Known URI September 2026
4.3. Target attributes
A link object MAY carry the target attributes type, title, and
hreflang ([RFC8288], Section 3.4.1; [RFC9264], Section 4.2.4.1), and
the extension target attribute profile, whose values are profile URIs
([RFC6906]). As [RFC9264], Section 4.2.4.1 requires, the values of
type and title are strings and the value of hreflang is an array of
strings. type is an advisory hint: a client MUST NOT depend on it,
and MUST use the media type of the response it actually receives.
Every extension target attribute value, profile included, is an array
of strings, even when one value is carried ([RFC9264],
Section 4.2.4.3). A client MUST ignore an extension target attribute
it does not recognize.
4.3.1. The digest attribute
A link object MAY carry the target attribute digest. Its value is an
array holding one string. That string is the serialization of a
Dictionary ([RFC9651], Section 3.2) with a single member whose key is
the algorithm name sha-256 from the "Hash Algorithms for HTTP Digest
Fields" registry ([RFC9530], Section 7.2) and whose value is a Byte
Sequence ([RFC9651], Section 3.3.5) serialized as specified in
[RFC9651], Section 4.1, that is, base64 between colons:
"digest": [
"sha-256=:JeigkAtOPS9f9BzKym+X6J2O4awt53GEua1AhIAiLfE=:"
]
The digest is taken over the canonical bytes of the target: the bytes
the publisher generated and serves, before any content coding applied
by the transfer. A client that has retrieved the target compares the
digest against the decoded representation data. The attribute name
is deliberately not prefixed, so that a generic link set client that
already understands digest fields can read it.
4.3.2. Bundle-fact attributes
Facts about the Bundle as a whole ride on one link and one link only:
the describedby link of the anchor whose target is the Bundle's JSON-
LD graph. They are:
agsc-spec-version: one value, the version of [AGSC-SPEC] the node
publishes against.
agsc-generated-at: one value, the instant the artefacts were
Besleaga Expires 3 April 2027 [Page 9]
Internet-Draft knowledge-linkset Well-Known URI September 2026
generated, as YYYY-MM-DDTHH:MM:SSZ -- UTC, second precision, no
offset. A node that supports reproducible builds derives it from
the build's source date rather than from the wall clock.
agsc-counts: one string per item type, of the form <type-
plural>=<n>, in code point order of the type name, counted over
the published set.
agsc-bundle-hash: one value, the digest of the Bundle's canonical
N-Quads serialization, in the syntax of Section 4.3.1; it equals
the digest of the graph link to that serialization.
agsc-bundle-version: one value, the publisher's content version for
the state the artefacts were generated from: a short name a person
can read and cite, where the hash says only whether two retrievals
carry the same content. It is derived by the publisher and is
opaque to a client, which MUST NOT order two values or infer a
sequence from them.
One further attribute rides on the ledger extension relation's link
and nowhere else:
agsc-ledger-head: one value, the lowercase hexadecimal SHA-256 of
the last entry of the derived change ledger. A client that keeps
the head it saw on an earlier retrieval can detect a ledger that
no longer extends the one it read.
A client MUST NOT read a bundle-fact attribute from any other link.
4.3.3. Declaration attributes
The extension target attributes below declare what a node is, rather
than what it published. They are present at every level of
completeness.
agsc-surface and agsc-surface-version: on a surface link, one value
each: the kind of agent-facing surface the node serves, and, where
the surface is defined by an external specification, the revision
of that specification the node targets.
agsc-access: on a surface link, one value: none, consent, or
credential.
agsc-visibility: on the anchor's describedby link, the single value
restricted, emitted only by a node whose content is gated. A node
whose content is public carries no such attribute.
agsc-contribute-mode: on a contribute link, one value naming how
Besleaga Expires 3 April 2027 [Page 10]
Internet-Draft knowledge-linkset Well-Known URI September 2026
contributions are accepted.
agsc-tombstone: on the anchor's describedby link, one instant in the
form of agsc-generated-at, present only on a node that has stopped
publishing (Section 9.7).
A client that meets a value it does not know in any of these
attributes MUST NOT fail. It MUST treat the unknown value as the
most restrictive member of that attribute's list.
4.4. The reduced form
A publisher without a build engine -- a content management system or
a wiki that exports static files -- publishes the same link set with
every digest attribute and every bundle-fact attribute omitted. Such
a publisher has no ledger, no build instant, no bundle hash and no
content version, and this document does not ask for any of them. The
declaration attributes of Section 4.3.3 are unaffected.
There is no structural difference between the two forms: linkset is
the sole top-level member in both, the anchor is the Bundle IRI in
both, and the relation set is the same. A client MUST treat a link
without a digest attribute as _unverified_, never as _invalid_.
4.5. Related-system links
A node MAY carry, in the same link context, links to other discovery
documents and to related systems: an agent-facing text file, a
dataset description, a catalogue entry, an agent card, a tool
server's description, a query endpoint. Such links use registered
short names only, chosen by meaning: describedby when the target
describes this node, alternate when the target is the same knowledge
in another representation, related for a related resource, service-
desc, service-doc, and service-meta for an interface, collection and
item for containment, and cite-as ([RFC8574]) for the identifier a
reader should cite in preference to the node, such as a persistent
identifier's landing page. Each MUST carry type and MAY carry
profile and title.
A client MUST ignore a related-system link it does not understand.
No related-system link affects any digest, and none is followed by
the walk of Section 7.2, which follows peer links only.
5. Discovery from a Page
A node SHOULD place, in the head element of every HTML page it
generates:
Besleaga Expires 3 April 2027 [Page 11]
Internet-Draft knowledge-linkset Well-Known URI September 2026
<link rel="describedby"
href="/.well-known/knowledge-linkset"
type="application/linkset+json">
and SHOULD send, at least on the origin's root route, the equivalent
response header field:
Link: </.well-known/knowledge-linkset>; rel="describedby";
type="application/linkset+json"
5.1. Why 'describedby', and why no new relation
describedby is registered in the "Link Relation Types" registry by
the POWDER Description Resources Recommendation [POWDER-DR], whose
Appendix D defines it and whose Section 4.1.4 uses it; [RFC6892]
registers its inverse, describes. Its registered meaning -- the
target is a description of the context -- is exactly the meaning of
this link. What _kind_ of description the target is, is said by the
target's media type and by its profile URI, not by a new relation
name. A new relation would add a name for a distinction the media
type already draws, and would leave every existing describedby-aware
client unable to use it.
A page may carry several describedby links, because other
conventions, [LLMSTXT] among them, use the same relation for their
own description resources. A client selects this one by
type="application/linkset+json", and, having fetched it, confirms the
profile (Section 3.1). Where several candidates remain, a client
SHOULD fetch the one whose href resolves to /.well-known/knowledge-
linkset on the origin.
This document therefore requests no link relation registration.
6. The Profile URI
The profile URI of the discovery document is
https://w3id.org/agentic-system-core/profile/agentic-knowledge
6.1. What the profile fixes
A client that ignores the profile reads the document as a link set
and nothing is lost ([RFC6906], Section 3). A client that recognizes
it may rely on the following, all of which are specified in this
document:
* linkset is the sole top-level member, and the array holds one link
context whose anchor is the Bundle IRI (Section 4.1);
Besleaga Expires 3 April 2027 [Page 12]
Internet-Draft knowledge-linkset Well-Known URI September 2026
* the relation set is the closed set of Section 4.2, which only a
later version of [AGSC-SPEC] extends (Section 6.3);
* digest, where present, is a single-member Dictionary keyed sha-256
over the canonical bytes of the target (Section 4.3.1);
* bundle facts ride on the anchor's describedby link to the graph,
and the ledger head on the ledger link, and nowhere else
(Section 4.3.2);
* every extension target attribute value is an array of strings
(Section 4.3).
The profile constrains no other document and changes the semantics of
application/linkset+json for no client.
6.2. Carriage and resolution
The profile URI is carried as specified in Section 3.1: on the media
type, or in a Link header field, or both.
The profile URI, and every extension relation URI of Section 4.2,
resolves through w3id.org, a persistent-identifier service, with an
HTTP 303 redirect ([RFC9110], Section 15.4.4) to a published
specification page. That page carries one fragment identifier for
the list of relations and one per relation name, so that every
extension relation URI dereferences to its own documentation, as
[RFC8288], Section 2.1.2, expects of an extension relation.
Registration of the profile URI is requested independently of this
document; see Section 11.2.
6.3. Versions
The profile URI carries no version number. It names the same profile
for every version of [AGSC-SPEC] that has the same major version
number, and a discovery document in the full form states the version
it follows in its agsc-spec-version attribute (Section 4.3.2).
A later minor version of [AGSC-SPEC] only adds to what this document
describes: further members of the closed set of extension relations
of Section 4.2, under the same base URI and each with its own
fragment on the specification page of Section 6.2; further extension
target attributes with the agsc- prefix; further related-system
relations once they are registered; and further values of the
declaration attributes. A client written against this document
ignores an unknown relation name (Section 4.2), an unknown extension
target attribute (Section 4.3) and a related-system link it does not
Besleaga Expires 3 April 2027 [Page 13]
Internet-Draft knowledge-linkset Well-Known URI September 2026
understand (Section 4.5), and treats an unknown declaration value as
Section 4.3.3 requires, so it reads a document written against a
later minor version without error and without change. A change that
such a client could not read in that way is made only in a new major
version of [AGSC-SPEC].
7. Client Behaviour
A client of this document is any program that fetches a discovery
document: a crawler, an agent runtime, a validator, a browser script.
This section states what such a client is required to do. A client
that only fetches one document from an origin it was given needs
Section 7.3 and Section 7.1; a client that follows peer links needs
all of it.
7.1. Fetch safety
* A client MUST fetch a discovery document with an absolute URL
whose scheme is https. http is permitted only to a loopback
address and only when the client has been explicitly placed in a
development mode. Any other scheme, and any relative reference,
MUST be refused.
* Before connecting, a client MUST resolve the host and MUST refuse
any resolved address that is not globally reachable according to
the IANA IPv4 Special-Purpose Address Registry [IANA-IPV4-SPECIAL]
or, for an IPv6 address, according to the IANA IPv6 Special-
Purpose Address Registry [IANA-IPV6-SPECIAL]. A client MUST
equally refuse any IPv6 address that embeds an IPv4 address --
IPv4-mapped, IPv4-compatible, NAT64, Teredo, and 6to4 addresses --
classifying the embedded IPv4 address instead, and any multicast
address. A host that resolves to several addresses MUST be
refused if any one of them is refused.
* A client MUST classify addresses with a tested library or with the
platform's own classification, and MUST NOT parse address literals
by hand.
* A client MUST connect to one of the addresses it classified, MUST
NOT re-resolve the host between classification and connection, and
MUST re-verify the remote address of the established connection
against the same rules, closing the connection on a mismatch.
This is the guard against DNS rebinding.
Besleaga Expires 3 April 2027 [Page 14]
Internet-Draft knowledge-linkset Well-Known URI September 2026
* A client MUST bound the number of redirects it follows, MUST re-
apply the two rules above to every hop, and MUST NOT follow a
redirect to a non-https URL other than the development loopback
case. The final URL of a redirected fetch is not substituted for
the URL that was declared.
* A client MUST bound the size of a discovery document it will read.
One mebibyte is a sufficient bound for the documents this document
describes; a client MUST treat a larger response as unreadable
rather than buffering it.
* A client SHOULD bound the time it waits for a response.
7.2. Following peers
A node names peers with the peer extension relation; the target is
the peer's discovery document URL. Two nodes are peers of each other
when each names the other; nothing else establishes the relation, and
nothing about it is negotiated.
A client that walks from a starting node MUST:
* bound the depth of the walk, the starting node being depth zero;
* consider at most a fixed number of peer links per discovery
document, in document order, ignoring the rest;
* issue at most a fixed number of requests per walk, counting every
request including redirects;
* keep a visited set keyed by the canonical well-known URL, and
never fetch a member of it twice, which is the guard against
cycles across origins;
* treat a peer whose fetch times out, returns a non-2xx status,
exceeds the size bound, or yields a document that is not a
conformant discovery document as unreachable: record it, skip it,
and never retry it within the walk.
A client that stops because a bound was reached, or that ignored
links beyond its per-document bound, MUST report the result as
partial, with the set of nodes it did visit. A client that completes
without touching any bound MUST report the result as complete. The
number of requests a walk can make is bounded by the smaller of the
request bound and the sum, over the permitted depths, of the per-
document bound raised to the power of the depth.
Besleaga Expires 3 April 2027 [Page 15]
Internet-Draft knowledge-linkset Well-Known URI September 2026
Suggested defaults, which a deployment may lower and which this
document does not require a client to exceed: depth three, fifty peer
links per document, five hundred requests per walk, ten seconds per
request, three redirects per fetch.
7.3. Untrusted content
Everything a client obtains from a node other than the one it is
acting for is untrusted data. A client MUST carry that fact with the
data: a search hit, a retrieved item, a chunk, or a quotation derived
from another node MUST be labelled untrusted and MUST name the origin
it came from, through every interface the client offers and every
export it produces. A client MUST NOT merge another node's prose
into its own published artefacts other than through a reviewed
proposal that records the other node's IRI as the source.
7.4. Federation is client-side
The walk of Section 7.2 is performed by the client. A node's query
surface is the set of artefacts it publishes. A node MUST NOT fetch
another node while building its own artefacts, and MUST NOT expose an
endpoint that fetches another node on a caller's behalf. There is
therefore no server-to-server call anywhere in this design, and no
node can be made into an open relay by naming it as a peer.
8. Relationship to Other Work
This section records what neighbouring work does. It is informative.
Every statement is of the form "that work addresses X"; none is a
comparison.
api-catalog [RFC9727] registers a well-known URI whose representation
is a link set identified by a profile URI, listing an origin's APIs.
It is the precedent for the shape used here, applied to a different
object.
llms.txt [LLMSTXT] is a community convention for a Markdown file at
/llms.txt that presents an origin's content for consumption by
language models. Version 2, modified 10 August 2026, recommends
rel="describedby" for pointing at the file and rel="alternate" with
type="text/markdown" for pointing at a page's Markdown rendering. A
node may name such a file with the alternate relation.
[I-D.arsentev-llm-context-discovery] defines discovery of a
publisher-curated context file, typically /llms.txt, through a well-
known URI, a link relation, and a robots.txt record, and sets size
bounds on the index and detail resources. It discovers one text
file.
Besleaga Expires 3 April 2027 [Page 16]
Internet-Draft knowledge-linkset Well-Known URI September 2026
[I-D.serra-mcp-discovery-uri] defines an mcp URI scheme and the
discovery of Model Context Protocol servers through a well-known path
and DNS TXT records.
[MCP] defines a protocol between a client and a tool server, and
carries proposals for server cards that describe a server. A node
may declare a Model Context Protocol server as one of its surfaces
(Section 4.3.3).
[A2A] defines an agent card, served at a well-known path, that
describes an agent's capabilities and interfaces. A node may declare
an agent card as one of its surfaces.
The proposed dawn working group [DAWN-CHARTER] addresses the
discovery of agents by name. The survey
[I-D.jimenez-dawn-discovery-landscape] catalogues the mechanisms in
that space.
The agentproto BOF request [AGENTPROTO-BOF] addresses long-lived
sessions between agents and the resources they use.
The aipref working group defines a vocabulary for expressing
preferences about AI usage of content [I-D.ietf-aipref-vocab] and the
means of attaching such preferences to content in HTTP
[I-D.ietf-aipref-attach]. This document defines no preference
expression; a publisher attaches preferences by those means, and by
robots.txt [RFC9309], to the artefacts a discovery document names.
The webbotauth working group defines HTTP message signatures for
automated traffic [I-D.ietf-webbotauth-httpsig-protocol], which
identify the client making a request.
The W3C AI Agent Memory Interoperability Community Group [AIMEM-CG]
addresses the interoperability of protocols for AI agent memory. The
artefacts a discovery document names are read-only published files,
not a memory interface.
The Open Knowledge Format [OKF] defines a content model of Markdown
files with front matter and an index file. It calls its unit a
"Knowledge Bundle"; the Bundle of this document is a different object
and the two names are not interchangeable.
VoID [VOID] defines a vocabulary for describing RDF datasets and is
associated with the registered well-known URI void. DCAT [DCAT3]
defines a vocabulary for describing catalogues and datasets. A
publisher that also publishes such a description names it with a
further describedby link (Section 4.5).
Besleaga Expires 3 April 2027 [Page 17]
Internet-Draft knowledge-linkset Well-Known URI September 2026
Two further Internet-Drafts request well-known URI suffixes for AI-
related discovery: [I-D.aiendpoint-ai-discovery] requests ai (with
ai-discovery as an alternative) for a description of a service's
capabilities, and [I-D.car-ai-txt-wellknown] requests ai.txt and
ai.json for declarations of AI usage preferences and licensing. Both
describe an endpoint or a policy. The suffix requested here names
the class of resource served -- a link set of published knowledge
artefacts -- and deliberately does not begin with ai or agent.
9. Security Considerations
9.1. What a digest proves
A digest attribute binds an artefact to the discovery document. It
lets a client detect that the artefact it retrieved is not the one
the publisher described: a truncated file, a cache that served an
older copy, a mirror that altered the bytes, a transfer that
corrupted them.
A digest attribute does not bind the discovery document to an author.
An attacker who controls the origin controls the discovery document
and the artefacts together, and can make them agree. A client
obtains the identity of the publisher from the TLS certificate and
the DNS name of the origin, and from nothing in the document. A
publisher who needs a client to verify authorship independently of
the origin signs the responses -- [RFC9421] defines one way -- or
publishes a detached signature and names it with the signature
extension relation (Section 4.2). This document defines no signature
format: a client MUST ignore that link if it does not understand the
target, and the link affects no digest and no walk.
A client that keeps the agsc-ledger-head value it saw on an earlier
retrieval, and that later reads a head that does not extend the
earlier one, has observed a rollback or a replacement of the ledger,
and SHOULD treat it as such rather than as an ordinary update.
9.2. Fetching
A discovery document is a list of URLs supplied by a third party, and
a client that follows them is a request forwarder. Section 7.1 is
therefore normative and not advisory: the scheme restriction, the
address refusals, the rule against re-resolving between
classification and connection, the re-verification of the established
connection, the redirect bounds, and the size bound together keep a
client from being used to reach a network the attacker cannot reach,
to probe an internal address space, or to be held open. A client
that omits them can be directed, by any origin it reads, at any
address its network can reach.
Besleaga Expires 3 April 2027 [Page 18]
Internet-Draft knowledge-linkset Well-Known URI September 2026
Because no node ever fetches another node (Section 7.4), a node
cannot be turned into a request forwarder by being named as a peer.
The risk is entirely on the client side, where the bounds apply.
9.3. Content is data
The artefacts a discovery document names are documents, and the prose
in them is data. A client that passes retrieved prose to a language
model, a shell, a query engine, or any other interpreter MUST treat
it as data: never executed, never interpolated into a path, a URL, or
a command string, never resolved as an identifier, and never read as
an instruction to the client. Prose retrieved from another node
carries the untrusted label of Section 7.3 to every place it is used.
9.4. What is not claimed
The mechanisms of this document prove neither safety nor the absence
of a novel attack carried in the content of an artefact. A digest
proves only that an artefact is what was published. An
implementation MUST NOT claim more.
9.5. Exposure
A discovery document is public. A publisher MUST NOT name in it any
resource that is not intended to be public, and MUST NOT let the set
of links reveal the existence of resources it does not serve
publicly. A node whose content is gated serves the discovery
document publicly all the same (Section 3.3), which is a deliberate
disclosure that the node exists.
A node whose content is gated MUST omit the agsc-counts, agsc-bundle-
hash and agsc-bundle-version attributes and the ledger link, and MUST
omit every digest whose target it does not serve without
authentication: a digest over a gated artefact lets anyone confirm a
guess of its content, and the counts and the content version disclose
activity. It still carries agsc-spec-version and agsc-generated-at,
which say only that the node exists and is current.
The path /.well-known/ on an origin MUST be under the publisher's
control. On static hosting this means that the file is produced by
the publisher's build and upload path and by nothing else.
9.6. Size
A client MUST bound the size of a discovery document it reads
(Section 7.1) and the number of requests a walk may make
(Section 7.2). A publisher SHOULD keep a discovery document small:
it describes a Bundle's artefacts, not its items.
Besleaga Expires 3 April 2027 [Page 19]
Internet-Draft knowledge-linkset Well-Known URI September 2026
9.7. Tombstones
A node that stops publishing MUST keep serving a valid discovery
document whose anchor's describedby link carries the agsc-tombstone
attribute of Section 4.3.3, MAY carry an alternate link to a
successor node's discovery document, and MAY omit every other
artefact link.
A client MUST NOT treat a successor named that way as the same node.
It MUST establish the peer relation with the successor afresh, and
everything it derives from the successor carries the successor's own
Bundle IRI as its origin (Section 7.3). A walk (Section 7.2) does
not descend into a tombstoned node.
10. Privacy Considerations
A discovery document is a static description of an origin's own
published artefacts. Serving it collects nothing, sets no cookie,
carries no identifier of a reader, and requires no request header
field beyond those a simple cross-origin request already carries
(Section 3.3). A client's retrieval appears in the publisher's
server logs like any other request for a static file.
The document may name an author link, and the artefacts it points at
may contain personal data. What appears there is chosen by the
publisher, and this document requires no personal data anywhere in
the discovery document. A publisher SHOULD use a role rather than a
personal contact where one will do.
A client SHOULD NOT send identifying header fields beyond those
[RFC9110] makes ordinary when fetching a discovery document, and a
client walking peers SHOULD NOT disclose to one node which other
nodes it has visited.
11. IANA Considerations
This document requests one registration in an existing registry and
records the fields of one further registration that is to be
requested separately. It creates no registry, requests no media
type, requests no URI scheme, and requests no link relation type. No
allocation described here requires IETF Review or Standards Action.
11.1. Well-Known URI Registration
IANA is requested to register the following entry in the "Well-Known
URIs" registry, per [RFC8615], Section 3.1:
* *URI suffix*: knowledge-linkset
Besleaga Expires 3 April 2027 [Page 20]
Internet-Draft knowledge-linkset Well-Known URI September 2026
* *Change controller*: Andrei N. Besleaga
(andrei.besleaga.nicolae@gmail.com)
* *Specification document(s)*: This document.
* *Status*: provisional
* *Related information*: Used with the "https" URI scheme. The
resource is an application/linkset+json document [RFC9264]
carrying the profile URI https://w3id.org/agentic-system-
core/profile/agentic-knowledge, whose registration is described in
Section 11.2.
The suffix names the class of resource served -- a link set of the
knowledge artefacts an origin publishes -- rather than a subject
area, in keeping with the precision [RFC8615], Section 3, expects of
a registered name. Provisional status is requested because this is
an Independent Submission; the designated experts may promote the
entry to permanent once the resource is found to be in wide use
([RFC8615], Section 3.1).
11.2. Profile URI
Registration of the following profile URI in the "Profile URIs"
registry ([RFC7284], Section 4) is to be requested separately from
this document; that registry's policy is First Come First Served.
The fields are given here so that this document, which specifies the
profile, records them:
* *Profile URI*: https://w3id.org/agentic-system-core/profile/
agentic-knowledge
* *Common Name*: AgenticSystemCore knowledge link set profile
* *Description*: Identifies an application/linkset+json document
[RFC9264] that describes a published knowledge Bundle: one link
context whose anchor is the Bundle IRI, links to the Bundle's
artefacts -- graph serializations, a JSON-LD context, a
vocabulary, a chunk export, an agent-facing text file, a change
ledger -- each optionally carrying a digest target attribute in
the syntax of [RFC9530], and the bundle-fact and declaration
target attributes this document defines. Served at /.well-known/
knowledge-linkset; linked from pages with rel="describedby" and
type="application/linkset+json".
* *Reference*: This document; and [AGSC-SPEC], which defines the
artefacts and their canonical bytes.
Besleaga Expires 3 April 2027 [Page 21]
Internet-Draft knowledge-linkset Well-Known URI September 2026
* *Notes*: The profile does not change the semantics of application/
linkset+json for a client that ignores it ([RFC6906], Section 3);
it adds integrity, bundle-fact, and declaration target attributes
that a client MAY use. The same profile URI serves every version
of the AgenticSystemCore specification with the same major version
number; a document in the full form states the version it follows
in its agsc-spec-version attribute. Change controller: Andrei N.
Besleaga, Independent, andrei.besleaga.nicolae@gmail.com.
12. Implementation Status
[Note to the RFC Editor: please remove this section before
publication.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
The implementations recorded here are those of the author, at the
time of writing.
*Reference node.*
* Organization: the author (Independent).
* Name and description: the node at https://agenticsystemcore.com/,
a static site that serves a discovery document at /.well-known/
knowledge-linkset, the artefacts it names, and the published
specification that the profile URI and the extension relation URIs
resolve to.
Besleaga Expires 3 April 2027 [Page 22]
Internet-Draft knowledge-linkset Well-Known URI September 2026
* Level of maturity: working implementation of a specification that
is at release-candidate status; the node is public at the address
above, and the reference engine is publicly released at 1.0.0-rc.6
(npm and PyPI agentic-system-core).
* Coverage: Section 3, Section 4, Section 5, and Section 6, in the
full form; the reduced form of Section 4.4 is exercised by the
validator's level-0 mode.
* Version compatibility: [AGSC-SPEC].
* Licensing: the site's own terms; see the node.
* Contact: the author.
*Validator.*
* Organization: the author (Independent).
* Name and description: validate-wellknown, a command-line validator
that takes a URL or a local file and checks that the response
media type is application/linkset+json or that a Link header field
names the profile URI; that linkset is the sole top-level member;
that every relation name is a registered short name or a member of
the closed extension set; that every extension target attribute
value is an array of strings; that the reduced form's omissions
are accepted where the reduced form is claimed and that the
digests and bundle facts are present and recomputable otherwise.
A --peer flag performs the mutual test of Section 7.2 and accepts
two local files, so that the test runs with no network access.
* Level of maturity: working implementation; publicly released with
the reference engine at 1.0.0-rc.6 (npm and PyPI agentic-system-
core).
* Coverage: Section 3, Section 4, and the mutual peer test of
Section 7.2.
* Licensing: Apache-2.0.
* Contact: the author.
*Conformance vectors.*
* Organization: the author (Independent).
Besleaga Expires 3 April 2027 [Page 23]
Internet-Draft knowledge-linkset Well-Known URI September 2026
* Name and description: a set of JSON test vectors for the discovery
layer, each naming the rule it proves: the conformant link set
shape and its target attributes, the reduced form, and the mutual
peer test. They are fixtures rather than an implementation, and
any independent implementation can be run against them.
* Level of maturity: working implementation; the vectors are
fixtures, publicly released with the reference engine at
1.0.0-rc.6.
* Coverage: Section 4, Section 4.4, Section 7.2.
* Licensing: Apache-2.0.
* Contact: the author.
13. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC7284] Lanthaler, M., "The Profile URI Registry", RFC 7284,
DOI 10.17487/RFC7284, June 2014,
<https://www.rfc-editor.org/info/rfc7284>.
[RFC6906] Wilde, E., "The 'profile' Link Relation Type", RFC 6906,
DOI 10.17487/RFC6906, March 2013,
<https://www.rfc-editor.org/info/rfc6906>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
Besleaga Expires 3 April 2027 [Page 24]
Internet-Draft knowledge-linkset Well-Known URI September 2026
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9264] Wilde, E. and H. Van de Sompel, "Linkset: Media Types and
a Link Relation Type for Link Sets", RFC 9264,
DOI 10.17487/RFC9264, July 2022,
<https://www.rfc-editor.org/info/rfc9264>.
[RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
DOI 10.17487/RFC9530, February 2024,
<https://www.rfc-editor.org/info/rfc9530>.
[RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/info/rfc9651>.
[POWDER-DR]
Archer, P., Smith, K., and A. Perego, "Protocol for Web
Description Resources (POWDER): Description Resources",
W3C Recommendation, 1 September 2009,
<https://www.w3.org/TR/2009/REC-powder-dr-20090901/>.
14. Informative References
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
January 2005, <https://www.rfc-editor.org/info/rfc3987>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC6892] Wilde, E., "The 'describes' Link Relation Type", RFC 6892,
DOI 10.17487/RFC6892, March 2013,
<https://www.rfc-editor.org/info/rfc6892>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
Besleaga Expires 3 April 2027 [Page 25]
Internet-Draft knowledge-linkset Well-Known URI September 2026
[RFC8574] Van de Sompel, H., Nelson, M., Bilder, G., Kunze, J., and
S. Warner, "cite-as: A Link Relation to Convey a Preferred
URI for Referencing", RFC 8574, DOI 10.17487/RFC8574,
April 2019, <https://www.rfc-editor.org/info/rfc8574>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
[RFC9309] Koster, M., Illyes, G., Zeller, H., and L. Sassman,
"Robots Exclusion Protocol", RFC 9309,
DOI 10.17487/RFC9309, September 2022,
<https://www.rfc-editor.org/info/rfc9309>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/info/rfc9421>.
[RFC9727] Smith, K., "api-catalog: A Well-Known URI and Link
Relation to Help Discovery of APIs", RFC 9727,
DOI 10.17487/RFC9727, June 2025,
<https://www.rfc-editor.org/info/rfc9727>.
[I-D.jimenez-dawn-discovery-landscape]
Jimenez, J., Feng, J., Arkko, J., Kuehlewind, M., and R.
Kandoi, "A Survey of AI Agent Discovery Mechanisms", Work
in Progress, Internet-Draft, draft-jimenez-dawn-discovery-
landscape-00, 3 July 2026,
<https://datatracker.ietf.org/doc/html/draft-jimenez-dawn-
discovery-landscape-00>.
[I-D.arsentev-llm-context-discovery]
Arsentev, E., "Discovery and Retrieval of Publisher-
Curated Context Files for Large Language Model Consumers",
Work in Progress, Internet-Draft, draft-arsentev-llm-
context-discovery-00, 11 September 2026,
<https://datatracker.ietf.org/doc/html/draft-arsentev-llm-
context-discovery-00>.
[I-D.serra-mcp-discovery-uri]
serra, M., "The "mcp" URI Scheme and MCP Server Discovery
Mechanism", Work in Progress, Internet-Draft, draft-serra-
Besleaga Expires 3 April 2027 [Page 26]
Internet-Draft knowledge-linkset Well-Known URI September 2026
mcp-discovery-uri-04, 26 March 2026,
<https://datatracker.ietf.org/doc/html/draft-serra-mcp-
discovery-uri-04>.
[I-D.ietf-aipref-vocab]
Keller, P. and M. Thomson, "A Vocabulary For Expressing AI
Usage Preferences", Work in Progress, Internet-Draft,
draft-ietf-aipref-vocab-08, 13 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-aipref-
vocab-08>.
[I-D.ietf-aipref-attach]
Illyes, G. and M. Thomson, "Associating AI Usage
Preferences with Content in HTTP", Work in Progress,
Internet-Draft, draft-ietf-aipref-attach-05, 18 August
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
aipref-attach-05>.
[I-D.ietf-webbotauth-httpsig-protocol]
Meunier, T. and S. Major, "HTTP Message Signatures for
automated traffic", Work in Progress, Internet-Draft,
draft-ietf-webbotauth-httpsig-protocol-00, 1 September
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
webbotauth-httpsig-protocol-00>.
[I-D.aiendpoint-ai-discovery]
AIEndpoint, "The AI Discovery Endpoint: A Structured
Mechanism for AI Agent Service Discovery and Capability
Exposure", Work in Progress, Internet-Draft, draft-
aiendpoint-ai-discovery-01, 28 July 2026,
<https://datatracker.ietf.org/doc/html/draft-aiendpoint-
ai-discovery-01>.
[I-D.car-ai-txt-wellknown]
Cardillo, K., "AI.TXT: A Declaration File for AI Usage
Preferences, Licensing, and Policy", Work in Progress,
Internet-Draft, draft-car-ai-txt-wellknown-00, 12 June
2026, <https://datatracker.ietf.org/doc/html/draft-car-ai-
txt-wellknown-00>.
[DAWN-CHARTER]
IETF, "Discovery of Agents With Names (dawn) -- proposed
working group charter", 11 September 2026,
<https://datatracker.ietf.org/doc/charter-ietf-dawn/>.
Besleaga Expires 3 April 2027 [Page 27]
Internet-Draft knowledge-linkset Well-Known URI September 2026
[AGENTPROTO-BOF]
IETF, "Agent Communication Protocols (agentproto) -- BOF
request", 4 September 2026,
<https://datatracker.ietf.org/doc/bofreq-steele-
agentproto/>.
[MCP] Model Context Protocol, a Series of LF Projects, LLC,
"Model Context Protocol Specification, revision
2026-07-28", 28 July 2026,
<https://modelcontextprotocol.io/
specification/2026-07-28>.
[A2A] Agentic AI Foundation, "Agent2Agent (A2A) Protocol
Specification, version 1.0", 28 May 2026,
<https://a2a-protocol.org/latest/specification/>.
[LLMSTXT] Howard, J., "The /llms.txt file, version 2", 10 August
2026, <https://llmstxt.org/>.
[OKF] Google Cloud, "Open Knowledge Format, version 0.2", 2026,
<https://github.com/GoogleCloudPlatform/open-knowledge-
format>.
[AIMEM-CG] W3C, "AI Agent Memory Interoperability Community Group",
n.d.,
<https://www.w3.org/community/ai-agent-memory-interop/>.
[VOID] W3C Semantic Web Interest Group, "Describing Linked
Datasets with the VoID Vocabulary", W3C Interest Group
Note, 3 March 2011, <https://www.w3.org/TR/void/>.
[DCAT3] W3C Dataset Exchange Working Group, "Data Catalog
Vocabulary (DCAT) -- Version 3", W3C Recommendation, 22
August 2024, <https://www.w3.org/TR/vocab-dcat-3/>.
[IANA-IPV4-SPECIAL]
IANA, "IANA IPv4 Special-Purpose Address Registry", n.d.,
<https://www.iana.org/assignments/iana-ipv4-special-
registry/>.
[IANA-IPV6-SPECIAL]
IANA, "IANA IPv6 Special-Purpose Address Registry", n.d.,
<https://www.iana.org/assignments/iana-ipv6-special-
registry/>.
Besleaga Expires 3 April 2027 [Page 28]
Internet-Draft knowledge-linkset Well-Known URI September 2026
[AGSC-SPEC]
Besleaga, A. N., "AgenticSystemCore Specification, version
1.0.0-rc.6 (release candidate)", 2026,
<https://agenticsystemcore.com/specs/>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
Appendix A. A Complete Example
The document below is a complete discovery document for a node at
https://example.org/, in the full form of Section 4. It is shown
pretty-printed; a node that produces canonical bytes [RFC8785] serves
the equivalent document with no insignificant whitespace.
NOTE: '\' line wrapping per RFC 8792
{
"linkset": [
{
"anchor": "https://example.org/",
"alternate": [
{
"href": "https://example.org/llms-full.txt",
"type": "text/plain",
"digest": [
"sha-256=:Nfm1AxNikrZAb82mhnWgjpi3i8rGJa9K64wnI0ZiJY0=:"
]
},
{
"href": "https://example.org/llms.txt",
"type": "text/plain",
"digest": [
"sha-256=:QjxPZtSHNKLvYtiXXCOwnjJn+fYmfqkRYmash8n7+O0=:"
]
}
],
"author": [
{
"href": "https://example.org/about/",
"type": "text/html"
}
],
"describedby": [
{
"href": "https://example.org/graph.jsonld",
Besleaga Expires 3 April 2027 [Page 29]
Internet-Draft knowledge-linkset Well-Known URI September 2026
"type": "application/ld+json",
"agsc-bundle-hash": [
"sha-256=:/WQyaCbIwaeGFFMAFw/eMonm8tK+F7amphaKNT4BpB0=:"
],
"agsc-bundle-version": [
"v1.4.0"
],
"agsc-counts": [
"clusters=6",
"concepts=142",
"episodes=17",
"gates=4",
"lessons=39",
"procedures=28"
],
"agsc-generated-at": [
"2026-10-09T08:15:00Z"
],
"agsc-spec-version": [
"1.0.0-rc.6"
],
"digest": [
"sha-256=:JeigkAtOPS9f9BzKym+X6J2O4awt53GEua1AhIAiLfE=:"
]
}
],
"license": [
{
"href": "https://example.org/legal/",
"type": "text/html"
}
],
"service-doc": [
{
"href": "https://example.org/specs/",
"type": "text/html"
}
],
"https://w3id.org/agentic-system-core/rel#context": [
{
"href": "https://example.org/ns/context.jsonld",
"type": "application/ld+json",
"digest": [
"sha-256=:Dv8ogyqhEZ0jxdWQj0FkVfpXbuTnyfvWEFNwtbRTSEA=:"
]
}
],
"https://w3id.org/agentic-system-core/rel#graph": [
Besleaga Expires 3 April 2027 [Page 30]
Internet-Draft knowledge-linkset Well-Known URI September 2026
{
"href": "https://example.org/graph.nq",
"type": "application/n-quads",
"digest": [
"sha-256=:/WQyaCbIwaeGFFMAFw/eMonm8tK+F7amphaKNT4BpB0=:"
]
},
{
"href": "https://example.org/graph.ttl",
"type": "text/turtle",
"digest": [
"sha-256=:SylBDgXPkysmlRZkx+BvHSxVTbm3ZWGzFXskHf+kH80=:"
]
}
],
"https://w3id.org/agentic-system-core/rel#ledger": [
{
"href": "https://example.org/ledger.jsonl",
"type": "application/jsonl",
"agsc-ledger-head": [
"6acd55d78bf24c2b7866c0e46a3bb88a4b7259cea9ca0bfa6263\
81068b0d56ed"
],
"digest": [
"sha-256=:mIn5HVeWxmn0Ecmh5Qwkc3doL+0fdO+Z7HieEDozhz0=:"
]
}
],
"https://w3id.org/agentic-system-core/rel#now": [
{
"href": "https://example.org/now.md",
"type": "text/markdown",
"digest": [
"sha-256=:cJvRMVgkkW5Usdn/z0q1iNxyBErb59kLWRv83qvpx8A=:"
]
}
],
"https://w3id.org/agentic-system-core/rel#ontology": [
{
"href": "https://example.org/ns/agsc.ttl",
"type": "text/turtle",
"digest": [
"sha-256=:kjVLSaNilITtebImxe9J+ukr7UOdmTG+NAtppRjsrH8=:"
]
}
],
"https://w3id.org/agentic-system-core/rel#peer": [
{
Besleaga Expires 3 April 2027 [Page 31]
Internet-Draft knowledge-linkset Well-Known URI September 2026
"href": "https://b.example/.well-known/knowledge-linkset",
"type": "application/linkset+json"
}
],
"https://w3id.org/agentic-system-core/rel#skills": [
{
"href": "https://example.org/skills/index.json",
"type": "application/json",
"digest": [
"sha-256=:NnyPQz+rxvP/Zl9ja4+0xRSCpb7gdArcAVXlAG5IoU0=:"
]
}
],
"https://w3id.org/agentic-system-core/rel#surface": [
{
"href": "https://example.org/chunks.jsonl",
"type": "application/jsonl",
"agsc-access": [
"none"
],
"agsc-surface": [
"chunks"
],
"digest": [
"sha-256=:vAlDuXGRaRPyTeeRfLAFWa7acFyOL3Y7o+vbywRofDk=:"
]
},
{
"href": "https://example.org/llms.txt",
"type": "text/plain",
"agsc-access": [
"none"
],
"agsc-surface": [
"llms-txt"
]
}
]
}
]
}
Figure 3: A complete discovery document
The same node, publishing without a build engine, serves the reduced
form of Section 4.4: a link set of the same structure that names only
the artefacts such a publisher has, with no digest attribute, no
bundle-fact attribute and no ledger link.
Besleaga Expires 3 April 2027 [Page 32]
Internet-Draft knowledge-linkset Well-Known URI September 2026
{
"linkset": [
{
"anchor": "https://example.org/",
"alternate": [
{
"href": "https://example.org/llms.txt",
"type": "text/plain"
}
],
"describedby": [
{
"href": "https://example.org/graph.jsonld",
"type": "application/ld+json"
}
],
"license": [
{
"href": "https://example.org/legal/"
}
]
}
]
}
Figure 4: The same document in the reduced form
Appendix B. Change Log
[Note to the RFC Editor: please remove this appendix before
publication.]
This is the initial version, -00. Later revisions record their
changes here.
Author's Address
Andrei N. Besleaga
Independent
Email: andrei.besleaga.nicolae@gmail.com
Besleaga Expires 3 April 2027 [Page 33]