rfc2291.txt

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

        o root member of the graph
        o predecessor member(s)
        o successor member(s)
        o default member of the graph

   It must be possible in some way for a versioning client to access
   versions related to a resource currently being examined.

   5.9.2.7. Version Topology. There must be a way to retrieve the
   complete version topology for a version graph, including information
   about all members of the version graph. The format for this
   information must be standardized so that the basic information can be
   used by all clients. Other specialized formats should be
   accommodated, for servers and clients that require information that
   cannot be included in the standard topology.

   5.9.2.8. A client must be able to propose a version identifier to be
   used for a new member of a version graph. The server may refuse to
   use the client's suggested version identifier.  The server should
   tell the client what version identifier it has assigned to the new
   member of the version graph.

   5.9.2.9. A version identifier must be unique across a version graph.

   5.9.2.10. A client must be able to supply version-specific properties
   to be associated with a new member of a version graph. (See Section
   5.1 "Properties" above.) At a minimum, it must be possible to
   associate comments with the new member, explaining what changes were
   made.

   5.9.2.11. A client must be able to query the server for information
   about a version tree, including which versions are locked, which are
   reserved for editing, and by whom (Session Tracking).

5.9.3. Rationale

   Versioning in the context of the world-wide web offers a variety of
   benefits:

   It provides infrastructure for efficient and controlled management of
   large evolving web sites. Modern configuration management systems are
   built on some form of repository that can track the revision history
   of individual resources, and provide the higher-level tools to manage
   those saved versions. Basic versioning capabilities are required to
   support such systems.






Slein, et. al.               Informational                     [Page 15]

RFC 2291          Distributed Authoring and Versioning     February 1998


   It allows parallel development and update of single resources. Since
   versioning systems register change by creating new objects, they
   enable simultaneous write access by allowing the creation of variant
   versions. Many also provide merge support to ease the reverse
   operation.

   It provides a framework for coordinating changes to resources. While
   specifics vary, most systems provide some method of controlling or
   tracking access to enable collaborative resource development.

   It allows browsing through past and alternative versions of a
   resource.  Frequently the modification and authorship history of a
   resource is critical information in itself.

   It provides stable names that can support externally stored links for
   annotation and link-server support. Both annotation and link servers
   frequently need to store stable references to portions of resources
   that are not under their direct control. By providing stable states
   of resources, version control systems allow not only stable pointers
   into those resources, but also well-defined methods to determine the
   relationships of those states of a resource.

   It allows explicit semantic representation of single resources with
   multiple states. A versioning system directly represents the fact
   that a resource has an explicit history, and a persistent identity
   across the various states it has had during the course of that
   history.

5.10. Variants

   Detailed requirements for variants will be developed in a separate
   document.

5.10.1. Functional Requirements

   It must be possible to send variants to the server, describing the
   relationships between the variants and their parent resource.  In
   addition, it must be possible to write and retrieve variants of
   property labels, property descriptions, and property values.

5.10.2. Rationale

   The HTTP working group is addressing problems of content negotiation
   and retrieval of variants of a resource.  To extend this work to an
   authoring environment, WEBDAV must standardize mechanisms for authors
   to use when submitting variants to a server.  Authors need to be able
   to provide variants in different file or document formats, for
   different uses. They need to provide variants optimized for different



Slein, et. al.               Informational                     [Page 16]

RFC 2291          Distributed Authoring and Versioning     February 1998


   clients and for different output devices.  They need to be able to
   provide variants in different languages in the international
   environment of the Web.  In support of internationalization
   requirements (See 5.12 below), variants need to be supported not just
   for the content of resources, but for any information intended for
   human use, such as property values, labels, and descriptions.

5.11. Security

   5.11.1. Authentication. The WebDAV specification should state how the
   WebDAV extensions interoperate with existing authentication schemes,
   and should make recommendations for using those schemes.

   5.11.2. Access Control. Access control requirements are specified in
   a separate access control work in progress [AC].

   5.11.3. Interoperability with Security Protocols. The WebDAV
   specification must provide a minimal list of security protocols which
   any compliant server / client must support.  These protocols should
   insure the authenticity of messages and the privacy and integrity of
   messages in transit.

5.12. Internationalization

5.12.1. Character Sets and Languages

   Since Web distributed authoring occurs in a multi-lingual
   environment, information intended for user comprehension must conform
   to the IETF Character Set Policy [CHAR].  This policy addresses
   character sets and encodings, and language tagging.

5.12.2. Rationale

   In the international environment of the Internet, it is important to
   insure that any information intended for user comprehension can be
   displayed in a writing system and language agreeable to both the
   client and the server. The information encompassed by this
   requirement includes not only the content of resources, but also such
   things as display names and descriptions of properties, property
   values, and status messages.

6. Acknowledgements

   Our understanding of these issues has emerged as the result of much
   thoughtful discussion, email, and assistance by many people, who
   deserve recognition for their effort.





Slein, et. al.               Informational                     [Page 17]

RFC 2291          Distributed Authoring and Versioning     February 1998


   Terry Allen, [e-mail]
   Alan Babich, FileNet, [e-mail]
   Dylan Barrell, Open Text, [e-mail]
   Barbara Bazemore, PC DOCS, [e-mail]
   Martin Cagan, Continuus Software, [e-mail]
   Steve Carter, Novell, [e-mail]
   Dan Connolly, World Wide Web Consortium, [e-mail]
   Jim Cunningham, Netscape, [e-mail]
   Ron Daniel Jr., Los Alamos National Laboratory, [e-mail]
   Mark Day, Lotus, [e-mail]
   Martin J. Duerst, [e-mail]
   Asad Faizi, Netscape, [e-mail]
   Ron Fein, Microsoft, [e-mail]
   David Fiander, Mortice Kern Systems, [e-mail]
   Roy Fielding, U.C. Irvine, [e-mail]
   Mark Fisher, Thomson Consumer Electronics, [e-mail]
   Yaron Y. Goland, Microsoft, [e-mail]
   Phill Hallam-Baker, MIT, [e-mail]
   Dennis Hamilton, Xerox PARC, [e-mail]
   Andre van der Hoek, University of Colorado, Boulder,
     [e-mail]
   Del Jensen, Novell, [e-mail]
   Gail Kaiser, Columbia University, [e-mail]
   Rohit Khare, World Wide Web Consortium, [e-mail]
   Ora Lassila, Nokia Research Center, [e-mail]
   Ben Laurie, A.L. Digital, [e-mail]
   Mike Little, Bellcore, [e-mail]
   Dave Long, America Online, [e-mail]
   Larry Masinter, Xerox PARC, [e-mail]
   Murray Maloney, SoftQuad, [e-mail]
   Jim Miller, World Wide Web Consortium, [e-mail]
   Howard S. Modell, Boeing, [e-mail]
   Keith Moore, University of Tennessee, Knoxville, [e-mail]
   Henrik Frystyk Nielsen, World Wide Web Consortium, [e-mail]
   Jon Radoff, NovaLink, [e-mail]
   Alan Robertson, [e-mail]
   Henry Sanders, Microsoft,
   Andrew Schulert, Microsoft, [e-mail]
   Christopher Seiwald, Perforce Software, [e-mail]
   Einar Stefferud, [e-mail]
   Richard Taylor, U.C. Irvine, [e-mail]
   Robert Thau, MIT, [e-mail]
   Sankar Virdhagriswaran, [e-mail]
   Dan Whelan, FileNet, [e-mail]
   Gregory J. Woodhouse, [e-mail]






Slein, et. al.               Informational                     [Page 18]

RFC 2291          Distributed Authoring and Versioning     February 1998


7. References

   [AC] J. Radoff, "Requirements for Access Control within Distributed
   Authoring and Versioning Environments on the World Wide Web",
   unpublished manuscript, <http://lists.w3.org/Archives/Public/w3c-
   dist-auth/1997AprJun/0183.html>

   [CHAR] Alvestrand, H., "IETF Policy on Character Sets and Languages",
   RFC 2277, January 1998.

   [CM] P. Feiler, "Configuration Management Models in Commercial
   Environments", Software Engineering Institute Technical Report
   CMU/SEI-91-TR-7,
   <http://www.sei.cmu.edu/products/publications/91.reports/91.tr.007.html>

   [HTML] Berners-Lee, T., and  D. Connolly, "HyperText Markup Language
   Specification - 2.0", RFC 1866, November 1995.

   [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
   Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068,
   January 1997.

   [ISO 10646] ISO/IEC 10646-1:1993. "International Standard --
   Information Technology -- Universal Multiple-Octet Coded Character
   Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane."

   [URL] Berners-Lee, T., Masinter, L., and M. McCahill. "Uniform
   Resource Locators (URL)", RFC 1738, December 1994.

   [VSE] A. Haake, D. Hicks, "VerSE: Towards Hypertext Versioning
   Styles", Proc. Hypertext'96, The Seventh ACM Conference on Hypertext,
   1996, pages 224-234.



















Slein, et. al.               Informational                     [Page 19]

RFC 2291          Distributed Authoring and Versioning     February 1998


8. Authors' Addresses

   Judith Slein
   Xerox Corporation
   800 Phillips Road 128-29E
   Webster, NY 14580

   EMail: [e-mail]


   Fabio Vitali
   Department of Computer Science
   University of Bologna
   ITALY

   EMail: [e-mail]


   E. James Whitehead, Jr.
   Department of Information and Computer Science
   University of California
   Irvine, CA 92697-3425

   Fax: [phone]
   EMail: [e-mail]


   David G. Durand
   Department of Computer Science
   Boston University
   Boston, MA

   EMail: [e-mail]


















Slein, et. al.               Informational                     [Page 20]

RFC 2291          Distributed Authoring and Versioning     February 1998


9.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Slein, et. al.               Informational                     [Page 21]