RFC1862 日本語訳
1862 Report of the IAB Workshop on Internet InformationInfrastructure, October 12-14, 1994. M. McCahill, J. Romkey, M.Schwartz, K. Sollins, T. Verschuren, C. Weider. November 1995. (Format: TXT=62483 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. McCahill
Request For Comments: 1862 University of Minnesota
Category: Informational J. Romkey, Editor
M. Schwartz
University of Colorado
K. Sollins
MIT
T. Verschuren
SURFnet
C. Weider
Bunyip Information Systems, Inc.
November 1995
Network Working Group M. McCahill Request For Comments: 1862 University of Minnesota Category: Informational J. Romkey, Editor M. Schwartz University of Colorado K. Sollins MIT T. Verschuren SURFnet C. Weider Bunyip Information Systems, Inc. November 1995
Report of the IAB Workshop on Internet Information Infrastructure,
October 12-14, 1994
Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994
Status of this Memo
Status of this Memo
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Abstract
Abstract
This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994. This workshop generally focused on aspects of the information infrastructure on the Internet.
This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994. This workshop generally focused on aspects of the information infrastructure on the Internet.
1. Introduction
1. Introduction
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF), under the leadership of the Internet Engineering Steering Group (IESG) and area directorates.
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF), under the leadership of the Internet Engineering Steering Group (IESG) and area directorates.
An IAB-initiated workshop on the architecture of the "information infrastructure" of the Internet was held on October 12-14, 1994 at MCI in Tysons Corner, Virginia.
An IAB-initiated workshop on the architecture of the "information infrastructure" of the Internet was held on October 12-14, 1994 at MCI in Tysons Corner, Virginia.
In addition to the IAB members, attendees at this meeting included the IESG Area Directors for the relevant areas (Applications, User Services) and a group of other experts in the following areas:
In addition to the IAB members, attendees at this meeting included the IESG Area Directors for the relevant areas (Applications, User Services) and a group of other experts in the following areas:
McCahill, et al Informational [Page 1] RFC 1862 IAB Workshop Report November 1995
McCahill, et al Informational [Page 1] RFC 1862 IAB Workshop Report November 1995
gopher, the World Wide Web, naming, WAIS, searching, indexing, and library services. The IAB explicitly tried to balance the number of attendees from each area of expertise. Logistics limited the attendance to about 35, which unfortunately meant that many highly qualified experts were omitted from the invitation list.
gopher, the World Wide Web, naming, WAIS, searching, indexing, and library services. The IAB explicitly tried to balance the number of attendees from each area of expertise. Logistics limited the attendance to about 35, which unfortunately meant that many highly qualified experts were omitted from the invitation list.
The objectives of the workshop were to explore the architecture of "information" applications on the Internet, to provide the IESG with a solid set of recommendations for further work, and to provide a place for communication between the communities of people associated with the lower and upper layers of the Internet protocol suite, as well as allow experience to be exchanged between the communities.
The objectives of the workshop were to explore the architecture of "information" applications on the Internet, to provide the IESG with a solid set of recommendations for further work, and to provide a place for communication between the communities of people associated with the lower and upper layers of the Internet protocol suite, as well as allow experience to be exchanged between the communities.
The 34 attendees divided into three "breakout groups" which met for the second half of the first day and the entire second day. Each group wrote a report of its activities. The reports are contained in this document, in addition to a set of specific recommendations to the IESG and IETF community.
The 34 attendees divided into three "breakout groups" which met for the second half of the first day and the entire second day. Each group wrote a report of its activities. The reports are contained in this document, in addition to a set of specific recommendations to the IESG and IETF community.
2. Summary
2. Summary
Although there were some disagreements between the groups on specific functionalities for architectural components, there was broad agreement on the general shape of an information architecture and on general principles for constructing the architecture. The discussions of the architecture generalized a number of concepts that are currently used in deployed systems such as the World Wide Web, but the main thrust was to define general architectural components rather than focus on current technologies.
Although there were some disagreements between the groups on specific functionalities for architectural components, there was broad agreement on the general shape of an information architecture and on general principles for constructing the architecture. The discussions of the architecture generalized a number of concepts that are currently used in deployed systems such as the World Wide Web, but the main thrust was to define general architectural components rather than focus on current technologies.
Research recommendations include:
Research recommendations include:
- increased focus on a general caching and replication architecture
- increased focus on a general caching and replication architecture
- a rapid deployment of name resolution services, and
- a rapid deployment of name resolution services, and
- the articulation of a common security architecture for information
applications.
- the articulation of a common security architecture for information applications.
Procedural recommendations for forwarding this work in the IETF include:
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
- making common identifiers such as the IANA assigned numbers available in an on-line database
- tightening the requirements on Proposed Standards to insure that
they adequately address security
- tightening the requirements on Proposed Standards to insure that they adequately address security
McCahill, et al Informational [Page 2] RFC 1862 IAB Workshop Report November 1995
McCahill, et al Informational [Page 2] RFC 1862 IAB Workshop Report November 1995
- articulating the procedures necessary to facilitate joining IETF
working group meetings, and
- articulating the procedures necessary to facilitate joining IETF working group meetings, and
- reviewing the key distribution infrastructure for use in
information applications
- reviewing the key distribution infrastructure for use in information applications
3. Group 1 report: The Distributed Database Problem
3. Group 1 report: The Distributed Database Problem
Elise Gerich, Tim Berners-Lee, Mark McCahill, Dave Sincoskie, Mike Schwartz, Mitra, Yakov Rekhter, John Klensin, Steve Crocker, Ton Verschuren
Elise Gerich, Tim Berners-Lee, Mark McCahill, Dave Sincoskie, Mike Schwartz, Mitra, Yakov Rekhter, John Klensin, Steve Crocker, Ton Verschuren
Editors: Mark McCahill, Mike Schwartz, Ton Verschuren
Editors: Mark McCahill, Mike Schwartz, Ton Verschuren
3.1 Problem and Needs
3.1 Problem and Needs
Because of the increasing popularity of accessing networked information, current Internet information services are experiencing performance, reliability, and scaling problems. These are general problems, given the distributed nature of the Internet. Current and future applications would benefit from much more widespread use of caching and replication.
Because of the increasing popularity of accessing networked information, current Internet information services are experiencing performance, reliability, and scaling problems. These are general problems, given the distributed nature of the Internet. Current and future applications would benefit from much more widespread use of caching and replication.
For instance, popular WWW and Gopher servers experience serious overloading, as many thousands of users per day attempt to access them simultaneously. Neither of these systems was designed with explicit caching or replication support in the core protocol. Moreover, because the DNS is currently the only widely deployed distributed and replicated data storage system in the Internet, it is often used to help support more scalable operation in this environment -- for example, storing service-specific pointer information, or providing a means of rotating service accesses among replicated copies of NCSA's extremely popular WWW server. In most cases, such uses of the DNS semantically overload the system. The DNS may not be able to stand such "semantic extensions" and continue to perform well. It was not designed to be a general-purpose replicated distributed database system.
For instance, popular WWW and Gopher servers experience serious overloading, as many thousands of users per day attempt to access them simultaneously. Neither of these systems was designed with explicit caching or replication support in the core protocol. Moreover, because the DNS is currently the only widely deployed distributed and replicated data storage system in the Internet, it is often used to help support more scalable operation in this environment -- for example, storing service-specific pointer information, or providing a means of rotating service accesses among replicated copies of NCSA's extremely popular WWW server. In most cases, such uses of the DNS semantically overload the system. The DNS may not be able to stand such "semantic extensions" and continue to perform well. It was not designed to be a general-purpose replicated distributed database system.
There are many examples of systems that need or would benefit from caching or replication. Examples include key distribution for authentication services, DHCP, multicast SD, and Internet white pages.
There are many examples of systems that need or would benefit from caching or replication. Examples include key distribution for authentication services, DHCP, multicast SD, and Internet white pages.
To date there have been a number of independent attempts to provide caching and replication facilities. The question we address here is whether it might be possible to define a general service interface or protocol, so that caches and replica servers (implemented in a variety of ways to support a range of different situations) might
To date there have been a number of independent attempts to provide caching and replication facilities. The question we address here is whether it might be possible to define a general service interface or protocol, so that caches and replica servers (implemented in a variety of ways to support a range of different situations) might
McCahill, et al Informational [Page 3] RFC 1862 IAB Workshop Report November 1995
McCahill, et al Informational [Page 3] RFC 1862 IAB Workshop Report November 1995
interoperate, and so that we might reduce the amount of wasted re- implementation effort currently being expended. Replication and caching schemes could form a sort of network "middleware" to fulfill a common need of distributed services.
interoperate, and so that we might reduce the amount of wasted re- implementation effort currently being expended. Replication and caching schemes could form a sort of network "middleware" to fulfill a common need of distributed services.
It should be noted that it is an open question whether it would be feasible to define a unified interface to all caching and replication problems. For example, very different considerations must go into providing a system to support a nationwide video service for 1,000,000 concurrent users than would be needed for supporting worldwide accesses to popular WWW pages. We recommend research and experimentation to address this more general issue.
It should be noted that it is an open question whether it would be feasible to define a unified interface to all caching and replication problems. For example, very different considerations must go into providing a system to support a nationwide video service for 1,000,000 concurrent users than would be needed for supporting worldwide accesses to popular WWW pages. We recommend research and experimentation to address this more general issue.
3.2 Characteristics of Solutions
3.2 Characteristics of Solutions
While on the surface caching and replication may appear to occupy two ends of a spectrum, further analysis shows that these are two different approaches with different characteristics. There are cases where a combination of the two techniques is the optimal solution, which further complicates the situation.
While on the surface caching and replication may appear to occupy two ends of a spectrum, further analysis shows that these are two different approaches with different characteristics. There are cases where a combination of the two techniques is the optimal solution, which further complicates the situation.
We can roughly characterize the two approaches as follows:
We can roughly characterize the two approaches as follows:
Caching:
Caching:
- a cache contains a partial set of data
- a cache contains a partial set of data
- a cache is built on demand
- a cache is built on demand
- a cache is audience-specific, since the cache is built in
response to demands of a community
- a cache is audience-specific, since the cache is built in response to demands of a community
Replication:
Replication:
- replicated databases contain the entire data set or a
server-defined subset of a given database
- 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
- 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
- data is pushed onto the replicating server rather than pulled on demand
While there are important differences between caches and replicated databases, there are some issues common to both, especially when considering how updates and data consistency can be handled.
While there are important differences between caches and replicated databases, there are some issues common to both, especially when considering how updates and data consistency can be handled.
McCahill, et al Informational [Page 4] RFC 1862 IAB Workshop Report November 1995
McCahill, et al Informational [Page 4] RFC 1862 IAB Workshop Report November 1995
A variety of methods can be used to update caches and replicas:
A variety of methods can be used to update caches and replicas:
- master-slave
- master-slave
- peer-to-peer
- peer-to-peer
- flooding techniques (such as that used by NNTP).
- flooding techniques (such as that used by NNTP).
Which strategy one chooses influences important characteristics of the cache or replicated database, such as:
Which strategy one chooses influences important characteristics of the cache or replicated database, such as:
- consistency of data
- consistency of data
- is locking used to achieve consistency? this influences
performance...
- 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?)
- 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), and there are cases where it is acceptable to trade consistency for better performance or availability. Since there is a range of qualities of service with respect to consistency and performance, we would like 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 is unlikely one can implement a high performance solution to all of these problems in a single system.
Consistency guarantees depend on the granularity of synchronization (ms, sec, hr, day), and there are cases where it is acceptable to trade consistency for better performance or availability. Since there is a range of qualities of service with respect to consistency and performance, we would like 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 is unlikely one can implement a high performance solution to all of these problems in a single system.
Beyond simply performing replication or caching, there is a need for managing cache and replication servers. There are several models for organizing groups of caches/replication servers that range from totally adaptive to a rigidly administered, centrally controlled model:
Beyond simply performing replication or caching, there is a need for managing cache and replication servers. There are several models for organizing groups of caches/replication servers that range 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, available
network bandwidth.
- a club model. Minimal administrative overhead to join the club. Participation is a function of disk space, CPU, 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.
- 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
- hybrid combinations of the club and centrally coordinated models
McCahill, et al Informational [Page 5] RFC 1862 IAB Workshop Report November 1995
McCahill, et al Informational [Page 5] RFC 1862 IAB Workshop Report November 1995
There are a couple of models for how to organize the management of a group of cooperating servers, but this does not address the question of 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:
There are a couple of models for how to organize the management of a group of cooperating servers, but this does not address the question of 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.
- 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 will not be able to
get the information again for an indeterminate amount of time.
- flushing the cache. There are circumstances where the information source has become inaccessible and the normal cache aging strategy is inappropriate since you will not 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.
- 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 needed, a common protocol would allow for simplified management of a collection of caching and replicating servers since you would be able to both control them with a single set of commands and query them about their capabilities. A common language/protocol would also allow different implementations to interoperate.
Given a common set of management controls needed, a common protocol would allow for simplified management of a collection of caching and replicating servers since you would be able to both control them with a single set of commands and query them about their capabilities. A common language/protocol would also allow different implementations to interoperate.
Replicating or caching information immediately raises issues of billing, access control and authentication. Ignoring authentication and access control issues 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 issue. 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 issues regarding intellectual property in this scenario.
Replicating or caching information immediately raises issues of billing, access control and authentication. Ignoring authentication and access control issues 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 issue. 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 issues regarding intellectual property 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/replication servers directs the users to the closest server. In the more general case, there are several replicated/cached copies of an object, so you may receive several URLs when you resolve a URN. How do you select the best URL?
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/replication servers directs the users to the closest server. In the more general case, there are several replicated/cached copies of an object, so you may receive several URLs when you resolve a URN. 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
Either client developers create ad hoc performance metrics or (in an ideal world) the lower level protocols would give the client
McCahill, et al Informational [Page 6] RFC 1862 IAB Workshop Report November 1995
McCahill, et al Informational [Page 6] RFC 1862 IAB Workshop Report November 1995
application some guidance about the "closest" copy of the object. In other words, if better information about network performance was available from lower levels of the protocol stack, applications would not have to build ad hoc models of network topology
application some guidance about the "closest" copy of the object. In other words, if better information about network performance was available from lower levels of the protocol stack, applications would not have to build ad hoc models of network topology
We did not model the functions of a cache/replication server in detail, but we did an (incomplete) model of some of the functions (see Figure 1). The idea here was to start work on a general form which might include features such as a push function for use in both maintaining consistency and in preloading information that the information publisher believes will be requested in the near future.
We did not model the functions of a cache/replication server in detail, but we did an (incomplete) model of some of the functions (see Figure 1). The idea here was to start work on a general form which might include features such as a push function for use in both maintaining consistency and in 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 the use patterns of its community. The distributed nature of links to other servers also limit the knowledge of a single information publisher. In any case, being able to accurately predict usage patterns can result in significant performance enhancements for caches.
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 the use patterns of its community. The distributed nature of links to other servers also limit the knowledge of a single information publisher. In any case, being able to accurately predict usage patterns can result in significant performance enhancements for caches.
Figure 1: a rough cut at functions
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)
requests from client (in) | | | \|/ +---------------------+ | | (management) | cache/replicated db |<--- commands from admins, | | publishers, caches +---------------------+ | | | \|/ requests sent to information providers (out)
in: (requests from a client)
in: (requests from a client)
- give me meta-info about cached object (how up-to-date,
ttl, expiry, signatures/checksum, billing information )
- give me meta-info about cached object (how up-to-date, ttl, expiry, signatures/checksum, billing information )
- give me the object
- give me the object
- go get the object from the net
- go get the object from the net
McCahill, et al Informational [Page 7] RFC 1862 IAB Workshop Report November 1995
McCahill, et al Informational [Page 7] RFC 1862 IAB Workshop Report November 1995
- cache, what objects should I pre-fetch?
(this assumes that the client software believes that the
cache/replica has some knowledge of use patterns and can
predict what the user will do next)
- cache, what objects should I pre-fetch? (this assumes that the client software believes that 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)
out: (requests sent to an information publisher or a cache further up the food chain)
- server, do I have latest copy of this object?
- server, do I have latest copy of this object?
- give me object x and the meta data for object x
- 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)
- 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)
- 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)
management: (commands from administrators, other cooperating caches, and object publishers)
- turn parameters (e.g. consistency) on/off
- turn parameters (e.g. consistency) on/off
- flush the cache
- flush the cache
- there's a new version of object x, take it
- there's a new version of object x, take it
3.3 Recommendations
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 do not believe any single implementation can suffice for the broad range of needs in 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.
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 do not believe any single implementation can suffice for the broad range of needs in 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.
McCahill, et al Informational [Page 8] RFC 1862 IAB Workshop Report November 1995
McCahill, et al Informational [Page 8] RFC 1862 IAB Workshop Report November 1995
4. Group 2A report: Building an Information Architecture
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
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 layers on which it would sit and the layers that would sit on it. In order to describe an architecture, one must describe not only what it includes, but also what it excludes.
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 layers on which it would sit and the layers that would sit on it. In order to describe an architecture, one must describe not only what it includes, but also what it excludes.
4.1. The core model and service structure
4.1. The core model and service structure
The general architecture has as its centerpiece objects, or as they are known in the Uniform Resource Identifier Working Group, resources. An object in this architecture has several characteristics. First, it has an identifier, assigned within the context of some namespace. Such an identifier is globally unique and will not be reassigned to another object. Thus, it can be said to be globally unique for a long time. Because such an identifier must remain unique for all time, it cannot contain location-relevant information ... locations can and will be reused. Also, since resources may appear in zero, one, or many locations simultaneously, location-dependent information can lead to a vast number of identifiers for an object, which will make it difficult to identify separately retrieved copies of an object as being the same object. These locations are defined by the supporting layers that provide transport and access. Therefore the definition of locations is not within the architecture, although their existence is accepted. Second, an object will support one or more abstract types. Further determination beyond this statement was not made. One can conclude from these two points that an object cannot be part of such an architected universe without having at least one such identifier and without supporting at least one type if it has at least one location.
The general architecture has as its centerpiece objects, or as they are known in the Uniform Resource Identifier Working Group, resources. An object in this architecture has several characteristics. First, it has an identifier, assigned within the context of some namespace. Such an identifier is globally unique and will not be reassigned to another object. Thus, it can be said to be globally unique for a long time. Because such an identifier must remain unique for all time, it cannot contain location-relevant information ... locations can and will be reused. Also, since resources may appear in zero, one, or many locations simultaneously, location-dependent information can lead to a vast number of identifiers for an object, which will make it difficult to identify separately retrieved copies of an object as being the same object. These locations are defined by the supporting layers that provide transport and access. Therefore the definition of locations is not within the architecture, although their existence is accepted. Second, an object will support one or more abstract types. Further determination beyond this statement was not made. One can conclude from these two points that an object cannot be part of such an architected universe without having at least one such identifier and without supporting at least one type if it has at least one location.
In addition, the architecture contains several other components. First, there will be a prescribed class of objects called links that express a relationship among other objects including the nature of that relationship. It is through links that composite objects composed of related objects can be created and managed. Finally, there is a need for several sorts of meta-information, both in order to discover identifiers (e.g. for indices and in support of searching) and to aid in the process of mapping an identifier to one or more potential locations. Both of these sorts of meta-information are associated with objects, although they will be used and therefore
In addition, the architecture contains several other components. First, there will be a prescribed class of objects called links that express a relationship among other objects including the nature of that relationship. It is through links that composite objects composed of related objects can be created and managed. Finally, there is a need for several sorts of meta-information, both in order to discover identifiers (e.g. for indices and in support of searching) and to aid in the process of mapping an identifier to one or more potential locations. Both of these sorts of meta-information are associated with objects, although they will be used and therefore
McCahill, et al Informational [Page 9] RFC 1862 IAB Workshop Report November 1995
McCahill, et al Informational [Page 9] RFC 1862 IAB Workshop Report November 1995
most likely managed differently, to support their distinctive access and update requirements.
most likely managed differently, to support their distinctive access and update requirements.
Given this architecture of information objects, one can identify several boundary points. First, something that does not have an identifier or type is outside the architecture. Second, the architecture does not, at this point, include any statement about computations, or communications paradigms other than second-handedly by assuming that traversal of links will occur. Third, although pre-fetching, caching, and replication are important, such details may be hidden from higher level software components, and thus are not part of the data model exposed to the application in the normal case (though some applications may want to specify such characteristics).
Given this architecture of information objects, one can identify several boundary points. First, something that does not have an identifier or type is outside the architecture. Second, the architecture does not, at this point, include any statement about computations, or communications paradigms other than second-handedly by assuming that traversal of links will occur. Third, although pre-fetching, caching, and replication are important, such details may be hidden from higher level software components, and thus are not part of the data model exposed to the application in the normal case (though some applications may want to specify such characteristics).
Now one can ask how such a model fits into a layered network model, how it might be modularized and realized. We envisioned this information layer as an information "wholesale" layer. It provides the general, broad model and provision of shared, network-based information. Above this sit the "retailers," the marketers or providers of information to the marketplace of applications users. Below the "wholesalers" lie the providers of "raw materials." Here will be the provision of supporting mechanisms and architecture from which information objects can come.
Now one can ask how such a model fits into a layered network model, how it might be modularized and realized. We envisioned this information layer as an information "wholesale" layer. It provides the general, broad model and provision of shared, network-based information. Above this sit the "retailers," the marketers or providers of information to the marketplace of applications users. Below the "wholesalers" lie the providers of "raw materials." Here will be the provision of supporting mechanisms and architecture from which information objects can come.
The remainder of this group's report describes the modular decomposition of the wholesale layer, including the interactions among those modules, separate discussions of the interactions first between the retail and wholesale layers and then between the wholesale and raw material layers. The report concludes with recommendations for where the most effective immediate efforts could be made to provide for the wholesale layer and make it useful.
The remainder of this group's report describes the modular decomposition of the wholesale layer, including the interactions among those modules, separate discussions of the interactions first between the retail and wholesale layers and then between the wholesale and raw material layers. The report concludes with recommendations for where the most effective immediate efforts could be made to provide for the wholesale layer and make it useful.
4.2. The Wholesale Layer
4.2. The Wholesale Layer
In order to realize the information architecture in the network a variety of classes of services or functionality must be provided. In each case, there will be many instances of a sort of service, coordinating to a lesser or greater degree, but all within the general Internet model of autonomy and loose federation. There also may be variants of any sort of service, to provide more specialized or constrained service. In addition, services may exist that will provide more than one of these services, where that is deemed useful. Each such service will reside in one or more administrative domains and may be restricted or managed based on policies of those domains. The list of core services is described below. Because there are many interdependencies, there may often be forward references in describing a service and its relationships to other services.
In order to realize the information architecture in the network a variety of classes of services or functionality must be provided. In each case, there will be many instances of a sort of service, coordinating to a lesser or greater degree, but all within the general Internet model of autonomy and loose federation. There also may be variants of any sort of service, to provide more specialized or constrained service. In addition, services may exist that will provide more than one of these services, where that is deemed useful. Each such service will reside in one or more administrative domains and may be restricted or managed based on policies of those domains. The list of core services is described below. Because there are many interdependencies, there may often be forward references in describing a service and its relationships to other services.
McCahill, et al Informational [Page 10] RFC 1862 IAB Workshop Report November 1995
McCahill, et al Informational [Page 10] RFC 1862 IAB Workshop Report November 1995
* RESOURCE DISCOVERY: Much of the activity of resource discovery, indexing and searching, will be in the domain of the retailers, although there are supporting hooks that can be provided by the wholesaler layer as well. A resource discovery service will hold mappings from descriptions to identifiers of objects. They will need to be queried. Thus there is a general functionality for a wholesale layer service that answers queries formulated in certain ways and responds with identifiers. The business of on what basis indices are computed or how they are managed will be domain specific.
* リソース発見: リソース発見の活動の索引をつけていて探している多くは、小売業者のドメインにあるでしょう、卸売業者層で提供できるサポートフックがまた、ありますが。 リソース発見サービスは記述からオブジェクトに関する識別子までマッピングを保持するでしょう。 彼らは、質問される必要があるでしょう。 したがって、ある方法で定式化された質問に答えて、識別子で応じる大量の層のサービスのための一般的な機能性があります。 インデックスリストがどんなベースで計算されるか、そして、またはそれらがどのように管理されるかに関するビジネスはドメイン特有になるでしょう。
* NAMING or IDENTIFICATION: There are two aspects to assigning an identifier to an object, one in the wholesale layer, and one, arguably, in the retail layer. In the wholesale layer, one can generate identifiers that are guaranteed to be unique. In the retail layer one might ask the question about whether two objects are the same or different by the rules of an identification authority that therefore would determine whether they should bear the same or different identification from that authority. It should be noted that the URI Working Group has included these two functions in the requirements document for URNs.
* 命名か識別: 小売の層には識別子をオブジェクトに割り当てることへの2つの局面、大量の層の1、および1つが論証上あります。 大量の層の中では、1つは、保証される識別子が特有であると生成することができます。 小売では、層1は、2個のオブジェクトがしたがって、彼らが同じであるかその権威と異なった識別に堪えるべきであるかどうか決定する識別権威の規則で同じであるか、またはほとんど異なっているかを質問に尋ねるかもしれません。 URI作業部会がURNsのための要件ドキュメントでのこれらの2つの機能を含めたことに注意されるべきです。
An identification service will obviously provide functionality to the uniqueness authority. It will also provide identification in the process of publication of objects, as will be discussed below, in the management of resource discovery information, object location and storage services, as well as cache and replication management.
識別サービスは明らかにユニークさの権威に機能性を提供するでしょう。 また、それはオブジェクトの公表の途中に識別を提供するでしょう、以下でリソース発見情報、オブジェクト位置、およびストレージサービスの管理で議論するように、キャッシュと模写管理と同様に。
* NAME or IDENTIFICATION RESOLUTION: Since identifiers are presumed to be location independent, there is a need for a resolution service. Such a service may sometimes return other identifiers at this same level of abstraction (the equivalent of aliases) or location information, the information delivered to a transport service to access or retrieve an object.
* 名前か識別解決: 識別子があえて位置の独立者であるので、解決サービスの必要があります。 そのようなサービスは抽象化(別名の同等物)のこの同程度か位置情報(オブジェクトをアクセスするか、または検索するために輸送サービスに提供された情報)で他の識別子を時々返すかもしれません。
* OBJECT RETRIEVAL: Object retrieval is tightly coupled to resolution, because without resolution it cannot proceed. Object retrieval provides the functionality of causing a representation of an object to be provided locally to the requester of an object retrieval. This may involve the functionality of object publication (see below) and object storage, caching and replication services as well as the supporting transport facilities.
* オブジェクト検索: 解決なしで続くことができないので、オブジェクト検索は解決への密結合です。 オブジェクト検索はオブジェクトの表現が局所的にオブジェクト検索のリクエスタに提供されることを引き起こす機能性を提供します。 これはオブジェクト公表(以下を見る)とオブジェクトストレージの機能性にかかわるかもしれません、キャッシュしていて、サポートすることと同様に復元サービスは施設を輸送します。
* OBJECT PUBLICATION: When an object comes into existence in the universe of the information infrastructure, it is said to be "published." There will be two common scenarios in publication. One will be the use of tools to directly enter and create the information that comprises an object in the information infrastructure. Thus there may be object creation tools visible to users in applications.
* オブジェクト公表: オブジェクトが情報インフラストラクチャの宇宙の中で生まれるとき、それは「発行される」と言われます。 公表には2つの共通したシナリオがあるでしょう。 なるツールを使用するのに1つが直接情報インフラストラクチャでオブジェクトを包括する情報を入力して、作成するために。 したがって、アプリケーションにはユーザにとって、目に見えるオブジェクト作成ツールがあるかもしれません。
McCahill, et al Informational [Page 11] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[11ページ]RFC1862IAB Workshop Report1995年11月
In contrast there may also be tools outside the information infrastructure (for example word processing or text editing tools) that provide for the entry of data separately from the operation of assigning an object an identifier and causing it to support information infrastructure definitions of objects. Thus, there will also be visible at the interface between the wholesale and retail layers the ability to cause some pre-existing data to become one or more objects. In addition to interacting with the identification service, publication is likely to cause interaction with object storage, and possibly caching and replication.
対照的に、また、情報インフラストラクチャ(例えば、文書処理かテキスト編集ツール)の外における別々に識別子をオブジェクトに割り当てて、情報インフラストラクチャがオブジェクトの定義であるとサポートすることを引き起こす操作からデータのエントリーに備えるツールがあるかもしれません。 また、卸売りの間のインタフェースでしたがって、そこでは、目に見えて、小売は、1個以上のオブジェクトになるようにいくつかの先在にデータを引き起こす能力を層にします。 識別サービスと対話することに加えて、公表はオブジェクトストレージ、ことによるとキャッシュ、および模写との相互作用を引き起こしそうです。
* DEFINITIONS: If the information infrastructure is to both survive and evolve over a long time period, we must be prepared for a wide variety and growing number of different sorts of information with different functionalities that each supports. For objects available on the net, the functionality that each provides must be exposed or able to be learned. To do this objects must be able to indicate by name or identifier the types of functionality they are supporting. Given such an identifier, an object is only useful to a client, if the client can discover the definition and perhaps a useful implementation of the type in question. This will be acquired from a definitions service, which will be used in conjunction with applications themselves directly, object publication, and object retrieval.
* 定義: 情報インフラストラクチャが長い期間にわたって生き残って、発展するつもりであるなら、異なった種類の広いバラエティーと増加している数の情報のためにそれぞれがサポートする異なった機能性で私たちを準備しなければなりません。 ネットで利用可能なオブジェクトに関しては、それぞれ提供される機能性は、暴露されなければならないか、または学習できなければなりません。 これをするために、オブジェクトは名前か識別子で彼らがサポートしている機能性のタイプを示すことができなければなりません。 そのような識別子を考えて、オブジェクトは単にクライアントの役に立ちます、クライアントが問題のタイプの定義と恐らく役に立つ実装を発見できるなら。 定義サービス、どれが直接アプリケーション自体に関連して使用されるだろうか、そして、オブジェクト公表、およびオブジェクト検索からこれを取得するでしょう。
* ATTRIBUTE MANAGEMENT: The attributes considered here relate to policy, although any understanding of that policy will be above the wholesale level. There are, for example, access management and copyright attributes. There is a question here about whether there is or should be any access time enforcement or only after the fact enforcement. The information is likely to be in the form of attribute-value pairs and must be able to capture copyright knowledge effectively.
* 管理を結果と考えてください: その方針のどんな理解も大量のレベルを超えているでしょうが、ここで考えられた属性は方針に関連します。 例えば、アクセス管理と著作権属性があります。 実施はあるべきであるか、または何かアクセスタイム実施か事実の後にだけ、あるべきであるかに関して質問がここにあります。 情報は、属性値組の形にありそうであって、著作権が知識であると有効にキャプチャすることができなければなりません。
* ACCOUNTING: An accounting service provides metering of the use of resources. The resources wholly contained in the wholesale layer are the services discussed here. It will also be important to provide metering tools in the wholesale layer to be used by the retail layer to meter usage or content access in that layer. Metering may be used for a variety of purposes ranging from providing better utilization or service from the resources to pricing and billing. Hence accounting services will be used by object storage, caching and replication, lower layer networking services, as well as pricing and billing services. In the form of content metering it will also interact with attribute management.
* 会計: 会計サービスは、リソースの使用を計量しながら、提供されます。 大量の層に完全に含まれたリソースはここで議論したサービスです。 また、小売の層によって使用されて、その層の中で用法か満足しているアクセスを計量するために計量ツールを大量の層に供給するのも重要でしょう。 計量はリソースから、より良い利用かサービスを提供するのから価格設定まで及ぶさまざまな目的と支払いに使用されるかもしれません。 したがって、会計サービスはオブジェクトストレージ、キャッシュ、および模写で利用されるでしょう、下層ネットワークサービス、価格設定と支払いサービスと同様に。 また、内容の形では、それを計量するのは属性管理と対話するでしょう。
McCahill, et al Informational [Page 12] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[12ページ]RFC1862IAB Workshop Report1995年11月
* PRICING, BILLING and PAYMENT: Pricing and payment services straddle two layers in the information infrastructure. Servers that maintain account balances and with which users interact to retrieve and edit account information are applications that will be built on top of wholesale layer services. Pricing will be determined in the applications environment for application level activities. However, it must be possible for middle layer services to process payment instruments analogous to cash, credit card slips, and checks, without an understanding of the specific implementation of the payment mechanism. Application programming interfaces supporting payment should be provided, and a common tagged representation of payment instruments should allow instruments from a variety of payment systems to be presented within middle layer protocols.
* 価格設定、支払い、および支払い: 価格設定と支払いサービスは情報インフラストラクチャで2つの層にまたがっています。 勘定残高を維持して、ユーザが会計情報を検索して、編集するために相互作用するサーバは大量の層のサービスの上で組立てられるアプリケーションです。 価格設定はアプリケーションレベル活動のためのアプリケーション環境で決定するでしょう。 しかしながら、中間層サービスが現金、クレジットカードメモ用紙、およびチェックへの類似の支払い器具を処理するのは、可能であるに違いありません、支払いメカニズムの特定の実装の理解なしで。 支払いをサポートするアプリケーションプログラミングインターフェースを前提とするべきです、そして、支払い器具の一般的なタグ付けをされた表現はさまざまな決済システムからの器具が中間層プロトコルの中に示されるのを許容するべきです。
* OBJECT STORAGE, CACHING and REPLICATION: There is a recognition that caching and replication are important, but the discussion of that was left to another group that had taken that as the focus of their agenda. Object storage will take an object and put it somewhere, while maintaining both the identity and nature of the object. It is tightly coupled to caching and replication, as well as accounting, often in order to determine patterns of caching and replication. It is also tightly coupled to object publication, translation, and provides interfaces to both supporting storage facilities such as local file systems, as well as direct access from applications, needing access to objects.
* オブジェクトストレージ、キャッシュ、および模写: キャッシュと模写が重要ですが、その議論がそれらの議題の焦点としてそれをみなした別のグループに残されたという認識があります。 両方がオブジェクトのアイデンティティと自然であることを支持している間、オブジェクトストレージは、目的語を取って、どこかにそれを置くでしょう。 それは、キャッシュと模写のパターンを決定するキャッシュへの密結合としばしば説明することと同様に模写です。 それは、また、しっかりオブジェクト公表、翻訳と結合されて、ストレージがローカルファイルシステムなどの施設であるとサポートしながら、インタフェースを両方に提供します、アプリケーションからの直接アクセスと同様に、オブジェクトへのアクセスを必要として。
* TRANSLATION: A translation service allows an object to behave with a nature different than that it would otherwise support. Thus, for example, it might provide a WYSIWYG interface to an object whose functionality might not otherwise support that, or it might generate text on the fly from an audio stream. Translation services will be used by object publication (allowing for identification of an object including a translation of it) and with object storage, providing an interface only within the wholesale or to the retail layers.
* 翻訳: オブジェクトは翻訳サービスでそれと異なった自然でそれを反応させることができます。そうでなければ、サポートするでしょう。 このようにして、例えば、そうでなければ機能性がそれをサポートしないかもしれないオブジェクトにWYSIWYGインタフェースを供給するかもしれませんか、またはそれはオーディオストリームからテキストを急いで作るかもしれません。 翻訳、通訳のサービスはオブジェクト公表(それに関する翻訳を含むオブジェクトの識別を考慮する)とオブジェクトストレージと共に使用されるでしょう、卸売り以内かだけ小売の層にインタフェースを供給して。
* SERVER AND SERVICE LOCATION: It will be necessary as part of the infrastructure to be able to find services of the kinds described here and the servers supporting them. This service has direct contact with the lower layer of raw materials, in that it will provide, in the final analysis, the addresses needed to actually locate objects and services using lower level protocols, such as the existing access protocols in use today, for example FTP, SMTP, HTTP, or TCP. This service will provide functionality directly to resource discovery as well as remote object storage services.
* サーバANDサービス位置: インフラストラクチャの一部として、ここで説明された種類とサーバのサービスがそれらをサポートしているのがわかることができるのが必要でしょう。 このサービスには、原料の下層とのダイレクト接触があります、提供するので、最終分析で、実際に下のレベルプロトコルを使用することでオブジェクトとサービスの場所を見つけるのに必要であるアドレス、例えば、今日の使用中の既存のアクセス・プロトコル、FTP、SMTP、HTTP、またはTCPなどのように。 このサービスは直接リモート・オブジェクトストレージサービスと同様にリソース発見に機能性を提供するでしょう。
McCahill, et al Informational [Page 13] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[13ページ]RFC1862IAB Workshop Report1995年11月
* ADAPTIVE GLUE: This is not a single service as much as a recognition that there must be a path for a flow of information between the network layers and the applications. The application may have constraints, based both on its own needs as well as needs of the objects in the wholesale layer. Only the application can really know what compromises in services provided below are acceptable to it. At the same time, the supporting network layers understand what qualities of service are available at what price. Hence there is the potential for flow of information both up and down through the wholesale layer, perhaps mediated by the wholesale layer. Hence the adaptive glue has hooks into all three levels.
* 適応型の接着剤: これはネットワーク層とアプリケーションの間には、情報の流れのための経路があるに違いないという認識ほどただ一つのサービスではありません。 アプリケーションには、規制があるかもしれません、大量の層のオブジェクトの必要性と同様にそれ自身の必要性両方の、に基づきます。 アプリケーションだけが、以下に提供されたサービスにおけるどんな感染がそれに許容できるかを本当に知ることができます。 同時に、サポートネットワーク層は、どんなサービスの品質がどんな価格に利用可能であるかを理解しています。 したがって、恐らく大量の層によって調停された大量の層を通して情報の流れの可能性がともに上下にあります。 したがって、適応型の接着剤はすべての3つのレベルにフックを持っています。
* SECURITY: Security services will be a critical piece of the infrastructure architecture. For any real business to be conducted, organizations must make their information available over the network, yet they require the ability to control access to that information on a per user and per object basis. To account properly for the use of higher level services, organization must be able to identify and authenticate their users accurately. Finally, payment services must be based on security to prevent fraudulent charges, or disclosure of compromising information.
* セキュリティ: セキュリティー・サービスはインフラストラクチャアーキテクチャの1つの批評的な記事になるでしょう。 組織はどんな本当の業務も行われるために、それらの情報をネットワークの上で利用可能にしなければなりません、しかし、彼らがユーザと対象分類あたりのaのその情報へのアクセスを制御する能力を必要とします。 適切により高い平らなサービス、組織の使用を説明するのは、正確に彼らのユーザを特定して、認証できなければなりません。 最終的に、詐欺的な充電、または評判を落とすような情報の公開を防ぐために支払いサービスをセキュリティに基礎づけなければなりません。
The two biggest problems in providing security services at the wholesale layer are poor infrastructure and multiple security mechanisms that need to be individually integrated with applications. The poor state of the infrastructure is the result of a lack of an accepted certification hierarchy for authentication. A commonly held position is that there will not be a single hierarchy, but there must be established authorities whose assertions are widely accepted, who indirectly certify the identities of individuals with which one has not had prior contact.
2つの大量の層でセキュリティー・サービスを提供するのにおいて最も大きい問題が、アプリケーションについて個別に統合している必要がある貧しいインフラストラクチャと複数のセキュリティー対策です。 インフラストラクチャの貧しい状態は認証のための受け入れられた証明階層構造の不足の結果です。 主張が広く受け入れられる確立された権威があるに違いありません、そして、ただ一つの階層構造がないという一般的に保持された位置がありますが、だれがどれで間接的に個人のアイデンティティを公認するかに、先の接触がありません。
Integration with applications is made difficult because, though security services are themselves layered upon one another, such services do not fit into the information architecture at a single layer. By integrating security services with lower layers of the information infrastructure, security can be provided to higher layers, but some security information, such as client's identity, may be needed at higher layers, so such support will not be completely transparent. Further, the security requirements for 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 applied.
セキュリティー・サービスがお互いで層にされますが、そのようなサービスが単一層にインフォメーション・アーキテクチャに収まらないので、アプリケーションによる統合を難しくします。 そのようなサポートは、情報インフラストラクチャの下層とセキュリティー・サービスを統合することによって、より高い層にセキュリティを提供できますが、より高い層でクライアントのアイデンティティなどの何らかのセキュリティ情報を必要とするかもしれないので、完全にわかりやすくなるというわけではないでしょう。 さらに、それぞれの中間層情報サービス、およびアプリケーション自体のセキュリティ要件を考えなければなりません、そして、セキュリティー・サービスが適用した中間層で適切な使用をしなければなりません。
Integration with applications will require user demand for security, together with common interfaces such as the GSS-API, so that applications and middle layer information services can utilize the security services that are available, without understanding the
アプリケーションによる統合はセキュリティのユーザ要求を必要とするでしょう、GSS-APIなどの一般的なインタフェースと共に、アプリケーションと中間層情報サービスが利用可能なセキュリティー・サービスを利用できるように、理解なしで
McCahill, et al Informational [Page 14] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[14ページ]RFC1862IAB Workshop Report1995年11月
details of the specific security mechanism that is employed.
採用している特定のセキュリティー対策の細部。
* BOOTSTRAPPING: In order for a newly participating machine to join the infrastructure, it must have some way of finding out about at least one instance of many of the services described here. This can be done either by providing it with some form of configuration provided by the human bringing it up or by a bootstrapping service. The bootstrapping service is more flexible and manageable; it is included here in recognition that this information must be provided in some form or other. The bootstrapping service will sit directly on the raw materials layer and will have contact with all the services described here.
* ブートストラップ法: 新たに参加しているマシンがインフラストラクチャを接合するように、それで、ここにサービスの多くの少なくともおよそ1つのインスタンスを見つける何らかの方法を述べなければなりません。 それを持って来る人間によって提供された何らかのフォームの構成をそれに提供するか、ブートストラップ法サービスでこれができます。 ブートストラップ法サービスは、よりフレキシブルであって、処理しやすいです。 それはここ、この情報を何らかのフォームに提供しなければならないという認識に含まれています。 ブートストラップ法サービスは、直接原料層に座って、すべてのサービスがここで説明されている状態で、接触を持つでしょう。
This completes the description of the services as identified by this group in the wholesale layer. Although this section suggests which services have interfaces to the retail and raw materials layers, each of these topics will need to be described separately as well, to clarify the functionality expected by each layer of the layer below.
大量の層のこのグループによって特定されるようにこれはサービスの記述を終了します。 このセクションは、どのサービスが小売と原料層にインタフェースを持っているかを示しますが、それぞれのこれらの話題は、以下の層の各層によって予想された機能性をはっきりさせるために別々にまた、説明される必要があるでしょう。
3. Interface to retail layer
3. 連結して、層を小売してください。
The interface to the retail layer is the embodiment of the object model and attendant services. Thus the interface provides the application environment with a collection of objects having identifiers for distinguishing them within the wholesale layer and support for a typing or abstract functionality model. It provides for the ability to create or import objects into this object world by the publication paradigm, and allows objects to evolve to support new or evolving functionality through the translation paradigm. Access to the objects is provided by object storage, enhanced with caching and replication services and mediated by the attributes managed by attribute management and accounting or content metering. Discovery of resources (figuring out which identifier to be chasing) is provided by resource discovery services. Types are registered and hence available both as definitions and perhaps in the form of implementations from a definition service. Lastly, there is a vertical model of providing the two-way services of adaptive glue for quality of service negotiation and for security constraints and requirements, with access and services at all three layers.
小売の層へのインタフェースはオブジェクト・モデルと付き添いのサービスの具体化です。 したがって、インタフェースはタイプか抽象的な機能性モデルの大量の層とサポートの中でそれらを区別するための識別子を持っているオブジェクトの収集をアプリケーション環境に提供します。 それは、公表パラダイムでこのオブジェクト世界にオブジェクトを作成するか、またはインポートする能力に備えて、オブジェクトが翻訳パラダイムを通して新しいか発展している機能性をサポートするために発展するのを許容します。 オブジェクトへのアクセスは、オブジェクトストレージで提供されて、キャッシュと復元サービスで機能アップされて、属性管理と会計か満足している計量で管理された属性によって調停されます。 リソース発見サービスでリソース(どの識別子を追いかけたらよいかを理解する)の発見を提供します。 タイプは、登録されていてしたがって、定義と恐らく定義サービスからの実装の形に手があいています。 最後に、サービスの質交渉とセキュリティ規制と要件に適応型の接着剤の両用サービスを提供する垂直なモデルがあります、アクセスとサービスがすべての3つの層にある状態で。
4. Interface to the raw materials layer
4. 原料層に連結してください。
The raw materials layer falls into networking and operating systems. Hence it provides all those services currently available from current networking and operating systems. Wholesale services such as object management will be dependent on local operating system support such as a file system, as well as perhaps transport protocols. In fact, all instances of any of the above services will be dependent on local
原料層はネットワークとオペレーティングシステムになります。したがって、それは現在現在のネットワークとオペレーティングシステムから利用可能なそれらのすべてのサービスを提供します。オブジェクト管理などの大量のサービスは、ファイルシステムなどの地方のオペレーティングシステムサポートに依存していて、恐らくプロトコルを輸送するでしょう。 事実上、上のサービスのどれかのすべてのインスタンスが地方に依存するようになるでしょう。
McCahill, et al Informational [Page 15] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[15ページ]RFC1862IAB Workshop Report1995年11月
storage, process management, local access control and other security mechanisms, as well as general transport protocols for communications both often among services of the same sort and among services dependent on each other that may not be collocated. In addition the group identified a set of issues that appear important for the networking components of the raw materials layer to provide to the wholesale layer in addition to the basic best effort transmission services that are commonly available. These take the form of a wish list with the recognition that they are not all equally easy or possible.
しばしば同じ種類のサービスの中と、そして、互いの上のそうしないかもしれないサービス扶養家族の中のコミュニケーションのためのストレージ、工程管理、地方のアクセスコントロール、他のセキュリティー対策、および一般的なトランスポート・プロトコルは並べられました。 さらに、グループは原料層のネットワークの構成要素が一般的に利用可能な基本的なベストエフォート型トランスミッションサービスに加えて大量の層に供給されるために重要に見える1セットの問題を特定しました。 これらはそれらがすべて等しく簡単でもなくて、また可能でもないという認識で欲しい物のリストの形を取ります。
* Connectivity: It is useful and important for the operation of applications and the wholesale services to understand what connectivity is currently available. The group identified four categories of connectivity that it would be useful to know about represented by four questions:
* 接続性: アプリケーションの操作と大量のサービスが、どんな接続性が現在利用可能であるかを理解しているのは、役に立って重要です。 グループは4つの質問によって表された知るのが役に立つ接続性の4つのカテゴリを特定しました:
1) Is there a wire out of the back of my machine?
1) 私のマシンの後部の外にワイヤがありますか?
2) Am I connected to a router?
2) 私はルータに接続されますか?
3) Am I connected to the global internet? (Can I get beyond
my own domain?)
3) 私はグローバルなインターネットに接続されますか? (私は私自身のドメインを越えてもよいですか?)
4) Am I connected to a specific host?
4) 私は特定のホストに接されますか?
These are probably in increasing difficulty of knowing.
これらが知っているというたぶん増加する困難にあります。
* Connectivity forecast: Although this is recognized as either extremely difficult or impossible to do, some form of connectivity forecast would be very useful to the upper layers
* 接続性予測: これは非常に難しいかする不可能であるとして認識されますが、何らかの形式の接続性予測は非常に上側の層の役に立つでしょう。
* Bandwidth availability and reservation: It is useful for the application to know both what bandwidth might be available to it and, better yet, for it to be able to make some form of reservation.
* 帯域幅の有用性と予約: アプリケーションが、両方のどんな帯域幅が何らかの形式の予約をすることができるようにそれと、そして、さらに良いそれに利用可能であるかもしれないかを知るのは、役に立ちます。
* Latency availability and reservation: It is useful for the application to know both what latency the network is experiencing and, better yet, be able to set limits on it by means of a reservation.
* 潜在の有用性と予約: アプリケーションがネットワークが両方のどんな潜在を経験しているかを知って、予約によってそれでさらに良く制限を加えることができるのは、役に立ちます。
* Reliability availability and reservation: Again, reliability constraints are important for many applications, although they may have differing reliability constraints and may be able to adapt differently to different circumstances. But, if the application could make a statement (reservation) about what level of unreliability it can tolerate, it might be able to make tradeoffs.
* 信頼性の有用性と予約: 一方、多くのアプリケーションには、信頼性の規制は重要です、異なった信頼性の規制を持って、異なった事情に異なって順応できるかもしれませんが。 しかし、アプリケーションがそれがどんなレベルの非信頼性を許容できるかに関する声明(予約)を出すことができるなら、見返りを作ることができるでしょうに。
McCahill, et al Informational [Page 16] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[16ページ]RFC1862IAB Workshop Report1995年11月
* Burstiness support: Although it is unlikely that the network can make predictions about the burstiness of its services, if the application can predict to the network its burstiness behavior, the network might be able to take advantage of that knowledge.
* Burstinessサポート: ネットワークがサービスのburstinessに関する予測をすることができるのが、ありそうもないのですが、アプリケーションがburstinessの振舞いをネットワークに予測できるなら、ネットワークはその知識を利用できるかもしれません。
* Service envelope: It is possible that, as an alternative to the above four issues, the raw materials layer could negotiate a whole service envelope with the layers it is supporting.
* 封筒を調整してください: 原料層が上の4冊に代わる手段としてそれが支えている層と全体のサービス封筒を交渉するかもしれないのは、可能です。
* Security availability: In many cases, it will be important for the upper layers to be able to know what sorts and levels of security are available from the raw materials layer. This is true of both any operating system support as well as transmission.
* セキュリティの有用性: 多くの場合、上側の層が、原料層からどんな種類とレベルのセキュリティが利用可能であるかを知ることができるのは、重要でしょう。 これはどんなオペレーティングシステムサポートとトランスミッションの両方に関しても本当です。
* Cost: If there is to be usage charging at other than fixed flat rates, it will be important for applications and users to understand what those costs or at least estimates of them will be.
* 以下かかってください。 修理されるのを除いて、均一料金に突進する用法があると、アプリケーションとユーザが、それらのそれらのコストか少なくとも見積りが何になるかを理解しているのは、重要でしょう。
* Policy routing: If it will be important for transport services to support policy routing, it will be important for users of the transport services to identify into which policy classes they might fall.
* 方針ルーティング: 輸送サービスが方針ルーティングをサポートするのが、重要であるなら、輸送サービスのユーザが、それらがどの方針のクラスに落下するかもしれないかを特定するのは、重要でしょう。
4.5. Recommendations
4.5. 推薦
This group has two categories of recommendations. One is those services in the wholesale layer that will both be especially useful and readily achieved because work is soon to be or already underway. The other set of recommendations was a three item rank ordering of services that are most important for the lower layer to provide to the wholesale layer.
このグループには、推薦の2つのカテゴリがあります。 1つは既に特に役に立って仕事がすぐ達成されるので容易に達成されているか、または進行中になる大量の層でそれらのサービスです。 もう片方のセットの推薦は下層が大量の層に供給されるために最も重要でありサービスの3項目等級序列でした。
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 in which there would be quick payoff if the raw materials layer could provide them. They are:
さらに、グループランクは原料層がそれらを提供できるなら迅速な支払いがある3つの領域を命令しました。 それらは以下の通りです。
1. Connectivity
1. 接続性
2. Bandwidth, latency, and reliability or service envelope
2. 帯域幅か、潜在と、信頼性かサービス封筒
McCahill, et al Informational [Page 17] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[17ページ]RFC1862IAB Workshop Report1995年11月
3. Security constraints on communication and transactions
3. コミュニケーションとトランザクションにおけるセキュリティ規制
5. Group 2B Report: Components of an Internet Information Architecture
5. グループ2Bは報告します: インターネットインフォメーション・アーキテクチャの成分
Cecilia Preston, Chris Weider, Christian Huitema, Cliff Lynch, John Romkey, Joyce Reynolds, Larry Masinter, Mitra, Jill Foster
シシリア・プレストン、クリス・ワイダー、クリスチャンのHuitema、クリフ・リンチ、ジョンRomkey、ジョイス・レイノルズ、ラリーMasinter、ミトラジル・フォスター
Group 2B discussed various aspects of problems in the Internet Information Infrastructure, thinking about recommendations to the IESG to focus on particular areas, and also paying attention to some of the philosophical and economic backgrounds to some of the problems. Economics can dictate some points of architecture: one can see economically why a publisher might bear the burden of the costs of publishing, or a consumer might bear the burden of costs associated with consumption, but not how some free-floating third party would necessarily bear the costs of providing services (such as third-party translators).
グループ2Bはインターネット情報Infrastructureの問題の種々相について議論しました、特定の領域に焦点を合わせるためにIESGに推薦について考えて、また、哲学的で経済のバックグラウンドのいくつかに問題のいくつかに注意を向けて。経済学はアーキテクチャの諸点を決めることができます: 人が、出版社がなぜ出版のコストの負担を持っているかもしれないかを経済的に見ることができますか、または消費者は浮動性の第三者は必ずどう費用を負担するだろうかではなく、サービス(第三者翻訳者などの)を提供する消費に関連しているコストの負担を持っているかもしれません。
The group discussed the following topics:
グループは以下の話題について議論しました:
access(URL)
アクセス(URL)
gateways
ゲートウェイ
URN resolution
URN解決
definitions
定義
updates
アップデート
service location
サービス位置
cache & replication
キャッシュと模写
security & authentication
セキュリティと認証
payments, charging
支払い、充電
presentation
プレゼンテーション
search & index
検索とインデックス
metainformation
metainformation
boot service
サービスをブートしてください。
general computation
一般的な計算
McCahill, et al Informational [Page 18] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[18ページ]RFC1862IAB Workshop Report1995年11月
5.1 URNs
5.1 つぼ
There are several issues in the use of Uniform Resource Names and Uniform Resource Locators. URN resolution is a database lookup that returns the URLs associated with a URN. The architecture must take into account not only how the lookup is performed, but how the database is maintained. Both the lookup problem and the update problem must be solved at the same time to allow deployment of URNs.
いくつかの問題がUniform Resource NamesとUniform Resource Locatorの使用であります。 URN解決はURNに関連しているURLを返すデータベースルックアップです。 アーキテクチャはルックアップがどう実行されるかだけではなく、データベースがどう維持もされるかも考慮に入れなければなりません。 同時に、URNsの展開を許すためにルックアップ問題とアップデート問題の両方を解決しなければなりません。
There are at least two problems in human interaction with unique names. First, the notion of a unique name is a fallacy. Unique naming cannot be enforced. Names may be forged or may simply be duplicated due to human error. The architecture must accept this observation and still operate in the face of it. Designing for global uniqueness, but not requiring it, was adequate. Errors based on names not being unique are likely to be insignificant compared to other errors.
ユニークな名前との人間の交流には少なくとも2つの問題があります。 まず最初に、ユニークな名前の概念は誤りです。 ユニークな命名を励行されることができません。 名前は、作り出されるか、または人為ミスのため単にコピーされるかもしれません。 アーキテクチャは、この観測を受け入れて、それに直面してまだ作動しなければなりません。 グローバルなユニークさのために設計しますが、それを必要としないのは適切でした。 ユニークでない名前に基づく誤りは他の誤りと比べて、無意味にである傾向があります。
Also, people frequently make assertions and assumptions about names rather than the documents that are being named. Making assertions about names is working at the wrong level of indirection. Making assumptions about names, such as determining the contents of the named object from the syntax of the name, can lead to nasty surprises.
また、人々は頻繁に命名されているドキュメントよりむしろ名前に関する主張と仮定をします。 名前に関して主張をするのは間違ったレベルの間接指定で働いています。 名前の構文から命名されたオブジェクトのコンテンツを決定などなどの名前に関する仮定をするのは不快な驚きに通じることができます。
Having a single, unified naming system is vital. While it is healthy to have multiple competing forms of other aspects of the information architecture, the naming system is what ties it all together. There must be only one naming system. If there is more than one, it may not be possible to compare names or to lookup locations based on names, and we will continue (to our detriment) to use locators rather than names.
単一の、そして、統一された命名システムを持っているのは重大です。 複数の競争しているフォームのインフォメーション・アーキテクチャの他の局面を持っているのが健康ですが、命名システムは一斉にそれを結ぶものです。 1台の命名システムしかないに違いありません。 1つ以上があれば、名前か名前に基づくルックアップ位置と比較するのが可能でないかもしれなく、私たちは、名前よりむしろロケータを使用し続けるつもりです(私たちの損傷に)。
5.2 Global Service Location
5.2 グローバルなサービス位置
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.
IANAはサービス識別のための主要なスイッチポイントになりました。. また、分配された情報システム(例えば、Assigned民数記)における使用のために正式に定義されて、ドキュメントに閉じ込めた数が使用のためにある種のデータベースでアプリケーションでオンラインで分配されるべきであることを勧めました。 この分配はアクセス法(恐らく複数のアクセス法)とアップデートメソッドの両方を必要とします。
5.3 Security
5.3 セキュリティ
Issues involving security arose over and over again. Security includes things like validation of authority, confidentiality, integrity of data, integrity of services, access control. The group agreed that, although often overlooked, confidentiality is important,
セキュリティを伴う問題が幾重にも起こりました。 権威の合法化、秘密性、データの完全性、サービスの保全がコントロールにアクセスするようにセキュリティはものを含んでいます。 グループは、しばしば見落とされますが、秘密性が重要であるのに同意しました。
McCahill, et al Informational [Page 19] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[19ページ]RFC1862IAB Workshop Report1995年11月
and, more strongly: anonymity is important. It should be possible to access documents or objects without the architecture requiring you to 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.
セキュリティは終わりから終わりへのベースに起こらなければなりません。 インターネットで使用されるドキュメントかオブジェクトがインターネットを横断するかもしれないだけではありません。 基本的なプロトコル群でセキュリティー対策を当てにすると、終わりから終わりへの認証か秘密性が必ず提供されるというわけではありません。
Currently lower layer security is ill-defined and widely unimplemented. Designers building information applications atop the Internet currently receive little guidance in how to design security features into their applications, leading to weak ad hoc or nonexistent security in new applications. Designers are also unclear as to how to deal with the "security considerations" section that is mandatory in RFCs, and often fill them with boilerplate text.
現在低い層のセキュリティは、ほとんど定義されて広く非実装されません。 現在インターネットの上で情報アプリケーションを組立てるデザイナーがどう彼らのアプリケーションにセキュリティ機能を設計するかでほとんど指導を受けません、新しいアプリケーションにおける弱い臨時の、または、実在しないセキュリティに通じて。 また、デザイナーもRFCsで義務的な「セキュリティ問題」セクションと取り引きして、決まり文句のテキストで彼らをしばしばどう満たすかに関して不明瞭です。
Furthermore, retrofitting security into existing architectures does not work well. The best systems are built considering security from the very beginning. Some systems are being designed that, for instance, 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:
グループはセキュリティに関して以下の推薦状をIESGにします:
A. Develop and communicate a security model usable by designers of information applications - current models are not considered usable.
A. 情報アプリケーションのデザイナーが使用可能な機密保護モデルを開発して、伝えてください--現在のモデルは使用可能であると考えられません。
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.
どんなセキュリティ問題が、概説されている必要があるか、そして、どのようにそれらを書くかに関するアドバイスをB. RFC作者に与えるべきです。 IESGセキュリティ領域は、セキュリティ問題を書くためにガイドラインを準備するべきです。
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.
彼らが本当にセキュリティを考えないなら、IESGはC.の提案されたStandardsを受け入れるはずがありません。 これは、推薦AとBが実装されて、ガイドラインが作者が彼らの存在を知ると合理的に予想できるくらいの目に見えることを受けたのを必要とするでしょう。
D. Develop security modules usable by the implementors of information clients and servers - reusable across many different, heterogeneous applications and platforms.
D. 情報クライアントとサーバの作成者が使用可能なセキュリティーモジュールを開発してください--多くの異なって、異種のアプリケーションとプラットホームの向こう側に再利用できます。
E. Make clear what security services you can expect from the lower layers.
E. あなたが下層から予想できるすべてのセキュリティー・サービスを明らかにしてください。
F. Make sure that the key distribution infrastructure is reviewed for usability by information applications.
F. 主要な分配インフラストラクチャがユーザビリティのために情報アプリケーションで見直されるのを確実にしてください。
McCahill, et al Informational [Page 20] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[20ページ]RFC1862IAB Workshop Report1995年11月
5.4 Search and Index
5.4 検索とインデックス
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 the indexing, information is frequently indexed multiple times. This is wasteful, but due to the current economics of the Internet, it tends not to cost more money. If the Internet (or parts of thereof) 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 which is sent to a search/index server is vastly preferable to having that server "walk the net" to discover information to index.
何よりも、アーキテクチャは通常、情報が索引をつけられない状況を奨励するべきではありません。 それは唯一のaただ一つの時にインデックスデータの収集を奨励するべきです。 そのサーバが情報が索引をつけると発見するために「ネットを歩くこと」を持っているより検索/インデックスサーバに送られる概要の地方の計算を持っているのは広大に望ましいです。
Indexing and search techniques are quite varied. It is quite likely that index and search are too close to general computation to try to standardize on a single protocol for either. Instead, it is 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 large differences in the quality and usability of indices that are machine-generated vs. human generated.
インデックスと検索技術はかなり変えられます。 そのインデックスと検索が試みる一般的な計算のどちらかのためにただ一つのプロトコルで標準化できないくらい近くにあるのは、かなりありそうです。 代わりに、アーキテクチャが複数の検索技術を許容するのは、重要です。 現在、人間が彼らの意味内容のレベルのために作ることができるだけである、あるタイプのインデックスリストがあります。 生成された人間に対してマシンで発生しているインデックスリストの品質とユーザビリティには大きな違いがあります。
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.
統一されたディレクトリは、全く異なったテクニックから結果に索引をつけながら結合する傾向があります。 アーキテクチャがインデックスを抑制するべきであるので、可能なままで、異なったプロトコルかインデキシング方式によって行われた2つの検索の結果を合併するのは残っています。URNsなどの標準書式の返品情報はこの問題を助けることができます。
Vocabulary issues in search and index are very difficult. The library and information services communities do not necessarily use vocabulary that is consistent with the IETF community, which can lead to difficult misunderstandings.
検索とインデックスのボキャブラリー問題は非常に難しいです。 図書館情報学共同体は必ずIETF共同体と一致したボキャブラリーを使用するというわけではありません。共同体は難しい誤解に通じることができます。
"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.
「インターネットで検索します」はあなたが捜すのを試みている情報を分類する不適当な試みです。 代わりに、私たちはインターネットのあるパブリックスペースを捜します。 パブリックスペース対インターネットのプライベート・スペースの概念はさらなる調査に値します。
McCahill, et al Informational [Page 21] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[21ページ]RFC1862IAB Workshop Report1995年11月
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. This is 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
5.5 その他
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 seem to imply that the information content of the Internet is uniformly retrievable and manageable. This perception is misleading because most protocols are used for other applications than they were originally designed for. In addition, Telnet, which has no concept of information retrieval and management, is often used to access information as well, for example in DIALOG and card file accesses. Since each protocol has different access and management capabilities, the inconsistencies show up in 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.
電子メール、ネットニュース、FTP、およびウェブは、今日ネットの情報にアクセスするのに頻繁に使用されます。 各プロトコルはインターネットの情報の一貫した意見を提供するように思えます。 追加、モザイクなどのクライアントが思えるマルチプロトコルの最近の人気では、それを含意するために、インターネットの情報量は、一様に回収可能であって、処理しやすいです。 ほとんどのプロトコルがそれらが元々設計されたこと以外のアプリケーションに使用されるので、この知覚は紛らわしいです。 さらに、Telnet(情報検索と管理の概念を全く持っていない)はまた、情報にアクセスするのにしばしば使用されます、例えば、DIALOGとカードファイルアクセスで。 各プロトコルには異なったアクセスと管理能力があるので、矛盾は情報に対処するための標準のテクニックの不安定な検索、検索結果、不可解なエラーメッセージ、および基本的な不足で現れます。 一貫した基本的なインフォメーション・アーキテクチャはこれらの問題を軽減することに向かってはるばる行くでしょう。
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.
グループは、スケジューリング合同作業部会ミーティングにおける困難があったことに注意して、計画をするのを容易にするIETFの中の明確に定義されたプロセスがそのようなミーティングであったならそこでそれを推薦します。
6. Conclusions and Recommendations
6. 結論と推薦
The workshop provided an opportunity for ongoing conversations about the architecture to continue and also provided space for focused examination of some issues and for some new voices and experience from other areas of Internet growth to participate in the architectural process.
ワークショップは、アーキテクチャに関する進行中の会話が続く機会を提供して、また、建築プロセスに参加するためにスペースをインターネットの成長の他の領域から何らかのいくつかの問題の集中している試験と新しい声と経験に提供しました。
McCahill, et al Informational [Page 22] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[22ページ]RFC1862IAB Workshop Report1995年11月
Part of the conclusion of the workshop is a set of recommendations to the IESG and IETF community.
ワークショップの結論の一部がIESGとIETF共同体への1セットの推薦です。
Recommendations on research/implementation directions:
研究/実装方向における推薦:
1. Caching and replication are important and overlooked pieces of Internet middleware. We should do something about it as soon as possible, perhaps by defining an architecture and service model for common implementation.
1. キャッシュと模写は重要で見落とされた片のインターネットミドルウェアです。 私たちはできるだけ早くそれに関して何かをするべきです、恐らく一般的な実装のためにアーキテクチャとサービスモデルを定義することによって。
2. Within the 'wholesale' layer, i.e. within the layer which provides a consistent view of the information resources available on the Internet, the first services that should be provided are:
2. すなわち、'大量'の層、インターネットで利用可能な情報資源の一貫した意見を提供する層の中では、提供されるべきであるファーストサービスは以下の通りです。
* Object retrieval,
* オブジェクト検索
* Name resolution,
* 名前解決
* Caching and replication.
* キャッシュと模写。
3. There would be quick payoff if the raw materials layer, i.e. the layer in which information resources are physically transmitted to computers, could provide the following services:
3. 原料層(すなわち、情報資源が物理的にコンピュータに伝えられる層)が以下のサービスを提供できるなら、迅速な支払いがあるでしょうに:
* 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
4. 情報クライアントの作成者が使用可能なセキュリティーモジュールと多くの異なって、異種のアプリケーションとプラットホームの向こう側に再利用できるサーバを開発してください。
Recommendations to the IESG, IETF, and IANA
IESG、IETF、および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.
1. 分配された情報システム(例えば、Assigned民数記)のドキュメントに正式に定義されて、保たれる数はある種のデータベースでアプリケーションによる使用に有効であるべきです。
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.
2. 情報アプリケーションのデザイナーが使用可能な機密保護モデルを開発して、伝えてください--現在のモデルは、使用可能であることは考えられないか、またはインターネットで広く受け入れられません。
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.
3. セキュリティ問題が、どう書かれている必要があるかに関するアドバイスをRFC作者に与えるべきです。 IESGセキュリティ領域は、セキュリティ問題を書くためにガイドラインを準備するべきです。
McCahill, et al Informational [Page 23] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[23ページ]RFC1862IAB Workshop Report1995年11月
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.
4. 彼らが本当にセキュリティを考えないなら、IESGは提案されたStandardsを受け入れるはずがありません。 これは、推薦2と3が最初に実装されるのを必要とするでしょう。
5. Make clear what security services you can expect from the lower layers.
5. あなたが下層から予想できるすべてのセキュリティー・サービスを明らかにしてください。
6. Make sure that the key distribution infrastructure is reviewed for usability by information applications.
6. 主要な分配インフラストラクチャがユーザビリティのために情報アプリケーションで見直されるのを確実にしてください。
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.
7. プロセスが主要な分配WGがIIIRと一緒に例えば会うことができるように2つのワーキンググループの間の合同会議の計画をするためのIETFの中であるのが必要です。
McCahill, et al Informational [Page 24] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[24ページ]RFC1862IAB Workshop Report1995年11月
APPENDIX A - Workshop Organization
付録A--ワークショップ組織
The workshop was held at MCI's facility in Tyson Corners, Virginia. The workshop organizers and attendees wish to thank MCI for the use of their facilities to host the workshop.
ワークショップはタイソンコーナー、ヴァージニアのMCIの施設で開かれました。 ワークショップオーガナイザーと出席者は、彼らの施設の使用のためのMCIがそのワークショップを主催するのに感謝したがっています。
All attendees met in joint session for the first half of October 12. They then 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.
すべての出席者が10月12日の前半の合同会議で会いました。 そして、彼らは3つのグループに分かれました。 最初のグループはインターネットの地域の設計で幾重にも起こった「分散データベース」問題を考えました。 他の2つのグループが、情報インフラストラクチャに関係する問題のリストを考えるために会いました。 グループを10月14日の朝まで独自に経営していました。(その時、それらは合同会議で再会しました)。
The following people attended the workshop:
以下の人々はワークショップに出席しました:
Abel Weinrib abel@bellcore.com
アベルWeinrib abel@bellcore.com
Barry Leiner BLeiner@ARPA.MIL
バリーLeiner BLeiner@ARPA.MIL
Cecilia Preston cpreston@info.berkeley.edu
シシリアプレストン cpreston@info.berkeley.edu
Chris Weider clw@bunyip.com
クリスワイダー clw@bunyip.com
Christian Huitema Christian.Huitema@SOPHIA.INRIA.FR
クリスチャンのHuitema Christian.Huitema@SOPHIA.INRIA.FR
Cliff Lynch calur@uccmvsa.ucop.edu
クリフリンチ calur@uccmvsa.ucop.edu
Clifford Neuman bcn@isi.edu
クリフォードヌーマン bcn@isi.edu
Dan LaLiberte liberte@ncsa.uiuc.edu
ダンLaLiberte liberte@ncsa.uiuc.edu
Dave Sincoskie sincos@THUMPER.BELLCORE.COM
デーヴSincoskie sincos@THUMPER.BELLCORE.COM
Elise Gerich epg@MERIT.EDU
エリーズGerich epg@MERIT.EDU
Erik Huizer Erik.Huizer@SURFnet.nl
エリックHuizer Erik.Huizer@SURFnet.nl
Jill Foster Jill.Foster@newcastle.ac.uk
ジルフォスター Jill.Foster@newcastle.ac.uk
John Curran jcurran@near.net
ジョンカラン jcurran@near.net
John Klensin klensin@infoods.mit.edu
ジョンKlensin klensin@infoods.mit.edu
John Romkey romkey@asylum.sf.ca.us
ジョンRomkey romkey@asylum.sf.ca.us
Joyce Reynolds jkrey@isi.edu
ジョイスレイノルズ jkrey@isi.edu
McCahill, et al Informational [Page 25] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[25ページ]RFC1862IAB Workshop Report1995年11月
Karen Sollins sollins@lcs.mit.edu
カレンSollins sollins@lcs.mit.edu
Larry Masinter masinter@parc.xerox.com
ラリーMasinter masinter@parc.xerox.com
Lixia Zhang LIXIA@PARC.XEROX.COM
Lixiaチャン LIXIA@PARC.XEROX.COM
Mark McCahill mpm@boombox.micro.umn.edu
マークMcCahill mpm@boombox.micro.umn.edu
Michael Mealling Michael.Mealling@oit.gatech.edu
Michael.Mealling@oit.gatech.edu を荒びきにするマイケル
Mitchell Charity mcharity@lcs.mit.edu
ミッチェルCharity mcharity@lcs.mit.edu
Mike Schwartz schwartz@cs.colorado.edu
マイクシュワルツ schwartz@cs.colorado.edu
Mike St. Johns stjohns@DARPA.MIL
マイク通りジョーンズ stjohns@DARPA.MIL
Mitra mitra@pandora.sf.ca.us
ミトラ mitra@pandora.sf.ca.us
Paul Mockapetris pvm@zephyr.isi.edu
ポールMockapetris pvm@zephyr.isi.edu
Steve Crocker Crocker@TIS.COM
スティーブクロッカー Crocker@TIS.COM
Tim Berners-Lee tbl@info.cern.ch
ティム・バーナーズ・リー tbl@info.cern.ch
Ton Verschuren Ton.Verschuren@surfnet.nl
トンVerschuren Ton.Verschuren@surfnet.nl
Yakov Rekhter yakov@WATSON.IBM.COM
ヤコフRekhter yakov@WATSON.IBM.COM
Security Considerations
セキュリティ問題
This memo discusses certain aspects of security and the information infrastructure. It contains general recommendations about security enhancements required by information applications on the Internet.
このメモはセキュリティのある一定の局面と情報インフラストラクチャについて議論します。 それはインターネットにおける情報アプリケーションで必要であるセキュリティ増進に関して一般的な推薦を含んでいます。
McCahill, et al Informational [Page 26] RFC 1862 IAB Workshop Report November 1995
McCahill、他Informational[26ページ]RFC1862IAB Workshop Report1995年11月
Authors' Addresses
作者のアドレス
Mark McCahill University of Minnesota room 190 Shepherd Labs 100 Union Street SE Minneapolis, MN 55455 EMail: mpm@boombox.micro.umn.edu
McCahillミネソタ大学部屋が190Shepherd Labs100のユニオン・ストリートSEミネアポリス(ミネソタ)55455EMailであるとマークしてください: mpm@boombox.micro.umn.edu
John Romkey [Editor] 1770 Massachusetts Ave. #331 Cambridge, MA 02140 EMail: romkey@apocalypse.org
ジョンRomkey[エディタ]1770マサチューセッツAve。 #331 ケンブリッジ、MA 02140はメールされます: romkey@apocalypse.org
Michael F. Schwartz Department of Computer Science University of Colorado Boulder, CO 80309-0430 EMail: schwartz@cs.colorado.edu
コロラドボウルダーのマイケルF.シュワルツコンピュータサイエンス学部大学、CO80309-0430メール: schwartz@cs.colorado.edu
Karen Sollins MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139-1986 EMail: sollins@lcs.mit.edu
技術の正方形のケンブリッジ、カレンSollins MIT Laboratory for Computer Science545MA02139-1986はメールされます: sollins@lcs.mit.edu
Ton Verschuren SURFNet P.O. Box 19035 3501 DA Utrecht The Netherlands EMail: Ton.Verschuren@surfnet.nl
トンVerschuren SURFNet私書箱19035 3501DAユトレヒトオランダはメールされます: 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
クリスワイダー詐欺師情報システム310セント・キャサリン西Suite300の聖PQ H2A2X1モントリオール(カナダ)はメールされます: clw@bunyip.com
McCahill, et al Informational [Page 27]
McCahill、他のInformational[27ページ]
一覧
スポンサーリンク
