RFC 1728

RFC 1728: Resource Transponders 🦋

• Network Working Group 🌸
• Author: C. Weider (Chris Weider) 💅
• Organization: Bunyip Information Systems 🏢
• Category: Informational 📚
• Date: December 1994 🗓️
• Obsoletes / Updates: neither field appears in this document's header 🙈

Status of This Memo ✨

okay so this memo is just giving info for the Internet community 🫶 It does not specify an Internet standard of any kind, so don't go treating it like one. Distribution of this memo is unlimited, so share it with everyone 💖

Abstract 🌸

ngl, a bunch of systems have popped up over the last several years to help people find resources and get around the Internet 🧭 The catch is that all the info inside them has to be maintained and updated by hand, which is a lot. This paper introduces the resource transponder, an automatic mechanism for keeping resource location info up to date 🔥

Author's Note 💅

this doc is kind of a research paper, so there are no protocol specs or anything like that 📝 The author hopes we can take it from here and actually design them if people agree they'd be useful 🤞 Once we know what functionality is needed, we can go out and standardize it 🎀

Disclaimer 🫶

these are only the author's opinions, not the consensus of the IIIR Working Group 🙈 The group does recognize this as one legitimate approach to solving the problem, though, which is iconic 👑

1. Introduction 🔥

so in the last few years we've watched information location systems get invented and blow up, like archie, Gopher, and WAIS 🌈 But as these systems got widely deployed, some maintenance and security problems showed up. The big ones are:

1. Most of these systems hold pointers to the resources, not the resources themselves 📍 So if a resource goes obsolete, gets modified, or moves, somebody has to update the location system by hand 😩 Some systems (archie in particular) fix this by contacting every resource on a schedule (every 30 days or so) to rebuild their indexes. But that means the system can be up to 30 days out of date, and the process can be super inefficient depending on how much of the info has changed 💀
2. Anyone maintaining a resource they want indexed has to keep track of every directory that points to it, so that when it changes, all those directories get updated too 🙃 Honestly, that's a very optimistic scenario.
3. A lot of organizations that installed these systems don't have the resources or expertise to maintain the info 🥲 So we end up with long stretches where the info drifts, followed by a short burst where it gets updated again.
4. These systems are almost always out of date today, and it's only going to get harder for humans to manage by hand as everyone becomes their own publisher 📣 As the net speeds up and people depend more on accurate info, human-caused delays in updates will become more and more intolerable ⏰
5. Most, if not all, of these systems provide no security whatsoever 😱 If a pointer to a resource shows up in a locator system, it's assumed to be meant for public consumption. Lots of info providers would love to use public information systems to publish to a very select audience, but they don't want the whole net having access to their resources 🔒

2. Requirements for a Solution 🎀

any proposed solution to these problems has to hit several objectives:

1. We need to decrease the personnel resources needed for indexing and pointer maintenance 🧑‍💻
2. We need to increase the reliability and accuracy of the info held in resource location systems 🎯
3. We need to provide some security mechanisms, especially ones that mediate access to the resources 🛡️
4. We need to make it easy for non-experts, like librarians, archivists, and database maintainers, to announce their new resources to the various resource location services 📢

honestly, a lot of these problems can be solved by a resource transponder mechanism 🦋

3. Resource Transponders 🧚

the resource transponder system works by adding two new layers to every resource: metainformation, and an agent that updates a resource location system (RLS) with that metainformation 💫 The metainformation layer is physically attached to every resource, so when the resource is moved or altered, the metainformation is immediately available to update the RLS ⚡ The agent layer may or may not be attached to the resource. The implications of both options are discussed in detail below 👀

3.1 Metainformation 💜

the metainformation layer of a resource holds any info that might be needed to create a pointer to that resource, plus any info that's useful for cataloging or indexing it 📚 For example, the metainformation layer of a text document might include the Uniform Resource Name (URN) of the document (basically an ISBN for electronic resources 📖), the title, a Uniform Resource Locator (URL) for the document (a combo of net address and access method indicator, used for retrieval 🔗), the size of the document, and so on. So yeah, the metainformation layer is data about the resource it's attached to 💖

This metainformation is expected to be modifiable 🔄 For example, the metainformation layer might keep a history of everywhere this particular copy of a resource has been. Say a resource/transponder pair gets moved. When it reaches its new location, the agent can try contacting the resource at its old location to see whether it's still there 👀 If it is, the agent simply adds the new location to the RLS. If it isn't, the agent can tell the RLS to add the current pointer and delete the old one 🧹

Other possibilities for what the metainformation layer could contain are covered in section 4.1 ✨

3.2 Agents 🌈

the agent layer of a resource holds an executable program that reads the metainformation attached to the resource and uses it to update an RLS 🤖 It's also responsible for updating the metainformation where needed, and for running any indexing programs the RLS it's updating requires 🏃‍♀️

once the tools for building agents are built and deployed, the author expects agents to start mediating access to resources 🚪 This is especially true for agents attached to resources that aren't currently considered active processes, like text files and digitized images. In this futuristic model, someone who wants to read a document would first have to negotiate access with the agent, and then the agent would deliver the data to the client 🧑‍🎤 But this kind of agent isn't expected to be widely deployed for some time, so don't hold your breath 😅

Different ways of implementing agents are discussed in section 4.2 🧩

4. Models for implementations of resource transponders 🍓

4.1. Models for implementations of the metainformation layer 🫧

the metainformation layer can be implemented in a bunch of ways, depending on what resource it's attached to 🎨 For an "active" resource, like an on-line catalog or a mail-based service, the metainformation can be stored in a file with a well-known name in the software distribution 📂 Or, it could be stored as a record in the data the resource serves 🗃️ For a text document, the metainformation could be stored as the first or last N bytes of the document. That would break a number of editors and file display techniques, but it would guarantee the metainformation moves with the resource 💪 Another option is a file with a logically associated name, like paper2.meta next to paper2.txt. The problem with this second approach is that the user has to know they need to move the metainformation along with the file, or things will start breaking 💀 And if an agent is explicitly attached to the resource, the agent could contain the metainformation internally 🧠

no matter which option you pick, the resource transponder system must be able to guarantee that the metainformation is moved when the resource is moved 🫶

4.2 Models for implementations of the agents 🧃

the agent layer can also be implemented in a bunch of ways, depending on things like system loads, desired sizes of resources, multitasking capabilities, and so on 🛠️

The easiest way to implement an agent, and for lots of unitasking systems the cleanest, is to have one agent per computer 🖥️ Then, when a resource gets moved onto that computer, the agent is explicitly activated and told where the new resource is 📬 For example, say someone wants to download a copy of a resource and then let the RLS know it's available for public consumption 🌍 They'd download it and then run the agent, which notifies the RLS and updates the metainformation attached to the resource ✅ This model could also be used to track files on a LAN, or to provide local location services without needing to run a bigger RLS 🏠

Another way to implement an agent is to have one agent per resource 🎁 In this model, the agent moves along with the resource and the metainformation. The agent could be implemented in a file associated with the resource. In that case, the agent would have to be explicitly activated when the resource gets moved 🔛 Alternatively, the agent, metainformation, and resource could be one system, or live in one file. Then the agent is always active and handles mediating access to the resource 🚦 When someone does a telnet to a resource with an active agent, the agent accepts the telnet connection and takes care of security and translation for the data 🔐 This could give resources great security while still letting pointers to them live in public RLSs. The data in the resource could be encrypted, with the agent in charge of decrypting it 🗝️✨

5. Security Considerations 💀

⚠️ security issues are discussed throughout this memo. Seriously, read the whole thing with that in mind, because the protection of resources and their pointers depends on it 🚨

6. Author's Address 🫶

Chris Weider
Bunyip Information Systems, Inc.
2001 S. Huron Parkway, #12
Ann Arbor, MI 48104
USA

Phone: +1 313-971-2223
Fax: +1 313-971-2223
EMail: clw@bunyip.com