The "dereferenceable identifier" pattern
draft-bormann-t2trg-deref-id-01
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
Expired & archived
|
|
|---|---|---|---|
| Authors | Carsten Bormann , Christian Amsüss | ||
| Last updated | 2023-11-10 (Latest revision 2023-05-09) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
In a protocol or an application environment, it is often important to be able to create unambiguous identifiers for some meaning (concept or some entity). Due to the simplicity of creating URIs, these have become popular for this purpose. Beyond the purpose of identifiers to be uniquely associated with a meaning, some of these URIs are in principle _dereferenceable_, so something can be placed that can be retrieved when encountering such a URI. The present -00 version is a stub to draw some attention to the opportunity that this pattern would benefit from a common description, documenting its benefits and pitfalls, and some mitigations for the latter.
Authors
Carsten Bormann
Christian Amsüss
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)