One document matched: draft-ietf-core-link-format-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC5198 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5198.xml">
<!ENTITY RFC5785 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5785.xml">
<!ENTITY RFC5988 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5988.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-coap-03.xml">
<!ENTITY I-D.ietf-core-observe SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-observe-00.xml">
<!ENTITY I-D.ietf-core-block SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-block-00.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" ipr="trust200902" docName="draft-ietf-core-link-format-02">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>CoRE Link Format</title>
<author initials="Z" surname="Shelby" fullname="Zach Shelby">
<organization>
Sensinode
</organization>
<address>
<postal>
<street>Kidekuja 2</street>
<city>Vuokatti</city>
<code>88600</code>
<country>FINLAND</country>
</postal>
<phone>+358407796297</phone>
<email>zach@sensinode.com</email>
</address>
</author>
<date year="2010"/>
<area>Internet</area>
<workgroup>CoRE</workgroup>
<keyword>CoRE, Link Format, HTTP Link Header Format, Resource Discovery</keyword>
<abstract>
<t>
This document defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header format defined in RFC5988, the CoRE Link Format is carried as a payload and is assigned an Internet media type. A well-known URI is defined as a default entry-point for requesting the links hosted by a server.
</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='introduction' title="Introduction">
<!--
Definitions:
Web Linking - A framework for indicating the relationships between web resources.
Link - Also called "typed links" in RFC5988. A link is a typed connection between two resources identified by URIs. Made up of:
- a context URI
- a link relation type
- a tarfet URI
- and optional target attributes
Link Format - A particular serialisation of typed links.
CoRE Link Format - A particular serialization of these links based the HTTP Link Header serialization defined in Section 5 of RFC5988.
Attribute - Properly called "Target Attribute" in RFC5988. A set of key/value pairs that descibe the link or its target.
CoRE Resource Discovery - When a client discovers the list of resources hosted by a server, their attributes and other link relations by accessing /.well-known/core.
-->
<t>
The Constrained RESTful Environments (CoRE) working group aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g. 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to-machine (M2M) applications such as smart energy and building automation.
</t>
<t>
The discovery of resources hosted by a constrained server is very important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility. The discovery of resources provided by an HTTP Web Server is typically called Web Discovery and the description of relations between resources is called Web Linking <xref target="RFC5988"/>. In this document we refer to the discovery of resources hosted by a constrained web server, their attributes and other resource relations as CoRE Resource Discovery.
</t>
<t>
The main function of such a discovery mechanism is to provide URIs (called links) for the resources hosted by the server, complemented by attributes about those resources and possible further link relations. In CoRE this collection of links is carried as a resource of its own (as opposed to as HTTP headers delivered with a specific resource). This document specifies a link format for use in CoRE Resource Discovery by extending the HTTP Link Header Format <xref target="RFC5988"/> to describe these link descriptions. The CoRE Link Format is carried as a payload and is assigned an Internet media type. A well-known URI "/.well-known/core" is defined as a default entry-point for requesting the list of links about resources hosted by a server, and thus performing CoRE Resource Discovery.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='format' title="Link Format">
<t>
The CoRE Link Format extends the HTTP Link Header format specified in <xref target="RFC5988"/>, which is specified in Augmented Backus-Naur Form (ABNF) notation. The format does not require special XML or binary parsing, is fairly compact, and is extensible - all important characteristics for CoRE. It should be noted that this link format is just one serialization of typed links defined in <xref target="RFC5988"/>, others include Atom or HTTP links. It is expected that resources discovered in the CoRE Link Format may also be made available in alternative formats on the greater Internet.
</t>
<t>
Section 5 of <xref target="RFC5988"/> did not require an Internet media type for the defined link format, as it was defined to be carried in an HTTP header. This specification thus defines a Internet media type for the CoRE Link Format (see <xref target="iana-mime"/>).
</t>
<t>
The CoRE link format uses the ABNF description and associated rules in Section 5 of <xref target="RFC5988"/>. In addition, the pchar rule is taken from <xref target="RFC3986"/>. The "Link:" text is omitted as that is part of the HTTP Link Header. As in <xref target="RFC5988"/>, multiple link descriptions are separated by commas. Note that commas can also occur in quoted strings and URIs but do not end a description. The CoRE link format MUST use UTF-8 encoding, which SHOULD be in NFC (Unicode Normalization Form C). See Section 3 of <xref target="RFC5198"/>, which explains why it useful to represent Unicode in a single unique form.
</t>
<section title="Web Linking in CoRE">
<t>
This link format is used for a similar purpose to that described in <xref target="RFC5988"/>, to describe relationships between resources via typed links, so-called "Web Linking". However in this specification Web Linking is extended with specific constrained M2M attributes, links are carried as a message payload rather than in an HTTP Link Header, and a default interface is defined to discover resources hosted by a server. This specification defines a new relation type "hosts", which indicates that the resource is hosted by the server from which the link document was requested.
</t>
<section title="Target and context URIs">
<t>
Each link conveys one target URI as a URI-reference inside angle brackets ("<>"). The context URI of a link (also called base URI in <xref target="RFC3986"/>) conveyed in the CoRE Link Format is by default built from the scheme and authority parts of the target URI. In the absence of this information in the target URI, the context URI is built from the scheme and authority that was used for referencing the resource returning the set of links, replacing the path with an empty path. Thus by default links can be thought of as describing a target resource hosted by the server. Other relations can be expressed by including an anchor parameter (which defines the context URI) along with an explicit relation parameter. This is an important difference to the way the HTTP Link Header format is used, as it is included in the header of an HTTP response for some URI (this URI is by default the context URI). Thus the HTTP Link Header is by default relating the target URI to the URI that was requested. In comparison, the CoRE link format includes one or more links, each describing a resource hosted by a server by default. Other relations can be expressed by using the anchor parameter. See Section 5 of <xref target="RFC3986"/> for a description of how URIs are constructed from URI references.
</t>
</section>
<section title="Link relations">
<t>
Since links in the CoRE Link Format are typically used to describe resources hosted by a server, and thus in the absence of the relation parameter the new relation type "hosts" is assumed (see <xref target="iana-relation"/>). The "hosts" relation type indicates that the target URI is a resource hosted by the server given by the base URI, or, if present, the anchor parameter.
</t>
<t>
To express other relations a links can make use of any registered relation parameter or target attributes by including the relation parameter. The context of a relation can be defined using the anchor parameter. In this way, relations between resources hosted on a server, or between hosted resources and external resources can be expressed.</t>
</section>
<section title="Use of anchors">
<t>
As per Section 5.2 of <xref target="RFC5988"/> a link description MAY include an "anchor" attribute, in which case the context is the URI included in that attribute. This is used to describe a relationship between two resources. A consuming implementation can however choose to ignore such links. It is not expected that all implementations will be able to derive useful information from explicitly anchored links.
</t>
</section>
</section>
<section title="CoRE link extensions">
<t>
The following CoRE specific target attributes are defined. These attributes describe information useful in accessing the target link of the relation, and in some cases may be URIs. These URIs MUST be treated as indicators, and are not meant to be actually retrieved like a URL. When attributes are compared, they MUST be compared as strings. Relationships to resources that are meant to be retrieved should be expressed as separate links using the anchor attribute and the appropriate relation type.
</t>
<figure>
<artwork><![CDATA[
link-extension = ( "n" "=" quoted-string )
link-extension = ( "d" "=" <"> URI-reference <">)
link-extension = ( "ct" "=" integer )
link-extension = ( "sz" "=" integer )
link-extension = ( "obs" )
integer = 1*DIGIT
]]></artwork>
</figure>
<section title="Resource name 'n' attribute">
<t>
The resource name "n" attribute is used to assign a semantically important name to a resource. In the case of a temperature sensor resource this could be an application-specific semantic name like "TemperatureC", a URN like "urn:temperature:centigrade" or a URI referencing a specific concept in an ontology like "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". Multiple name attributes MAY appear in a link.
</t>
<t>
The name attribute is not meant to used to assign a human readable name to a resource. The "title" attribute defined in <xref target="RFC5988"/> is meant for that purpose.
</t>
</section>
<section title="Interface description 'd' attribute">
<t>
The interface description "d" attribute is used to provide a URI or URN indicating a specific interface definition used to interact with the target resource. This could be for example the URI of a WADL definition of the target resource "http://www.example.org/sensor.wadl", or a URN indicating the type of interface to the resource "urn:sensor". Multiple description attributes MAY appear in a link.
</t>
</section>
<section title="Content-type code 'ct' attribute">
<t>
The Content-type code "ct" attribute provides a hint about the Internet media type this resource returns. Note that this is only a hint, and does not override the Content-type Option of a CoAP response obtained by actually following the link. The value is in the CoAP identifier code format as a decimal ASCII integer <xref target="I-D.ietf-core-coap"/>. For example application/xml would be indicated as "ct=41". If no Content-type code attribute is present then nothing about the type can be assumed. The Content-type code attribute MUST NOT appear more than once in a link.
</t>
<t>
Alternatively, the "type" attribute MAY be used to indicate an Internet media type as a quoted-string <xref target="RFC5988"/>. It is not however expected that constrained implementations are able to parse quoted-string Content-type values. A link MAY include either a ct attribute or a type attribute, but MUST NOT include both.
</t>
</section>
<section title="Maximum size estimate 'sz' attribute">
<t>
The maximum size estimate attribute "sz" gives an indication of the maximum size of the link indicated by the target URI. This attribute is not expected to be included for small resources that can comfortably by carried in a single MTU, but SHOULD be included for resources larger than that. The maximum size estimate attribute MUST NOT appear more than once in a link.
</t>
</section>
<section title="Observable 'obs' attribute">
<t>
The observable attribute "obs" is used to indicate that this resource supports the observation feature defined in <xref target="I-D.ietf-core-observe"/>. This attribute is used as a flag, and thus it has no value component. The observable attribute MUST NOT appear more than once in a link.
</t>
</section>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='well-known' title="Well-known Interface">
<t>
Resource discovery in CoRE is accomplished through the use of a well-known resource URI which returns a list of links about resources hosted by that server and other link relations. Well-known resources have a path component that begins with "/.well-known/" as specified in <xref target="RFC5785"/>. This document defines a new well-known resource for CoRE Resource Discovery "/.well-known/core". A server implementing this specification MUST support this resource on the default port appropriate for the protocol for the purpose of resource discovery. It is however up to the application which links are included and how they are organized. In the absence of any links, a zero-length payload is returned. The resource representation of this resource uses the CoRE Link Format described in <xref target="format"/>. URIs under the path /.well-known/core are reserved by this specification for use by servers in organizing links into multiple resources, each with their own URI.
</t>
<t>
The CoRE resource discovery interface supports the following interactions:
<list style="symbols">
<t>Performing a GET on /.well-known/core to the default port returns a set of links available from the CoAP server (if any) in the CoRE Link Format. These links might describe resources hosted on that server, on other servers, or express other kinds of link relations as described in <xref target="format"/>. </t>
<t>Filtering may be performed on any of the link format attributes using a query string as specified in <xref target="filtering"/>. For example [GET /.well-known/core?n=TemperatureC] would request resources with the name TemperatureC. A server is not however required to support filtering.
</t>
<t>More capable servers such as proxies could support a resource directory by requesting the resource descriptions of other end-points or allowing servers to POST requests to /.well-known/core. The details of such resource directory functionality is however out of scope for this document, and is expected to be specified separately.</t>
</list>
</t>
<t>
End-points with a large number of resources SHOULD include resource descriptions only for important links and MAY organize their resource descriptions into a hierarchy of link resources. This is done by including links in the /.well-known/core list which point to other resource lists using the "section" relation type, e.g. <![CDATA[</.well-known/core/sensors>]]>. Such a hierarchy MUST be under the /.well-known/core path.
</t>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='filtering' title="Query Filtering">
<t>
A server implementing this document MAY recognize the query part of a resource-discovery URI as a filter on the resources to be returned. The query part should conform to the following syntax. Note that this only defines querying for a single parameter at a time.
</t>
<figure>
<artwork><![CDATA[
filter-query = resource-param "=" query-pattern
resource-param = "uri" | parmname
query-pattern = 1*pchar [ "*" ]
]]></artwork>
</figure>
<t>
The resource-param "uri" refers to the URI-reference between the <![CDATA["<" and ">"]]> characters of a link. Other resource-param values refer to the link attribute they name. Filtering is performed by comparing the query-pattern against the value of the attribute identified by the resource-param for each link-value in the collection of resources identified by the URI path.</t>
<t>
If the decoded query-pattern does not end with "*", a link value matches the query only if the value of the attribute or URI-reference denoted by the resource-param is bytewise identical to the query-pattern. If the decoded query-pattern ends with "*", it is sufficient that the remainder of the query-pattern be a prefix of the value denoted by the resource-param.
</t>
<t>
It is not expected that very constrained nodes support filtering. Implementations not supporting filtering MUST simply ignore the query string and return the whole resource for unicast requests. An implementation supporting filtering MUST return only those entries for which the value of the link attribute identified by the resource-param contains the query-pattern as a substring. If resource descriptions are organized hierarchically, a query on the root resource /.well-known/core MUST return all matching resource descriptions from the entire hierarchy.
</t>
<t>When using a transfer protocol like CoAP that supports multicast requests, special care is taken. A multicast request with a query string MUST not be responded to if filtering is not supported (to avoid a needless response storm).
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='examples' title="Examples">
<t>
A few examples of typical link descriptions in this format follows. Multiple resource descriptions in a representation are separated by commas. Linefeeds never occur in the actual format, but are shown in the example for readability. </t>
<t>This example includes links to two different sensors.</t>
<figure>
<artwork><![CDATA[
REQ: GET /.well-known/core
RES: 200 OK
</sensors/temp>;ct=41;n="TemperatureC",
</sensors/light>;ct=41;n="LightLux"
]]></artwork>
</figure>
<t>This example arranges link descriptions hierarchically, with the entry point including a link to a sub-resource containing links about the sensors.</t>
<figure>
<artwork><![CDATA[
REQ: GET /.well-known/core
RES: 200 OK
</.well-known/core/sensors>;rel="section";ct=40
REQ: GET /.well-known/core/sensors
RES: 200 OK
</sensors/temp>;n="TemperatureC",
</sensors/light>;ct=41;n="LightLux"
]]></artwork>
</figure>
<t>
An example query filter may look like:
</t>
<figure>
<artwork><![CDATA[
REQ: GET /.well-known/core?n=LightLux
RES: 200 OK
</sensors/light>;ct=41;n="LightLux"
]]></artwork>
</figure>
<t>This example shows the use of an anchor attribute to relate the temperature sensor resource to an external description and to an alternative URL.</t>
<figure>
<artwork><![CDATA[
REQ: GET /.well-known/core
RES: 200 OK
</sensors>;rel="index";n="Sensor Index",
</sensors/temp>;n="TemperatureC",
</sensors/light>;ct=41;n="LightLux",
<http://www.example.com/sensors/temp123>;anchor="/sensors/temp"
;rel=describedby,
</t>;anchor="/sensors/temp";rel=alternate
]]></artwork>
</figure>
<t>If a client is interested to find relations about a particular resource, it can perform a query on the anchor parameter:</t>
<figure>
<artwork><![CDATA[
REQ: GET /.well-known/core?anchor=/sensors/temp
RES: 200 OK
<http://www.example.com/sensors/temp123>;anchor="/sensors/temp"
;rel=describedby,
</t>;anchor="/sensors/temp";rel=alternate
]]></artwork>
</figure>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Security Considerations">
<t>
This document needs the same security considerations as described in Section 7 of <xref target="RFC5988"/>. The /.well-known/core resource may be protected e.g. using DTLS when hosted on a CoAP server as per <xref target="I-D.ietf-core-coap"/> Section 10.2.
</t>
<t>
Multicast requests using CoAP for the well-known link-format resources could be used to perform denial of service on a constrained network. A multicast request SHOULD only be accepted if the request is sufficiently authenticated and secured.
</t>
<t>
CoRE link format parsers should be aware that a link description may be cyclical, i.e., contain a link to itself. These cyclical links could be direct or indirect (i.e., through referenced link resources). Care should be taken when parsing link descriptions and accessing cyclical links.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="IANA Considerations">
<section anchor='iana-well-known' title="Well-known 'core' URI">
<t>This memo registers the "core" well-known URI in the Well-Known
URI Registry as defined by [RFC5785].</t>
<t>URI suffix: core</t>
<t>Change controller: IETF</t>
<t>Specification document(s): [[ this document ]]</t>
<t>Related information: None</t>
</section>
<section anchor='iana-relation' title="New 'hosts' relation type">
<t>This memo registers the new "hosts" Web Linking relation type as per [RFC5988].</t>
<t>Relation Name: hosts</t>
<t>Description: Refers to a resource hosted by the server indicated by the link context.</t>
<t>Reference: [[ this document ]]</t>
<t>Notes: This relation is used in CoRE where links are retrieved as a /.well-known/core resource representation, and by default the context of the links is the server at coap://authority from which /.well-known/core was requested.</t>
<t>Application Data: None</t>
</section>
<section anchor='iana-mime' title="New link-format Internet media type">
<t>This memo registers the a new Internet media type for the CoRE link format, application/link-format. </t>
<t>Type name: application </t>
<t>Subtype name: link-format </t>
<t>Required parameters: None </t>
<t>Optional parameters: The query string may contain uri= to match the URI, or any other attribute defined for the link format to match that attribute. </t>
<t>Encoding considerations: UTF-8 (NFC) </t>
<t>Security considerations: None </t>
<t>Interoperability considerations: </t>
<t>Published specification: [[ this document ]] </t>
<t>Applications that use this media type: CoAP server and client implementations for resource discovery and HTTP applications that use the link-format as a payload.</t>
<t>Additional information: </t>
<t>Magic number(s): </t>
<t>File extension(s): </t>
<t>Macintosh file type code(s): </t>
<t>Intended usage: COMMON </t>
<t>Restrictions on usage: None </t>
<t>Author: CoRE WG </t>
<t>Change controller: IETF </t>
</section>
</section>
<!------------------------------------------------------>
<!-- SECTION: ACKNOWLEDGMENTS -->
<!------------------------------------------------------>
<section title="Acknowledgments">
<t>Special thanks to Peter Bigot, who has made a considerable number reviews and text contributions that greatly improved the document. In particular, Peter is responsible for the ABNF descriptions and the idea for a new "hosts" relation type.
</t>
<t>Thanks to Mark Nottingham and Eran Hammer-Lahav for discussions and ideas that led to this draft, and to Carsten Bormann and Martin Thomson for extensive comments and contributions that improved the text.</t>
<t>Thanks to Michael Stuber, Richard Kelsey, Cullen Jennings, Guido Moritz, Peter Van Der Stok, Adriano Pezzuto, Lisa Dussealt, Alexey Melnikov, Gilbert Clark, Salvatore Loreto, Petri Mutka, Szymon Sasin, Robert Quattlebaum, Robert Cragie, Angelo Castellani, Tom Herbst, Ed Beroset, Gilman Tolle, Robby Simpson, Colin O'Flynn and David Ryan for helpful comments and discussions that have shaped the document.</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Changelog">
<t>Changes from ietf-01 to ietf-02:
<list>
<t>o Added references to RFC5988 (#41).</t>
<t>o Removed sh and id link-extensions (#42).</t>
<t>o Defined the use of UTF-8 (#84).</t>
<t>o Changed query filter definition for any parameter (#70).</t>
<t>o Added more example, now as a separate section (#43).</t>
<t>o Mentioned cyclical links in the security section (#57).</t>
<t>o Removed the sh and id attributes, added obs and sz attributes (#42).</t>
<t>o Improved the context and relation description wrt RFC5988 and requested a new "hosts" default relation type (#85).</t>
</list>
</t>
<t>Changes from ietf-00 to ietf-01:
<list>
<t>o Editorial changes to correct references. </t>
<t>o Formal definition for filter query string.</t>
<t>o Removed URI-reference option from "n" and "id". </t>
<t>o Added security text about multicast requests. </t>
</list>
</t>
<t>Changes from shelby-00 to ietf-00:
<list>
<t>o Fixed the ABNF link-extension definitions (quotes around URIs, integer definition). </t>
<t>o Clarified that filtering is optional, and the query string is to be ignored if not supported (and the URL path processed as normally). </t>
<t>o Required support of wildcard * processing if filtering is supported.</t>
<t>o Removed the aussumption of a default content-type assumption.</t>
</list>
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC3986;
&RFC5988;
</references>
<references title='Informative References'>
&RFC5198;
&RFC5785;
&I-D.ietf-core-coap;
&I-D.ietf-core-observe;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:06:24 |