rfc1862.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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

   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.

   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:

        1. Connectivity

        2. Bandwidth, latency, and reliability or service envelope



McCahill, et al              Informational                     [Page 17]

RFC 1862                  IAB Workshop Report              November 1995


        3. Security constraints on communication and transactions

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

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

   Group 2B 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).

   The group discussed the following topics:

   access(URL)

   gateways

   URN resolution

   definitions

   updates

   service location

   cache & replication

   security & authentication

   payments, charging

   presentation

   search & index

   metainformation

   boot service

   general computation




McCahill, et al              Informational                     [Page 18]

RFC 1862                  IAB Workshop Report              November 1995


5.1 URNs

   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.

   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.

   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.

5.2 Global Service Location

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

5.3 Security

   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


   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.

   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:

   A. Develop and communicate a security model usable by designers of
   information applications - current models are not considered usable.

   B. RFC authors should be given advice on what security considerations
   need to be outlined and how to write them. The IESG security area
   should prepare guidelines for writing security considerations.

   C. Proposed Standards should not be accepted by the IESG unless they
   really consider security. This will require that recommendations A
   and B have been implemented and that the guidelines have received
   enough visibility to reasonably expect authors to know of their
   existence.

   D. Develop security modules usable by the implementors of information
   clients and servers - reusable across many different, heterogeneous
   applications and platforms.

   E. Make clear what security services you can expect from the lower
   layers.

   F. Make sure that the key distribution infrastructure is reviewed for
   usability by information applications.



McCahill, et al              Informational                     [Page 20]

RFC 1862                  IAB Workshop Report              November 1995


5.4 Search and Index

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

   Indexing is currently done on the Internet via many mechanisms. Given
   the current ad hoc nature of 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.

   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.

   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.

   "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


   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

   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.

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