OSF DCE SIG W. Tuvell (OSF) Request For Comments: 0.0 May 1992 INTRODUCTION TO DCE-RFC'S (Required Reading for All Users) 1. INTRODUCTION The DCE-RFC series of technical notes is intended as an "online forum" for the Open Software Foundation's Distributed Computing Environment Special Interest Group[1] to share information about the DCE and related technologies. It is inspired by and in many ways intended to resemble its highly successful precursor, the Internet- RFC series. In the taxonomy of communications amongst OSF and the DCE SIG, DCE- RFC's occupy an intermediate position of finality and formality, somewhere between email and official publications. Thus even though the DCE-RFC series is oriented more toward inclusivity than exclusivity, initial brainstorming and inconclusive debate are not good candidates for the series, nor are the materials distributed as part of the DCE offering (source code, tests, documentation, AES, validation suite, etc.). This note, the first DCE-RFC, discusses the fundamental facts about this series and is considered required reading for all users of this series. It builds on the experience of Internet-RFC's by assuming familiarity with them and focusing on the similarities and dissimilarities between the two series of notes. 2. REQUIREMENTS FOR THIS SERIES For the original "statement of need" to OSF by the DCE SIG, dating from March 1991, see Appendix A.[2] __________ 1. By the "DCE SIG", we always mean the broad interpretation of "all persons affiliated with all member organizations of OSF, including OSF itself, who are interested in DCE", not just the narrow interpretation of "people who attend the DCE SIG meetings". 2. The reason the DCE-RFC series has not been implemented before now is that the potential notes for the series were formerly based on DCE Snapshots, and therefore were not considered of broadly general interest and value. Now that DCE 1.0 has shipped (in January 1992), conditions Tuvell Page 1 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 2.1. Why a New Series? It is a legitimate question why a new series of RFC's is being started for DCE, instead of just submitting DCE-related RFC's to the Internet series. The main reasons are the following. (a) The DCE-RFC series exists primarily as a convenience and service for the DCE SIG, for whom it is convenient to keep the DCE-RFC's all together in a centralized place without burdening SIG members with monitoring Internet-RFC's for those notes that might be related to DCE. (b) DCE is envisioned as the infrastructure for a major technology paradigm, ultimately approaching the size of the Internet paradigm itself, so submitting DCE-RFC's to the Internet-RFC series would tend to make the Internet series disproportionately top-heavy with DCE notes. (c) The Internet-RFC's are primarily concerned with the Internet protocol suite, especially at the transport level and below, together with certain other protocols layered directly on the transport protocol. DCE-RFC's, on the other hand, are primarily concerned with the higher protocol layer afforded by the DCE RPC technology (which is intended to be transport layer independent, not particularly tied to Internet protocols), together with other protocols layered upon it. (d) The industry expertise on DCE resides within the DCE SIG, not within the greater Internet community, and diluting the focus of DCE activity away from the DCE SIG would be counterproductive. (e) There is a certain amount of "Internet ownership" associated with the Internet-RFC series, in the sense that the Internet community maintains a standardization process closely associated with the Internet-RFC series, but it is desirable that "ownership" of DCE be retained by OSF and that it not be tightly bound to the DCE-RFC series. 2.2. Comparison and Contrast with Internet-RFC's This document assumes that the reader is familiar with, and has access to, the Internet-RFC series.[3] In particular, the following ________________________________________________________________________ are considered right to implement the DCE-RFC series. 3. Quick reminder on how to obtain Internet-RFC's: (1) "ftp nic.ddn.mil", user "anonymous", password "guest", "cd rfc", "get rfc- Tuvell Page 2 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 Internet-RFC's are especially relevant here. The information contained in them is used liberally in this document without further explicit reference. (a) The basic rules for Internet-RFC's are laid out in [RFC 1111]. (b) The Internet Activities Board's view of Internet-RFC's is given in [RFC 1160, section 2]. (c) A tutorial introduction to Internet-RFC's is given in [RFC 1206, section 6]. (d) The Internet standardization process and its relationship to Internet-RFC's is explained in [RFC 1200, sections 1 and 2] and [RFC 1310, section 2.3]. (e) A historical perspective on the Internet-RFC series is given in [RFC 1000, section entitled "The Origins of RFC's"]. (f) Another summary of the Internet-RFC process is given in [RFC 1118, section entitled "RFC's"]. These basic references taken together are understood to embody the "spirit" of the Internet-RFC series. Unless explicitly stated otherwise in this document, DCE-RFC's are understood to participate in a similar spirit. 3. MANAGEMENT OF THE DCE-RFC SERIES 3.1. RFC Editor The DCE-RFC Editor performs a function analogous to that of the Internet-RFC Editor. The Editor: (1) attempts to maintain the quality of the series, (2) manages its archiving and announcements, and (3) encourages a consistent style (namely, the one exhibited in the present DCE-RFC). The decision of which documents are accepted into the series is that of the Editor. As a rule, documents meeting prevailing standards of relevance, quality and style will be accepted. ________________________________________________________________________ index.txt", follow directions contained therein; (2) "mail service@nic.ddn.mil", "Subject: help" (null body), follow directions in the reply. Tuvell Page 3 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 DCE-RFC's must be submitted to the Editor in markup language format (see below). The Editor also assigns the actual DCE-RFC number (see below). The current DCE-RFC Editor is always the author of the current reissue of DCE-RFC 0. 3.2. Numbering Scheme Internet-RFC's are numbered with a single decimal number, and when they are reissued or updated they acquire a new number. In contrast, DCE-RFC's are numbered with a pair of decimal numbers, a "major" number "M" and a "minor" number "m" separated by a decimal point. This numbering syntax has the advantage of tracking the lineage of DCE-RFC's in a cleaner manner. Thus, the "official" names look something like: DCE-RFC M.m When they are reissued or updated they (usually) retain the same major number while the minor number is incremented: DCE-RFC M.m+1 The truncated name "DCE-RFC M" is shorthand for the most recent reissue (highest minor number) of the DCE-RFC having major number M. Thus, the present document is "DCE-RFC 0". 3.3. Obtaining DCE-RFC's Currently, DCE-RFC's are distributed by the following methods. (a) Internet FTP.[4] This is the primary retrieval method for any site that has FTP connectivity to the DCE-RFC FTP archive machine. (i) Open an FTP session with the DCE-RFC FTP archive machine: "ftp grabbag.osf.org".[5] The user is "dce-rfc", and the password is also "dce-rfc". __________ 4. Unlike Internet-RFC's, DCE-RFC's are not distributed via Kermit. 5. The Internet address of this machine is currently "130.105.100.2". Tuvell Page 4 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 (ii) Change directory context to the DCE-RFC directory: "cd dce-rfc". (iii) Issue normal FTP commands (e.g., "ls", "get") to retrieve the files you want. Typically you would start with "rfc-index.txt" to find the right reference to the exact DCE-RFC you want -- in particular, its most recent reissue number and filename (see below). (b) Internet email server. This is an alternative retrieval method, for sites that do not have FTP connectivity to the DCE-RFC FTP archive machine, but do have Internet email connectivity (perhaps through a mail gateway) to the DCE-RFC Internet email server. (i) Send mail to the DCE-RFC Internet email server: "mail dce-rfc-archive@osf.org".[6] The "Subject:" line should be null. (ii) In the body of the message, specify (on a line by itself) the email address to which the reply should be sent (this helps thwart the addressing eccentricities of some email gateways): "path ". (iii) To retrieve a file (e.g., "rfc-index.txt"), specify (on a line by itself): "send rfc ". Multiple files can be specified, either on multiple lines or as a blank-separated list of filenames. (iv) To find out more about the email archive service, specify (on a line by itself): "help".[7] (c) Special distribution. Requests for special distribution (e.g., hardcopy, or a specially formatted electronic copy) should be addressed to the author of the RFC in question. OSF does not provide these services. In the future it is anticipated that other distribution methods will be supported (e.g., a DCE RPC server, or a DCE DFS archive). In particular, note that the current distribution schemes do not support strong access controls, even though distribution is intended to be __________ 6. For UUCP, use "...!{uunet|...}!osf.org!dce-rfc-archive". 7. The DCE-RFC email archive service is a piece of a more general email archive service supported by OSF, and the "help" request refers to this more general service. Tuvell Page 5 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 limited to the DCE SIG. Whether or not strong access controls will be enforced when future technology supports it remains a subject for further study. 3.3.1. Filenames The filenames identifying DCE-RFC's (i.e., the names to specify when obtaining RFC's by the above distribution methods) have "extensions" indicating their formats (see below): (a) Roff format: "rfcM.m.roff" (b) Text format: "rfcM.m.txt" (c) PostScript format: "rfcM.m.ps" The relationships among these formats are the obvious ones:[8] (a) nroff -Tlpr rfcM.m.roff > rfcM.m.txt (b) troff -Tps rfcM.m.roff | > rfcM.m.ps 3.3.2. Index An index of DCE-RFC's is also maintained (in the same distribution centers as the RFC's themselves) by the RFC Editor. Its filename is "rfc-index.txt". 3.4. Announcement List The RFC Editor sends an announcement of each new DCE-RFC to the Internet email list "sig-dce@osf.org". To get on this list, send mail to "sig-dce-request@osf.org". 3.5. No Standardization Process Internet-RFC's have a highly-developed relationship with the Internet standardization process. Experimental protocols and proposed standards are published as (possibly draft) Internet-RFC's and are subject to "commentary" before they progress along the standardization track, and all Internet standards are disseminated as Internet-RFC's. __________ 8. In this document, "troff" denotes the so-called "device-independent" "troff", sometimes known as "ditroff". The "ps-post-processor" mentioned here is a post-processing filter which converts "ditroff" intermediate code to PostScript code. Tuvell Page 6 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 DCE-RFC's have no such necessary relationship with the OSF DCE offering (which is the moral equivalent of an Internet standard). Thus for example, there is no commitment that components to be included in future releases of the DCE will be debated via DCE-RFC's, nor is the DCE-RFC series intended as an avenue for publication of the documentation for the DCE offering, nor for the DCE AES. 3.6. Disclaimers This section briefly addresses the legal issues surrounding the DCE- RFC series.[9] Informally paraphrased in ordinary English: If somebody at Organization ABC writes a DCE-RFC that somebody at Organization XYZ has a problem with, then those folks should settle their differences themselves and shouldn't sue OSF -- i.e., "Don't shoot the messenger", "Use at your own risk", etc. A little more formally: (a) Although OSF is willing to administer this DCE-RFC publishing service, OSF's decision to publish any DCE-RFC does not mean that OSF endorses any opinions expressed, or vouches for the accuracy of any information contained in the DCE-RFC. (b) OSF disclaims any liability arising from anyone's use of the DCE-RFC's (including any infringement of intellectual property rights), or from reliance on the information they contain. Users must assume all risks arising from their use of DCE- RFC's. (c) The DCE-RFC publishing service is not intended to convey any confidential information. Therefore, each submitter is solely responsible for the consequences of submitting confidential information to OSF for publication. Also, each submitter is solely responsible for incorporating any appropriate copyright notices. (d) OSF reserves the right to defend itself in any litigation arising from the DCE-RFC series, and to attempt to recover losses from any resulting claims. __________ 9. In all likelihood, of course, this section will turn out to be purely precautionary, and will never actually have to be invoked in a legal proceeding! Tuvell Page 7 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 There are precedents that say these are reasonable expectations for electronic bulletin boards. But in any event, OSF requires no legally binding instruments to be executed for participation in the DCE-RFC forum, these Disclaimers notwithstanding (i.e., the legal options of participants remain open). 4. FORMAT AND STYLE OF DCE-RFC'S Like Internet-RFC's, DCE-RFC's allow for multiple distribution formats, each embodied in a single character file (expressed in the English language, and encoded in ASCII). Actually, the supported formats come as both markup and formatted files, and there are currently three supported formats: (a) Roff. This is the only (currently) supported markup format. It supports both text and/or PostScript formatted files (see below). (b) Text. This is the "normal" format, because it is as close as we (currently) have to a lingua franca interchange format, and because it can be used with online tools (text editors/viewers, "grep"/"awk", etc.). (c) PostScript. This format should be used if sophisticated formatting capabilities (e.g., graphics) are required. Unlike Internet-RFC's, DCE-RFC's can be distributed as markup language files (e.g., the roff format) because most of the target audience (DCE SIG members) have access to the necessary formatting tools (e.g., "nroff" and "troff", with "mm" macros). Markup language versions allow local customization for those who do not like the supported formatted versions (e.g., text, PostScript). In addition, other common tools associated with a given markup suite (e.g., "tbl", "eqn", "pic" for the roff class) are acceptable.[10] Additional tools may become acceptable in the future (e.g., TEX, or a standard semantic markup language that may be adopted by OSF). The formatted distribution files (e.g., text, PostScript) are supported for quick hassle-free screen and offprinting convenience for the majority of the DCE SIG membership, as well as for those who do not have access to the necessary formatting tools. __________ 10. The requisite formatting command(s) (possibly a pipeline, with options) must be specified as a comment in the markup file, especially if some of these additional tools are used. Tuvell Page 8 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 As mentioned above, if the supported distribution formats do not satisfy a reader's requirements, a special distribution request may be addressed to the author of a given RFC. 4.1. Roff Style Guide Template The roff version of a DCE-RFC is the one that an author submits to the Editor. It supports either the text or PostScript version of the DCE-RFC, or (preferably) both (at the author's option, as specified in a format comment near the top of the roff file). Thus the roff version is supported in the archives for every DCE-RFC (whereas one of the formatted versions may be optional), and can be modified to support local customization conventions. The roff version of this document (DCE-RFC 0), which does support both text and PostScript formats, serves as a required style-guide template for all DCE-RFC's. 4.2. Text Format/Style Internet-RFC's in their text format have a distinctive "look and feel" which is effective at facilitating information transfer (clean and versatile, sophisticated yet not fussy). This has been emulated by DCE-RFC's with a few minor changes for the convenience of the intended audience (the DCE SIG). (a) Standard page size is 66 rows by 80 columns. (b) A consistent header and footer style, section and list numbering, indentation scheme (based on multiples of 3 and 6), etc., is enforced via the roff template by the "mm" macro package.[11] (c) Keep it simple. We want to allow common online tools (text editors/viewers, "grep"/"awk", etc.) to work on the formatted document. For example: (i) No backspaces, tabs, form feeds, control characters, underlining, overstriking, or other "special effects". __________ 11. The Internet-RFC series uses the more primitive "ms" macro package, but "mm" is much closer to the ideal of what a full-featured markup language (or at least, macro package) "should be", and as such represents the direction future developments in text processing are more likely to take. Tuvell Page 9 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 (ii) No line adjustment (= filling, right justification, hyphenation). (iii) No "tbl", "eqn", "pic" or other auxiliary tools ("typewriter art" is okay though). (d) Footnotes are acceptable, because they are useful (sort of a primitive hypertext) and because the resulting text file satisfies all our other requirements (no control characters, etc.).[12] 4.3. PostScript Format/Style Internet-RFC's in the PostScript format do not present so large a body of "established practice" as the text format does, but the following guidelines should nevertheless prove serviceable for DCE- RFC's. (a) Standard page size is 8.5 by 11 inches. (b) In addition to the things listed for the text format/style (above), a consistent point size and line spacing, font selection (Times, Courier, Helvetica, Special), hyphenation, line adjustment, etc., is enforced via the roff template by the "mm" macro package. (c) Keep it relatively simple. Lowest common denominator PostScript features should be used, because of varying PostScript printer capabilities. In particular, the following PostScript commands should not be used: banddevice, copypage, erasepage, framedevice, grestoreall, initclip, initgraphics, initmatrix, nulldevice, renderbands 4.4. RFC Header; Page Header and Footer; Drafts No cover page is employed on DCE-RFC's, but the top of the first page does contain some important header information: the RFC number, author's name, author's affiliation, date, "relation to other RFC's" (below), and title. This information is repeated in the page header and footer information on each page. __________ 12. As a stylistic convention in the text format, footnotes are indicated in running text by a number enclosed in square brackets (in the PostScript format, superscripts are used). References, on the other hand, are indicated by a mnemonic string enclosed in square brackets. Tuvell Page 10 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 On occasion, it may be convenient to post a "draft" DCE-RFC, i.e., one which is intended to be finalized after a specified review period.[13] Such drafts are marked as such in the page footer. 4.4.1. Relation to other RFC's Internet-RFC's use the keywords "updates" and "obsoletes" (formerly, "supersedes" and "replaces") to indicate certain relations among RFC's. These occur in the RFC header information, and in the RFC index (where "obsoleted-by" and "updated-by" are also used). These notations serve a useful purpose, and are adopted for DCE- RFC's. To the extent feasible, the major-minor numbering scheme is used as a collectivizing mechanism for RFC's that are related to one another (namely, closely related RFC's have the same major number). 4.5. No Page Numbers: Author's Divisions Instead Internal references within a DCE-RFC, as well as external references to other DCE-RFC's, should not contain any page numbers, because of the distribution in markup language (namely, a customized page length or line length or font size, etc., would alter page numbering). Instead of page numbers, all references should be based on the "author's divisions" (dotted section numbers), so authors have the responsibility to apply these appropriately (it's good to have at least one numbered division per page). 4.6. Introduction Section The first section of each DCE-RFC should be an introduction to its contents, and should place it in the context of other RFC's and other literature. 4.6.1. Table of contents DCE-RFC's should not contain a table of contents that includes page numbers, though an outline-only table of contents is okay if the author desires it (it should only be necessary for very long RFC's). If such a table of contents is included, it should occur as a __________ 13. A draft cycle for a DCE-RFC is an exception rather than the rule, and relies on the discretion of the Editor. In the normal course of events, the topic of a DCE-RFC is debated amongst a select group of interested participants (perhaps via a privately circulated series of drafts) and attains a certain degree of finality before it is submitted to the DCE-RFC series. Tuvell Page 11 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 subsection of the introduction section. 4.7. No Status Statement Each Internet-RFC must include a "status of this memo" section which conveys the status granted the RFC by the Editor and the Internet Activities Board. Suggested status classifications are: "proposed protocol", "specification" (i.e., standard), "discussion", "information", and "status". DCE-RFC's do not have a similar formal status associated with them, therefore no status statement is required.[14] (Alternatively all DCE-RFC's may be viewed as corresponding to the Internet-RFC "discussion" and "information" classes.) While it is true the author of a DCE-RFC may have any of a number of ideas in mind about how the RFC will be received and responded to, it is the author's responsibility to make this known in the document without the formality of a status statement. 4.8. No Distribution Statement Each Internet-RFC must include a distribution statement, indicating whether its distribution is to be limited in some way. DCE-RFC's always have an unlimited scope of distribution (within the DCE SIG, of course), therefore they do not require a distribution statement. 4.9. No Security Statement Internet-RFC's are required to have an explicit statement expressing the security aspects (authentication, protected communication, authorization, etc.) of the technology described by the RFC.[15] Often enough, this turns out to be a null statement. There is no such hard requirement for DCE-RFC's. It is however assumed that because of the integral nature of the DCE security __________ 14. If experience indicates the status scheme is a good idea, it can be added in the future. 15. The exact source of this requirement is somewhat obscure. "Security Considerations" sections started appearing spontaneously in Internet- RFC's in late 1989, but are not required by [RFC 1111]. The first statement of such a requirement occurs in [RFC 1150], but as articulated there it applies only to Internet-FYI's, not all RFC's. A similar comment applies to Internet-STD's (see [RFC 1311]). Tuvell Page 12 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 services, security considerations are important for very many RFC's, and therefore are to be treated by the author of the RFC as a simple matter of course. 4.10. Acknowledgements, Appendices, References Acknowledgements, appendices and references, if any, should be included (in that order) following the body of the RFC. Acknowledgements should always include organizational affiliation. 4.11. Author's Address Each Internet-RFC must have at the very end a section giving the address(es) of author(s), including name and postal address, telephone number, and Internet email address. This section is required so that "Comments" to the "Request for Comments" may be addressed to the author(s) by readers of the RFC. This convention is a very useful one, and so is adopted for DCE- RFC's. 5. ACKNOWLEDGEMENTS General thanks are due to the whole membership of the DCE SIG, for their dedication to the success of DCE, which created and recognized the need for the DCE-RFC series. Particular thanks are due to Sumner Blount (DEC), chair of the DCE SIG, for his support of the DCE-RFC concept, and to Richard Curtis (HP) and especially Ittai Hershman (then of NYU), members of the DCE SIG, for their early analysis and design of the role of DCE-RFC's. Thanks are also due to Brad Johnson (OSF) for his initial investigations into the efficacy of a DCE-RFC mechanism, preceding even the SIG's interest in this area. Finally, an enormous debt of gratitude is owed, not only by OSF but by the entire computer industry, to the Internet community, for their pioneering technical work in networking and interoperability, and their generosity in sharing that work through the Internet-RFC series. The DCE community can do no better than strive to emulate their continuing leadership. APPENDIX A. STATEMENT OF NEED BY THE DCE SIG The following original "statement of need" for DCE-RFC's was delivered to OSF by the DCE SIG in March 1991. It has been edited slightly for inclusion here. Tuvell Page 13 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 A.1. `An RFC Process for the OSF DCE SIG', by Ittai Hershman At the March 1991 meeting of the DCE SIG, we proposed to initiate a process by which interested parties could publish ideas and proposals regarding DCE, for comment by the DCE community. A similar process has been enormously successful in the ARPANET/Internet community based on RFC (Request For Comments) documents. Just as the ARPANET paved the way for wide-scale computer networking, DCE is breaking new ground in how networked computers are used. As such, DCE is an "enabling technology" which has the potential to revolutionize the computer industry. In order to achieve that level of success, it is incumbent upon the OSF and its members to foster and promote technological innovation leveraged off the DCE technologies: not just the set of DCE internal technologies themselves. In its short history, the Open Software Foundation has established itself as a forum for industry cooperation, even to non-members, through the RFT process. The OSF has also recognized the importance of investment in the academic world through the Research Institute (RI). Both the RFT process and the RI, however, are OSF-initiated and concern themselves with fairly broad granularity topics. During the March meeting, it became evident that there are already many ideas floating around about how to use DCE technologies to solve problems other than those expressed in the original DCE RFT and that specific low-granularity problems can frequently be solved using various (perhaps mutually exclusive) methods. No process currently exists for DCE licensees and vendors to propose and experiment with these methods in any collaborative manner. Furthermore, as DCE is implemented -- especially within the research and education community -- many individuals will develop technologies, tools, utilities, and applications which may be valuable to others. An RFC process similar to that employed by the Internet community, would promote the voicing of ideas and methods, collaborative experimentation, and the sharing of new technologies. The rousing success of TCP/IP is largely due to the inclusion of innovative ideas not thought of by its original creators. This occurred largely through the RFC process; we envision that much the same will happen with DCE. As Douglas Comer well states in his seminal book [COMER]: Unlike scholarly scientific journals that concentrate on identifying papers of important archival interest, screening them carefully, and filing them for posterity, RFC's provide a record of ongoing conversations among the principals involved in designing, building, measuring and using the ARPANET and, later, the connected Internet. The reader understands at once Tuvell Page 14 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 that RFC's include the thoughts of researchers on the leading edge of technological innovation, not the studied opinions of scholars who have completely mastered a subject. The authors are not always sure of the consequences of their proposals, or even of the contents, but they clearly realize the issues are too complex to understand without community discussion. As the Internet has matured, so has the RFC process. In particular, RFC's can now be submitted on two tracks: proposed standards and more experimental proposals. The Proposed Standards track follows a rigorous committee review process, while all other RFC's are assigned numbers and announced by the RFC Editor. Anybody can write an RFC. RFC's are "published" online and are generally obtained by anonymous FTP. In the case of OSF and DCE, standardization would not be within the purview of the RFC process as it would violate pre-existing OSF processes for selection and standardization. This simplifies the RFC process considerably: all that is needed, therefore, is an RFC Editor and an FTP archive site. The RFC Editor should be limited to an administrative function: assigning numbers, copying into the archive, and announcing availability. The OSF would support this function just as it presently deals with mailing lists and other such administrivia. An RFC process is simply a tool for structured informal conversations of technical concepts, ideas, and proposed solutions. The DCE community stands to gain a great deal by adopting a DCE-RFC process. REFERENCES [COMER] D. Comer, "Internetworking with TCP/IP", v. 1, 2nd ed., Prentice Hall, 1991. [RFC 1000] J. Reynolds, J. Postel, "The Request for Comments Reference Guide", August 1987. [RFC 1111] J. Postel, "Request for Comments on Request for Comments, Instructions to RFC Authors", August 1989. [RFC 1118] E. Krol, "The Hitchhiker's Guide to the Internet", September 1989. [RFC 1150] G. Malkin, J. Reynolds, "F.Y.I. on F.Y.I., Introduction to the F.Y.I. Notes", March 1990. [RFC 1160] V. Cerf, "The Internet Activities Board", May 1990. [RFC 1200] Internet Activities Board (J. Postel, Editor), "IAB Official Protocol Standards", April 1991. Tuvell Page 15 DCE-RFC 0.0 Introduction to DCE-RFC's May 1992 [RFC 1206] G. Malkin, A. Marine, "FYI on Questions and Answers, Answers to Commonly Asked `New Internet User' Questions", February 1991. [RFC 1310] Internet Activities Board (L. Chapin, Chair), "The Internet Standards Process", March 1992. [RFC 1311] Internet Activities Board (J. Postel, Editor), "Introduction to the STD Notes", March 1992. AUTHOR'S ADDRESS Walter Tuvell Internet email: walt@osf.org Open Software Foundation Telephone: +1-617-621-8764 11 Cambridge Center Cambridge, MA 02142 USA Tuvell Page 16