RFC 1862

Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994

📅 published November 1995, from ietf

RFC 1862: Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994 🎀

okay bestie, so this is an RFC (the official docs that define how the Internet works) but it's a report, not a rulebook. no pressure, just vibes and recommendations 🦋

the header lore: it's from November 1995 📅 and the category is Informational, so it's sharing info, not setting a standard. it's part of the Network Working Group series. the author crew is M. McCahill (University of Minnesota), J. Romkey (who's also the Editor 💅), M. Schwartz (University of Colorado), K. Sollins (MIT), T. Verschuren (SURFnet), and C. Weider (Bunyip Information Systems, Inc.) 🫶. the header doesn't list anything it obsoletes or updates, so it's a standalone moment ✨

Status of this Memo ✨

this memo is here to give the Internet community information 📖. it does not specify an Internet standard of any kind. anyone can pass it around as much as they like 🌸

Abstract

this is a report from an Internet architecture workshop that the IAB kicked off, held at MCI on October 12-14, 1994. the workshop mostly zoomed in on aspects of the information infrastructure on the Internet 👑

1. Introduction

okay so the Internet Architecture Board (IAB) holds occasional workshops to think about long-term issues and strategies for the Internet and to suggest future directions for the Internet architecture 🔭. this long-term planning is a total complement to the ongoing engineering work done by IETF working groups, under the leadership of the Internet Engineering Steering Group (IESG) and the area directorates 🧚

this particular IAB-initiated workshop was all about the architecture of the "information infrastructure" of the Internet. it happened October 12-14, 1994 at MCI in Tysons Corner, Virginia 🌈

the IAB members came, obviously, and so did the IESG Area Directors for the relevant areas (Applications, User Services). there were also experts in gopher, the World Wide Web, naming, WAIS, searching, indexing, and library services 💜. the IAB really tried to balance how many people came from each area of expertise. logistics capped attendance at about 35, which sadly meant a lot of highly qualified experts didn't make the invitation list 😭

the goals were to explore the architecture of "information" applications on the Internet, give the IESG a solid set of recommendations for further work, and create a place where the people working on the lower layers and the people working on the upper layers of the Internet protocol suite could talk to each other and swap experience 🫶

the 34 attendees split into three "breakout groups" that met for the second half of the first day and the entire second day. each group wrote a report of what it got up to. those reports are in this document, plus a set of specific recommendations for the IESG and IETF community ✨

2. Summary

there were some disagreements between the groups on specific functionalities for architectural components, but everyone broadly agreed on the general shape of an information architecture and on the general principles for building it 🎀. the discussions generalized a bunch of concepts already used in deployed systems like the World Wide Web, but the main thrust was defining general architectural components instead of focusing on today's technologies 🧠

Research recommendations include:

  • increased focus on a general caching and replication architecture 💾
  • a rapid deployment of name resolution services, and
  • the articulation of a common security architecture for information applications 🔐

Procedural recommendations for forwarding this work in the IETF include:

  • making common identifiers such as the IANA assigned numbers available in an on-line database 📚
  • tightening the requirements on Proposed Standards to make sure they adequately address security 🛡️
  • articulating the procedures needed to make it easier to join IETF working group meetings, and
  • reviewing the key distribution infrastructure for use in information applications 🗝️

3. Group 1 report: The Distributed Database Problem

this is the group that tackled the distributed database problem 💅. the people in it were Elise Gerich, Tim Berners-Lee, Mark McCahill, Dave Sincoskie, Mike Schwartz, Mitra, Yakov Rekhter, John Klensin, Steve Crocker, and Ton Verschuren 🌷

the editors were Mark McCahill, Mike Schwartz, and Ton Verschuren ✍️

3.1 Problem and Needs

so because more and more people want to access networked information, the current Internet information services are running into performance, reliability, and scaling problems 😩. these are general problems, honestly, because the Internet is so distributed. current and future applications would really benefit from way more widespread use of caching and replication 🙌

for example, popular WWW and Gopher servers get seriously overloaded, since many thousands of users per day try to reach them all at once 💀. neither of those systems was designed with explicit caching or replication support in the core protocol 🙈. and here's the tea: the DNS is currently the only widely deployed distributed and replicated data storage system on the Internet, so people often end up using it to make things more scalable. some examples are storing service-specific pointer information, or rotating service accesses among replicated copies of NCSA's extremely popular WWW server 🔄. in most cases, these uses of the DNS semantically overload the system. the DNS may not be able to handle these "semantic extensions" and keep performing well, because it was never designed to be a general-purpose replicated distributed database system 🥲

there are so many systems that need caching or replication, or would benefit from it. examples include key distribution for authentication services, DHCP, multicast SD, and Internet white pages 🍓

there have been a number of independent attempts to provide caching and replication facilities so far. the question this group looked at was whether it might be possible to define a general service interface or protocol, so that caches and replica servers (built in a variety of ways for different situations) could interoperate. that would mean less wasted re-implementation effort, which is currently a lot 😤. replication and caching schemes could form a sort of network "middleware" to fulfill a common need of distributed services 🧚‍♀️

it's still an open question whether it would be feasible to define a unified interface for all caching and replication problems. for example, a nationwide video service for 1,000,000 concurrent users needs very different considerations than supporting worldwide accesses to popular WWW pages 📺. the group recommends research and experimentation to dig into this bigger question 🔬

3.2 Characteristics of Solutions

okay so on the surface, caching and replication look like two ends of the same spectrum 👀 but bestie, further analysis shows they're two different approaches with different vibes 💅 There are cases where mixing the two is the optimal solution, which, ngl, makes everything even more complicated 🙈

We can roughly characterize the two approaches like this:

Caching:

  • a cache contains a partial set of data
  • a cache is built on demand
  • a cache is audience-specific, since the cache is built in response to demands of a community

Replication:

  • replicated databases contain the entire data set or a server-defined subset of a given database
  • a replicated database can return an authoritative answer about existence of an item
  • data is pushed onto the replicating server rather than pulled on demand

While caches and replicated databases have important differences, they share some issues, especially when it comes to how updates and data consistency get handled 🫶

A variety of methods can be used to update caches and replicas:

  • master-slave
  • peer-to-peer
  • flooding techniques (such as that used by NNTP).

Which strategy you pick changes important characteristics of the cache or replicated database, like:

  • consistency of data
  • is locking used to achieve consistency? this influences performance...
  • are there a priori guarantees of existence of an item in the database (is the answer authoritative, do you detect conflicts after the fact, or is there no guarantee on authoritativeness of the answer?)

Consistency guarantees depend on the granularity of synchronization (ms, sec, hr, day). There are cases where it's acceptable to trade consistency for better performance or availability 🦋 Since there's a whole range of qualities of service when it comes to consistency and performance, we would love to be able to tune these parameters for a given application. However, we recognize that this may not be possible in all cases, since it's unlikely one can implement a high performance solution to all of these problems in a single system 😭

Beyond just doing replication or caching, there's a need for managing cache and replication servers. There are several models for organizing groups of caches and replication servers, ranging from totally adaptive to a rigidly administered, centrally controlled model 👑

  • a club model. Minimal administrative overhead to join the club. Participation is a function of disk space, CPU, and available network bandwidth.
  • centrally coordinated service. Here administrators can take advantage of their knowledge of the system's topology and the community they intend to serve. There may be scaling problems with this model.
  • hybrid combinations of the club and centrally coordinated models

There are a couple of models for how to organize the management of a group of cooperating servers, but that doesn't address what sorts of commands the manager (be it a person or a program) issues to a cache or replicated server 🧚 A manager needs to be able to address issues on a server such as:

  • control of caching algorithms, defining how information is aged out of the cache based on disk space, usage demands, etc. This is where you would control time-to-live and expiry settings.
  • flushing the cache. There are circumstances where the information source has become inaccessible, and the normal cache aging strategy is inappropriate, since you won't be able to get the information again for an indeterminate amount of time.
  • management control might also be a way for information providers to control how information is pushed on servers for maintaining data consistency, but this raises tricky problems with trust and authentication 🙈

Given a common set of management controls, a common protocol would let you simplify managing a collection of caching and replicating servers, since you'd be able to both control them with a single set of commands and query them about their capabilities 🎀 A common language or protocol would also let different implementations interoperate 🌈

Replicating or caching information immediately raises issues of billing, access control, and authentication. Ignoring authentication and access control simplifies the replication and caching problem a great deal 😌 Exactly who is running the replication or caching server makes a big difference in how you approach this. If the information publisher runs a set of servers, they can easily handle billing and authentication. On the other hand, if an organization is running a cache on its firewall (a boundary cache) and purchasing information from a vendor, there are sticky intellectual property issues in this scenario 💀

Selecting an appropriate cache or replica of a database is simple in the case of a captive user group (for instance, a company behind a firewall). In this case, configuring the user's software to go through one or more boundary caches or replication servers directs users to the closest server 🍓 In the more general case, there are several replicated or cached copies of an object, so you may receive several URLs when you resolve a URN. So how do you select the best URL? 🤔

Either client developers create ad hoc performance metrics, or (in an ideal world) the lower level protocols would give the client application some guidance about the "closest" copy of the object. In other words, if better information about network performance were available from the lower levels of the protocol stack, applications wouldn't have to build ad hoc models of network topology ✨

We did not model the functions of a cache or replication server in detail, but we did an (incomplete) model of some of the functions (see Figure 1). The idea was to start work on a general form which might include features such as a push function, for use in both maintaining consistency and preloading information that the information publisher believes will be requested in the near future 🦋

Preloading information via a push command might be a function of observed behavior patterns (when you ask for A, you'll probably want B and C). The decision about what to preload can be made either by the information publisher or by the cache server. The cache server has the advantage that it has better knowledge of its community's use patterns. The distributed nature of links to other servers also limits the knowledge of any single information publisher. Either way, being able to accurately predict usage patterns can result in significant performance enhancements for caches 🚀

Figure 1: a rough cut at functions 🎀

                 requests from client (in)
                           |
                           |
                           |
                          \|/
                  +---------------------+
                  |                     |     (management)
                  | cache/replicated db |<--- commands from admins,
                  |                     |     publishers, caches
                  +---------------------+
                           |
                           |
                           |
                          \|/
         requests sent to information providers (out)

in: (requests from a client)

  • give me meta-info about the cached object (how up-to-date it is, ttl, expiry, signatures/checksum, billing information)
  • give me the object
  • go get the object from the net
  • cache, what objects should I pre-fetch? (this assumes that the client software believes the cache/replica has some knowledge of use patterns and can predict what the user will do next)

out: (requests sent to an information publisher or a cache further up the food chain)

  • server, do I have latest copy of this object?
  • give me object x and the meta data for object x
  • I have a copy of object x (announcing you have a copy of object x to other caches or URN to URL server)
  • info publisher, what objects should I pre-fetch? (this assumes that the information publisher has some knowledge of use patterns and can predict what the user will do next)

management: (commands from administrators, other cooperating caches, and object publishers)

  • turn parameters (e.g. consistency) on/off
  • flush the cache
  • there's a new version of object x, take it

3.3 Recommendations

Caching and replication are important pieces of Internet middleware, and solutions need to be found soon 🔥 Caches and replicas have different performance characteristics, and there are cases where a combination of the two provides the best solution. There are also many strategies for updating and maintaining consistency of caches and replicated databases, and we don't believe any single implementation can cover the broad range of needs on the Internet 🌸 One possible solution would be to define a general protocol for a replicated distributed database and for caching, so that different information application implementations can interoperate and be managed via a common management interface. A common protocol would provide a framework for future protocols (e.g., URN2URL, DHCP) or existing protocols (e.g., Gopher or WWW) that presently lack a consistent solution 🧚

4. Group 2A report: Building an Information Architecture ✨

Karen Sollins, Abel Weinrib, Barry Leiner, Clifford Neuman, Dan LaLiberte, Erik Huizer, John Curran, John Klensin, Lixia Zhang, Michael Mealling, Mitchell Charity, Mike St. Johns, Paul Mockapetris 🫶

This group took as its central agenda exploring an information architecture, the services that would instantiate such an architecture, and the functional interfaces between a realization of such an architecture and both the layers it would sit on and the layers that would sit on top of it 💖 To describe an architecture, you have to describe not only what it includes, but also what it excludes 🦋

4.1. The core model and service structure 🎀

Okay bestie, so the centerpiece of this whole architecture is the object 🧚, or what the Uniform Resource Identifier Working Group calls resources. An object has a few main traits. First, it has an identifier that gets assigned inside some namespace. That identifier is globally unique and is never reassigned to a different object, so it's globally unique for a long time ✨. Since it has to stay unique for all time, it can't contain location-relevant information ... and that's because locations can and will be reused 🙈. Also, a resource might show up in zero, one, or many locations at once. If the identifier carried location info, one object could end up with a huge pile of identifiers 💀, and then it'd be really hard to tell that two separately retrieved copies are the same object. The locations themselves get defined by the supporting layers that handle transport and access. So the architecture doesn't define locations, but it does accept that they exist 🫶.

Second, an object supports one or more abstract types, and the architecture doesn't go any further than that 🤷. Put those two points together and you get this: an object can't be part of this architected universe without at least one identifier, and if it has at least one location, it also has to support at least one type 💅.

The architecture has a few other pieces too 💜. First, there's a prescribed class of objects called links. A link expresses a relationship between other objects, including what kind of relationship it is. Links are how composite objects, made up of related objects, get created and managed 🍓. Last, there's a need for several kinds of meta-information. Some of it helps you discover identifiers (think indices and searching), and some of it helps you map an identifier to one or more potential locations 🔍. Both kinds are attached to objects, but they get used, and most likely managed, differently, since they have different access and update needs 🌈.

Given this architecture of information objects, you can spot a few boundary points 🚧. First, anything without an identifier or a type is outside the architecture 🙅. Second, the architecture doesn't say anything yet about computation or communication paradigms, except in a second-hand way by just assuming that links will get traversed 🔗. Third, pre-fetching, caching, and replication matter a lot, but they can be hidden from higher-level software components. That means they're normally not part of the data model the application sees, though some applications may want to specify those characteristics 🎯.

Now, how does this model fit into a layered network model, and how might it be modularized and realized? 🧱 They pictured this information layer as a "wholesale" layer 🏬. It provides the general, broad model and the provision of shared, network-based information. Sitting above it are the "retailers," the marketers or providers who bring information to the marketplace of application users 🛍️. Down below the "wholesalers" are the providers of "raw materials," meaning the supporting mechanisms and architecture that information objects can come from 🏭.

The rest of this group's report 📝 breaks the wholesale layer down into modules and covers how those modules interact with each other. It looks at the interactions between the retail and wholesale layers first, and then between the wholesale and raw materials layers. It wraps up with recommendations on where the most effective immediate efforts could go to provide for the wholesale layer and make it useful 🎀.

4.2. The Wholesale Layer 💜

To realize the information architecture in the network, you need a bunch of different classes of services or functionality 🛠️. For each class, there'll be many instances of that service, coordinating with each other to a greater or lesser degree, all within the general Internet model of autonomy and loose federation 🌐. Variants of any service can exist for more specialized or constrained service. Services can also provide more than one of these functions where that's useful. Each service lives in one or more administrative domains, and those domains may restrict or manage it based on their policies 📜. The list of core services is below. Because there are lots of interdependencies, you'll sometimes see forward references, where one service gets described in terms of another that hasn't been explained yet 🔁.

  • RESOURCE DISCOVERY: Most of the resource discovery work (discovery, indexing, and searching) belongs to the retailers 🛍️, though the wholesale layer can provide supporting hooks too. A resource discovery service holds mappings from descriptions to object identifiers, and those mappings need to be queried. So the wholesale layer needs a general function: a service that answers queries formulated in certain ways and responds with identifiers 🔎. On what basis indices get computed, and how they're managed, is domain-specific 🙃.
  • NAMING or IDENTIFICATION: Assigning an identifier to an object has two sides, one in the wholesale layer and one that arguably lives in the retail layer 🪪. In the wholesale layer, you can generate identifiers that are guaranteed to be unique. In the retail layer, you might ask whether two objects are the same or different, according to the rules of an identification authority. That authority then decides whether they get the same identification or different ones 🤔. It's worth noting that the URI Working Group put both of these functions into the requirements document for URNs 📋.

An identification service obviously gives functionality to the uniqueness authority 👑. It also provides identification during the publication of objects (more on that below), in managing resource discovery information, in object location and storage services, and in cache and replication management 🧾.

  • NAME or IDENTIFICATION RESOLUTION: Identifiers are location independent, so you need a resolution service 🗺️. Sometimes that service hands back other identifiers at the same level of abstraction, which are basically aliases. Other times it hands back location information, which goes to a transport service so the object can be accessed or retrieved 🚚.
  • OBJECT RETRIEVAL: Object retrieval is tightly coupled to resolution, since nothing can proceed without it 🔗. Its job is to get a representation of an object provided locally to whoever requested it 📦. That can involve object publication (see below), object storage, caching, and replication services, plus the supporting transport facilities 🚀.
  • OBJECT PUBLICATION: When an object comes into existence in the universe of the information infrastructure, it's said to be "published" 📢. There are two common scenarios. In the first, you use tools to directly enter and create the information that makes up an object, so there may be object creation tools visible to users in applications ✍️.

The second scenario is different. You might use tools that live outside the information infrastructure, like word processing or text editing tools 📝. Those tools let you enter data separately from assigning an object an identifier and making it support the infrastructure's definitions of objects. So the interface between the wholesale and retail layers will also make it possible to cause some pre-existing data to become one or more objects 🪄. On top of interacting with the identification service, publication is likely to interact with object storage, and possibly with caching and replication too 💾.

  • DEFINITIONS: If the information infrastructure is going to both survive and evolve over a long time, we have to be ready for a wide variety of information, and a growing number of different sorts of it, each with different functionality 🧩. For objects on the net, the functionality each one provides must be exposed or able to be learned. So objects need to be able to indicate, by name or identifier, which types of functionality they support 🏷️. Given that identifier, an object is only useful to a client if the client can discover the definition of that type, and perhaps a useful implementation of it 🔍. That gets acquired from a definitions service, which is used together with applications themselves, object publication, and object retrieval 💡.
  • ATTRIBUTE MANAGEMENT: The attributes here relate to policy, though any real understanding of that policy sits above the wholesale level 🛡️. Examples include access management and copyright attributes 🎨. There's an open question about whether access-time enforcement exists or should exist, or whether enforcement happens only after the fact ⏳. The information is likely to take the form of attribute-value pairs, and it must be able to capture copyright knowledge effectively 📚.
  • ACCOUNTING: An accounting service provides metering of how resources get used 🧮. The resources that are wholly contained in the wholesale layer are the services we've been talking about. It's also important to provide metering tools in the wholesale layer, so the retail layer can meter usage or content access over there 📊. Metering can serve all kinds of purposes, from getting better utilization or service out of the resources all the way to pricing and billing 💸. Because of that, object storage, caching and replication, lower-layer networking services, and pricing and billing services will all use accounting services 🤝. When it comes to content metering, accounting also interacts with attribute management 🧾.
  • PRICING, BILLING and PAYMENT: Pricing and payment services straddle two layers of the information infrastructure 🌉. The servers that maintain account balances, and that users interact with to retrieve and edit account information, are applications built on top of wholesale layer services 🏦. Pricing gets determined in the applications environment for application-level activities 🏷️. However, middle layer services still need to be able to process payment instruments that work like cash, credit card slips, and checks, without understanding the specific implementation of the payment mechanism 💳. Application programming interfaces supporting payment should be provided 🛠️, and a common tagged representation of payment instruments should let instruments from a variety of payment systems be presented within middle layer protocols 🎫.

OBJECT STORAGE, CACHING and REPLICATION 📦 caching and replication matter a lot, but another group had them as their main focus, so this group left that discussion to them 🙈 Object storage takes an object, puts it somewhere, and keeps both its identity and its nature intact ✨ It's super tightly coupled to caching, replication, and accounting (accounting helps figure out the patterns of caching and replication). It's also tied to object publication and translation, and it gives interfaces to storage underneath, like local file systems, plus direct access for apps that need objects 💅

  • TRANSLATION 🦋 A translation service lets an object act like something other than what it normally supports. For example, it could give a WYSIWYG interface to an object that otherwise wouldn't have one, or generate text on the fly from an audio stream. Object publication uses translation so an object can be identified along with a translation of it, and object storage uses it too, but only to provide an interface within the wholesale layer or to the retail layers.
  • SERVER AND SERVICE LOCATION 🔍 The infrastructure needs a way to find these kinds of services and the servers that support them. This one talks directly to the raw materials layer, since in the end it provides the addresses needed to actually locate objects and services using lower-level protocols like FTP, SMTP, HTTP, or TCP. It feeds straight into resource discovery and remote object storage services.
  • ADAPTIVE GLUE 🌊 This isn't really one service, more a recognition that information has to be able to flow between the network layers and the applications. An app can have constraints based on its own needs and on the needs of objects in the wholesale layer, and only the app can really know which compromises in the services below are okay for it. Meanwhile the network layers know which qualities of service are available and what they cost. So information can flow both up and down, maybe mediated by the wholesale layer, which means adaptive glue has hooks into all three levels.
  • SECURITY 🔐 Security services are a critical piece of the infrastructure architecture, bestie. For any real business to happen, organizations have to make their info available over the network, but they also need to control access on a per user and per object basis. To account properly for the use of higher-level services, organizations must be able to identify and authenticate their users accurately. And payment services must be built on security so there are no fraudulent charges or leaks of compromising information.

The two biggest problems with security services at the wholesale layer are poor infrastructure and multiple security mechanisms that each have to be integrated with applications one by one 😤 The infrastructure is poor because there's no accepted certification hierarchy for authentication. A commonly held view is that there won't be a single hierarchy, but there must be established authorities whose assertions are widely accepted, and who indirectly certify the identities of people you've never had prior contact with 🫶

Integrating with apps is hard because, even though security services are layered on top of each other, they don't fit into the information architecture at a single layer. If you integrate security with the lower layers of the information infrastructure, you can provide security to higher layers, but some security information, like a client's identity, may be needed higher up, so that support won't be completely transparent. Also, the security requirements of each middle-layer information service, and of the application itself, must be considered, and appropriate use must be made of the middle-layer security services that get applied.

Integration with apps will take user demand for security, along with common interfaces like the GSS-API, so that applications and middle-layer information services can use whatever security services are available without needing to understand the details of the specific security mechanism being used 💜

  • BOOTSTRAPPING 🥾 A newly participating machine needs some way to find out about at least one instance of many of the services described here. That can happen either through some configuration provided by the human bringing it up, or through a bootstrapping service. The bootstrapping service is more flexible and manageable, and it's included here because this info has to be provided somehow or other. It sits directly on the raw materials layer and has contact with all of the services described here.

This completes the description of the services that this group identified in the wholesale layer. This section suggests which services have interfaces to the retail and raw materials layers, but each of those topics will also need its own separate description, so the functionality expected by each layer from the layer below is clear 🌸

3. Interface to retail layer 🛍️

The interface to the retail layer is where the object model and its attendant services come to life 💖 It gives the application environment a collection of objects, each with identifiers that tell them apart within the wholesale layer, plus support for a typing or abstract functionality model. It lets you create or import objects into this object world through the publication paradigm, and lets objects evolve to support new or changing functionality through the translation paradigm. Access to objects is provided by object storage, boosted with caching and replication services, and controlled by the attributes managed by attribute management and accounting or content metering. Resource discovery services handle figuring out which identifier to be chasing. Types are registered, so they're available as definitions and maybe as implementations from a definition service. Lastly, there's a vertical model that offers two-way adaptive glue services for quality of service negotiation and for security constraints and requirements, with access and services at all three layers ✨

4. Interface to the raw materials layer 🧱

The raw materials layer covers networking and operating systems, so it provides all the services that current networking and operating systems offer today 🖥️ Wholesale services like object management will depend on local operating system support, like a file system, and maybe on transport protocols too. In fact, every instance of any of the above services will depend on local storage, process management, local access control, and other security mechanisms, as well as general transport protocols for communication. That communication is often among services of the same sort, and also among services that depend on each other but might not be in the same place. On top of that, the group identified a set of issues that seem important for the networking parts of the raw materials layer to provide to the wholesale layer, beyond the basic best-effort transmission that's commonly available. Think of it as a wish list, with the understanding that they aren't all equally easy or possible 🧞

  • Connectivity 📡 It's useful and important for apps and wholesale services to know what connectivity is currently available. The group identified four categories of connectivity to know about, which come down to four questions:
    1. Is there a wire out of the back of my machine?
    2. Am I connected to a router?
    3. Am I connected to the global internet? (Can I get beyond my own domain?)
    4. Am I connected to a specific host?

These are probably in increasing order of difficulty to know.

  • Connectivity forecast 🔮 This is recognized as either extremely difficult or impossible to do, but some form of connectivity forecast would be super useful to the upper layers.
  • Bandwidth availability and reservation 🚰 It's useful for an app to know what bandwidth might be available to it and, even better, to be able to make some form of reservation.
  • Latency availability and reservation ⏱️ It's useful for an app to know what latency the network is experiencing and, even better, to be able to set limits on it through a reservation.
  • Reliability availability and reservation 🛡️ Reliability constraints matter for lots of apps, though they may have different reliability constraints and may adapt differently to different circumstances. But if an app could make a statement (a reservation) about what level of unreliability it can tolerate, it might be able to make tradeoffs.
  • Burstiness support 💥 It's unlikely the network can predict the burstiness of its services. But if an app can predict its own burstiness behavior to the network, the network might be able to take advantage of that knowledge.
  • Service envelope 👛 As an alternative to the four issues above, the raw materials layer could negotiate a whole service envelope with the layers it supports.
  • Security availability 🔒 In many cases, it'll be important for upper layers to know what sorts and levels of security are available from the raw materials layer. That's true for operating system support as well as for transmission.
  • Cost 💸 If usage charging happens at anything other than fixed flat rates, it'll be important for apps and users to understand what those costs are, or at least estimates of them.
  • Policy routing 🗺️ If transport services are going to support policy routing, it'll be important for users of those services to identify which policy classes they might fall into.

4.5. Recommendations 🏆

This group came up with two categories of recommendations 💅 The first is services in the wholesale layer that will be especially useful and readily achieved, because work on them is soon to be underway or already is. The second set is a three-item rank ordering of the services that are most important for the lower layer to provide to the wholesale layer.

Within the wholesale layer, the first services that should be provided are:

  • Object retrieval,
  • Name resolution,
  • Caching and replication.

In addition, the group rank ordered three areas where there would be a quick payoff if the raw materials layer could provide them. They are:

  1. Connectivity
  2. Bandwidth, latency, and reliability or service envelope
  3. Security constraints on communication and transactions

5. Group 2B Report: Components of an Internet Information Architecture ✨

Cecilia Preston, Chris Weider, Christian Huitema, Cliff Lynch, John Romkey, Joyce Reynolds, Larry Masinter, Mitra, Jill Foster 🫶

Group 2B was basically the group chat for the Internet Information Infrastructure 🦋. They talked through a bunch of problems, thought about recommendations they could send to the IESG so it could focus on certain areas, and also looked at the philosophy and economics behind some of the problems. Economics can actually dictate some architecture choices 💅. You can see why a publisher would bear the cost of publishing, or a consumer would bear the cost of consuming, but it's not clear how some free-floating third party would just cover the costs of services (like third-party translators) 💀.

The group discussed the following topics:

  • access(URL)
  • gateways
  • URN resolution
  • definitions
  • updates
  • service location
  • cache & replication
  • security & authentication
  • payments, charging
  • presentation
  • search & index
  • metainformation
  • boot service
  • general computation

5.1 URNs

There are a bunch of issues with Uniform Resource Names and Uniform Resource Locators 🌸. URN resolution is basically a database lookup that hands back the URLs linked to a URN. The architecture has to think about not just how the lookup works, but also how that database gets maintained 🧚. The lookup problem and the update problem both have to be solved at the same time, or URNs can't really get deployed 😭.

Humans have at least two problems with unique names 🙈. First, the idea of a unique name is a fallacy 💀. Unique naming cannot be enforced. Names can get forged or accidentally duplicated because, well, humans. The architecture has to accept that and still work anyway. Designing for global uniqueness, but not requiring it, was adequate. Errors from names not being unique are probably tiny compared to other errors 🎀.

Also, people often make assertions and assumptions about names instead of the documents being named 👀. Making assertions about names is working at the wrong level of indirection. Making assumptions about names, like figuring out what's inside the named object from the syntax of the name, can lead to nasty surprises 😬.

Having a single, unified naming system is vital 👑. It's healthy to have multiple competing forms of other aspects of the information architecture, but the naming system is what ties it all together. There must be only one naming system. If there's more than one, it may not be possible to compare names or look up locations based on names, and we'll keep (to our detriment) using locators instead of names 😤.

5.2 Global Service Location

The IANA has become the central switch point for service identification. and recommended that numbers that are formally defined and kept in documents for use in distributed information systems (for instance, Assigned Numbers) should also be distributed online in some kind of database for use by applications 🦋. This distribution requires both an access method (perhaps multiple access methods) and an update method 🌈.

5.3 Security

Security came up over and over again 🔐. It includes things like validation of authority, confidentiality, integrity of data, integrity of services, and access control. The group agreed that confidentiality is important (even though it's often overlooked), and, even more strongly, anonymity is important ✨. You should be able to access documents or objects without the architecture making you leave digital fingerprints all over the place 🕵️‍♀️.

Security must occur on an end-to-end basis 🫶. Documents or objects used on the Internet may not only traverse the Internet. Relying on security mechanisms in the underlying protocol suite does not necessarily provide end-to-end authentication or confidentiality 🙅‍♀️.

Lower layer security is ill-defined and widely unimplemented 💀. Designers building information applications on top of the Internet get little guidance on putting security features into their apps, which leads to weak ad hoc or nonexistent security in new applications 😭. Designers are also unclear on how to deal with the "security considerations" section that's mandatory in RFCs, so they often fill it with boilerplate text 🙄.

Retrofitting security into existing architectures does not work well 🔥. The best systems are built with security in mind from the very beginning. Some systems being designed have no place for a digital signature to authenticate the data they pass. These issues apply to data management as well 🧚.

The group makes the following recommendations to the IESG regarding security 💖:

  • A. Develop and communicate a security model usable by designers of information applications. Current models are not considered usable 🙈.
  • B. RFC authors should be given advice on what security considerations need to be outlined and how to write them. The IESG security area should prepare guidelines for writing security considerations 📝.
  • C. Proposed Standards should not be accepted by the IESG unless they really consider security. This will require that recommendations A and B have been implemented and that the guidelines have received enough visibility to reasonably expect authors to know of their existence 🔒.
  • D. Develop security modules usable by the implementors of information clients and servers, reusable across many different, heterogeneous applications and platforms 🧩.
  • E. Make clear what security services you can expect from the lower layers 👀.
  • F. Make sure that the key distribution infrastructure is reviewed for usability by information applications 🔑.

5.4 Search and Index

Searching is looking through directories that point to information. Indexing is scanning information to create directories. A "unified directory" is the result of combining several indices 📚.

Indexing is currently done on the Internet via many mechanisms 🍓. Given the current ad hoc nature of indexing, information is frequently indexed multiple times. That's wasteful, but because of the current economics of the Internet, it tends not to cost more money. If the Internet (or parts of it) transitions to usage-based charging, it may cost the information provider too much to allow the information to be indexed. In general, the provider should have control over how the information they control is indexed 👑.

Above all, the architecture should not encourage a situation where information is normally not indexed. It should encourage the collection of indexing data only a single time. Having a local computation of a summary sent to a search/index server is vastly preferable to having that server "walk the net" to discover information to index 🧚.

Indexing and search techniques are quite varied 🌈. It's quite likely that index and search are too close to general computation to try to standardize on a single protocol for either. Instead, it's important that the architecture allow multiple search techniques. There are currently certain types of indices that can only be generated by humans because of their level of semantic content. There are big differences in the quality and usability of machine-generated indices vs. human-generated ones 🤓.

Unified directories tend to combine indexing results from quite different techniques 💜. The architecture should constrain indexing so that it remains possible to merge the results of two searches done by different protocols or indexing systems. Returning information in standard formats such as URNs can help this problem ✨.

Vocabulary issues in search and index are very difficult 🙈. The library and information services communities don't necessarily use vocabulary that's consistent with the IETF community, which can lead to difficult misunderstandings.

"Searching the Internet" is an inappropriate attempt to categorize the information you're attempting to search 🙅‍♀️. Instead, we search certain public spaces on the Internet. The concept of public space vs. private space on the Internet deserves further investigation 🔍.

Indexing can run afoul of access control considerations 🚫. Access control must be done at the object, but access control information should be propagated through indices as well. The index should be able to say "you're not allowed to ask that," rather than the user attempting to retrieve the object and being denied 😭.

An architectural point was raised that an index query should return the same result independent of who is asking. This is an important notion in the Domain Name System. It's inconsistent with some real-world indexing (for instance, corporate record management systems) which doesn't want to admit that some documents exist if you're not allowed to read them 🤫.

5.5 Miscellaneous

Electronic mail, netnews, FTP and the web are frequently used to access information on the net today. Each protocol seems to provide a consistent view of the information on the Internet 👀. In addition, the recent popularity of multi-protocol clients such as Mosaic seems to imply that the information content of the Internet is uniformly retrievable and manageable. This perception is misleading because most protocols are used for applications other than the ones they were originally designed for 💀. Telnet, which has no concept of information retrieval and management, is often used to access information too, for example in DIALOG and card file accesses 📇. Since each protocol has different access and management capabilities, the inconsistencies show up as erratic search and retrieval results, puzzling error messages, and a basic lack of standard techniques for dealing with information 🌪️. A consistent underlying information architecture will go a long way towards alleviating these problems 💖.

As the information architecture develops, we should reconsider the electronic mail and netnews architecture in terms of the new architecture 📬.

The group noted that there have been difficulties in scheduling joint working group meetings, and recommends that there be a clearly defined process inside the IETF to facilitate scheduling such meetings 🗓️.

6. Conclusions and Recommendations ✨

okay so the workshop gave everyone a chance to keep chatting about the architecture 🫶 and it made room for some focused deep dives on specific issues. it also brought in some brand new voices and experience from other corners of Internet growth to jump into the architecture process. main character energy 👑

part of the workshop wrap-up is a set of recommendations for the IESG and the IETF community 🎀

Recommendations on research/implementation directions:

  1. caching and replication are important and overlooked pieces of Internet middleware, ngl they deserve way more love 💖 we should do something about it asap, maybe by defining an architecture and service model for common implementation.
  2. within the 'wholesale' layer (the one that gives a consistent view of the information resources available on the Internet), the first services that should be provided are:
    • Object retrieval,
    • Name resolution,
    • Caching and replication.
  3. there would be a quick payoff if the raw materials layer (the layer where information resources actually get physically transmitted to computers) could provide the following services:
    • Connectivity
    • Bandwidth, latency, and reliability or a service envelope
    • Security constraints on communication and transactions
  4. develop security modules usable by the implementors of information clients and servers 🔐 reusable across many different, heterogeneous applications and platforms, periodt 💅

Recommendations to the IESG, IETF, and IANA

  1. numbers that are formally defined and kept in documents in distributed information systems (for instance, Assigned Numbers) should be available in some kind of database for use by applications 🧚
  2. develop and communicate a security model usable by designers of information applications. current models are not considered usable or are not widely accepted on the Internet 😭
  3. RFC authors should be given advice on how security considerations need to be written. the IESG security area should prepare guidelines for writing security considerations 📝
  4. Proposed Standards should not be accepted by the IESG unless they really consider security. this will require recommendations 2 and 3 to be implemented first 🙈
  5. make clear what security services you can expect from the lower layers 🫶
  6. make sure that the key distribution infrastructure is reviewed for usability by information applications 🔑
  7. there needs to be a process inside the IETF for scheduling a joint meeting between two working groups, for example so that the key distribution WG can meet jointly with IIIR 🦋

APPENDIX A - Workshop Organization 🎀

the workshop was held at MCI's facility in Tyson Corners, Virginia. the organizers and attendees really want to thank MCI for letting them use their facilities to host the workshop 🥰

all attendees met in joint session for the first half of October 12. then they split into three groups. the first group considered the "distributed database" problem, which has arisen over and over again in the design of parts of the Internet. the two other groups met to consider a list of issues pertaining to the information infrastructure. the groups ran independently until the morning of October 14, when they met again in joint session 🌸

the following people attended the workshop:

Abel Weinrib            abel@bellcore.com

Barry Leiner            BLeiner@ARPA.MIL

Cecilia Preston         cpreston@info.berkeley.edu

Chris Weider            clw@bunyip.com

Christian Huitema       Christian.Huitema@SOPHIA.INRIA.FR

Cliff Lynch             calur@uccmvsa.ucop.edu

Clifford Neuman         bcn@isi.edu

Dan LaLiberte           liberte@ncsa.uiuc.edu

Dave Sincoskie          sincos@THUMPER.BELLCORE.COM

Elise Gerich            epg@MERIT.EDU

Erik Huizer             Erik.Huizer@SURFnet.nl

Jill Foster             Jill.Foster@newcastle.ac.uk

John Curran             jcurran@near.net

John Klensin            klensin@infoods.mit.edu

John Romkey             romkey@asylum.sf.ca.us

Joyce Reynolds          jkrey@isi.edu
Karen Sollins           sollins@lcs.mit.edu

Larry Masinter          masinter@parc.xerox.com

Lixia Zhang             LIXIA@PARC.XEROX.COM

Mark McCahill           mpm@boombox.micro.umn.edu

Michael Mealling        Michael.Mealling@oit.gatech.edu

Mitchell Charity        mcharity@lcs.mit.edu

Mike Schwartz           schwartz@cs.colorado.edu

Mike St. Johns          stjohns@DARPA.MIL

Mitra                   mitra@pandora.sf.ca.us

Paul Mockapetris        pvm@zephyr.isi.edu

Steve Crocker           Crocker@TIS.COM

Tim Berners-Lee         tbl@info.cern.ch

Ton Verschuren          Ton.Verschuren@surfnet.nl

Yakov Rekhter           yakov@WATSON.IBM.COM

Security Considerations 🔐

this one is SUPER important bestie 💀 this memo talks about certain aspects of security and the information infrastructure. it has general recommendations about security enhancements required by information applications on the Internet.

Authors' Addresses 🦋

here's who wrote it, bestie 🫶

Mark McCahill
University of Minnesota
room 190 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
EMail: mpm@boombox.micro.umn.edu


John Romkey [Editor]
1770 Massachusetts Ave. #331
Cambridge, MA  02140
EMail: romkey@apocalypse.org


Michael F.  Schwartz
Department of Computer Science
University of Colorado
Boulder, CO 80309-0430
EMail: schwartz@cs.colorado.edu


Karen Sollins
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139-1986
EMail: sollins@lcs.mit.edu


Ton Verschuren
SURFNet
P.O. Box 19035
3501 DA Utrecht
The Netherlands
EMail: Ton.Verschuren@surfnet.nl


Chris Weider
Bunyip Information Systems
310 St. Catherine St. West
Suite 300
Montreal, PQ H2A 2X1
CANADA
EMail: clw@bunyip.com

and that's a wrap, the end 🌈💖

📦 where this page comes from